As I discussed last year, the rapid ascension of Kubernetes, first as a de facto and later a de jure standard for cluster management significantly improved the prospects for container mobility across both on-premise and cloud-hosted platforms.
Unfortunately for advocates of workload portability and frictionless migration between clouds, there's more to a containerized application than the runtime engine and cluster manager. This leads to lock-in traps for the unwary.
Container-as-a-service (CaaS) products from the major cloud vendors, notably AWS EKS and Fargate, Azure AKS and Container Instances and Google Cloud Container Engine, present classic trade-offs between convenience and dependence.
With their ability to tap into a plethora of cloud data, security and developer services that are unique in implementation if not conception, container products from the big three vendors can trap users in a maze of platform dependencies with no easy exit path.
As container use in the enterprise moves from developer sandboxes to production systems, the desire for multi-environment portability presents an opportunity to devise standards, software, and automation systems that facilitate platform-agnostic container platforms. The idea is to ensure easy migration between private and public container environments. Recent announcements from Cisco, Google, and Pivotal Software are important milestones on the road to platform agnostic container infrastructure.
Like other packaged Kubernetes offerings, Cisco says the product simplifies cluster deployment and management via jointly-developed software. It achieves this by building on open source Kubernetes with improvements in user management, monitoring, and analytics. Aside from the convenience of pre-integrated, turnkey software, a presentation at the European Cisco Live event last winter touts that the product improves on open source Kubernetes via features such as:
- Integration of container and physical networks with improved security and load balancing.
- Support for external storage and workload data persistence
- Redundant control infrastructure including multiple Kubernetes master nodes
- Security and governance policies
- Support for clusters on either bare metal servers of VMware VMs
Network integration is provided using Cisco’s implementation of Contiv, an open source container fabric that, in Cisco’s adaptation supports several deployment models shown in the above image.
While most think of Pivotal Cloud Foundry, the commercial version of the most popular enterprise PaaS, as a development environment, it is evolving into a multi-cloud platform. See my previous Cloud Foundry coverage here and here.
PKS, the Pivotal Container Service, started as the simplest of hybrid platforms with integrated support for both on-premise VMware infrastructure and Google Cloud Platform. However, the company has just announced support for AWS EC2, providing a consistent, multi-cloud container environment with a single management, policy and developer interface that can deploy workloads across any supported on-premise or cloud infrastructure.
PKS achieves infrastructure consistency using the Cloud Foundry BOSH automation software that it augments with a unified network fabric. PKS is built from VMware NSX-T that provides dynamic load balancing of multiple Kubernetes Master Node instances that can span cloud availability zones or multiple private data centers to improve cluster availability.
PKS also uses NSX-T to implement network profiles that describe the configuration of network parameters, load balancers and security policy to simplify cluster creation using a standard template. (See my recent commentary for details on NSX here).
Pivotal also just announced a slew of other PKS enhancements including the latest in a sequence of quarterly updates to Kubernetes (to version 1.11), OS upgrades for Ubuntu (to version 16.04) and Windows (to Server v1803), along with integration with two VMware management: Log Insights for monitoring and vRealize Automation for cluster management.
CaaS products from the mega-cloud vendors continue to evolve with features like managed instances (see my overview here), and while these use Kubernetes as their orchestration engine, they are not interchangeable. As the Cisco and Pivotal announcements demonstrate, these CaaS products leave an opening for vendors looking to satisfy the desire by most enterprises for container infrastructure that can span multiple platforms without modification.
A survey of attendees at the 2017 KubeCon found significant fractions of the respondents running Kubernetes on a mix of on-premise infrastructure and the three mega-clouds. Almost 12 percent claimed to have deployments on all five of the identified platforms. Caveat: Platform9 conducted the survey so there’s the potential for selection bias, however it was done at a neutral gathering of container developers. The same survey found that 38 percent are “very concerned” about the complexity of managing multi-cloud container infrastructure.
Another survey of Cloud Foundry developers found that nearly half of respondents currently operate on multiple cloud environments, with two-thirds citing cross-platform flexibility as "very important." Given the audience, these respondents are likely referring to the development environment writ large, however, Cloud Foundry is based on containers where differences in the runtime container infrastructure pose a significant impediment to cross-platform deployments.
There’s an existing, admittedly small, market for multi-cloud container software from vendors like Containership, GoPaddle, Nirmata and Platform9. Along with the previously mentioned Cisco and Pivotal products, these are tapping into the desire by both developers and IT leaders to avoid platform lock-in via products and technologies that can span cloud implementations.
I believe that the market for such pan-cloud meta-environments is nascent and that as container usage expands, the demands from enterprise customers will lead all of the major cloud vendors to embrace some form of cloud-neutral environment, even if it just provides baseline features. Indeed, the desire of enterprises to avoid cloud lock-in goes far beyond containers and is reflected in my recent column about VMware’s strategy to create an infrastructure-agnostic platform in which I write,
In VMware’s idealized world, differences between cloud service providers are blurred and enterprises interact with a VMware substrate, whether that’s Dimension-vSphere infrastructure services or PKS container services.
In the new model, VMware might end up being the standard virtual infrastructure that rides atop public clouds (and on-premise systems), but those same cloud service providers might, in turn, run their higher-level PaaS, database, analytics and AI services atop the VMware substrate.
Herein lies the risk that enterprises could end up trading one form of lock-in (to the cloud vendor) for another (to the meta-cloud platform). It’s a genuine concern in the VMware scenario since it seeks to manage all facets of enterprise infrastructure. However I believe it’s less a concern with container environments due to existing, universally-adopted standards and the user and developer community’s commitment to extending standards across all segments of the ecosystem. I will be closely watching developments in multi-platform container technology, particularly at what are sure to be seminal events this fall for the user community: AWS re:Invent and the Cloud Native Computing Foundation KubeCon.