Real World Analogy to Understand Microservices, Cloning & Monoliths.
“Our services are backed by a scalable microservice architecture”, “We are planning to switch to microservices architecture”. If you are a developer, then you must have come across these phrases very often and would have definitely tried to understand - WTF is a microservice? Don’t worry! This guide will give you a solid understanding of microservice architecture using real world example. Wait! Did I mention that there isn’t any code snippet in this article?
A Big Ice cream Machine - Monolith
For a moment, let’s forget about microservices and consider an ice cream machine which has four parts - ice cream scooper, nuts shredder, chocolate funnel, and strawberry syrup funnel. Ice cream scooper adds one scoop of vanilla/mango ice cream to the cup, and as the name indicates, nuts shredder sprinkles shredded nuts over the ice cream scoop. Chocolate or strawberry funnel pour desired liquid syrups on the ice cream scoop. Except ice cream scoop (from scooper part) , all the toppings are optional for the customer.
You being the owner of the ice cream shop start with a small ice cream machine which has 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 would be a time when you will run out of options as the machine manufacturer company will not have any bigger machine than you current machine.
This is what is known as a monolith architecture in development world. You start with a single app which has all different parts amalgamated in a single code base. As the resource requirement increases, you rent bigger machines but after certain point of time, a limit is reached when you already have the biggest possible machine.
Buy More (Monolith) Ice cream Machines
You must be thinking that 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 what is known as cloning, where you use multiple instances of an application to cater your user requests.
Now, with God’s grace and your hard work, people became 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
When you started your business, you hired one technician who was responsible for fixing any issues with the machine or for upgrading the machine. Everything was running smoothly. But when you bought multiple machines, you felt the need of hiring more technicians because you never want to be ‘unavailable’ to your customers.
Now, upon customer requests, you decided to sell a new ice cream flavor. You decided to add chocolate ice cream to your ice cream scooper. But since, all the four parts of each machine are dependent on each other, your technicians had hard time adding the new ice cream flavor. But somehow they achieved their goal, and as soon as they completed the integration of new flavor, the strawberry funnel stopped working because the parts of the machine are interdependent and modifying one broke the other.
Each Machine with Single Purpose- Microservice
Due to the limit of scalability, you decided to set up a new infrastructure. You requested machine manufacturer company to provide you separate part machines for each of the four parts. One ice cream scooper part machine, one nut shredder part machine, two funnel part machines for chocolate & strawberry syrups respectively. Now, you distributed your technicians into separate independent teams with each team taking care of a single separate part machine.
This is known as a microservice architecture, where a big monolith application is divided in to separate independent modules and each module serves as an application on its own, dedicated to perform specific tasks.
Monolith vs Microservice
- Scalability: As you might have noticed that after buying the biggest possible ice cream machine, it isn’t possible to scale more. Whereas with separate part machines (microservices), you can always continue to set up multiple microservice machines for a single part.
- Maintenance: Adding new ice cream flavor to a monolithic ice cream machine broke strawberry funnel because one big monolith system usually have parts which are interdependent. For example, if one module of an application requires change in database schema, then doing that might break other parts of the application. However, in 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 in releasing features quickly as intra-team communication is faster than inter-team communication in big organizations.
- Costs: You might be wondering that you solved the issue of scalability by having multiple big ice cream machines, but consider a scenario where you just want to increase the output of scooper, and not any other other part. In monolith ice cream machine scenario, you will have to buy the full machine every time, but if you have microservice part machine, then 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 comes with all parts integrated, you just have to keep it at the right place and start using it. However, microservice part machines, need to be connected, say through conveyor belts (in ice cream scenario), before actually using them. Therefore, microservices require more time and expertise to set up as services need to communicate to each to get the work done.
- Testing and Deployment: It gets really hard to test and deploy monolithic ice cream machine because all the parts are interdependent, allowing you to test and deploy it only when every part has been integrated. However, in microservice part machine, each part machine is independent, therefore testing and deploying individual parts gets easier.
Should I Directly Start with Microservices?
Short answer to this question is No! Most experts recommend that if you don’t need microservice architecture then you shouldn’t do it. Why not keep serving your customers with a monolithic ice cream machine until it reaches the point where it becomes hard to maintain or scale it. At that point break your monolith machine in to separate independent microservice part machines.
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 a big machine in itself, or it may have several clones running parallely to cater the user needs. For example, your scooper part machine might have 20 scoopers running parallely considering majority of your customers prefer only ice cream and no toppings.
Similarly, microservices could be separate applications in themselves, making them not so “micro”, and requiring good amount of effort to maintain and scale them.
Conclusion
Several big software companies who are currently using microservice architecture, started with a monolith application. Once they reached the limits of scalability and maintainability, they broke that monolith in to separate independent components/services.
No doubt, microservice architecture allows you to use different technologies for different services, and allows to scale and maintain better, but all this comes with an 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”.