Virtual Machines Are the Standard in Telco Cloud, But Containers Are the Future

Subscribe To Download This Insight

4Q 2018 | IN-5272

Virtual machines (VMs) are used extensively in cloud computing to meet two key requirements: one, to provide isolation across multiple workloads and entities (hardware units, hypervisors, etc.); and two, to avoid resource monopolization while preserving multitenant provisioning. VM-centric virtualization lays the groundwork for the Infrastructure-as-a-Service (IaaS; e.g., servers, storage, networking) cloud-computing model, which in turn serves as the foundation for Platform-as-a-Service (PaaS; e.g., development tools, business analytics, databases) and Software-as-a-Service (SaaS; e.g., hosted apps) deployment environments. VMs excel at isolation but running multiple apps, or different versions of the same app, in the same VM is not possible due to dependency conflicts. VMs, therefore, may not be very conducive to app agility and cloud-native friendliness. VM-induced overhead may also be a challenge because of each VM running on a full operating system (OS) and because of a hypervisor that serves as a conduit for data flowing to the outside world.

Registered users can unlock up to five pieces of premium content each month.

Log in or register to unlock this Insight.

 

VMs versus Containers

NEWS


Virtual machines (VMs) are used extensively in cloud computing to meet two key requirements: one, to provide isolation across multiple workloads and entities (hardware units, hypervisors, etc.); and two, to avoid resource monopolization while preserving multitenant provisioning. VM-centric virtualization lays the groundwork for the Infrastructure-as-a-Service (IaaS; e.g., servers, storage, networking) cloud-computing model, which in turn serves as the foundation for Platform-as-a-Service (PaaS; e.g., development tools, business analytics, databases) and Software-as-a-Service (SaaS; e.g., hosted apps) deployment environments. VMs excel at isolation but running multiple apps, or different versions of the same app, in the same VM is not possible due to dependency conflicts. VMs, therefore, may not be very conducive to app agility and cloud-native friendliness. VM-induced overhead may also be a challenge because of each VM running on a full operating system (OS) and because of a hypervisor that serves as a conduit for data flowing to the outside world.

Container-based virtualization is an alternative that encapsulates the host OS kernel and container run time into a distinct layer (container image) running natively on bare metal. This container image decouples the underlying hardware from any containerized apps and any associated dependencies running on top of it. Containers offer an efficient alternative to spinning up dedicated VMs to run multiple apps—an approach that would not scale well for dense deployments of ephemeral or light functions. Though containers offer better scale and efficiency, the multiplicity of discrete entities raises new requirements such as mass-container instantiation and orchestration. Vendors should take the lead to help telcos navigate a range of (hybrid) virtualization options that accelerate the adoption of cloud-native technologies in the long term while satisfying short-term network automation and orchestration demands.

  VMs versus Containers  

 

Container Infrastructure

IMPACT


Containers provide nearly direct access to the hardware with little or no virtualization overhead, and unlike a VM (which runs a full guest OS), a container’s computational remit can be limited to a single process. A container that closely resembles the environment given by a VM is called a system container (LXD is an example). The alternative, an application container, is designed to run a single app affording granular isolation and enhanced portability better suited for cloud-native deployments. The deployment of each container configuration will vary with specific environment requirements. An application container has a leaner footprint; therefore, it consumes less resources relative to a system container or VM, and it does not require its own Internet Protocol (IP) address. That said, a system container may be needed for VM-like performance to handle heavy workloads.

Containers are a nascent technology that are unequipped with a management mechanism whereby resource constrains are enforced on running processes. Given that containers may not be aware of their resource limits, challenges associated with the “noisy neighbor” phenomenon may arise when one process monopolizes available resources, leading to starvation and performance degradation of other processes. Products that provide “observation” and container-orchestration capabilities—the monitoring of behavior that forms the basis of a quota management system and a stable telco software—are in scarce supply; this space calls for more vendor involvement. Open-source cloud-native platforms—such as Kubernetes, OpenShift, and Mesos—offer a rich set of tools that can be implemented for containers, but they should be adopted and extended for the complex requirements in telco environments.

Containers can render the performance differences between bare metal and IaaS as negligible due to the VM-like isolation and bare-metal performance they provide, and this is important, particularly for containers and heavy workloads. Rather than configuring different images for VMs and non-virtualized hardware, a container image is flexible to be deployed either on a subset of capacity (computer processing unit, random access memory) or an entire machine. Containers provide an architectural approach that is a natural precursor to microservices—fine-grained, isolated, and elastic functions, all at the same time. A key consideration for telcos is how to shift network functions from physical instances to containerizing microservices, and how these microservices will align. While there is no standardization or even industry consensus on which cloud-native platform is relevant for the telco cloud, vendors need to start embracing containers, which are in fact more suitable for microservices and have the much-needed agility telcos demand today. Vendors must pay attention to cloud-native management platforms and ensure that current software (e.g., OpenStack) will be able to migrate to container management in the future.

Containers in Telco Environments

RECOMMENDATIONS


Containers have been widely deployed in the information technology world, a domain where companies such Amazon, Facebook and Google are composable and “flat” by design—hence the transition from VMs to containers is relatively smoother. The telecoms’ domain, however, is characterized by inflexible legacy systems and processes. Therefore, it may be easier for telcos to shift network functions from physical hardware to software in a VM (P2V—Physical to Virtual), than it is for them to make the direct leap to containerizing the software (P2C—Production to Consumer, or V2C—Virtual to Cloud). Though almost all current deployments to virtualize network functions are going ahead with VMs, ABI Research anticipates an eventual evolution toward containers, provided that the industry continues to build on the work from the European Telecommunications Standards Institute’s Industry Specification Group for Network Functions Virtualization (ETSI ISG for NFV) to explore best-practice container use in telecoms.

VM-centric workloads rely on kernel modifications for enhanced performance and do not directly rely on the stable Linux kernel Application Binary Interfaces (ABIs). For example, VM-centric Virtual Network Functions (VNFs) benefit from specific enhancements that have been implemented in hypervisors and OpenStack such as Single-Root Input/Output Virtualization (SR/IOV) and Data Plane Development Kit (DPDK). Absent a similar hardened container infrastructure, the recent industry practice of deploying containers in VMs may become a common occurrence (see IN-5235). Although this practice may be necessary in the short term to enable P2V, it will result in performance overhead that may dilute the operational efficiencies that could be gained when deploying containers on non-virtualized bare metal.

Containers promote small shared images by isolating the OS, arguably the bulkiest part, and isolating the app dependencies. A full entrenchment into telco fabric, however, is dependent on container tracing and a built-in (decentralized) orchestration and management mechanism that aligns with a self-serve and distributed model. This is an area that warrants further industry engagement and product maturity, particularly for Management and Orchestration (MANO) stacks which vendors such as Amdocs and NEC/Netcracker, among a few others, have already begun to explore. Regardless of the virtualization mode telcos choose (VM only, container only, hybrid, container-in-VM), a rich choice is at their disposal, but each use case will need to be evaluated on its degree of cloud readiness, commercial potential, and appetite for risk.

Services

Companies Mentioned