Month: November 2018

At the turn of the previous decade, you would be considered perfectly sound to place a bet on Platform-as-a-Service (PaaS) as the dominant cloud service model (over IaaS). With offerings such as Google’s App Engine, Microsoft’s original Azure, newcomers Heroku and EngineYard, and OpenShift from Red Hat, to name just a few, the stage seemed set for this model of opinionated, abstracted operations to take immediate hold.

But within a few years, many a PaaS-y startup started to run into trouble when raising money. “PaaS” became a dirty word (one founder I worked closely with told me of a lost weekend he spent redoing his company’s collateral and website to remove all mention of the word “platform”). So what went wrong, and how is it changing now?

The perfect storm of 2008

The Great Recession which started in 2008 created some key conditions for the renewed rise of startups. These have have been well documented for years: chiefly, negative (real) cost of capital made seed capital more accessible; and large numbers of young software engineers, many with open source and “post-Web 2.0” experience, were left without jobs, looking for something to do.

Amazon stumbled upon this market to complete the golden triangle of capital-talent-technology. At a time when leading (and emerging) PaaS vendors were banking on abstracting IT for enterprise developers, AWS found that startup developers—many of them with shallow pockets and deep experiences—tended to have their own development environments and just wanted access to someone else’s machines, not someone else’s opinions. Amazon Web Services’ EC2 (Elastic Compute Cloud) service gave them just that, as did upstarts such as DigitalOcean and open projects such as OpenStack.

As many of these developer teams evolved into the first cloud-native companies, there emerged a common need for simplification and abstraction, to support rapid scaleup. However, even that didn’t push the market over to PaaS. Many have criticized the inherent pricing model of many PaaS tools as unfit for scale, but I would like to offer an additional, technical argument: the first cloud-native companies had access to an exploding universe of open source code and great technical talent who, put together, could help in building and maintaining complex IT ‘stacks’—in other words, the first hyper-scale cloud companies chose to own system complexity rather than take someone else’s rigid opinion.

Since these early days of AWS, the history of cloud computing can be summarized as follows: who will come in a distant second?

(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.

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 DigitalOcean, Oracle 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?