In this second post of a four-part series, we restart our Kubernetes journey with containers. Microsoft tells us that:
Containers are a technology for packaging and running Windows and Linux applications across diverse environments on-premises and in the cloud. Containers provide a lightweight, isolated environment that makes apps easier to develop, deploy, and manage. Containers start and stop quickly, making them ideal for apps that need to rapidly adapt to changing demand. The lightweight nature of containers also make them a useful tool for increasing the density and utilization of your infrastructure.
I use Microsoft as a reference here because their definition is succinct, and they make the point that containers are useful for any application environment, and Linux is not the only path to hosting containers. This is important to fundamentally appreciate the utility and universality of containers.
Let’s take a look at the canonical diagram for comparing traditional virtualization to containers and the evolution from scale-up bare metal hardware:
In the long ago past, when an organization deployed an application it would first provision the hardware platform. Application deployment took weeks or months. Enter virtualized infrastructure spearheaded by VMware.
While virtualization was supported in mainframe and other specialized environments, it was not until the x86 platforms were virtualized that virtualization was adopted ubiquitously. A virtual machine via a hypervisor can safely run multiple different applications on a single physical host. The application-protected sandbox here is a virtual machine where each application (or set of related applications) run on their own copy of an operating system, reducing the operating system for all intents and purposes to an application-specific runtime library. Each (potentially different) operating system runs in its own VM which emulates a full, independent machine effectively separating applications into their own sandbox. Resource allocations, such as memory and CPU cores, could be doled out to each application on a case by case basis.
As I mentioned in the last post, while the initial impetus for virtualization was gaining access to unused CPU capacity as multicore CPUs became dominant, it was the emergence of the software defined and orchestrated data center that became the data-center-wide architectural impact of virtualization. Applications were launched to increasingly commoditized hardware platforms via a software command. Provisioning an application now took minutes instead of weeks. And for a while, we could say the rest was history.
Until containers came along.
If you squint your eyes, containers resemble virtualized instances. Virtualization and containerization both provide a protected sandbox in which to execute an application, but in very different ways. Containerization is a lighter weight mechanism that abstracts only the necessary parts of the host operating system to provide a set of services specific to a given application (or set of applications) in a container.
As the Kubernetes site states “Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.” But the underlying host operating system is shared amongst containerized applications. Now, a container is not as transparent to the application as a virtual machine is. Containerizing your application is a bit more work, but companies including Docker and Microsoft are making the process easier for legacy applications. New applications intended for deployment in containers are being crafted as cooperating microservices, which fully unleashes the potential of containerized applications. Now application provisioning that took minutes in a virtualized environment takes seconds in the lightweight containerized infrastructure. Further, containers lend themselves to agile development and infrastructure and fueled the DevOps movement to a degree that virtualization never did.
Docker emerged in 2013 to launch the modern container revolution, and the world is a better place for it. If you’re interested, this article describes the fascinating history of all the techniques that eventually resulted in containers as we know them today.
So, what’s the downside of containers? Running different applications requiring very different runtime environments, that is different operating systems such as Windows or Linux, on a containerized host is harder. Containers are lightweight because they share much of the underlying infrastructure on a physical host. Docker and Microsoft do provide a solution to run containerized Linux apps on Windows 10, which makes Windows as a containerization platform pretty interesting. But like many aspects of the container world, things are continuing to evolve.
As more companies adopt containers as a strategy, they are looking to standardization of APIs to give them flexibility and protection of their investments. One of the first APIs to be standardized is the Container Runtime Interface (CRI) in Kubernetes. You see, there is more than one container solution out there. Besides Docker, which really got this whole container movement going in a big way, there are other methods of packaging your application as a container. An up and comer is containerd, which lives alongside much of the Kubernetes technology under the Cloud Native Computing Foundation (CNCF) umbrella. Different containerization approaches provide slightly different capabilities when packaging an application, and CRI allows you to buffer your Kubernetes deployment from the details of any one particular container approach – and even to run multiple container approaches simultaneously.
And now we’re back to a Kubernetes discussion. Containers were accepted and adopted without much fanfare. Virtualization had already proven the technique of application partitioning to be worthwhile. What was lacking around containers was a method of managing containers in the large. Containers encourage a nimble data center where you start up services and move them quickly. Orchestration became the key to container enablement in the end. And Kubernetes has emerged as the runaway leader for the next generation data center orchestration.
This is just a reminder, that the thing to expect in the Kubernetes world is change. The technology and solutions continue to evolve rapidly.
Next up in this blog series is a required dive into scale-out applications.