Why Microservices

We, the programmers, are fashionable folks. We love everything what is currently in fashion in every aspect of the programming. The new, shiny ideas are more attractive than old, covered with rust. Objective programming? No, the functional programming is now trendy, so let’s use it, because it is better. Or node.js ecosystem? New frameworks, which will completely change your life and save you years of development? They are provided weekly, and have funny names. Some of them are also abandoned quickly, so don’t rely on small, untested ones.

The same goes with Microservices, since it is a fashionable and trendy topic, there will be many teams, which will decide to go the Microservices way, in the situation where Monolith would be enough. Current fashion cannot be the only reason to implement split architecture instead of a small and concise instance. Let’s talk about when Monolithic architecture is better than Microservices and vice-versa.

Difference Between Monolith And Microservices

Before we dive deep into the world of Microservices, you have to meet their parent first, which is a Monolith. It comes from a monolithic adjective and Oxford Dictionary has two definitions of this term:

• something formed into a single, large block of stone
• a large, powerful and slow to change (of organization or system)

A software Monolith is in fact a massive stone. When being deployed, the whole system must be build, tested and rolled through the servers. The more complex systems becomes, the more time is needed for the process. With its increasing complexity, project also becomes slower to change and update.

A remedy to Monolith’s pains was to use old tactics called divide and rule, but in a good way. It was called a Microservices and assumes splitting your Monolithic system, to many independent units, having its own deployment process.

Should I Start Project With Monolith Or Microservices?

It depends. First, lets talk about a greenfield project. This is a quite comfortable situation, you are not burdened with any legacy system, with its quirks and workarounds. On the other hand, you will have to solve all the problems yourself, which in contrary to existing system, are already dealt with.

Microservices Or Monolith In Greenfield Project

There are few factors to take into consideration, when deciding if the greenfield project needs Microservices. First, lets talk budget wise. If there is enough money for one development team, the client must be informed that time to complete will be longer than with two or three teams. Small amount of people engaged in a project leads to start with a Monolith. Simple deployment process and lack of dependencies lets the team focus mostly on features rather than the infrastructure.

Another factor is anticipated or calculated number of concurrent users using the system. The more connections, the more resources are needed to handle them. The resource here is an instance of your application, put somewhere behind a load balancer. The weight of your Monolith’s build will require more and more RAM and CPU, and this is directly connected with hosting expenditures. Moreover, this big instance holds the logic for whole system, even for those rarely used parts. It also involves opened connections to other systems, what makes the overall system usage even higher. In this situation, it is wise to start with Microservices approach to share a load between different modules and save money on infrastructure.

The last question you will have to ask yourself, is about time of system’s deliverance. It may be crucial for your customer, to get it up and running within 6 months, so the budget will include funds for 5 teams. In such a situation, it might be difficult for about 20 people to communicate effectively, because there will be too many communication channels. To reduce their number, the 5 teams have been formed as it was decided earlier. Now, each team can implement their features with technologies they feel the most comfortable with. The only requirement is to maintain a unified and consistent API between each Microservice.

Microservices Or Monolith In Existing Project

If existing, battle-tested software needs new features and functionalities, there is also a place for deciding which approach will be better. If the project happens to be Microservices already, then decision is obvious. It is unlikely for Microservices to be forged back into the Monolith, so you now how to continue.

The Monolith architecture is expected in most of the situations, so the decision will have to be made. Do we keep with the Monolith, or we split it in many smaller parts? If with new features an overall system load will increase, or complexity of code architecture will grow significantly, it may be a sign to go with Microservices.

Just like in the greenfield projects, the time of deliverance might be the importance. If so, the architecture must follow towards Microservices, rather than Monolith. Thanks to the technology-independence, it is also easier to hire developers, since you don’t have to search specialist in one, particular language.

Summary

The table below contains summary and help you with answering the “Monolith or Microservices” question.