Linux Container Operating Systems: Thin Is In

8 Linux Security Improvements In 8 Years

When is less really more? When it's a Linux operating system designed to run containers, such as Red Hat Atomic Host, Ubuntu Snappy, or CoreOS. As developers increasingly embrace containers for building and running apps, these small footprint systems could change the operating system's long-standing role as a catch-all for historic but less-important functions, like fax servers.

The small size is all about speed -- an inactive container operating system at rest in solid state memory can be called up and running in 1.5 seconds, letting containers scale up much faster than the equivalent virtual machine. As a result, cloud computing software stacks will offer a container operating system -- if possible, one that offers their customers advantage over other cloud stacks.

Because of their efficiency, containers and container operating systems are used in applications such as Google search, where millions of small tasks are presented to clustered operating systems 24 hours a day. Google builds (and destroys) two billion containers a week, with many running copies of the container operating system holding it on that pace.

Just how small are these container operating systems? CoreOS Inc.'s CoreOS system "is the equivalent of about 25 pictures on your phone," says CEO Alex Polvi. The whole operating system adds up to about 100 megabytes of RAM, he estimates.

Red Hat expresses the size issue a different way: 6,000 open source code packages go into a full assembly of Red Hat Enterprise Linux, while about 300 go into its Atomic Host for running containers. Whether measured in smartphone pictures, megabytes of memory, or source code modules, the container operating system is weighing in at one-twentieth or less of the typical Linux distribution.

[Want to see the extent VMware has gotten involved in the wave of container interest? See VMware Rides Container Wave With Open Source Projects.]

In part that's because Linux containers have reversed the priorities for server operating systems, which until recently had to be all things to all people over a long time period. The same is true of Windows Server, and why it needs at least 3-4 GB of disk when it gets installed, while Windows Nano, the version designed to run Docker containers, needs only a fraction of that.

For example, Windows Server still includes all the code needed to set up a fax server, even though many offices have discontinued the use of fax machines. It's one example of how Windows and Linux in their full-bore implementations "have become catch-all repositories -- in some cases, virtual software junkyards" for subsystems and specialized functionality that's no longer relevant, write IDC software analysts Al Hilwa, Gary Chen, and Al Gillen in Can Less OS Really Be More?

Critics call it operating system bloat, but no one sets out to create bloated server software. It's just that when the operating system owner announces something is about to be discontinued, "these features can't be dropped since they remain useful to a shrinking portion of the customer base," and they hear from that portion, the writers conclude.

Containers aren't a direct response to operating system bloat. They became popular (led by Docker) as a way for developers to quickly package up their code and move it to other members of the team, to a central repository, or to a prospective production environment. But once containers became popular, the need for much of the functionality that gives operating systems their bloat went away.

Containers hold the application code and some of its immediate dependencies, like a lightweight Tomcat server, in a series of file system layers that reflect the order in which they should be booted up. In Docker's case, they also dictate specifications for the Linux environment in which they're to run. All a container operating system needs to do is grab such metadata, set operational parameters, and load the image.

That means the operating system can be limited to those functions the kernel and only the kernel performs, such as memory management, task scheduling, process execution tracking, and calling the appropriate device driver, when needed. The result: bloat discarded, essential function remains.

Four Container Operating Systems To Watch

Red Hat Atomic Host: Red Hat was early out of the blocks with pledged support of Docker last spring, making that support part of Red Hat Enterprise Linux 7 in June last year. It followed with a beta release of Red Hat Atomic Host container operating system, based on RHEL 7, in October. Atomic Host became generally available in March 5.

Atomic Host is a key playing card for Red Hat as it attempts to win support for its OpenShift platform-as-a-service. OpenShift saw some of its supporters migrate in the direction of Cloud Foundry last year as that project joined the Linux Foundation and gained its own independent board of governors. As a result, OpenShift faces an uphill battle, but Atomic Host is guaranteed to work with other elements in the Red Hat pantheon of products, making it a possible target system for application developers. 

In addition, Red Hat this week announced in Vancouver at the opening of the OpenStack Summit that OpenShift can be folded into Red Hat's distribution of OpenStack designed to run both virtual machines and containers. The announcement means development in the cloud can occur on the same platform as deployment, giving enterprises a broad new software stack on which to establish a private cloud, while interoperating with a public cloud. A container operating system is an implicit necessary ingredient. Red Hat's got one.

CoreOS: CoreOS is a newcomer as a two-year-old startup out of San Francisco, but it's break-out from the Docker open source project, the launch of its own container runtime (Rocket), and its growing presence as a supplier of a slenderized, container operating system has garnered it plenty of attention. CoreOS played a bit of one-upmanship by proposing a Linux container specification and calling on Docker to adhere to the spec. The fact that Google Ventures supplied the startup with $40 million in capital in April wasn't missed by many container enthusiasts either. CoreOS has a shot at becoming one of the winners in the race to become one of two or three container operating systems to get firmly established.

Ubuntu Snappy: Snappy is less of a known quantity, but Ubuntu remains one of the most popular Linuxes with which to build an OpenStack cloud. In the long run OpenStack and some form of open source development, whether Cloud Foundry or OpenShift or something else, is likely to serve as a broad developer base for building microservice, containerized applications. If Ubuntu OpenStack gets widely adopted, the company is ready with a container operating system.

Cloud Foundry keeps coming up because it's lurking in the background as one of the best integrated open source platforms available for building containerized applications. Pivotal's VP and general manager of the Cloud Platform Group James Watters said at the recent Cloud Foundry Summit that Cloud Foundry also wants a container operating system but hasn't settled on any of the available alternatives.

Important Cloud Foundry sponsors, including VMware, are in direct competition with Red Hat on virtualization and managing the Linux servers in the enterprise data center. VMware, Pivotal, and other sponsors are wary of Docker's ambitions and how they may cut into the existing fields of virtualization software and development platforms. As a result, Cloud Foundry is unlikely to go with any of the existing choices and could wait for the fourth option we'll highlight: Photon, a container operating system VMware is producing.

Photon: VMware has proven chops in managing virtualized environments, and many data center operations managers are adopting its view that in the long run, virtual machines and containers will be working in the enterprise data center together. If that's the case, and VMware aspires to manage both forms of application isolation, then VMware needs its own container operating system inside its software stack.

Photon would be a fourth entrant into the container operating system race, and four is one more than the typical broad technology market is likely to sustain over time. At this point, it's hard to tell who will emerge with the upper hand. But what is clear is that bloat is out, and thin is in.