F5 and Containerization

Organizations constantly struggle between embracing technological changes to open up new business opportunities and protecting the business from new challenges and risks. In this paper, we’ll examine containerization and how the adoption of this technology in F5 products affects IT professionals, architects, and business decision makers.

In the last 20 years, virtualization has transformed server computing, enabling multiple separate operating systems to run on one hardware platform. A more modern approach is containerization (or operating system virtualization), which enables multiple apps to run on a single instance of a host operating system. Each app instance then shares the binaries and libraries installed into the single operating system instance. Figure 1 compares these approaches.

Unlike virtual machines (VMs), containers can share the same operating system, virtualizing at the OS level, rather than the hypervisor level.

Not surprisingly, developers like containers because they make developing and deploying applications and spinning up microservices quick and easy. Containerization also enables greater portability, as apps in containers are easier to deploy to different operating systems, hardware platforms, and cloud services. Containers use up fewer resources than applications running directly on bare metal-hosted operating systems or on virtual machines.

Generally, most of the discussion (and documentation) about containers focuses on the programming or DevOps perspective. As an IT professional, system architect, or business decision maker, while you appreciate the flexibility that containerization can bring, you may have genuine concerns about how this change will affect administration, management, and monitoring of apps and services within your environment. You also want to ensure that containerization does not adversely affect network and app security.

In an increasingly competitive market, modern IT systems must deliver realizable business benefits. To deliver on this requirement, it is vital that IT departments can grow their application capital, designing and creating architectures which feature not just more apps, but apps with greater functionality, enhanced usability, and easier integration.

The challenge for IT directors is that their departments must deliver greater functionality without enlarging headcount. Improvements to productivity now come, not from hiring more people, but from advances in technology and automation that enable increasing the number of apps available to customers, managed by the same-sized team.

Ease of container deployment presents a further challenge. Developers need education and guidance to ensure that they consider both scale and security when creating applications and IT professionals can help them achieve those outputs. Here, you need to think about the impact on production from container platforms such as Kubernetes and Docker, and how the need to be agile does not result in undesirable outcomes from poor security practice or failure to consider production loads. 

A key factor in delivering realizable business benefits is minimizing time to value. Increasingly, factors such as performance and latency take a back seat with respect to ease of insertion. In consequence, if you have two components, both of which have nearly identical functionality, but one has higher performance whereas the other is easier to integrate, organizations tend to choose the component that is easier to integrate with the current environment. As environmental complexity rises, this bias is likely to continue.

When looking to implement a technology such as containerization, you need some way of measuring the value that this new approach brings. The factors that affect value would typically include suitability, capability, effort, and cost. The following equation gives an example of how to assign relative value based on those factors.

The units that you use in the equation are irrelevant; what is important is that they are the same for each item that you evaluate.

This equation highlights that technology must be seamless to integrate and that familiarity (that is, ease of insertion) can be more important than best-in-class features or performance. In consequence, deployment effort has a balancing effect when it comes to overall value calculations, which can result in less capable products being more appealing to customers due to their ease of insertion.

An example of this effect might be with two competing monitoring solutions. Product A has fantastic specifications, with best-in-class logging and reporting. It incorporates military-grade security and is highly manageable. Unfortunately, its proprietary command-line interface, poor support for open standards, and lack of integration features make it difficult to install. It is also more expensive than most other products on the market.

In comparison, Product B has nowhere near the capabilities of its rival, albeit still providing acceptable levels of monitoring and security. However, it scores over the competing product when it comes to both cost and ease of installation. Tabulating the scores for each product produces the table below, with marks awarded from 1 to 10 for suitability, capability, and installation effort, with 1 as the lowest and 10 as the highest.

Plugging these figures into the equation above produces the value score listed in the bottom row of the table.

You can see how the less suitable and capable product that is five times easier to install at half the price delivers an estimated three times the value compared to its best-of-breed rival. Many organizations understand these considerations and are increasingly using ease of installation and integration as a key factor when adopting and deploying new technologies. Container-based approaches can significantly reduce deployment effort and control costs while also maintaining both suitability and capability.

With apps increasingly driving business value, containerization provides a logical solution to the challenges of DevOps-centric IT implementation practices. Containers provide isolation from the platform on which they run and from each other without the management overhead of running virtual machines. Developers can easily spin up app environments that contain all the binaries and libraries that they need, with the required networking and management facilities built in. Containerization also simplifies application testing and deployment.

Container-based environments provide greater resource utilization than virtual computers by massively scaling up the number of application instances that can run on a server. Without the overhead of both host and guest operating systems, container environments make more efficient use of processor time and memory space by sharing the operating system kernel. Containerization also gives more architectural flexibility, as the underlying platform can be either a virtual machine or a physical server. Red Hat Product Strategy¹ indicates that nearly half of Kubernetes customers deploying apps into containers in the future will run the container engine directly on bare metal.

Containerization provides the next advancement in the road from hardware-based computing to virtualization to multi-cloud, enabling up to 100% automation, sub-second service creation times, and service lifetimes that can be measured in seconds. It is this immediate provisioning and deprovisioning of services and microservices within a modern IT architecture that container environments such as Docker, OpenShift, and Kubernetes enable.

Importantly, containerization delivers a key benefit that is vital in today’s multi-platform and multi-cloud world—the ability to port apps from on-premises to cloud, to another cloud vendor, and back to on-premises again, all without changes to the underlying code. With interoperability being a key factor underpinning architectural decisions, this portability enables IT departments to achieve key milestones for app services deployments and supports DevOps teams in meeting organizational goals. A recent IBM report² highlights how the use of containers for app deployments also enables companies to improve app quality, reduce defects, and minimize application downtime and associated costs.

The same report also lists applications that are uniquely suited for container-based environments, which include data analytics, web services, and databases. Here, the key factor is performance, but other relevant factors to consider are whether the applications are likely to run across multiple environments and if they use microservices to support multiple DevOps teams working in parallel. With containers, you can address performance issues by simply spinning up more instances of an app—assuming you implement a stateless architecture design and provide app services at scale.

Containers are not entirely without deployment challenges and the still-young technology has not yet reached the level of maturity of virtualization. The following section highlights some of the challenges that containers bring.

1. Key management – Key management between containers can be problematic, particularly because a main benefit of containers is portability. Your key management environment needs to be able to cope with movement of containers between on-premises hosts, as well as out to the cloud and back again.
2. Networking – Containers challenge traditional networking models due to the speed with which containers can spin up and down. In consequence, static network addresses would be unworkable in such an environment. And although addressing mechanisms such as Dynamic Host Configuration Protocol (DHCP) worked fine with physical hosts and virtual machines, container workloads can appear and disappear before the container’s IP address can register it and the container itself becomes discoverable. Separation from the physical network hardware by using container-based software-defined networking (SDN) is vital so that you can migrate entire container topologies from on-premises to private and public cloud environments. Most container environments implement some form of Container Network Interface (CNI) to carry out this function.
3. Multiple container technologies – Your organization may already have several different container technologies implemented within your environment. Even with these implementations, it is probable that your staff lacks deep technical understanding of all these environments. Training is important, as is giving your team time to familiarize themselves with these different container implementations. Management of these multiple container technologies is also more expensive. However, improvements in manageability, particularly in the latest Kubernetes release, tend to result in organizations standardizing on the easiest and most used environment.
4. Default configuration risks – As apps are developed in containers, the risk of misconfigured containers rises. An example is deploying containers in their default configuration. Unit 42 global threat intelligence at Palo Alto³ recently identified over 40,000 unique container devices that have the default configuration settings. Of course, not all those instances are vulnerable to exploitation, but it highlights that basic misconfiguration practices are widespread and make these organizations targets for further exploitation.

A vital design criterion with containerization is a balance between the three vectors of performance, density, and reliability, as shown in Figure 2.

The F5 approach is to focus on containerization at the component-level rather than at the system-level. This approach brings several advantages, which include:

• Reducing the memory footprint of each container by not assigning memory to unused network functions.
• Minimizing the dependency on the host CNI, thereby avoiding networking performance issues.
• Implementing small, lightweight components, that bring the failure domain down to the subscriber/user level.

Component-level containerization enables us to achieve that three-way balance through disaggregation, scheduling, and orchestration. F5 products that implement containers will then use these features to maximize the benefits of containerization.

To support organizations as they adopt container-based technologies, F5 offers F5® Container Ingress Services, an open-source container integration. Container Ingress Services provides automation, orchestration, and networking services such as routing, SSL offload, HTTP routing, and robust security. Importantly, it integrates our range of BIG-IP services with native container environments, such as Kubernetes and Red Hat OpenShift.

Architecturally, Container Ingress Services occupies the following position in relation to your containerized apps, adding front-door Ingress controller services and enabling visibility and analytics through BIG-IP.

Container Ingress Services addresses two of the key issues identified earlier in this paper—scalability and security. You can scale apps to meet container workloads and protect container data by enabling security services. With the BIG-IP platform integration, you can implement self-service app performance within your orchestration environment. Using Container Ingress Services also reduces the likelihood of developers implementing Kubernetes containers with default settings by using Helm charts for template-based deployments and upgrades.

In addition, Container Ingress Services enables security with advanced container application attack protection and access control services. For app developers and DevOps professionals who are not familiar with configurations, F5 application services offer out-of-the-box policies and role-based access control (RBAC) with enterprise-grade support, in addition to DevCentral customer and open source communities.

The challenges associated with native Kubernetes are related to developing and scaling modern container apps without increased complexity. There may be constraints on performance and reliability, and services that provide a front-door to Kubernetes containers may be inconsistently implemented, requiring greater integration effort to deploy and configure.

The solution to these challenges is NGINX Kubernetes Ingress Controller, which enhances the basic Kubernetes environment by providing delivery services for Kubernetes apps. Typically, Kubernetes pods can only communicate with other pods in the same cluster. Figure 4 shows the Kubernetes Ingress Controller providing access from the external network to Kubernetes pods, governed using Ingress resource rules that control factors such as the Universal Resource Identifier (URI) path, backing service name, and other configuration information. The available services depend on whether you use NGINX or NGINX Plus. 

Enterprises using NGINX gain features such as load balancing, SSL or TLS encryption termination, URI rewriting, and upstream SSL or TLS encryption. NGINX Plus brings additional capabilities, such as session persistence for stateful applications and JSON Web Token (JWT) API authentication.

As organizations adopt microservices to unlock developer agility and cloud-native scalability, they encounter a learning curve while organizational capabilities catch up to the technology. These organizations want to quickly unlock the benefits of microservices while preserving the stability that underpins their customer experience.

Aspen Mesh is a fully supported version of the open source Istio service mesh that helps companies adopt microservices and Kubernetes at scale and gain observability, control and security of microservice architectures. Aspen Mesh adds key service mesh enterprise features, including a user interface that makes it easy to visualize and understand the status and health of your services, fine-grained RBAC, and policy and configuration capabilities that make it easier to drive a desired behavior in your containerized applications.

Aspen Mesh provides a Kubernetes-native implementation, which is deployed in your Kubernetes cluster and can run on your private or public cloud, or on-premises. Importantly, it can work cooperatively with an F5-based ingress mechanism, using Container Ingress Services to provision deeper Layer 7 capabilities.

Architecturally, Aspen Mesh leverages a sidecar proxy model to add levels of functionality and security to containerized applications, as seen in Figure 5.