{"id":12652,"date":"2022-02-12T20:52:59","date_gmt":"2022-02-12T20:52:59","guid":{"rendered":"https:\/\/mailinvest.blog\/index.php\/2022\/02\/12\/the-improbable-rise-of-kubernetes-to-become-the-operating-system-of-the-cloud\/"},"modified":"2022-02-12T20:52:59","modified_gmt":"2022-02-12T20:52:59","slug":"the-improbable-rise-of-kubernetes-to-become-the-operating-system-of-the-cloud","status":"publish","type":"post","link":"https:\/\/mailinvest.blog\/index.php\/2022\/02\/12\/the-improbable-rise-of-kubernetes-to-become-the-operating-system-of-the-cloud\/","title":{"rendered":"The improbable rise of Kubernetes to become the operating system of the cloud"},"content":{"rendered":"

<\/a>\n<\/p>\n

\n

The rise of Kubernetes came about through a combination of forces that were, in hindsight, quite a long shot.<\/p>\n

Amazon Web Services Inc.\u2019s dominance created momentum for cloud-native application development and the need for simpler experiences beyond easily spinning up compute as a service. This wave crashed into innovations from a startup named Docker Inc. and a reluctant open-source benefactor in Google that needed a way to change the game on Amazon.com Inc. in the cloud.<\/p>\n

Factor in Red Hat Inc., which needed a path beyond Linux and was just about to opt for an alternative to Kubernetes to power OpenShift.\u00a0Finally, figure out a governance structure to herd all the cats in the ecosystem so you can win out over other competition and create a de facto standard. Make all that happen and you get the remarkable ascendancy of Kubernetes.<\/p>\n

Such was the story unveiled recently in a new two-part documentary series from\u00a0Honeypot<\/a>\u00a0titled simply \u201cKubernetes.\u201d\u00a0<\/em>In this Breaking Analysis, we tap the back stories of this documentary, which explains the improbable events leading to the creation of Kubernetes. We\u2019ll share commentary from early Kubernetes committers and key players who came on theCUBE, SiliconANGLE\u2019s video studio, to piece together how it all happened.\u00a0Finally, we\u2019ll present new survey data from\u00a0Enterprise Technology Research<\/a>\u00a0on containers.<\/p>\n

The story of Kubernetes<\/h3>\n

Kubernetes Part 1<\/a>\u00a0explains the dynamics of the technology industry in the early part of last decade, the impact that AWS had on the DevOps movement, the importance of Docker, which blazed a new trail for developers, and how Google ultimately landed on the decision to open-source Kubernetes.\u00a0Part 2<\/a>\u00a0of the series introduces the contribution of Red Hat and how the ecosystem evolved to create a new standard for software development.<\/p>\n

\"\"<\/p>\n

The documentary is sponsored by Google, Red Hat and the CNCF. It includes commentary from many of the players who were early committers or key individuals who influenced the development of Kubernetes. Many of these innovators came on theCUBE at various events during the formative years of mainstream containers, including Tim Hockin, Kelsey Hightower, Craig McLuckie, Joe Beda, Brian Grant, Solomon Hykes, Jerry Chen and others.\u00a0John Furrier and Stu Miniman were at the many shows theCUBE covered and unpacked what was happening at the time. In this post, we\u2019ll share the commentary from the guests they interviewed.<\/p>\n

Developer-defined infrastructure<\/h3>\n

Over the years we\u2019ve used several phrases to describe the programmability of infrastructure. Jerry Chen is a partner at Greylock Ventures. Years ago, he coined the term developer-defined infrastructure or DDI.\u00a0Chen was head of VMware Inc.\u2019s cloud product group and left the company in 2013 to become a full time investor.<\/p>\n

His first investment was Docker.\u00a0Chen explained on theCUBE what happens when infrastructure is defined in software \u2014 how breaking down infrastructure into components that each have an application programming interface allows developers to control infrastructure through code and make applications portable, and how DDI completely disrupted the entire application development process.<\/p>\n

Listen to Jerry Chen from 2015 explain DDI and how it changed development in IT.<\/strong><\/a><\/em><\/p>\n

The concept of DDI or what Wikibon\u2019s David Floyer called\u00a0software-led infrastructure in 2012<\/a>, was spawned from the cloud and the obvious opportunity for automation. This ushered in the DevOps movement, which was initially seen as something for startup developers, but over time, as Kelsey Hightower explains, eventually it caught on with the ops crowd.<\/p>\n

Listen to Kelsey Hightower at KubeCon 2017 explain the dynamic between dev and ops.<\/strong><\/a><\/em><\/p>\n

Abstractions on abstractions<\/h3>\n

What Jerry was explaining is a new abstraction layer that was being built to essentially make infrastructure invisible to developers.\u00a0Here\u2019s some ETR data that quantifies that trend and visually shows you where we are today.<\/p>\n

\"\"<\/p>\n

The chart above shows Net Score or spending momentum on the vertical axis and Market Share, which represents the pervasiveness in the survey. As Jerry Chen and the innovators who created Docker saw, the cloud was becoming prominent and you can see it still has spending velocity that is elevated above that 40% red line \u2013 kind of a magic mark of momentum. And of course it\u2019s prominent on the X axis. Cloud is what got this movement going.<\/p>\n

Below the 40% line you see the low-level infrastructure, including virtualization. Virtualization is an abstraction layer above servers, storage and networking. Back in 2011, in a VMware briefing with Chad Sakac, we first heard the stated goal the company had to make infrastructure \u201cinvisible.\u201d Containers are yet another abstraction that lives above virtualization.<\/p>\n

And ironically the spending chart above shows this. The two red arrows point to containers \u2013 container orchestration and container platforms \u2013 which are the abstraction layers and services above the underlying VMs and hardware.<\/p>\n

And you can see the spending momentum containers have in the market along\u00a0with cloud, artificial intelligence, machine learning and robotic process automation.<\/p>\n

How the stars aligned to create Kubernetes<\/h3>\n

You had the forces that Jerry Chen and Kelsey Hightower described taking shape. The \u201cKubernetes\u201d documentary does an excellent job explaining how they came together in the words of the insiders at Google, Red Hat and CNCF.\u00a0The picture below identifies the key elements and we\u2019ll describe their improbable interaction that formed Kubernetes.<\/p>\n

\"\"<\/p>\n

In the upper left, you see AWS. We inserted a picture from a\u00a0post<\/a>\u00a0we did right after the first re:Invent in 2012. It was obvious Amazon was the cloud gorilla and had all the momentum in IT. We saw it as an unstoppable wave, as did the protagonists in the documentary.<\/p>\n

Solomon Hykes, the founder of Docker (pictured, upper right) saw the need to simplify the packaging of applications for cloud developers. Containers had been around for more than 30 years prior to Docker, initially developed as part of the Unix operating system to isolate certain processes from other application components. But the vast majority of programmers didn\u2019t know or care about containers. They were a low-level construct and hidden from the mainstream.<\/p>\n

Docker changed all that.\u00a0Docker at the time was a 30-person company and had just changed its name from dotcloud. It\u2019s astounding to think that this tiny company changed the history of computing.<\/p>\n

Listen to Solomon Hykes answer the question in 2014: \u201cWhat is a container?\u201d<\/strong><\/a><\/em><\/p>\n

Google\u2019s need to change the cloud game tips the scales<\/h4>\n

Imagine you\u2019re at Google in 2013. You\u2019ve built the world\u2019s largest and most impressive computer network with millions of servers around the world. You have great tech and along comes Amazon, an online commerce company.\u00a0Its entry into the cloud captures the minds and wallets of developers and organizations everywhere. Amazon has all the momentum in IT and your business is built on appropriating consumer data to sell ads. And your motto at the time is \u201cDon\u2019t be evil.\u201d<\/p>\n

If you\u2019re an engineer at Google, you want to change the world. You want to develop something meaningful. You don\u2019t want to just follow Amazon \u2013 that won\u2019t get you far.\u00a0So what\u2019s the play? Hence in the diagram above the question mark in the Google cloud logo.\u00a0\u00a0You see Docker emerge and it creates an opportunity. Docker is great because it simplified containers and took them mainstream. But Google sees that you need more. Heck, Docker saw that you needed more, and so did\u00a0Mesosphere and others.<\/p>\n

Why do you need something other than Docker?<\/h4>\n

So why exactly would you need more than what Docker had created? Craig McLuckie, who was a product manager at Google in 2014, explained to theCUBE host John Furrier the need for another management layer. He shares that what Docker did was create the capability to run a binary anywhere. But there needs to be a way to manage that with a framework that can run anywhere.<\/p>\n

Listen to Craig McLuckie discuss the union of Docker and Kubernetes and why there needed to be another layer.<\/a><\/strong><\/em><\/p>\n

So McLuckie explained why the industry needed something like Kubernetes, but let\u2019s go further back in time. Here\u2019s Google with this amazing cloud infrastructure but no commercial cloud business to compete with AWS \u2013 at least not one that was taken seriously at the time. It had compute as a service and could spin up virtual machines easily, but it really wasn\u2019t that exciting in Google\u2019s mind and AWS had nailed that use case. So Google needed a way to increase its relevance.<\/p>\n

Google never embraced virtualization to solve its internal challenges<\/h4>\n

Google had this thing called\u00a0Google Borg<\/a>,\u00a0which is a container management system and scheduler. And Google looked at the problem in cloud, which was not just \u201cHow to I spin up a virtual machine?\u201d but rather \u201cHow do I run and manage my code?\u201d<\/p>\n

Joe Beda, who was with Google at the time, explains to Furrier and Miniman the company\u2019s mindset and how it saw the opportunity.<\/p>\n

Listen to Joe Beda explain how Google engineers thought about the problem and how they thought about going beyond VMs as a service.<\/strong><\/a><\/em><\/p>\n

So Google looked at the market and said, \u201cWhat can we do to make Google relevant in cloud?\u201d Eric Brewer from Google explained on theCUBE Google\u2019s thought process at the time. Google started the same year as VMware. So it never used virtualization for its own infrastructure. Rather, it used containers and low-level processes to build its cloud network. So it came at the problem with a different mindset.<\/p>\n

Listen to Eric Brewer, Google\u2019s vice president of infrastructure, explain the company\u2019s use of containers in its early days.<\/strong><\/a><\/em><\/p>\n

Now, Brewer gave us the short version of the story. What he reveals in the documentary is that initially his posture was an instant negative reaction to open-sourcing Kubernetes. Google management was skeptical and asked, \u201cWhy would we open-source our secret sauce to help our competitors?\u201d But over time and through a series of meetings and discussions, Google\u2019s engineers were able to convince management that open-sourcing Kubernetes was not only good for the industry but also good for Google.<\/p>\n

Google management was reluctant to open-source Kubernetes<\/h4>\n

Tim Hockin and Brian Grant were on the original Kubernetes team and pressed management to persuade them to bless open-sourcing Kubernetes. Hockin explained to Furrier on theCUBE the narrative inside Google at the time.<\/p>\n

Listen to Tim Hockin explain how they pitched the idea of open-sourcing Kubernetes to senior Google management.<\/a><\/strong><\/em><\/p>\n

The open-source strategy became more compelling as they studied the problem because it gave Google a way to neutralize AWS\u2019 advantage: With containers, you could develop on AWS, for example, and then run the applications anywhere \u2014 such as on Google\u2019s cloud. So it not only gave developers a path off AWS, if Google could develop a strong service on Google Cloud Platform, it could make money from the play over time.<\/p>\n

Linux needed a path to the cloud<\/h4>\n

Now back to the diagram, which shows a smiling Alex Polvi from CoreOS. His company was acquired by RedHat in 2018. And he saw the need to bring Linux to the cloud. After all, Linux was powering the internet. It was the OS for enterprise apps and to Polvi, it made sense to extend its path.<\/p>\n

Linux became the operating system for the data center. It did so by becoming an open standard with consistent APIs. And although there are still other OSes out there, Linux is the dominant production-grade operating system for data center applications.<\/p>\n

At an OpenStack event in 2015, Polvi described how he thought a similar standard would emerge in an abstraction layer that treats the data center as a computer, rather than addressing individual machines. And he stated at the time his belief that that layer would standardize around Kubernetes.<\/p>\n

Listen to Alex Polvi describe the parallels between the standardization of Linux and Kubernetes.<\/strong><\/a><\/em><\/p>\n

Red Hat\u2019s future depended on a new path to the cloud<\/h4>\n

Red Hat had been around since 1993. So it needed a future that took the company to cloud. OpenShift was that future and it had to leverage a container management framework. According to the\u00a0documentary, Red Hat connected to Google through their respective board members, which led to a discussion among engineers about containers. Google was noncommittal but did expose that it was thinking about doing something and maybe open-sourcing this new project.<\/p>\n

But Google\u2019s internal debates and arm-twisting were taking too long, so Red Hat couldn\u2019t wait. It had to move forward with an open-source alternative, so it decided to do what Apple Inc., Airbnb Inc. and Heroku (now owned by Salesforce.com Inc.) were doing and build on an\u00a0alternative.\u00a0It was ready to commit to Mesos, which was more sophisticated and much more mature than Kubernetes.\u00a0But at the last minute, Google came back and said, \u201cLet\u2019s do it.\u201d<\/p>\n

Clayton Coleman was the Red Hat architect who started leaning in right away and was one of the first committers outside Google to participate in the project.<\/p>\n

Decision time for Kubernetes: Go for scale or simplicity?<\/h4>\n

At the time, you had competing forces in the market and internally between \u201cdo we go with simplicity or do we go for system scale?\u201d Google clearly had the expertise to build large, complex, scalable systems. Platforms such as Docker Swarm and Mesos were tackling more complex use cases and yet the Kubernetes team bet on simplicity first.<\/p>\n

Chen Goldberg from Google talked about why the company focused first on simplicity and getting that right before tackling the larger problems. Perhaps is seems obvious today, but with external market forces and internal engineers advocating for different directions, it was an important decision.\u00a0Goldberg explains that, rather than competing right away with say Mesos or Docker Swarm, which were far more baked, Google made the bet to keep it simple and go for ubiquitous adoption \u2014 which obviously turned out to be the right choice.<\/p>\n

Listen to Google\u2019s Chen Goldberg explain the rationale of focusing on simplicity first.<\/strong><\/em><\/a><\/p>\n

Herding the cats<\/h4>\n

The last piece of the complex puzzle was governance. According to commentary in the documentary, Google had promised to open-source Kubernetes, but when it started to open up to contributors outside Google, the code was still controlled by Google.\u00a0Developers had to sign Google papers that basically said Google could still do whatever it wanted.<\/p>\n

We\u2019ve seen this before when a large company tries to elbow its way into an open-source community and yet still maintain control.\u00a0Google had to pass the baton to an independent entity, and that\u2019s how CNCF was started. Kubernetes was its first project.<\/p>\n

Listen to Chris Aniszczyk describe the mission of CNCF as a neutral organization and how it supports the adoption of cloud-native technologies.<\/strong><\/em><\/a><\/p>\n

It was quite an amazing path to get to this point. CNCF now has more than 725 members and has become a premier organization hosting more than\u00a0100 projects<\/a>\u00a0beyond Kubernetes.<\/p>\n

Kubernetes\u2019 dominant position in the market<\/h4>\n

\"\"<\/p>\n

This ETR data above shows container orchestration offerings \u2013 the same XY graph as shown before \u2014 and you can see where Kubernetes lands.\u00a0Notwithstanding that Kubernetes is not a company, respondents know they\u2019re doing Kubernetes. They may not\u00a0know which platform they\u2019re using, but they know it\u2019s Kubernetes.<\/p>\n

The ETR taxonomy has two container categories, container platforms and container orchestration offerings. It\u2019s a challenging topic to survey within the ETR sample because Kubernetes is increasingly becoming embedded into cloud platforms and IT pros may not even know which one they\u2019re specifically using.<\/p>\n

In the diagram above, we link Red Hat OpenShift and Kubernetes because we really think OpenShift is a dominant revenue player in the market as an increasingly popular platform-as-a-service layer. Yes, you can download Kubernetes and do what you want with it, but if you\u2019re building enterprise apps, you\u2019re going to need support, and that\u2019s where OpenShift comes in.<\/p>\n

Tracking container revenue<\/h3>\n

There\u2019s not much market data on container software revenue, but we did find this\u00a0data below from Omdia.<\/a>\u00a0It shows revenue share for\u00a0container software players. It\u2019s not clear how that\u2019s defined, but Red Hat has a nearly 50% revenue share with Mirantis (Docker Swarm), VMware and SUSE (Rancher) in the top four.<\/p>\n

We found some other data from\u00a0Informa<\/a>, but it\u2019s dated. It also had Red Hat as the largest player by revenue, which we believe is accurate \u2014 especially because we know the muscle of IBM is behind OpenShift, which is a linchpin of IBM\u2019s application modernization services strategy.\u00a0IBM can bundle OpenShift into its application modernization services and that gives Red Hat a captive market. We\u2019ve always said that was a key return-on-investment enabler for the Red Hat acquisition and gives IBM an edge in the battle for hybrid cloud.<\/p>\n

\"\"<\/p>\n

Kubernetes under the hood<\/h3>\n

The CNCF recently released its annual survey. A data table from that publication is shown below:<\/p>\n

\"\"<\/p>\n

This past CNCF annual survey had 1,800 respondents, as shown above. The data indicates the following:<\/p>\n