Web applications have been around for a while now. Web hosting industry has also kept up the pace and scaled up drastically. As the web applications started to get larger and the team size started growing, the overhead of installing the same applications over and over again added to the overhead of setting up new environments. To get around this, the industry came up with concepts like Virtual Machines Images & Docker containers. Virtual machines helped in reducing the overhead by allowing to install and run a pre-stored image with all the applications.
This approach kept running for a while in the industry and was utilised by numerous organisations to isolate the development environments. The benefit of utilising VMs was that a single machine was able to serve multiple users at once. However, this approach was limited for use in dynamic environments where they require scalable compute. Moreover, the overhead of running a complete operating system for a production environment did not seem to be the right way to do things. This is where the need for Dockers came into picture.
Dockers – An Introduction
Dockers is not really a new term in the industry today. It has been around for a while. Here in, I would like to discuss about a bit of history about why dockers came into existence. As a developer, even I, at some time, questioned the same. I finally figured it out and felt that would be something worth sharing.
For large system architectures, it becomes difficult at times to migrate the setup from one machine to another. The primary reason behind the same is that there are a bunch of software systems and configurations involved in the process. These softwares could potentially take up a considerable amount of time to be setup and configured. Moreover, human intervention makes this process prone to error. Initially, people tried to solve this difficulty using Virtual machine images(VMI). The VMI however was not really elastically scalable
Dockers vs Virtual Machine
Virtual machine images posed several other issues like:
- Occupies additional memory for the OS processes which are not really required
- Cannot be easily migrated to other environments
- The memory and storage allocation cannot be changed on the fly
- Comes with its own OS which increases the load time
- Runs with hypervisor which adds to the memory occupancy
With Dockers, these issues are set back. The Docker run on docker engine without the need for any full-fledged OS. Docker memory management is dynamic and managed by the Docker engine. This makes it light weight and easier to migrate. Docker is supported by a huge infrastructure DockerHub which has numerous pre-built images to get started. Docker containers are easy to inherit and use as base for creating containers with additional features.
There is one specific point where Dockers also are weak. The Virtual machines lead the race when it comes to isolation. Every VM instance running on a machine are mutually isolated. However, Dockers are open for communication and share resources over a single kernel. This is the primary reason why organisations still choose VMI for deploying multiple web applications. This approach helps them to prevent a backdoor of one web application from affecting another.
The Scalability problem
Despite the dynamic nature of Dockers, they can be restricted in terms of resource usage. With multiple cloud providers in the market today, like AWS, Google Cloud,Digital Ocean and likes, people started getting resource sensitive. These cloud providers provide a scalable environment where you pay only for what you use. This made the people aware of how they could save on their expenses by optimising resource utilisation. In order to optimise the resource usage, they required a system that is able to automatically scale up or scale down as needed.
This process involves three major tasks to do:
- Create a layer of networking which manages deployments underneath
- Start an additional instance of application when needed
- Shut down any extra resources of application when needed
This process of automating the scaling of systems is called Docker Orchestration. This process covers all the tasks like deploying, scaling, management as well as availability of the dockers. Kubernetes comes into picture precisely at this point of system.
Kubernetes – High level understanding
Kubernetes is a popularly used docker orchestration engine developed by Google over years leveraging their experience in managing loads. Kubernetes can be considered as a layer of proxy routing server that routes the requests to multiple docker environments. The primary tasks that it performs during the process involves:
- Monitoring of resources deployed by it
- Automatically deploying extra servers/docker containers when the system load rises
- Automatically shutdown the idle instance of the docker containers
- Monitor dockers for uptime
- Automatically start a backup container in case a primary docker fails
- Act as the frontend face for the dockers containers running under the hood
- Manage seamless transfer of Containers from one version to another
Kubernetes helps in providing the end user a seamless experience with a single endpoint while performing dynamic routing to multiple containers in the backend. Kubernetes not only keeps a check for the failure of the containers, it can also monitor for release of a new version and auto deploy it. It basically takes in a list of containers to be deployed and taken care of. This list of containers are deployed and managed by Kubernetes to ensure that they do not go down and also do not run out of memory as far as possible.
In addition to managing deployment and keeping them running, it also helps in a smooth transition from one version to another by intelligently switching the version without any potential downtime. It makes this possible by running a separate container for the new release and diverting the traffic to it before turning off the docker of previous version.
A common misunderstanding
It has been noticed that there is a common misunderstanding amongst people about the Dockers and Kubernetes. Some of them even believe that Kubernetes is a replacement of Docker which is not a case. Kubernetes is a layer above the Dockers that manages them. Docker Swarm is one of the alternatives of Kubernetes. It is a similar orchestration engine available from the Docker community itself. It is a simpler to use engine when compared to Kubernetes while it lacks some of the features like Pods based management, custom logging, managing scalability and others.
In the next article, you would see an in-depth comparison between these two orchestration engines to help you choose the right one!
Here are some knowledgeable articles to help you with even more information on the topic: