Promoting multi-cloud portability starts with containers, but CNCF needs a broader vision

Cloud services are now a critical IT component for many enterprises, with surveys showing that most organizations plan to increase their cloud spending in the coming years. We’re well past the stage of initial adoption and many IT and business leaders have embarked on next-generation cloud strategies designed to integrate multiple service providers with private systems into a seamless multi-cloud infrastructure.

Indeed, IDC predicts that spending on cloud services and related equipment and software will double by 2021 with more than 90 percent of organizations having a multi-cloud environment. It is such a future that the Cloud Native Computing Foundation is designed to foster.

According to CNCF COO and CTO Chris Aniszczyk, the organization was founded in late 2015 with the initial goal of providing a vendor-neutral home for the recently released Kubernetes container orchestration software, however it has significantly expanded its mission over the intervening years to sponsoring and shepherding projects that facilitate cloud-native applications

Defining 'cloud-native' - a matter of viewpoint

The term “cloud-native” is both imprecise and subjective, but given its origins, it's not surprising that the foundation’s recently updated mission statement takes a decidedly container-centric view of the concept. Rather than prescribe a particular methodology or design, the CNCF asserts that cloud-native systems and applications are constrained to those having the following properties:

• Container packaged, namely running applications and processes in software containers to achieve resource isolation, facilitate code and component reuse and simplify infrastructure operations.
• Dynamically managed using a central orchestration process that actively schedules and manages containers to improve physical resource utilization and operating efficiency which result in lower costs for operations and maintenance.
• Micro-services-oriented with loose coupling between service containers and where dependencies and service interactions are described through APIs. Together, these increase the flexibility, maintainability and development and deployment agility of resulting applications. Furthermore, the foundation intends to “shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces.”

I pointed out to Aniszczyk that the definition completely ignores the use of packaged application, data and machine learning/cognitive cloud services like event-driven functions (Lambda), data warehouses (BigQuery), or image recognition (Rekognition), business intelligence (Quicksight) and search (Bing Custom Search) packages that eliminate the need for user-managed containers, at least for a subset of application services. Using such built-in services allows applications to adhere to properties 2 and 3 while eliminating, at least from the customer's/application operator's perspective (if not that of the cloud provider), property 1.

While Aniszczyk acknowledged that the concept of cloud-native is still subject to intense debate, including within the CNCF, I believe that embracing the use of use application-level cloud services would risk violating another core tenet of the CNCF, namely platform agnosticism. Indeed, many have posited that Kubernetes is the lynchpin to Google's long-term strategy of eliminating cloud lock-in and reducing AWS's advantage in differentiated services. Mirantis co-founder and CMO Boris Renski articulated the theory in a post last year by pointing out that when you're a distant third in the cloud market, turning the business into an interchangeable commodity makes more sense than trying to out-innovate the leader (emphasis added):

I'd like to postulate that K8S was the first move in a longer chess game [by Google] to Android AWS: one where the end goal is to destroy costs associated with moving workloads between clouds.

In that vein, the Kubernetes push is not about just making GKE [Google Container Engine] popular. Kubernetes is about seeding the industry with open source standards for application development and operations that aim to dis-intermediate workloads from the underlying infrastructure substrate, with a minimal hit to developer productivity. In other words, piece by piece, Google is re-building the concept of a PaaS, and Kubernetes is the first building block."

A necessary condition for such cloud commodification is the creation of, in the words of CNCF's web page, "a vendor-neutral home" for platform-agnostic projects that foster collaboration between developers, users and vendors. One flaw in the Kubernetes-as-Trojan-horse theory is that AWS, along with all the other mega cloud providers, is a Platinum member of CNCF and has subsequently released a managed Kubernetes service, EKS (which was made generally available this week) along with participating in several CNCF projects.

Furthermore, as Aniszczyk pointed out in our conversation, CNCF has significantly expanded its initial container-centric mandate to include more than 20 projects touching various aspects of cloud infrastructure and applications. We’ll see how AWS navigates the tension between open ecosystems and proprietary services, but for now it’s primary goal, in the words of Adrian Cockcroft, its VP of Cloud Architecture Strategy is “to create and drive the adoption of a new computing paradigm optimized for modern distributed systems.”

Building the plumbing for cloud-native systems

CNCF's executive director has likened its mission as building "the plumbing software for the internet," and while the metaphor is a bit sweeping, the breadth of its project portfolio illustrates a recognition that container infrastructure is but one piece of a cloud-native system. The organization has a useful infographic that outlines its view of the cloud-native application development landscape that shows containers as part of a larger ecosystem.

CNCF has a three-level hierarchy for project maturity. Those in the earliest stages being related to the Sandbox until they have reached a level of quality and developer acceptance to be deployed by three independent users and become eligible to graduate to Incubating status. Projects are deemed Graduated once they have achieved the level of maturity and industry usage to stand on their own. So far, Kubernetes is the only such project.

According to Aniszczyk, the three projects expected to graduate this year are:

• Envoy, a reverse proxy designed for edge devices and microservice service bus that Aniszczyk expects will rapidly displace NGINX for brokering communications between backend microservices and application users. Indeed, Aniszczyk says Google, Apple and Alibaba are some of the large providers that are already using Envoy.
• Fluentd, an extensible platform for log data collection and aggregation that creates a unified logging layer for service-based cloud applications.
• Prometheus, a systems monitoring and alerting platform for service-oriented applications and that is intended to be used with fluentd to create a complete system for application telemetry and analysis.

A significant recent update to the CNCF portfolio is the promotion of the Helm package manager for container-based software to a standalone project. Formerly part of the Kubernetes core project, Helm is designed to supplement the container ecosystem with a software-distribution and management platform.

Functions-as-a-Service, aka serverless offerings like Lambda and Azure Functions, are an exciting and innovative additon to the cloud service portfolio. Because the implementations are proprietary, serverless is also an area fraught with lock-in risk since event-driven applications using a particular implementation such as Lambda can’t be easily ported to another cloud platform. CNCF has chartered a serverless working group to develop a standard format for event data called CloudEvents to facilitate cross-cloud event definition, announcement and delivery. While a start, Aniszczyk sees a longer-term need for an event gateway project to develop a neutral service broker for cloud providers that can intermediate between disparate services like Lambda and Functions.

My take

Enterprises have ample experience with lock-in from legacy equipment and software providers and few want to relive the ordeal with their service providers, which is one reason an organization like CNCF is necessary. Indeed, the fact that it has rapidly grown to more than 200 member companies, triple the number of a year ago, is a testament to the hunger for cloud-neutral technologies.

While I extol the CNCF mission, I remain concerned about its container-centric architectural principles since, as mentioned, such tunnel vision ignores the benefits of higher-level, cloud-operated infrastructure, application, data, AI and developer services. Sure, it’s possible to operate a CI/CD pipeline using Git, Maven, Jenkins and other tools all run as containers on a Kubernetes-managed cluster, but why would you, particularly if your primary deployment target is the cloud where AWS packages all the tools as on-demand services like CodeCommit, CodePipeline and CodeDeploy?

Likewise, it’s far easier and cheaper to consume image or speech recognition applications as a service than to deploy and manage the required software and GPU-accelerated instances necessary to build, train and run the requisite deep learning models.

Nevertheless, as I wrote last year, Kubernetes’ rapid success in becoming the standard container management and orchestration system is both impressive and necessary to allow the industry to tackle other roadblocks to building cloud-native applications. I am encouraged by Aniszczyk’s long-term vision of creating a cloud-agnostic service broker, however I believe the vision should be grander.

CNCF (or another cloud-neutral organization) should address the broader problem of vendor lock-in when using higher-level cloud services by creating an intermediary service bus that can federate application access to different proprietary cloud products. The Kong API gateway is a compelling start that I plan to explore in more detail and that would make an excellent addition to the CNCF project portfolio.