This is the third post in a series about exploring the changing landscape of modern applications. In Part 1, I discuss how organizations started knocking down the wall between software engineers and administrators. In Part 2, I explore the history of containers and how they solved problems for developers and enterprise IT. Before we continue our journey, here’s a brief synopsis of what we’ve covered so far.
Enterprise IT organizations were tired of the cycle of six-month releases and lethargic deployments. They saw companies like Netflix embracing microservices, which helped them leapfrog their competitors. And they wanted to do that too. So they started building applications using microservices, transforming into a DevOps culture, and breaking large teams into smaller ones to build and run these microservices.
But you can run into some problems when you build and run microservices in DevOps teams. For example, one hurdle was packaging applications so you could deploy them in any environment, including a developer’s laptop. Containers solved this issue, but that resulted in having a lot of containers to manage. And that’s where the story of Kubernetes begins.
So let’s get into our time machine and go back to the time just before Kubernetes appeared on the scene.
How We Got Here: The Necessity of Kubernetes
Kubernetes is an application management platform.
As a very short aside, I’ll distinguish it from OpenStack, which was an infrastructure platform. Kubernetes and OpenStack are very different, but they did generate similar levels of interest. Ultimately, Kubernetes has succeeded where OpenStack failed. Why? Kubernetes focuses on where the business value is in Enterprise IT—applications. OpenStack orchestrated infrastructure. But, no matter how good your infrastructure orchestration or management is, you’re not solving business problems if you can’t run an application on top of it.
Platform as a Service (PaaS) provides the infrastructure to run an application and many of the application-specific processes required for daily operations: upgrades, deployments, migrations, and others. Pretty early on—after the birth of the cloud and Infrastructure as a Service (IaaS)—on-demand servers and storage were helpful, but developers still had to do a lot of work to deploy an application to production. They wanted to focus on their code instead of figuring out how to get an app from their laptop onto a server in the cloud somewhere.
Several companies set out to simplify things for developers to deploy and run applications. One of these is Heroku, which Salesforce acquired in 2010 to provide PaaS. Another company, dotCloud, wasn’t as well known as Heroku, but it was probably more influential. The dotCloud team went on to form Docker.
Before Docker, dotCloud built a PaaS for Ruby and Node JS applications. The company wanted to provide a way for developers to easily deploy and run an application without having to focus on operations. Just give the PaaS the code, and the PaaS would run it.
Both Heroku and dotCloud were very developer-centric. But this idea that developers should be able to focus on their applications, not on infrastructure, isn’t applicable only to small-end application developers and startups.
VMware started to create an open-source project that would do the same thing for enterprise applications. This enterprise PaaS became known as Cloud Foundry. It was very successful for a while because CIOs—its main buyers—realized that their developers were having the very same problems that Heroku and dotCloud addressed. But, Cloud Foundry was optimized for enterprises with the security, integrations, and other capabilities they needed.
There was enormous demand from both startups and enterprises for PaaS, but the platforms had some problems. They were opinionated. Using them meant having to change the way you develop applications. If the platforms are going to do the operations for you, you need to provide inputs that are well specified and don’t deviate from a fairly narrow set of boundaries.
One of those boundaries is the ability to run a database on the PaaS. This was considered taboo. In fact, it was a limitation of a PaaS that was almost turned into a commandment: Thou shalt not run data services on a PaaS. In fact, Heroku codified it in its Twelve-Factor App manifesto.
PaaS providers, including Cloud Foundry, made a point that organizations should run their data services outside of the platform. That meant, as Cloud Foundry became more popular and organizations saw more and more benefits, there were large classes of applications that couldn’t run on Cloud Foundry. As a result, the potential benefits of PaaS weren’t fully realized.
This brings us to the rise of Kubernetes. It provides a lot of the same benefits as PaaS by enabling developers to focus on coding rather than operations—but without some of the limits of a very opinionated framework.
The Battle for Orchestration Supremacy
In 2013–2014, most of Silicon Valley was obsessed with figuring out how to manage all of their Docker containers. There were a couple of competing solutions at the time. Mesosphere DC/OS orchestrated entire data centers. (DC/OS stands for data center operating system.) DC/OS could manage both VMs and containers. Docker also realized that people wanted to run a lot of Docker containers, so it created Docker Swarm.
There was a third player: Google. The company had been running some technology for about 10 years, and it was managing millions of containers. (Docker didn’t invent containers: They were in a Linux kernel, and Docker just wrapped them in an API). Google had been running LXC containers for Google Search and YouTube for a decade—millions of containers on tens of thousands of nodes. It was using software called Borg. Google decided to open source Borg, omitting the components that were specific to the company. This became Kubernetes.
So, there were three factions: Kubernetes, Docker, and Mesosphere DC/OS. There are loads of intrigue in the history of this stuff. All the machinations that went into this would make a fantastic show. But spoiler alert: Kubernetes (and Google) won the battle and the orchestration war. Some organizations still use the other orchestrators, but Kubernetes currently represents about 90% of the market.
Where We’re Headed Next
That’s the story of how Kubernetes became so important. The previous generation of PaaS was too opinionated and omitted too many types of applications. Enterprises needed something they could use to run all of their applications, no matter how important—even data services. And Kubernetes enables them to do that.
