Divide your application into smaller chunks | Intro to microservice & Docker

Jigar R
5 min readSep 8, 2022

--

An application always starts small. As it matures, more features and code gets added and becomes larger. Eventually, the application gets divided into separate projects focusing on different key areas. Then, some parts of it can be deployed together and others separately.

Let’s talk about extreme scenarios: if applications are deployed together, it would be challenging to scale up. You can maybe get more VMs and replicate the setup. You may save money by deploying some parts of an application on a separate VM.

Another scenario is when your application is fragmented into pieces. We can call these pieces micro-services or microservice. Imagine a web app with dedicated VMs that deal with the login of users, another app that figures out recommendations per user, another app that handles various payment methods, and so on. A microservice on its own is a piece of the puzzle. It needs to be able to interact with other microservices to paint the whole picture. If you observe that payment microservices are getting busier, you can increase the number of microservices to meet the demand. Isn’t that awesome? Just like any process, microservices need the following items:

  1. resources such as CPU, memory, disk, port
  2. security & networking
  3. instructions on what to do

Requirement 1: Resources such as CPU, memory, disk, port

How about we create a VM per microservice?

  • A microservice is micro. It needs cpu and disk. Let’s say 1 CPU and 100 MB disk space
  • A VM requires an Operating System — which needs more resources than our microservice needs
  • creating a VM per microservice is overkill as we would have to get more CPU and disk than we needed

Can we run our microservice just like a VM (but without Operating System)?

The answer is yes. In 2007, Google engineers released Control Groups (cgroups). Cgroups can limit how much resources a process can use; it can measure how much resources are being used and restart processes safely by taking snapshots.

Requirement 2: Security & networking

  • Let’s say we gave a microservice1 access to /micros_service1/path. It should not be able to read /micro_service2/path.
  • Microservice1 would have access to the memory. We need some way to isolate memory so that microservice1 can not read other microservices’ memory data.
  • If microservice1 needs to talk to microservice3, how do we do network between microservices?

Linux Namespaces (created in 2002) helps with above questions.

  • limited disk access is facilitated by the Mount namespace
  • memory access is facilitated by the process ID namespace
  • network related things are handled by the network namespace

There are other kinds of namespaces. Combine multiple namespaces to put a virtual fence around your microservice. To understand cgroups and namespaces in detail, check out the book “ Linux Kernel Networking: Implementation and Theory by Rosen, Rami.”

Docker (launced in 2013) combined the concepts of cgroups and namespace.

Requirement 3: instructions on what to do ?

With Docker, you would write a program in your favorite language, java/python/go. But you need to define how Docker can run your service. These instructions are stored in Dockerfile.

Let’s say you have a simple HTML file. We can run it on the Nginx server. The Dockerfile would look like following

FROM nginx
COPY index.html /usr/share/nginx/html/

Assuming you have installed docker on your machine. Run

  • docker build — just like how a java program is packaged inside a jar file, docker will package our program inside an image. You can run 1, 2, 3, or however many microservices you want, all of them performing instructions found inside an image.
  • docker run will run microservice which is also called a container.
Image copied from colorful-container-export-business-warehouse-urban-sky-cargo

You would run the following commands to run our microservice:

docker build -t test .
# -t option here is to name the image

docker run -d -p 20000:80 test
# find an image with name "test" and use it to run a container
# -d option to run command in the background
# -p to bind 20000 port of your machine to port 80 of container

If you went to localhost:20000 in the browser, you would see your index.html. You can even peek inside a container using docker exec command. You can also restrict how much memory and CPU a container can use. If you want to know more about docker, visit the official docker docs.

Interesting information

Ed Robinson (author of the book Kubernetes on AWS), mentions that chroot (1979) paved the way for modern docker.

Chroot provided very simple isolation for files. It can prevent access to files outside of the specified directory tree.

Sharing container images

We often use an app store to find and download smartphone apps. In the same way, after a container image is created, it can be published to a registry. Other people can find a container image, use it to develop and run their micro-services. Examples of popular registries are Docker Hub, Elastic Container Registry, and Google’s Container Registry.

A malicious container image can pose security issues. Therefore, doing some research before using containers written by someone else is critical.

In the previous example, the very 1st line of the dockerfile:

FROM nginx

will look up the “nginx” image from a registry and download it on the machine. The default option for registry with docker tool is Docker hub.

In this post, we covered

  • Microservice
  • Control Groups (cgroups) — to limit and track resource usage
  • Namespace
  • Docker
  • Image — Container
  • Registry for container images

Remember that Docker is a tool that packages software into standard unit called container. Podman, Kaniko and many other tools are alternatives of Docker.

References

Blogs & websites

Books

  • Kubernetes on AWS book — Robinson, Ed. Kubernetes on AWS. Zaltbommel, Netherlands, Van Haren Publishing, 2018.
  • Networking related — Rosen, Rami. Linux Kernel Networking: Implementation and Theory. Apress, 2013.
  • Ovens, Steve. “The 7 Most Used Linux Namespaces.” Enable Sysadmin, 11 Mar. 2022, www.redhat.com/sysadmin/7-linux-namespaces.

Image

--

--

Jigar R
Jigar R

Written by Jigar R

DevOps Engineer | feel free to reach out to me | LinkedIn — https://www.linkedin.com/in/jigarrathod/

No responses yet