Episode 56
Container revolution is one of the hottest topics nowadays in software development industry. The little blue whale, the Docker logo, can be seen on most programming conferences as well as numerous Twitter feeds of, so called, IT influencers.
Today, along with containers, we will talk about their older and fatter siblings: virtual machines. It’s good to understand similarities and differences between those two and how to take advantage of that. We will talk about what containers are and what they are not. Contrary to what might have seem, containers did not render virtual machines entirely obsolete and there are reasons to use both.
Virtual Machines
Virtual machines are emulations of computer architectures and provide functionality of a physical machine using appropriate combination of software and hardware. It’s not a new concept, as first implementation dates back to systems developed in the sixties like IBM CP-40. They are commonly used to run multiple instances of independent or even totally different operating systems on a single computer, for example to easily test software in different environments or to run many enterprise applications in isolation on powerful server machine.
Full virtualization is the desired state, where all features of underlying machine are available, and VMs are truly isolated. It requires a designated hardware support to be implemented efficiently as of Popek and Goldberg virtualization requirements. Surprisingly, those were met quite late in x86 architectures, only with introduction of Intel’s VT-x instruction set extension in 2005 and AMD-V soon after.
Hypervisor is a software / hardware component which creates, runs and manages virtual machines. They are two main types of hypervisors. Native, or type one hypervisor is sitting atop of bare metal, even before the actual operating system. An example is Microsoft Hyper-V, which runs Windows operating system instances on x86 architecture. The other is hosted hypervisor, or type two, which runs atop of operating system, common example being VirtualBox.
Although virtualization is not new, it started to gain rapid popularity around 2005 with hardware support additions. Increasing computing power, growing popularity of multi core processors, optimization and management of server farms were main reasons for fast adaptation.
Containers
I wrote just little bit about containers in episode 50. They are called system-level virtualization, although some people argue that containers are not virtualization nor lightweight VMs. Well, that’s partially true, because they use different technology than virtualization. Virtualization emulate entire physical machine and you can do whatever you want with it, for example install any operating system that runs on that machine and play with it. Multiple VMs share only the physical machine and nothing else.
Containers, on the other hand, use operating system features that allow for multiple, independent logical operating systems. Each of them has its own process tree, file system, network namespaces, user space. But in fact, there is only one physical operating system that provides all that. Multiple containers share common operating system kernel.
A good metaphor for this are houses and apartments. Both offer shelter and you can do similar things inside. However, house is a self-contained entity, and apartments inside apartment building share common infrastructure like water, electricity or stairs. Apartments in single building can be of different size, but they can’t exist without the building itself.
Container engine is to container as hypervisor is to virtual machine. It stores their offline, binary representations called images. It creates live, running container from those images, starts them, stops them, and destroys them. It can link them together, expose their network ports to outside world and do all kind of other fancy stuff. There is an entire different topic called container orchestration, but it’s about managing containers across different hosts and is out of scope of this article.
No Silver Bullet
Containers have tremendous advantage over VMs. Because they share a common kernel, they take much less space and start much faster than VMs. Looks like no-brainer, but…
Securing container is much more troublesome than VMs. In theory, they are isolated, but in practice it might not be the case. Not all resources of operating system are truly separated, and there is room to crack things.
You are stuck to a single operating system. That might not be a problem, but VMS give you much more freedom in this regard. Some application only runs on some exotic environment? No problem, give it a VM and you are good to go.
If you don’t run a server farm, but a testing workstation, you might like VMs with different operating systems or just different configurations and applications installed to have diverse environments at your disposal.
The choice depends on your needs. I won’t delve into much details here, since this article is meant as an introduction. If you want more on choice, check out this one. See you next week, stay tuned!
Images by:
How To Train Your Java 
2 responses to “Virtualization and Containers Intro”