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 container technology fits best for 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 behavior.

These are some of the key or standard features that social networks in this day and age have.

We’ll implement 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 this in the previous lessons, for fault tolerance, availability, and scalability. In addition, in my Web 101 course, I've discussed the use cases that fit microservices and monolithic architecture and when to pick which.

Illustration 1.51 - Microservices Architecture: Social Network Application

Deploying different services with containers

Once we are done writing code and our microservices are ready, we have to deploy them. We will leverage containers for that.

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. In addition, it’s easier to manage and scale the system with containers than running the services directly on VMs.

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 different services could be written using different technology stacks. Speaking of our social network application, we can implement different modules leveraging 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 certain technology before the application is deployed. And when the number of microservices and their instances reaches several thousand, 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.

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.

Let's continue this discussion in the next lesson.