Docker — The Dosa Analogy
Isolating applications from infrastructure in the age of containers
Work from home is tough, especially when your mom is interested in what you are working on. A few days back I had an interesting conversation with my mom, explaining to her what a docker container is. My mom is from a non-technical background. Cooking is her forte and hence I had to keep this story inside the kitchen. Hope this serves your appetite too.
Docker Platform — The Dosa Pan
Like how we need a dosa pan to make dosa, we have to install the docker platform to the underlying machine (physical or virtual) to be able to run docker containers
Docker Image — The Dosa Batter
Docker image is the underlying template on which the container is built. The difference between the docker image and the container is that of batter and dosa. The container is cooked out of the image and we can cook as many containers as we like from the same underlying image.
Docker Registry — The Bowl
Docker registry is where the docker images are stored.
Dockerfile — The Cookbook
Dockerfile is the cookbook that says how to make the batter. The dockerfile explains how a docker image has to be built. Usually, every dockerfile will have two important sections.
- Base technology — This is the base image on top of which our application has to run. This is defined by the syntax “FROM” in dockerfile
- Application code — This section consists of application-related information like an artifact, ports exposed etc.
Docker Config — The Dosa toppings
- Config file — the document that contains the environment information.
- Environment information — these are the details like the port numbers, database connections, interface application details etc.
Even though the underlying docker image is the same, based on the config that we apply on it, the characteristics of the docker container can be defined accordingly. In simple words, this is customising the dosa as we like.
Docker container — The Dosa
Docker container is the final product. Eating the dosa is similar to using the application. We can run as many docker containers as we like depending on the demand using the same docker image and same config file. This is called scaling the application which will be explained in the next post.
How does a developer use docker
For a developer, the major part of the work on docker is with writing the dockerfile. Developer programs the application and build artifacts and construct the dockerfile to build the docker image. This docker image then becomes his key deliverable along with the config file.
In other words, a developer spends most of his time in preparing the ingredients for making the batter. Once the ingredients are ready, he writes/updates the cookbook. Then the preparation of batter is now automated using CI/CD pipelines.
How docker isolate the application from infrastructure
The docker image package the infrastructure (Base image) with the application (code) and hence eliminating the dependencies that tie down the application deployment to the core physical machine.
While it also enables the seamless movement of the code to various environments (Development to Test to Production).
BC (Before Containerisation) era
Those were the times an infrastructure engineer would work for days to set up a new server and deploy the base software and dependent packages that are required to deploy an application artifact.
This roughly translates the process of making the batter from raw rice. This goes through a complex process of soaking and grinding and fermentation. This usually takes a day before the batter can be cooked.
AD (After Docker) era
With docker, the activity is done only once at the time of building the image. Moving the code from one environment to another is now as simple as pulling the docker image from the registry and running it. And this eliminated the dependencies that tied the application down to the underlying machine.
This roughly translates to getting the batter from a shop and making dosa in a matter of few minutes as opposed to days of preparing the batter in BC era. Think of the developer as the shop that prepares the batter.
Why the seamless movement of code is necessary
Once the developer programs the application it has to be tested before it is exposed to the real users. Hence the application has to be deployed at multiple environments to support the back and forth movement.
In the BC era, this happened to be the entire setup being done at every household before they test the batter and provide feedback. In AD, it’s as simple as moving a pack of batter from shop to household and thereby eliminating a lot of efforts
Takeaway
While it may be difficult for the legacy applications to move to docker, I strongly recommend the upcoming digital transformation projects to be run on docker and reduce the efforts that are spent on doing the same infrastructure setup over and over again, thereby eliminating any possible mistakes by isolating the applications from the infrastructure.
Bon appetit.
