Application Strategy and Digital Transformation Series - Part 2

Transform your virtualization journey with Containers – Get your basics right

Our first post gave you a sneak preview of containers. A container is a type of virtualization like virtual machines or virtual memory. But the edge it has over VM is in its ability to virtualize not only the hardware resources like CPU and RAM but also the OS resources like file system, registry, process tree etc.

Hence it is also called OS virtualization.

Containers provide virtual environments similar to virtual machines but they aren’t virtual machines. Here are the core similarities and differences between containers and VM:

• Like virtual machines, containers share same system resources to access compute, storage and networking
• Unlike VM, they don’t have a separate guest OS and all containers in a host share the same OS kernel

In simple words, a container is an execution of an application environment which can be persisted, versioned, packaged and shipped to different systems and then can quickly run on different systems without any installations or configuration set up. These containerized environments are lightweight, isolated and underlying OS dependents. The below picture depicts the stack view in VM and containers:

Getting a hold on containers’ functioning

Now, let’s try to understand how containers perform their tasks. From the above figure, it’s evident that the container-based virtualization works at an operating system level. Thus, all the virtual instances share a single OS kernel. Also, for the purpose of isolation, dedicated multiple user-space instances are created for each container.
As isolation is realized by using user space and not through a separate OS, container-based virtualization is expected to have weaker isolation than hypervisor-based virtualization. However for users, each container looks and executes exactly like a stand-alone OS. It achieves virtualization by engaging a set of techniques thereby fooling the running container/ application into believing that it’s the only container/ application running on the host even though there may be many others running simultaneously. These techniques are-

1. Isolation: In container-based virtualization, instance isolation is usually done by namespaces isolation. With this feature, different processes have different views on the system. Since applications are dependent on/ need support from OS resources such as file systems, network ports and the list of running processes, all such global resources are wrapped in a layer of virtual name space which provides an illusion that the container is its own system. With this restricted view, a container can’t view files or processes not included in its virtualized namespace and thus, can’t access them regardless of their permissions. Also, the container is unable to list or interact with applications that are not its part. To the running container, it appears that the underlying OS resources such as file, memory and other running processes are dedicated to itself.
2. Control groups: The next part is virtualizing computing resources and resources management/ governance. This is usually performed by Control Groups (cgroup – in Linux/ other native implementation specific to operating system). By using cgroups/ native mechanism, it is possible to allocate/ limit/ prioritize CPU, memory and I/O usage for each running container inside a host.

Comparison with big brother VM

Before we wind-up this post and move further on our journey to discover containers, let’s have a quick comparison with its big brother VM. Following table compares VM and containers on some key parameters:

But implementing this technology, though pretty useful, is no cake-walk as you will understand through our next post. But as usual, Hexaware will be there to guide you.

References