Microservices Part 2: Divide And Containerize
You know Appy, I was always fascinated by the term “Divide and Conquer” — or divide et impera if you like fancy talk — , it is so great that it was used in politics and in computer science. You don’t see these two fields mentioned in the same sentence too often, do you? Well, the concept of breaking up big headaches into smaller headaches can apply to a lot of things, whether it be armies, factions, algorithms, or Hawaiian pizza. Last time, I mentioned how you grew up being monolithic and were also divided into processes that were put in containers and became easier to manage. Anyway, do you remember where we stopped? How container isolation is possible? I see…
Well, that is easy but you need to pay attention though. Container isolation of processes is possible due to two mechanisms; Linux Namespaces and Linux Control Groups (cgroups). I want to start with Linux namespaces but before that, I want to be sure about something. You do have knowledge about Linux systems, right? Wow, that is a lot of coughing… I guess that’s a no then. I will just mention the relevant information.
Typically, a Linux system has one single namespace, and all the resources belong to that namespace, including filesystems, network interfaces, process IDs, and user IDs. Now if we run one of your processes, we will run it inside one of these namespaces. The process will only be able to see the resources inside the same namespace. Easy, right? It can get a bit complex though. Since we have different kinds of namespaces like:
- Mount (mnt)
- Process ID (pid)
- Network (net)
- Inter-process communication (ipc)
- UTS
- User ID (user)
Each of these will isolate a specific group of resources, so a process would belong to one namespace of each kind. Your parents would probably tell you more about what kind of resources they would isolate and how, but I will give you a small example, if we give each of your processes a different UTS namespace, it will be as if these different processes are running on different machines because they will be seeing different local hostnames! How cool is that ?! Yeah, I know you want to learn more about them but for now, I think this will be enough to give you an idea of how they would isolate processes running in containers.
Okay, Appy, now to complete the container isolation, we need to limit the amount of system resources that each container can consume. This is where cgroups, a Linux kernel feature, comes in play. It limits the processes’ resource usage, whether it’s CPU, memory, or network bandwidth. A process can’t use more than the configured amount so it cannot hog other processes’ resources.
How about it? Told you that it’s going to be easy to understand container technologies. they have been around for some time now though, they are not new, but they become more famous when Docker was introduced. Docker simplified the whole process of packaging the application with all its libraries, dependencies, and a whole OS file system that the application will run on. All that in a small, package that can be moved to any machine running Docker to provision the application.
Well, not ANY machine, there are some limitations. For example, if we containerize one of your applications built for x86 architecture, we can’t expect a machine with an ARM architecture to run that application just because it also runs Docker. We might need a Virtual Machine to solve that problem.
Hmm… we still have some time before I head out to work, but I will keep it short and tell you about the main concepts of Docker for now. We have Images, Registries, and Containers. Images are where we can package one of your applications with its environment, and other metadata. We build the image and run it on the same computer or we can push — upload — it to a Registry. Registries are like repositories that allow us to store our Docker images and easily share them with other people or computers. We can also pull — download — the image from the registry on another computer. Docker containers are just normal containers but based on a Docker image, and it will run on the host running Docker. Of course, it will be isolated from the other containers — or processes — and the host machine.
Okay, I really need to start preparing to head out, but let me know what your parents think of this. I will talk to you about Kubernetes and how IBM Kubernetes service can help your parents sometime later. Till then, stay stable!
Note: If you didn’t read part one, it’s probably better to do so. Cheers!
