If you’ve recently heard a lot of buzz around “containers” and have been curious about container technology lately, you’re far from being alone!
Recently many companies have egarly begun to show more interest in this new variation on virtual machines. Well, now what’s interesting about containers is that while they’re usually compared to VM’s, they’re not and are actually quite different. We will disucss this in the later part of this post.
But one thing we should remember that container technology isnt something new and has been around for more than a decade. The concept of containerization was originally developed, not as an alternative to VM environments, but as a way to segregate namespaces in a Linux operating system for security purposes. The first Linux environments, resembling modern container systems, produced partitions (sometimes called “jails”) within which applications of questionable security or authenticity could be executed without risk to the kernel. The kernel was still responsible for execution, though a layer of abstraction was inserted between the kernel and the workload.
It’s an approach to software development in which pieces of code are packaged in a standardized way so that they can quickly be plugged in and run on the operating system (OS) mostly Linux. Some of the earlier projects taking the container approach have included AIX Workload Partitions, FreeBSD Jails, Solaris Zones, and Unix V7, LXD, OpenVZ or even Java containers like Jetty, Tomcat, Wildfy and Springboot are all examples of container technologies that enable standalone Java applications.
Infact Pivotal has released a nice infographic that shows you the history of Containers, you can find it here
As the use of containers increases and you can go ahead and deploy multiple containers, you need some tools to manage containers across the infrastructure. That’s where the container orchestration tools comes into picture. You can find more about the comman tools that are being used today in this post here
When it comes to Virtual machines, how Different are Containers from them ?
Probably, one way to think of containers vs VMs is that, while VMs run several different operating systems on one compute node, container technology offers the opportunity to virtualize the operating system itself.
Containers are an abstraction at the app layer that packages code and dependencies together. As you can see in the figure a server running containerized applications say with Docker runs a single operating system, and each container shares the operating system kernel with the other containers. Shared parts of the operating system are read only, while each container has its own mount (i.e., a way to access the container) for writing. That means the containers are much more lightweight and use far fewer resources than virtual machines. Containers take up less space than VMs (container images are typically tens of MBs in size), and start almost instantly.
Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space.
Virtual machines (VMs) are an abstraction of physical hardware turning one server into many servers. The hypervisor allows multiple VMs to run on a single machine. Each VM includes a full copy of an operating system, one or more apps, necessary binaries and libraries – taking up tens of GBs. VMs can also be slow to boot
With virtualization technology, the package that can be passed around is a virtual machine, and it includes an entire operating system as well as the application. A physical server running three virtual machines would have a hypervisor and three separate operating systems running on top of it.
However, you can run containers ontop of your virtualsation layer within the virtual mahines. Containers and VMs used together provide a great deal of flexibility in deploying and managing apps.
Why use containers ?
A container may be only tens of megabytes in size, whereas a virtual machine with its own entire operating system may be several gigabytes in size. Because of this, a single server can host far more containers than virtual machines.
Another major benefit is that virtual machines may take several minutes to boot up their operating systems and begin running the applications they host, while containerized applications can be started almost instantly. That means containers can be instantiated in a “just in time” fashion when they are needed and can disappear when they are no longer required, freeing up resources on their hosts.
A third benefit is that containerization allows for greater modularity. Rather than run an entire complex application inside a single container, the application can be split in to modules (such as the database, the application front end, and so on). This is the so-called microservices approach. Applications built in this way are easier to manage because each module is relatively simple, and changes can be made to modules without having to rebuild the entire application. Because containers are so lightweight, individual modules (or microservices) can be instantiated only when they are needed and are available almost immediately.
You can also go through below videos that can help you understand about containers
1. What is Container – by VMware
2. Containers 101 – by VMware