Nowadays, the term “monolith” seems to have negative connotations. For many it sounds old-fashion, rigid and boring, on the other hand “microservices” seem to be the opposite: modern, flexible and fun.

Well, we do not agree with that, actually, it depends on the kind and size of your problem, functional and non-functional requirements, the size of the organization and the economic factors of the context for development and operation.

One size does not fit all, and if your development team is small, Microservices might be a terrible choice and can lead to unnecessary overhead, complexity and redundancy. On the contrary, a Monolith is usually the optimal granularity when you have only one development team.

Monoliths

Monoliths have many advantages, especially for small development teams or startups:

• They are easier to start off, you just set up the project and infrastructure once
• Less redundancy. As there is only one centralized source code and database, you have always all the information you need
• Less overhead since there is no need to define interface contracts and to orchestrate different services

Disadvantages of the monoliths:

• Difficult to change, for example, once the code base reach a certain size, it will be very time-consuming to change the framework or the database technology
• Difficult to scale technically, for example to be able to process more requests per second
• Difficult to scale organizationally, the more developers working on a single applications, the more communication overhead you have

Microservices

Microservices used right can provide the following advantages:

• A particular microservice is easy to understand and implement since they are smaller than monoliths, and they focus on a single concern
• Microservices are easier to scale technically. For example if you identify that you have a bottleneck on a particular microservice, you can simply run more instances of it
• Microservices can help you scale organizationally by having smaller teams in charge of a few microservices

Disadvantages of the microservices

• They add complexity and overhead to your architecture
• It can make it more complicated to understand the whole system to new developers
• You will need more resources (CPU, RAM, Machines) to run the whole system

Self-Contained Systems: the missing link between Monoliths and Microservices

Fortunately for those companies that are not a startup anymore but that have not reached the size of Amazon yet, there is a better fitting solution: Self-contained systems.

The idea behind self-contained systems is extremely simple: you just divide your monolith into smaller independent systems that focuses on one business domain. The granularity is up to you, and you should consider what is the current and near-future size of your development team.

If you are developing an online shop, and you plan to have 4 teams, you might split the online shops into 4 self-contained systems:

• ERP (product editor, stock management, order management, …)
• CMS (to manage the content of the home and landing pages, banners, etc…)
• Catalog (let the internet users find products and see the details)
• Checkout (let the users enter the delivery and payment information and submit the order)

But if you keep growing, and you have enough resources to set up new teams, you might want to split the catalog into smaller self-contained-systems:

• Home and landing pages
• Search
• Product detail page

Conclusion

Size matters! Microservices can be an overkill for small development teams, and Monoliths will slow you down when growing the number of developers working on it. If you are experiencing the pain of shared monolith, take self-contained systems into account and break your monolith considering the number of development teams and the business domains.

When developing and providing solutions, we have found that the following rules of thumb help to assign problem (parts) to applications and teams:

1. If you are using Scrum: staff a team with a size of around 5 team members + Scrum Master and Product Owner
2. One application should be owned by only one team. If you have more than one team maintaining the same application, you will create dependencies between the teams and weaken the ownership feeling
3. One team should work ideally on only one application. It can work on more but the more you have, the more overhead you have
4. Each Business Domain should not be split into different applications. For example the pricing business logic should have a clear ownership.
5. The team should work end-to-end to be able to deliver new features in one iteration, without being dependent on other teams. We should avoid separations like Frontend and Backend team.

But the core questions always remain the same: What is required from the applications to create a sustainable solution from the business point of view? How do we cut my problem into smaller problems? And how do we assign these parts to development teams.

Additional information

If you want to get a deeper understanding, we recommend you the following resources:

1. https://scs-architecture.org/
2. https://blog.appdynamics.com/engineering/microservices-monoliths-and-self-contained-systems-time-to-break-it-down/
3. https://www.elastic.io/breaking-down-monolith-microservices-and-self-contained-systems/
4. https://dev.otto.de/2016/03/20/why-microservices/