Containers Dissected … almost

HCL recently entered into partnership with Mesosphere and it’s been a long time since I blogged…. So I thought I got to put something. I was discussing about increasing ‘utilization efficiency’ of servers could hit breaks when discussion came towards the difference between hypervisor based VM and Containers. Verbal exchange apart, I thought this has to be the topic for today’s blog…so here goes.

First let us look at what happens with hypervisors:

In a VM based environment the Hypervisor is a fundamentally a Virtual Machine Emulator that creates logical processor, memory, network, disk and other interfaces completely ‘fooling’ the OS running in the guest OS to think it has control of the physical hardware. To do this the Hypervisor lets the OS boot up from its own image and run its own kernel, user land and user applications as per the image in the boot up disk. What the Guess OS actually gets is ‘an’ isolated process from the Host OS which could be given access to some or all the host’s cpus with policing. Similarly, the memory is completely isolated for the Guest and if needed overprovisioned. Network is provided using a variety of virtual networks (host only, bridged, open, direct NIC access etc.). Disks also are ultimately actually files located either locally or remotely. Bottom-line the guest has no access to both its host and its peers (other guest VMs).

This is great but things like boot up speed and physical size of the VM makes it feel slow and restricts mobility. And this is where containers come into the picture providing speed and mobility with a few compromises

In lieu of the Hypervisor in the VM world, the container has the ‘Container Engine’…Names can vary based on vendor but let’s call it container engine, CE in short. Now unlike the Hypervisor, the CE does not perform any emulation but rather runs the user land in an isolated process of the host OS. It further uses the very many tools available to control the access between the application in the Container and the host Resources. From a Process perspective the Host sees the container as just another application process forking sub processes. It also has capability to manipulate the container processes. The reverse is however blocked by the CE so the Container thinks it is the only process running. All other resources are similarly isolated like container has access to the host memory directly but CE can restrict the quantity of memory used. Network also is further provided using virtual networks and physical network access is not available to the container. Access to disk is managed by restricting to a folder in the host OS’s Disk or mounting a remote disk.

Bottom-line Containers ensure that applications run inside containers are isolated form their peers and the host but effectively work on the host’s kernel and its capabilities.

This technique however is not unique unlike how it is being projected by Docker and other Container Players. Isolated Execution environments have always been provided by JVM multi-tenancy and non-isolated application execution has been provided by the very many application servers (Tomcat, Windows Application Server, WebSphere etc.).

The value that containers bring is the capability to specify the environment in which the developer wants the application to work, develop the app in such an environment and ensure that the exact same environment is built when the app is run in production. That is a capability that other multi app serving solutions have not been able to provide for ages.

Before I finish I do want to mention one stray case here: VMware vSphere Integrated Containers (VIC). The Architecture above fits well for Docker engine, rkt, warden etc.…but the Architecture for VIC seems completely different. Will update this blog after further investigation.