By Jamie Duncan and John Osborne


Save 37% off OpenShift in Action with code fccduncan at manning.com.

Technology use cases

If you stop and think about it for a minute, you can hang the major innovations in IT on a timeline of people seeking more efficient process isolation. Starting out at mainframes, we were able to isolate applications more effectively with the client-server model and the x86 revolution. That was followed by the virtualization revolution. Multiple virtual machines can run on a single physical server. This gives administrators better density in their datacenters while still isolating processes from each other. With virtual machines, processes were isolated within each virtual machine. Because each virtual machine has a full operating system and a full kernel (figure 1), it needs all of the filesystems required for a full operating system. That also means they must be patched and managed and treated like traditional infrastructure.

Figure 1. Virtual machines being used for process isolation

Containers are the next step in this evolution. Inside an application container is everything the application needs to run:

  • Source code or compiled code for the application
  • Libraries or applications needed for the application to run properly
  • Configurations and information about connecting to shared data sources

What containers don’t contain is equally important. Unlike virtual machines, containers all run on a single, shared Linux kernel. To isolate the applications, containers use components inside the kernel (figure 2).

Figure 2. Containers use a single kernel to server applications, saving space and resources and providing flexible application platforms.

Because containers don’t have to include a full kernel to serve their application, along with all of the dependencies of an operating system, they tend to be much smaller. For example, where a typical virtual machine starts out with a 10 Gigabyte (GB) or larger disk, the CentOS 7 container image is 140 Megabytes (MB). Being smaller comes with a couple of advantages. First, portability is enhanced. Moving 140MB from one server to another is much faster than moving 10GB or more.

Secondly, because starting a container doesn’t include booting up an entire kernel, the startup process is much faster. Starting a container is typically measured in milliseconds, as opposed to seconds or minutes for virtual machines. The technologies behind containers provide multiple technical benefits. Additionally, they provide business advantages as well.

Use cases for businesses

Modern business solutions have to include some sort of time or resource savings as part of their design. Solutions today have to be able to better use resources, both human and computer. Containers’ ability to enable both types of savings is one the major reasons they’ve exploded on the scene the way they have.


When you compare a server using virtual machines to isolate processes to one using containers to do the same thing, you notice a few key differences (figure 3):

  • Containers use more of the server’s resources to serve applications. Because there’s only one shared kernel when running containers, instead of multiple virtualized kernels in virtual machines, more server resources are used for the applications.
  • Application density increases with containers. Because the basic unit used to deploy applications (container images) is much smaller than the unit for virtual machines (virtual machine images), more applications can fit per server. This means more applications take fewer servers to run.

Figure 3. Hypervisor server running virtual machines vs. Server running containers

Even though containers are great tools they aren’t always the best tool to use for every job. Let’s discuss a few times when containers aren’t the best fit.

When containers aren’t the answer

An ever-increasing number of workloads are good fits for containers. The container revolution started out with pure web applications, but now includes command line tools, desktop tools, and even relational databases. Even with the massive growth of use cases for containers, there are times when they aren’t a great fit.


If you have a complex legacy application, be careful when deciding to break it down and convert it to a series of containers. If an application is going to be around for eighteen months, and it’s going to take nine months of work properly containerize it, you may want to leave it where it is. It’s OK. We promise.


Containers started in the enterprise IT world. They’re designed to work with most storage and networking solutions, but they don’t work with all of them easily. When you’re using networking solutions like Infiniband, or storage solutions like Lustre, containers can be a challenge.

Infiniband is (en.wikipedia.org/wiki/InfiniBand) a high-performance networking standard which is often found in high performance computing (HPC) environments.

Lustre’s (lustre.org/) a high-performance parallel filesystem which is often found in HPC environments.


Some applications are always going to be huge, resource-intensive monolithic applications. Examples are software used to run HR departments, and some huge relational databases. If a single application is going to take up multiple servers on its own, running it inside a container that wants to share resources with other applications on a server doesn’t make a lot of sense.

Now that you have some more information on when (and when not) to use OpenShift for enterprise container management, maybe you’re ready to learn more. Check out the first chapter of OpenShift in Action for free here, and see this slide deck.