Microservices Part 1: The New Jenga
(disclaimer: The analogy used throughout this series is not meant to perpetuate gender roles and is purely meant for adding a storyline to make it easier for you to understand the concepts)
Look at you Appy, a full application growing up under the care of your parents. Your mom — the developer — who dresses you up with the prettiest features and UI, she just wants to see you the best out there. Your dad — the operations team — who is a bit strict about you running outside in this cruel, cruel world without him monitoring you. But you understand he is afraid that you might crash down and have a lot of bleeding errors, right? you saw how hard he works to maintain an environment which is robust, reliable and resilient for you to run on 24/7. Your parents don’t always see eye to eye though, probably because of how your development environment is just different from your production environment, or maybe because any change in any part of you while growing up will require your redeployment as a whole.
You become more stable and known as time goes on with your parents’ help, they are doing a great job… but uh-oh, that means more traffic and loads on the server you are running on, doesn’t it? They either need to scale the servers vertically (scaling up) by adding more CPUs, memory, and other server components, or maybe scale horizontally by running multiple replicas of you (scaling out). Well, you know that scaling vertically requires a lot of money although it doesn’t require changing you, or your pretty little features, but there is always a limit to how much they can scale up your servers.
So you ask them to scale out instead, your servers are shaking from the never ceasing, increasing loads. They tell you they will have to change your code, and it can be near impossible to scale out some of your components. They mention relational databases and sequential algorithms as examples, but you still don’t understand what the problem is, so they tell you that if any of your components are unscalable, you as a whole become unscalable. Unless they break you into pieces, that is their last resort.
By then, Microservices became the new hype. Your parents hear about it and are very excited, throwing fists in the air and high fiving each other. They explain to you what microservices are and that they will start splitting you into smaller independent deployable components that can communicate with each other through APIs.
A crease forms between your eyebrows conveying that you are a little bit confused, so they tell you that microservices allow you to become Jenga!… Well, boring Jenga, where if one block is taken out or replaced with a new one, the rest of the blocks won’t fall down. Each block is one of your components, and more blocks can be added to you at will. Your eyes become wider and you start nodding, you now understand why microservices are the new hype. Now scaling out or up isn’t an issue. In fact, they can scale out components that allow it, and scale up the rest of the parts… if needed.
All is good, all is well. Your tiny components — microservices if you want — are working together as a team and communicating just fine, you are growing up as well by scaling out/up as time goes by. You start to get out of hand though. with the increasing number of the microservices, it is getting hard for your dad to control you as a whole, with all of your microservices. You can’t even imagine what your dad will do when a server fails.
No worries though, I’ve got just the right solution for you. Kubernetes. Kubernetes can help your dad by automatically monitoring and rescheduling those microservices in case a server fails. Not only that, but it will allow your mom to deploy your microservices as much as she wants while requiring little to no assistance from your dad. It will just abstract away the actual hardware you were running on. How? Well, by using Linux container technologies so that complete isolation is provided for the microservices. But telling you about Kubernetes first will be putting the cart before the horse, so let’s start with what containers are.
As you — the grown-up application — have different components or services, you will have different, and possibly conflicting versions of libraries for each component. When you were a small application composed of a small number of components, it was completely fine to dedicate a virtual machine (VM) to each component and isolate it from the other components to avoid any confliction of dependencies. But when the components become smaller and increased in numbers, it doesn’t make sense to run each component on a separate VM, it’s like buying a whole fish tank for each one of your goldfish, just wasting resources. Not only that, but it is also a waste of time and effort for your dad to configure and manage each of the VMs. Instead, Linux container technologies are used. This allows multiple services to run on the same machine while isolating them from each other as VMs do but with less overhead… much less overhead. It also exposes a different environment to each of services.
To elaborate a bit about how containers are better than VMs, if we run four VMs on a single machine, we have four operating systems running separately and sharing the resources of the machine, and under those VMs, there is the machine’s OS and hypervisor that divides the resources between these four VMs. But with containers, there is only the host machine’s OS. Again, much less overhead. Don’t you think so?
So the way container isolation is possible is by… what? It’s your bedtime? I guess it is. I am getting sleepy too, let’s talk in depth about containers and Kubernetes next time, we can also talk about how IBM Cloud Kubernetes Service can help with your security, deployment, operation, scaling, and monitoring of your containerized microservices. I’m sure your parents will be delighted to know that you learned so much.
Good Night ✋
P.S: I can hear some of the microservices guys clicking their tongue and shaking their heads sideways from all the omitted information, but I didn’t want to scare little Appy here by going so deep in the topic from the get-go. Cheers!
