Creativa - Fotolia
Containers are seen as a better way than traditional VMs to encapsulate and manage applications on shared infrastructure. They enable developers to squeeze more performance out of applications in a smaller footprint, and can increase app portability and help facilitate a move to new infrastructure. But data and services wrapped around those containers often prove less portable than the container itself.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Container use often starts in on-premises environments, where application portability across a homogeneous container stack is guaranteed. But as more organizations turn to containers in cloud computing, there are services on the market to help, including Amazon Web Services (AWS) Elastic Container Service (ECS), Microsoft Azure Container Service and Google Container Engine (GKE). While each of these uses the Docker image format, the other services in the container ecosystem -- image registry, cluster manager, discovery service and persistent storage -- aren't necessarily compatible.
Following are some significant barriers to seamless portability with containers in cloud computing.
Persistent roadblocks among cloud platforms
Application containers are designed to be disposable, stateless modules deployed rapidly and consistently. However, most applications aren't stateless; they require access to persistent data that lives outside the container. There are several ways to incorporate storage into a container, most commonly local storage on a container cluster with a storage plug-in placed within the container image. Typical options include Docker pluggable storage volumes with support for plug-ins such as EMC libStorage, Flocker from now defunct ClusterHQ and others.
Public cloud hosting makes it more complicated to access persistent data, because each cloud platform has a different set of storage services. For example, Azure supports the Docker volume plug-in for use with the Azure File Storage service. Likewise, AWS ECS supports the ability to store container configuration data in Amazon Simple Storage Service, which is read at runtime but cannot be modified. However, it also allows the use of persistent data volumes when creating ECS task definitions.
Google Cloud provides a more flexible way to interact with persistent disks from GKE using its Kubernetes cluster manager to create a volume abstraction that is shared among container instances in a pod -- an application-specific host for one or more containers -- and that survives container restarts. The problem with all of these isn't just that they are different, but that the persistent data is tied to a cloud service -- creating friction when a containerized application must move.
Support for Windows containers also creates a potential roadblock to portability with containers in cloud computing. Although Docker was originally built on and for Linux, the engine has been ported to Windows to run Windows containers. As one would expect, Azure is developing support for Windows containers; however, at time of publication, this is still under development and currently in preview. Likewise, AWS support for Windows containers is limited and in beta. Although Google Cloud enables IT teams to run Windows containers on Compute Engine instances, the managed GKE container service does not. Differences in features and implementation make it difficult to port Windows containers across infrastructure platforms.
Container management support issues
Another element that complicates container portability is the software ecosystem supporting container management, including orchestration and cluster management software and container registries. There are several popular cluster management products that automate container placement, instance scaling and software updates, each of which uses different semantics for automation scripts. For example, both Docker Compose for swarm mode and Kubernetes use YAML files for deployment descriptions; however, the syntax and capabilities vary. And the Mesos Marathon meta framework uses JSON to define containerized applications.
In addition, several container registries are typically comprised of an image repository and a way to search and discover an image or microservice. Building processes and automation scripts around a set of container management tools and registry software helps maximize containerization's efficiency benefits, but also makes it more difficult to migrate to another platform. It's easy to move the workloads, i.e., images, but not the surrounding processes.
When using containers in cloud computing, the tendency is to integrate cloud-agnostic container images with cloud-specific services. For example, if an enterprise uses AWS ECS to deploy an instance, it would have to use proprietary ECS hooks. This pushes the IT team further into AWS-specific services that likely aren't supported outside of that platform.
Inconsistent container security creates obstacles
When running a hybrid infrastructure, it's difficult to maintain consistent security policies. This is no different with containers.
As with any virtualized infrastructure, container security is tied to an underlying user or group directory and the identity management system that underpins access controls and usage policies. Whether this is an on-premises Lightweight Directory Access Protocol directory such as Active Directory or a cloud service like Google Cloud Identity and Access Management, it's never easy to integrate identities and security rules across platforms.
Best practices for cross-cloud container portability
Issues with the application image rarely hinder cross-cloud container portability, especially when all major software and cloud vendors have embraced the Open Container Initiative (OCI). However, the OCI stresses that the specification isn't tied to a higher-level constructs like a client or stack; features such as naming and distribution within the spec are out of scope.
To maximize portability of containers in cloud computing, build a cloud-agnostic, hybrid design that has a locally run container management and orchestration system with centralized container images, registry and automation engines. These systems can deploy to multiple private and public container infrastructures, including Docker, ECS and GKE, among others. Essentially, IT teams should use the cloud for container runtime, but not the development and management ecosystem.
For data, there is a viable option to create a hybrid design in which a persistent state is stored in a central location that can be synchronized to various runtime services. A complex hybrid cloud design requires IT teams to divide application functions across clouds. This means that some components -- web front end, middleware business logic, big data engine -- will run on the public cloud and others on an owned infrastructure.
Use containers in cloud computing for what they do best -- creating tightly focused application or microservices functionality without having to embed data, security and governance policies. Strictly segregate application logic from infrastructure management and automation, and ensure that the container-management pieces of a container ecosystem are cloud- and platform-agnostic.
Nutanix's Acropolis Container Services mixes platforms on the same cluster
Compare VMs to bare-metal servers for container hosting
CoreOS container orchestration updates improve portability