The decision between microservices and monolithic architecture greatly impacts complexity and development speed. Microservices offer scalability but come with complexities and longer kickoff times. Monolithic architecture is simpler and suits smaller projects.
For a project managing assignments and leaves, a modular monolithic approach was chosen due to the project's scope. It allowed logical module separation and potential future transition to microservices. This approach prioritized milestone delivery over configuration. Projects should consider their needs and start with a modular monolithic approach if they might transition to microservices later.
Read on to discover the details.
The backend architecture is a make-or-break decision for any project. Making the wrong choice about using microservice can lead to:
When deciding on the architecture, you need to take into account factors such as domain complexity, team structure, CI and production environments, traffic expectations, and scaling.
When creating a product intended to display people’s assignments to projects, their availability, and leaves, we saw a clear division between modules that could be extracted:
Having logically separated parts of the domain, full control over the environment, and using the newest version of .NET, it was tempting to implement modules mentioned above as microservices. There were definitely some valid reasons to do so. However, we decided to start with a monolithic approach instead, which proved more efficient and allowed us to focus on feature development and fast delivery.
When considering the monolithic and microservices approach, we analyzed the most significant characteristics of both:
<span class="colorbox1"><h3>Monolith</h3><h4>Pros:</h4><ul><li>easier to start a smaller project</li><li>simple client (React app)</li><li>server (.NET backend) infrastructure</li></ul><h4>Cons:</h4><ul><li>single, bigger deployment</li><li>limited scaling possibilities</li></ul></span>
<span class="colorbox1"><h3>Microservices</h3><h4>Pros:</h4><ul><li>independent deployments</li><li>better scaling possibility</li></ul><h4>Cons:</h4><ul><li>project kickoff takes more time</li><li>complexity of the solution and infrastructure</li></ul></span>
Monolith is a more straightforward approach but has its limitations.
To define which suits your needs, ask yourself two questions:
If you answered YES twice, choose microservice-based architecture. Monolith may slow you down.
Our own answers were as follows:
Although we made a decision that microservices are not the correct approach for now, this could change in the future. We wanted to be prepared for a potential transition. In such cases, modular monolith architecture might be the best choice.
If the development team implements a monolith so that:
It’s possible to move from a modular monolith architecture to microservices, as shown below.
In the case of our project, the modular monolith architecture type allowed us to focus on pushing the product to the next phase rather than tweaking and tuning the connections. That said, every project is different, and there’s no universal way of structuring the application.
Some products, just like ours, might benefit from not splitting the backend into microservices until it’s absolutely certain they’re needed. If you fall into this category, start with a modular monolithic approach so that it’s easy to pivot when the decision is made to move to microservices-based architecture.
The Brainhub promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by demystifying the technology decision-making process based on practical software engineering experience.
Top reads this month
Get smarter in engineering and leadership in less than 60 seconds.
Join 300+ founders and engineering leaders, and get a weekly newsletter that takes our CEO 5-6 hours to prepare.
No previous chapters
No next chapters