How Microservices, Cloning, and Monoliths Work — Explained Like You’re Five!
Real World Analogy to Understand Microservices, Cloning & Monoliths
Monolith — A Big Ice Cream Machine
Let’s forget about microservices and consider an ice cream machine with four parts — ice cream scooper, nuts shredder, chocolate syrup funnel, and strawberry syrup funnel. Ice cream scooper adds one scoop of vanilla ice cream to the cup, and as the name indicates, the nuts shredder sprinkles shredded nuts over the ice cream scoop. Chocolate or strawberry funnel: Pour desired liquid syrups into the ice cream scoop. Except for the ice cream scoop (from the scooper part), all the toppings are optional for the customer.
As the ice cream shop owner, you start with a small machine with all these parts embedded in a single machine. Fortunately, people start loving your ice cream, and your business grows. What will you do? You will buy a bigger machine that can complete more ice cream orders in the given time. Following this procedure, there will be a time when you will run out of options as the machine manufacturer company will not have any bigger machines than your current machine.
This is what is known as a monolith architecture. You start with a single app with all parts integrated into a single code base. As the resource requirement increases, you rent bigger machines, but after a certain point, a limit is reached when you already have the biggest possible machine.
Cloning — Buy More Ice Cream Machines
You must think you could bypass this scenario by buying multiple ice cream machines. You are correct! So, you decided that instead of buying the most powerful ice cream machine, you will buy multiple smaller ones.
This is known as cloning, where you use multiple instances of an application to meet your user requests.
Now, imagine people becoming addicted to your ice cream flavors. To meet the demand, you will eventually have to upgrade all your ice cream machines to the most powerful versions.
Fix Broken Machines. How?
When you started your business, you hired one technician responsible for fixing any issues with the machine or upgrading the machine. Everything was running smoothly. But when you bought multiple machines, you needed to hire more technicians because you never want to be ‘unavailable’ to your customers.
Upon customer requests, you decided to sell a new ice cream flavor. You decided to add chocolate ice cream to your ice cream scooper. Since all four existing parts of each machine depend on each other, your technicians had difficulty adding the new ice cream flavor. But somehow, technicians achieved their goal. As soon as they completed the integration of the new flavor, the strawberry funnel stopped working because the machine parts were interdependent, and modifying one broke the other.
Microservice — Each Machine With Single Purpose
Due to the scalability limit, you decided to set up a new infrastructure. You requested a machine manufacturer company to provide separate machines for each of the four parts. One ice cream scooper part machine, one nut shredder part machine, and two funnel part machines for chocolate & strawberry syrups, respectively. Now, you distribute your technicians into separate independent teams, each caring for a single-part machine.
This is a microservice architecture in which a big monolith application is divided into separate, independent modules. Each module is an application dedicated to performing specific tasks.
Monolith vs Microservice
Scalability: You might have noticed that it isn't possible to scale more after buying the biggest ice cream machine. However, with separate part machines (microservices), you can always continue to set up multiple microservice machines (cloning) for a single part.
Maintenance: Adding new ice cream flavor to a monolithic machine broke the strawberry funnel because one big monolith system usually has interdependent parts. For example, if one module of an application requires a change in database schema, doing that might break other parts of the application. However, in the case of microservice architecture, you have assigned separate teams for each part machine, which makes each team responsible for the functioning of the part machine they control and avoids any conflicts because of the independent nature of the part machines. This independent development also facilitates releasing features quickly, as intra-team communication is faster than inter-team communication in big organizations.
Costs: You might wonder if you solved the scalability issue by having multiple big ice cream machines, but consider a scenario where you want to increase the output of the scooper and not any other part. In a monolith ice cream machine scenario, you will have to buy the full machine every time, but if you have a microservice part machine, you can have multiple part machines (cloning) only for the scooper. That would save your costs as you can scale up or down the instances for each independent service depending on the request load on that service.
Setup Time: Since the monolith ice cream machine has all parts integrated, you must keep it in the right place and start using it. However, microservice part machines must be connected through conveyor belts (in the ice cream scenario) before use. Therefore, microservices require more time and expertise to set up, as services need to communicate with each other to get the work done.
Testing and Deployment: Testing and deploying a monolithic ice cream machine is tough because all the parts are interdependent. You can test and deploy it only when every part has been integrated. However, each part is independent in a microservice-part machine, so testing and deploying individual parts becomes easier.
Microservices are not always “micro”
You might feel that if you reach the stage of having microservice part machines for your ice cream parlor, then these would be small part machines. Nope! Each microservice part machine could be big or have several parallel clones to cater to user needs. For example, your scooper part machine might have 20 scoopers running parallelly, considering that most customers prefer only ice cream and no toppings.
Similarly, microservices could be separate applications in themselves, making them less “micro” and requiring more effort to maintain and scale.
Conclusion
Microservice architecture undoubtedly allows you to use different technologies for different services, scale, and maintain better, but all this comes with overhead complexity and requires good expertise. Therefore, it’s never bad to start with a well-structured monolith ice cream machine instead of starting directly with microservice architecture and landing yourself in “accidental complexity.”