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 and so on.
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 users on the platform to interact with each other better, such as:
- The users can upload their photos on the site and share it with their friends.
- They can also tag their friends, places they visit and so on.
- They can share their opinion with the world by writing a post.
- They can get along with users on the platform, having similar interests by creating dedicated groups.
- Users should get recommendations on places to visit, new friends, books, movies & so on, based on their interest and browsing behaviour.
So, 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 make things complex?
I’ve discussed the concepts like when to choose microservices architecture for your application and so on in another 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 & our microservices are now ready; the next step is to pick 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 & not directly on VMs?
We’ve already discussed the differences between the VMs & the containers in the former lesson. We know that running containers is cost-effective, lightweight & consumes fewer resources. It’s easy to manage & scale the system as opposed to when running the services directly on VMs.
Some Stats: Uber runs over 4000 microservices.
According to an InfoQ article, posted back in 2014, Google starts over 2 billion containers per week, 3000 per second. You can imagine the container count at Google today.
Imagine running all that code in VMs and the resources it would require to do that.
For the container technology, we can pick Docker to run our services. To deploy one single microservice, we will first create a Docker image for it. That would 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.
Coming 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.
The entire system, when built using microservices, isn’t built 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 & so on.
If it wasn’t for the 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 go high, in the number of hundreds of thousands, this can become a huge pain.
Also, a microservice running on a certain technology cannot be deployed on the machine prepped up for any other technology, without making serious modifications to the environment.
But 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.