Microservices Deployment With Containers – Part 1
We know that containers are lightweight, provide a consistent environment across different platforms, have less startup time in comparison to VMs, facilitate better resource monitoring, etc.
Now let’s understand why the container technology suits best for the microservices deployment with the help of a simple example.
A social platform with microservices architecture
We’ll take the example of a social networking service like Facebook. It has several different features that enable the platform users to interact with each other better, such as:
- The users can upload their photos on the site and share them with their friends.
- They can also tag their friends, places they visit, and so on.
- They can share their opinions with the world by writing a post.
- They can get along with other users with similar interests by creating dedicated groups.
- Users get recommendations on places to visit, new friends, books, movies, etc., based on their interests and browsing behaviors.
These are some of the key features that our social network should have to make it big.
We’ll have every feature as a separate microservice.
If you are thinking, why? Why not code all the features as a monolith? Why have a separate service for every feature?
I’ve discussed the concepts like when to choose microservice architecture for your application and more in my other course. You can check it out here.
Illustration 1.51 - Microservices Architecture: Social Network Application
Deploying different services with containers
Once we are done writing code and our microservices are ready; the next step is picking the right technology to deploy our code. In this use case, we’ll leverage the container technology to deploy our microservices.
Why deploy in containers and not directly on VMs?
From the previous lesson, we know that running containers is cost-effective, lightweight and consumes fewer resources. It’s also easier to manage and scale the system with containers than running the services directly on VMs.
Some stats: Uber runs over 4000 microservices.
From an InfoQ article, posted back in 2014, Google starts over two billion containers per week, three-thousand per second. Everything at Google runs in containers. You can imagine the container count at Google today.
Imagine running all that code in VMs and the resources it would require. For container technology, we can pick Docker to run our services. To deploy one single microservice, we will first create a Docker image for it. The image will contain the application code, dependencies, configuration, libraries, and everything required to run that particular service. This step is known as containerizing the application.
Once the image is created, we will deploy that image on the machine from the command line tool. Mounting images and running them as containers is done by the container engine.
A running instance of a container image is called a container.
Illustration 1.52 - Deploying A Service In Containers
The container ecosystem also contains image registries that can be both public and private, just like the GitHub repositories. These registries contain container images as templates that can be reused with or without modifications at a later point in time.
Hopping back to why containers and not VMs discussion, containers save engineering teams a solid amount of time by letting them off the hook of making the machine ready to run a particular service built with a certain technology stack.
A large-scale system, when built using microservices, isn’t implemented using one particular technology. All the different services are written using different technology stacks. Speaking of our social network application, we can write different modules using different technologies such as C++, Java, RoR, Go, Python, and so on.
If it weren’t for container technology, the operations team would have to ascertain that the machines are ready with respect to compatibility with a particular technology before the application is deployed.
Now, when the number of microservices and their instances reaches hundreds of thousands, this can become a big pain.
Additionally, a microservice that runs on a certain technology cannot be deployed on the machine prepped up for any other technology without making serious modifications to the environment.
However, with containers, we don’t have to worry about all this stuff as they keep the environment isolated from the application code.
We’ll continue this discussion in the next lesson.