During the talks inside the IT industry, everyone at least heard about microservices. Microservices have long been a buzzword, even now. Everyone talks about them, everyone loves them, and everyone tries to implement them.
There is even a perception that If you do not have microservices, it usually means that the project is not interesting and simply outdated...
Looks like the IT industry has become enchanted with the idea of microservices, right?
Have you ever wondered why? Where did this sudden interest in microservices and the obsessive desire to implement them come from?
Microservices - their popularity and challenges
Microservices got their crazy popularity due to several things, including cloud solutions and containerization - mainly thanks to Docker / Kubernetes. Additionally, a vast number of lectures praise microservice architecture, quoting them as an example of the best possible solution.
We must remember that, as with any solution, microservices, on the one side, solve some problems but also - bring several others with them. Often much more difficult to tame than the ones we dealt with.
Let's look at some of the biggest challenges posed by microservices:
- Communication between services is complex and hard to maintain (temporary unavailability of the service, API contract maintenance, consistency also can be tricky if not handled properly)
- More services equal more resources.
- Debugging can be very problematic (because of the complexity of the whole architecture, sometimes you will need to debug through a few standalone services to gain information on what is not working correctly)
- Microservices can be very costly.
- If you are not aware of how to build microservices, you can create distributed monolith, which is the worst thing you can ever have
So, having all these in mind - do we really need microservices?
Well...The vast majority of IT companies do not need microservices till they reach the scale where microservices can show what they can do in all their glory. It's mainly about the scale of the system we have. Simply put, if we are not a company like Netflix, Shopify, etc., we probably will not see any benefits from using microservices.
Moreover, I think we will only hurt ourselves, in many aspects, also financially, because, as I mentioned earlier, microservices can consume a lot of resources - equal a lot of money.
What are the alternatives?
Naturally, the first alternative became the monolith that we all know already. Used for ages, hated by most people, but traditional monolith is not as bad as people think. It is all again a matter of scale. It is almost perfect architecture for minor projects developed by small development teams.
Welcome the Modular Monolith Architecture
We don't need a fancy architecture for simple CRUD systems, MVP, etc. But what if we know that our application will grow and the domain we are working on is demanding?
Modular Monolith Architecture comes with a helping hand.
How is it different from a traditional monolith? And why is it better?
First, Modular Monolith is composed of modules. Each module must complete a few requirements.:
- be independent and interchangeable
- have everything necessary to provide the desired functionality
- have defined API
Of course, there is no way that each module will be completely independent of the rest of the system, but we have to keep it as independent as possible. Each module only links to the code that it needs specifically.
A fundamental change is modularization. It allows us to extract each module as a microservice. When our scale is big enough, then there is no reason to don't extract each module as a microservice to gain all of its scaling benefits.
Compared to the traditional monolith, the modular monolith gives us:
- Reduced complexity
- It's easier to refactor
- It's a lot better for teams
In a modular monolith, we treat each module more as a business module than a technical module, which nicely leads us to the idea of Domain Driven Design.
Domain-Driven Design in Modular Monolith
Martin Fowler describes it very well in the below quote:
"Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain."
The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns.
In DDD, we have a term called bounded contexts. It's all about separating an application into business parts related somehow to each other. Following this path, each module in a modular monolith can be treated as a bounded context according to DDD. Thanks to this approach, we gain the well business structured modules we will extract in the future.
The DDD describes to us how business should be divided into bounded contexts. The Modular Monolith and its modularization tell us how to structure it as a code.
Want to learn more about Modular Monolith? I highly recommend this brilliant series of articles made by Kamil Grzybek: http://www.kamilgrzybek.com/design/modular-monolith-primer/
When and why the Modular Monolith is a better choice than Microservices?
In my experience, the modular monolith is an excellent architecture for most small to medium size projects (what I understand as huge-size projects? For example, Netflix, Shopify, etc.):
- We maintain modularity similar to the level represented by microservices.
- Communication usually takes place inside the monolith, so it is much simpler than that in microservices.
- Savings on resources. We still have a monolith but modular, so that the costs will be much lower than for microservices. In most cases, adding a new module will not cost you a lot.
- Debugging is much easier, mainly because of easier communication between modules.
- The deployment process is much simpler.
To sum up...
For most companies, a much better choice will be to implement a modular monolith until the scale is larger and microservices make sense. The above post is, of course, only my opinion on this subject but supported by my experiences with all the architectures discussed here. Hope you find it helpful!
