Applications running in Linux containers are isolated within a single copy of the operating system running on a physical server. This approach stands in contrast to hypervisor-based virtualization in which each application is bound to a complete copy of a guest operating system and communicates with the hardware through the intervening hypervisor. As a result, containers consume very few system resources such as memory and impose essentially no performance overhead on the application.
One of the implications of using containers is that the operating system copies running in a given environment tend to be relatively homogeneous because they are essentially acting as a sort of common shared substrate for all the applications running above. Specific dependencies can be packaged with the application (within an isolated process in userspace), but the kernel is shared among the containers running on a system.
The operating system is therefore not being configured, tuned, integrated, and ultimately married to a single application as was the historic norm, but it's no less important for that change. In fact, because the operating system provides the framework and support for all the containers sitting above it, it plays an even greater role than in the case of hardware server virtualization where that host was a hypervisor. (Of course, in the case of KVM for example, the hypervisor makes use of the operating system for the operating system-like functions that it needs, but there’s nothing inherent in the hypervisor architecture requiring that.)
All the security hardening, performance tuning, reliability engineering, and certifications that apply to the virtualized world still apply in the containerized one. And, in fact, the operating system shoulders a greater responsibility for providing security and resource isolation than in the case where a hypervisor is handling some of those tasks. We’re also moving toward a future in which the operating system explicitly deals with multi-host applications, serving as an orchestrator and scheduler for them. This includes modeling the app across multiple hosts and containers and providing the services and APIs to place the apps onto the appropriate resources. In other words, Linux is evolving to support an environment in which the “computer” is increasingly a complex of connected systems rather than a single discrete server.
In such an environment, it's also increasingly important to have a mechanism to portably compose applications. The general concept is nothing particularly new. Throughout the aughts, as an industry analyst, I spent a fair bit of time writing research notes about the various virtualization and partitioning technologies available at the time. One such set of techs was “application virtualization.” As a category, application virtualization remained something of a niche but it’s been re-imagined of late. Technologies including Docker are taking advantage of the containers model to create something which looks an awful lot like what application virtualization was intended to accomplish: compose applications as a set of layers and move them around an environment with low overhead.
Yes, there is absolutely an ongoing abstraction of the operating system; we’re moving away from the handcrafted and hardcoded operating instances that accompanied each application instance—just as we previously moved away from operating system instances lovingly crafted for each individual server. And, yes, applications that depend on this sort of extensive operating system customization to work are not a good match for a containerized environment. One of the trends that makes containers so interesting today in a way that they were not (beyond a niche) a decade ago is the wholesale shift toward more portable and less stateful application instances. The operating system's role remains central; it’s just that you’re using a standard base image across all of your applications rather than taking that standard base image and tweaking it for each individual one.
Add it all together and applications become much more adaptable, much more mobile, much more distributed, and much more lightweight. Their placement and provisioning becomes more automated. But they still need to run on something. Something solid. Something open. Something that's capable of evolving for new requirements and new types of workloads. And that something is a (Linux) operating system.
7 Comments