Kubernetes: Evolution Of An IT Revolution

(Note: this post assumes a basic level of familiarity with technologies such as containers and Kubernetes. For a primer, watch this lovely video.)

When asked about the impact of revolutionary developments in France, Chinese Communist leader Zhou Enlai famously replied, “It is too soon to say.” (Though it is still disputed if he was referring to 1789 or 1968!) Lucky for him, he didn’t have to deal with things such as the IT hype cycle.

The IT industry has never been short on marketing hype, and Kubernetes, the emerging standard for container orchestration, is no exception. For sure, Kubernetes’ technical pedigree is distinguished, having been born out of the technology that powers Google itself. Furthermore, since its birth in 2014 as an open source project hosted by The Cloud-Native Computing Foundation (CNCF), the project has seen impressive growth driven by a rich ecosystem—and that trend intensifies, as can be seen in the CNCF’s latest survey.

Birds’ eye view of ships

As impressive as growth can be, however, it isn’t the same thing as ubiquity (this is where marketing hype is effective in blurring reality). Judging from metrics such as tech conferences covering Kubernetes, the number of partner logos on the CNCF’s landscape, the volume of press releases—and even more tangible metrics such as commits to related projects on GitHub—one might be forgiven for believing that ubiquity has already been achieved.

It might be useful to remember, then, that according to a study cited on Forbes.com earlier this year, 12 years after the launch of AWS, only 31% of workloads are currently running exclusively on public clouds. In light of this data, would it be wise to assume that the cloud-native revolution has covered more ground in less than a third of that time? Likely not. More specifically: What can the rapid growth of Kubernetes tell us about the evolution of its usage model in enterprise? With some personal insight into this space, I can attempt to guess.

An alternative timeline

I have been fortunate enough to have been there (in the eye of the cloud-computing storm) when Kubernetes was released initially and as a stable (version 1.0) project, in June of 2014 and July of 2015, respectively. Having worked with cutting-edge engineering teams in this sector before and since then, I have also seen Kubernetes spread in usage and grow in maturity. General milestones in the project’s history are well-documented, but I see some actual adoption trends moving on a timeline as follows (vastly simplified/generalized for the sake of brevity):

  • 2014: Extreme-early adopters try to understand how Kubernetes works.
  • 2015: With the launch of the CNCF and Google’s managed Kubernetes, GKE, a wider community of software and system engineers now have a reference model for the technology. Red Hat’s OpenShift starts on the container-PaaS path.
  • 2016: Since only a small number of workloads actually run on Google’s public cloud at this time, the focus shifts to finding ways to install Kubernetes and to spin up clusters for test applications, on other clouds or on premises.
  • 2017: More managed Kubernetes services are made available (or at least announced), from Azure and AWS, and erstwhile Kubernetes rivals Docker and Mesosphere announce support for Kubernetes in their tooling. This effectively cements Kubernetes’ leadership as the de-facto standard for container orchestration. Early adopters, with access to top engineering talent, deploy production workloads at scale on the technology. The part of the mainstream that is actually doing something with Kubernetes still focuses on understanding how to install and manage it at a proof-of-concept level.
  • 2018, to date: Several more managed Kubernetes services are launched by DigitalOceanOracle and others; coupled with the growth of the top-3 clouds’ managed Kubernetes services (as well as Red Hat OpenShift), the problem of simple installation and management is effectively solved. The conversation shifts ‘left’ to problems in the pipeline—how to get code in a reliable, repeatable way into Kubernetes. It also shifts ‘right’ to lifecycle management—how to operate (monitor, log and secure) clusters, especially within hybrid environments. This means that production usage is still constrained—to run an app in production, one needs to address the whole cycle, rather than just spin up clusters.

In the grand scheme of things, this is still an evolving technology with a small footprint. Even for a technology with the robustness and backing to become pervasive, growth does not equal ubiquity—yet. So what does that mean for users, investors and vendors? And what else is happening that should influence decisions?

Leave a Reply