An Introduction to Containers

Terms like containers, Docker, Kubernetes and DC/OS are becoming more common in software magazines and CIO forums. What are containers and why do software developers need them? What problems do they solve? How do containers relate to Docker, Kubernetes and DC/OS?

A few years ago, the only way to run an application was to use a physical machine, i.e., to run it directly on hardware. These physical machines came from different manufacturers (and hence had different drivers), were of different classifications (server or desktop, etc.), came in different sizes and ran different operating systems (OS). The application would need to know which machine and what OS it was running on and manage accordingly. Those were the days when consumers downloaded a Windows®, Macintosh or Linux version of the application. The right version of the application would need to be installed on the machine and would execute only on that hardware. Maintaining multiple versions of each application, a lack of mobility from one type of hardware to another, and different support structures were some of the things that made the process very inefficient for developers and consumers.

Then the industry came up with the idea of virtual machines (VM). Virtualization technology enabled the running of multiple virtual machines on a single physical machine. Each VM had its own OS, application and system utilities. The various VMs on a single physical machine used the same physical memory and CPU on a time slice basis. The biggest advantage was that an application did not need to know what physical machine it was running on, and hence became hardware-independent. The VM was supposed to insulate the application from the hardware. Products like VMware and Microsoft® Hyper V provided VM mechanisms. The other big advantage with VMs was that a rogue application could kill a VM, but it could not kill the hardware; other VMs and applications could continue executing even with the rogue application. However, the application still had to know which OS it was running on and had to be version-dependent, e.g., a Microsoft® Windows 10 version and a Microsoft Windows 7 version.

With the advent of the cloud, the software community focused on making application development totally independent of the OS, hardware and other associated software involved in running it. For example, how could an application that was tested on Microsoft .Net framework 3.5 work when it was run on a system that had Microsoft .Net framework 4.5? How could an application developed for Azure execute on AWS without being bogged down by hardware, the OS and other factors outside of the developer’s control?

The answer to these questions is to use containers. Containers make applications mobile across different environments. A container holds only the application and application-specific utilities. The OS, software package and other system-related utilities are outside the container. Container management software takes care of the interaction between the application inside the container and the environment outside the container (either VM or physical machine), making the application independent of the environment. The picture below shows the physical machine, virtual machine manager and container manager scenarios described above.

Besides application mobility, there are two other major advantages of using containers.

1. Speed of initiation. Containers can be quickly initiated and shut down since they do not have bulky system components. Developers can initiate and shut down containers relatively quickly, utilizing resources only when needed. They are very fast and efficient.
2. Modularity. Containers can also be made very small and modular. These features allow an application to be broken into components, with each component executing over different containers. Also, modularity makes reuse possible. One container could manage a database, another the I/O devices, and a third could house the business logic, etc.

The first container technology that became well known was Docker. Docker became so popular that it was almost synonymous with container management software; its Enterprise Edition is probably the best-known container management solution. Docker was originally meant only for Linux, but with Windows Server 2016 and Windows 10, it can now run independently of the OS. In the meantime, Google created another container management software called Kubernetes, which builds on 15 years of running production workloads at Google. Kubernetes is also catching on very well among application developers.

Containers are extremely secure because they do not have the vulnerabilities of operating systems. Even if vulnerabilities are exploited, container technology allows applications to be quickly moved around without much impact to the consumer.

Mobile device management software (MDM) also uses the concept of a container, but in a slightly different way. MDMs create a container for security and house different types of data in different containers. For example, an enterprise may need to house proprietary company data in one container and personal data in another, but both containers are on the same mobile device. This gives the user freedom to have one device, while the company maintains the desired data security. The company can decide how to control the container, i.e., when and what to deploy or how long to keep the data, while the end user can control the operation of his personal container.

While container technology is starting to be used more and more by developers, it will be interesting to see if containers will replace virtualization. There is probably a need for both technologies in the long run. Not all applications need the mobility that containers provide, while others may choose to run on physical machines to avoid paying the “container-tax” or “virtualization-tax.” However, with containers, the technology to enable application mobility is now available to application developers.