Containers???

Wait wait wait, are we going to run our code in a container(from the above image), really???

In this article, we are going to understand the need for containers and how it helps us to easily deploy the applications. Let's dive into it

Traditional approach(before containers)

• If we want to deploy a web application, we need to allocate a physical machine with RAM, OS, and other hardware components and install the dependencies for the application and connected to the internet so that everyone can access the application.

• But the main drawback with this approach is, most of the hardware components are underutilized which gives us unwanted bills and we need to maintain the same environment for the development mode and production mode so that our code works fine.

• To make utilization of these servers, they came up with a concept called virtualization.

• We install a virtualization software called Hypervisor and launch multiple VMs which utilize the underlying hardware.

• Each VM needs its own OS to run and all these VMs are isolated from each other but use the same hardware components. The best example of this is how the cloud offers virtual servers to you.

• But there is some limit to these virtual machines, and it depends on the hardware.

  What might be the better approach for this???

Containers

Containerization is essentially a lightweight approach to virtualization. Instead of virtualizing hardware, the virtualization is done at the OS level.

Instead of having its own OS for each container, it can depend the OS functionalities on the host machine itself, and we can remove most of the OS functionalities as we need the basics like file management and process management. The rest of the functionalities can be dependent on the host machine.

With this approach, the size of the container is reduced and we can launch more containers, as the host machine treats these containers as each process we can spin up more than 100 containers, which means we can have 100s servers of the same application running.

The most famous containerization tool is DOCKER.

Generally in a container we specify the run time environment and the dependencies for the application and application code, these things are wrapped together as a container image and launch up as a container. The only thing we need to run this container is a container engine, with that we can run the container where ever we want with the help of the image.

Image: It is just an instruction which knows how to run an image.

Let's see some advantages of this:

1. Whenever we are deploying the applications, there is a high chance of having different environments during development and deployment. With the containers irrespective of the environment we can run the containers, as the image contains the environment, code and its dependencies. We just need a container run time engine to run.

2. With containers, applications can run consistently across on-premises data centers, public and private clouds.

3. During development, if we need to install any software like MongoDB/MySQL/Programming Languages to perform quick checkups and testing, we can easily install the container image without downloading, installing and configuring the software.

4. Containers are well-suited for building microservices-based applications. Each microservice can be packaged as a separate container, allowing independent development, and deployment.

5. One last thing is that these containers can effectively use the underlying hardware, and make our life easy to develop, deploy and scale our applications.

But if there are many running containers of the same image, how can we manage them? The answer to that is orchestration

I hope this article brings you some idea about how containers work, and why many organizations are moving to containers to deploy their applications.

Thankyou!