Introduction
“Well, it is working absolutely fine in my machine”, said Bob, the Software developer. “Why don’t you just ship your machine to the customer? I will give you the courier charges!”, retorted Alice, the QA of the team. Alice and Bob argued about a new feature they were about to ship. Bob’s environment reflected the changes, but Alice’s test environment did not.
Have you ever wondered why this happened? When the developers develop an application, they install lots of dependencies and libraries in their machine. Sometimes, they also need to perform some OS level configurations. Once the feature is developed, they send it to the QA for testing. They also need to send all the dependencies, libraries and OS level configurations along with the application for testing.
Often, some of the dependencies and libraries must have already existed in the developer’s machine and they don’t know about it. They may not send it to the QA and hence, the application behaves anomalously. So how can this issue be solved? This is when the ‘Hypervisors’ arrived.
HYPERVISORS
To understand the concept of Hypervisor, let us imagine two kinds of Houses:
- An individual Villa
- A single residential unit in a building
A villa is built on a piece of land that exclusively belongs to the owner of the villa. It has its own exclusive plumbing, electrical and drainage systems. It obviously has multiple rooms and furniture.
A residential unit in a building will have its own rooms and furniture. However, it shares the plumbing, electrical and drainage systems with other residences in the building. The land on which the building is built also belongs to every resident’s owner.
If the above difference is very clear to you, we can similarly state that the standalone server is like the Villa whereas the Virtual machine is the residential unit in a building.
A virtual machine is a software running on the top of a real Physical machine, that shares the resources of the physical machine, but it gives you the illusion of being an actual complete real machine. Just like that flat in a building that looks like a complete house but shares resources with other flats.
Hypervisor is a Software that enables you to run Multiple virtual machines on a single hardware. Every virtual machine has its own operating system and applications. The hypervisor is also responsible for distribution of the Hardware resources to the virtual machines.
But how the Heck does Hypervisor Solve the Problem?
With Hypervisors, we saw that we can create multiple virtual machines over a Single Hardware. Each Virtual machine can have its Own operating System. For Example, we can Have a Linux Server with a Hypervisor and over that, we can install Windows Virtual Machine and a Mac Virtual Machine.
Now the developers can install a Hypervisor and a Virtual Machine over that. They can download all the libraries and dependencies and then complete their development. Once completed, they create an image of the virtual machine and send it to the QA. The QA can create the instance of the image obtained. This will have the application along with all its dependencies and libraries and OS configurations. Alice and Bob no longer have to argue, and they live happily ever after. Or do they?
Enter Docker !!
When Bob suggested this idea, everybody in the team was happy. They setup the hypervisor and Virtual machines. Bob completed his development and then created an image of the Virtual machine on which he was working. He sent the image to Alice. All Alice had to do was to create an instance of the image of the virtual machine. She will then get the exact application that Bob developed along with its dependencies and OS level configurations. Sadly, when Alice created the instance and tried to run it, her system crashed! Alice was left cursing her fate, wondering what went wrong.
The problem with Hypervisor is that it is very Resource intensive. Every virtual machine will have its own Operating System code. What if there was a way to create multiple virtual machines that share the underlying Operating system code of the physical machine? In this way, we only must transfer the application along with its dependencies and libraries from one environment to another. This is where Docker comes into picture.
As per the AWS definition, “Docker is a software platform that allows you to build, test, and deploy applications quickly. Docker packages software into standardized units called containers that have everything the software needs to run including libraries, system tools, code, and runtime. Using Docker, you can quickly deploy and scale applications into any environment and know your code will run.”
In other words, using Docker, one can share the underlying operating System code along with the hardware resources. In Hypervisors, the system shares only the hardware resources, while each virtual machine maintains its own operating system code.
A container is like a Virtual machine with the difference being that unlike virtual machines, containers share the underlying Operating System code. Docker lets you develop and package your application as a Container. Containers are lightweight and include everything necessary to run the application, so you don’t need to rely on what’s installed on the host.
Bob develops a spring-boot application. He then packages the application along with its dependencies as a Docker image. Bob can distribute this Docker image and run it on Alice’s machine that has Docker installed. We can imagine the Docker image as a blueprint and the container as the actual object created from the blueprint.
Conclusion
When Alice receives the image, she creates a docker container from that image and runs the container in her machine. Containers are very light weight as they share the OS. Hence Alice’s System doesn’t crash. Finally they live happily ever after.
Clear with the Docker basics? Now learn about its architecture & key concepts in Part 2 here.
