logout
edit_square
cloudqubes
Delete this post
Last saved at 2025-03-14 05:09:44 +0530
Select cover image
Newsletter edition
Short Description
What is containerization and what is microservices. Many people mistakenly think that containerization and microservices mean the same thing. That's bad. Such peole get easily sold to ideas about modernization with microservices. Containerization is not microservices. Really? Then what is what? Containerization and microservices, often used interchangeably, mean very different things. So, what is containerization and what is microservices. And what is the reason for this confusion.
Sometime back, I got to sit across a meeting where a vendor was selling a Kubernetes based container platform to a customer. The platform could run both containers and virtual machines. Encouraging the customer to move all their workloads to this new platform, the sales person said, "Our new platform can run microservices applications alongside the legacy applications on virtual machines." "Great! we are trying to containerize our existing apps." One of the engineers at the customer side responded. The sales person was happy. Here's a customer with a drive to modernize. "Yes, microservices is the way to go." The conversation continued using **containers** and **microservices** interchangeably. Everyone was happy. The new Kubernetes platform is cool. But, wait... is the containerization the same as microservices? ## What is containerization Containerization is the process of packaging an application with all its dependencies into a container image that you can run on any target container platform. Didn't get it? OK. Imagine you have a Python web application. You want to deploy this for production use. What is the old school way of doing it? You get a Linux server. Then, you install a Python version management tool like [pyenv](https://github.com/pyenv/pyenv) on the server. Then, you install Python, the pip packages, and other binaries required for your application. Then you install a Python application server like Gunicorn. After that you can copy your Python code to the server and run. That's it!. Your Python web application is up and running. But, you need to regularly update it - fix bugs, add new features, etc. To update the application you must first copy the updated code to the server, stop the already running application, and then run the new code. What if your new code has new dependencies. Then, you must install these dependencies on the server before running the new code. And your application will be unavailable until you install all these and get the new code running. What if your new code needs a new Python release? You must install the new Python release on the server before running the new code. But, are you sure that the new Python release has no issues with your other dependencies. You will only know it once you run the new code on the server. How can you revert back if the new code crashes when initializing? And now, the worst case. The OS crashes in your production server. You must restore the server from a backup. Or, you must go through all the steps you followed at the beginning, to setup a new server. Either way, your application will be unavailable for a few hours. Your users are not going to be happy. Clearly, this is no the most efficient way to run a web application in production. What's the root cause of these inefficiencies? The application is tightly coupled to the operating system running on the server. To do away with this tight coupling we can deploy our Python web application on a container. Here's how we are going to do it. - Step #1: Install [Docker Desktop](https://www.docker.com/products/docker-desktop/) on your development workstation. - Step #2: Write a Dockerfile for the web application. - Step #3: Build a container image and push it to a container registry like DockerHub. - Step #4: Write a Docker compose file. - Step #5: Install [Docker Engine](https://docs.docker.com/engine/) on the production server and deploy the application with Docker compose. This is what we call containerization. **Instead of running code directly on the operating system on the server, now we package our code as a container image and run it on a container runtime**. We chose Docker Engine as the container runtime because it's easy to get started. ### Why did we containerize our web application Since we are running our application as a container image, updating or restoring our application is much easier than before. To update our application, we can build a new container image without touching the production server (step#1 to #4). Then, we just stop the running container image on the production server and run the new image. If something goes wrong we can instantly revert back by running the old container image. ## What is microservices Microservices is an architectural style for building complex software. Assume you are building an ecommerce application with functions and features such as user authentication, shopping cart, inventory management, order management, etc. You can choose to implement all these in a single application, package it as a single container image, and deploy. That's OK, if your ecommerce application is not that big. What if this ecommerce application is the next ebay. You have millions of people using it and your feature requirements are going to be very diverse. You have smart search, smart recommendations, integration with multiple payment gateways and much more. Sure, you can manage all this in a single application. But, it's not going to be very efficient. If you have a globally distributed team of developers, you also want them to work on different parts of the software without stepping on each other. This is where the microservices architecture can help. Instead of bundling all your code into a single application, you split your code into separate components - microservices - based on functions and feature. You can have separate microservices for user authentication, shopping cart, inventory management, etc. Instead of one big application, now you have a bunch of smaller components. that you can develop and deploy independently. ### How to run microservices architected applications in production Containers are the preferred method for packaging microservices-architected applications. Instead of one container image, now you get separate container images for each microservice. You need to deploy these container images on a container runtime - like Docker Engine or Kubernetes. Kubernetes supports scaling microservices, failure recovery, and a lot of other features that makes it the preferred platform for running microservices-architected applications. ## Containerization vs microservices Now you know that containerization is not microservices. To reiterate what we already discussed: Containerization is the process of packaging an application with all its runtime dependencies into a container image. Microservices is an architectural style for braking down the complexity of big software applications. To deploy a microservices-architected application you use containers. But even if your application is not architected in microservices, you can run it on a container. We will be talking more about containers and microservices in upcoming posts. Stay tuned...
