How CI/CD and Microservices Led to Kubernetes: Kube Explained Part 1

Engineering teams have always had constant pressure to deliver software faster, cheaper, and more reliably. As a result, many of the recent trends in backend infrastructure have been driven by these factors.Kubernetes, microservices, containers - the technologies that we collectively refer to as “cloud-native” - are helping engineers deploy software to the cloud more rapidly and at greater scale. Together, they represent the most significant innovation in backend infrastructure since the introduction of the cloud in the first place.While it may seem like these new tools emerged from the technological ether, in fact, they're rooted in pervasive organizational pressures going back to before the invention of the cloud. How teams of engineers work together to deliver software has driven the need for cloud-native design that we see today.So what organizational trends have led to the creation of cloud-native, and why?

The Emergence of CI/CD and Microservices

Before the cloud, the primary bottleneck to deploying software was the provisioning and management of physical hardware. New services required:

• New servers to be purchased and delivered.
• The servers to be installed in a datacenter.
• An administrator to configure them.

Together, these tasks required weeks of time and effort. It didn't matter how amazingly efficient your QA or deployment processes happened to be, as any speed gains in these areas would be dwarfed by the inefficiency of the hardware deployment process.The cloud, for the first time, allowed new compute to be provisioned in minutes. As a result, the primary bottleneck to deploying software shifted from provisioning hardware to engineering procedures governing software deployment. Below we'll describe in more detail how this bottleneck manifested and how CI/CD and microservices emerged to solve them.

CI/CD

At the time the cloud emerged, the process for deploying software was mostly manual – It looked something like this:

• A developer writes the software.
• A separate quality assurance team tests the software.
• The operations team deploys the software.

This process was extremely inefficient. It relied heavily on human effort that was highly error-prone. As a result of all this inefficiency, teams were standardizing on a two-week deployment sprint during which a batch of changes would be coded, tested, and deployed. Two weeks was a massive improvement over the worst of the pre-cloud era, but still left lots of room for improvement.

The main idea behind Continuous Integration / Continuous Delivery (CI/CD), was to automate the testing and deployment process completely. QA engineers and operators were no longer needed to test and deploy manually. Instead, they could write code that tests and deploys software for them. As a result, around this time, you start to see CI/CD platforms like Jenkins and infrastructure automation tools like Chef and Puppet gain popularity. With this new philosophy and a new set of tools, deployment times decreased from two weeks to less than two hours.

Microservices

When the cloud emerged, most teams were using what we now call a monolithic architecture. All of the code written by the entire engineering team would be compiled into a single large binary and deployed. From a purely technical perspective, this approach has a lot of advantages: it's easy to understand, debug, and operate. However, from an organizational perspective, it leads to unnecessary interdependence between development teams.As a result of this architecture, deploys to production were naturally batched – code changes bundled into a single monolith hit production at the same time. This made software engineers highly interdependent, constantly blocking on each other and unable to make independent progress.As a result, the concept of microservices emerged. Microservices replace the monolith with many small independent services, each of which has its own separate deployment pipeline and lifecycle. For the first time, microservices freed teams to make progress and deploy independently.

The Emergence of Kubernetes

While CI/CD and microservices made deploying software to the cloud more efficient, they also introduced new complexities and operational challenges. CI/CD dramatically increased the frequency with which we deploy software to production, and microservices increased the number of services that must be managed.Worse still, at the time the cloud first emerged, there was no standardized deployment artifact. Every microservice had its own peculiarities in terms of how it was packaged, started, stopped, monitored, and maintained. These differences were manageable when operators needed only contend with a relatively infrequently changing monolith. But once microservices and CI/CD emerged, the velocity of change made it untenable.Finally, as these trends gained popularity, containers emerged. One can think of a container as a fully standardized deployment artifact that has consistent packaging, distribution, monitoring, and lifecycle. Microservices packaged in containers allow infrastructure to be utterly ignorant of the particular details of their implementation, making them much easier to manage.Furthermore, as the deployment artifact finally standardized through containers, it became possible to build a general-purpose system that manages fleets of those containers. Kubernetes emerged as the inevitable result of these trends.Thus, we find ourselves today in a world where cloud-native tools are enabling software engineering teams to smooth out a process that was disrupted by the advent of cloud computing years ago. These tools did not emerge without reason, instead, they are the logical outcome of persistent pressure to deliver software faster, more reliably, and at greater scale.In Part 2 of “Kube Explained”, we'll discuss how these tools work together to produce today's standard cloud-native architecture and cover Docker and Kubernetes in more detail, and how  fits into the broader picture. Stay tuned.

Previously published at