Monolitic vs Microservices - which architecture to choose?

Choosing our system’s proper architecture is one of the most important decisions to make before we even think about starting to write code. Consequently, this choice will determine next decisions about language, frameworks, and libraries, which we want to use during our system’s development and maintenance. Quoting Michael Keeling (“Design It”)

“…A great architecture alone isn’t enough to guarantee your software will be a smashing success, but the wrong architecture almost guarantees failure. …”

Based on my personal experience, I would like to share my insights with you, which may help you to take the right direction — choosing between microservices and monolith.

I don’t want to deep dive into details of both architectures. You may find plenty of useful articles about that. However, I will present them briefly, to be sure we are on the same page.

Monolithic architecture

By definition, a monolithic application is independent and self-contained. The design philosophy based on an approach, that an application can perform and complete each business task from end to end. So, in other words, we compose all in one piece. From a developer perspective, we can run one application on one machine to have a fully working software. This approach gives you the following advantages:

• faster to develop
• possible to implement fully transactional operations
• simple to perform end-to-end testing
• easy code sharing between modules, class etc., avoiding code duplications
• simple deploying
• less security and network latency issues than in the case of microservices architecture

Microservices architecture

I think there is no single definition of microservices architecture. In general, we can say that this is a style in which we structure an application to collect loosely coupled and independence services with their own strictly defined responsibilities. So unlike the monolith, we have several small applications, which communicate with each other to process complex business tasks and return the result of the operation. So this architecture comes with the following benefits:

• scalability (each service can be scaled independently)
• clear and transparent responsibilities of each service
• services decoupling, isolating services for using different languages/frameworks etc
• possibility to develop and deploy each service independently by a team focused on the service
• decreasing of business logic complexity by splitting to the smallest parts, more comfortable to understand

You might be interested in: How to design microservices architecture >>

So which software architecture suits your solution and your business best?

Monolith for the start

One of the common mistakes in choosing architecture for our new project is following trends blindly. Sometimes its result is that we are deciding to use something that we don’t need or, in other words, we are trying to solve problems that we don’t meet yet. So maybe it would be good to consider a monolith approach for a start and not discard it right away, even if we plan to have the microservices architecture in the future.
I can point here a few reasons which are most important from my perspective.

Focusing mostly on the business logic

Choosing monolith could give us a better understanding of the business domain, which is very important when we want to prepare a proper microservices architecture design. In the same time, we can deliver business values and achieve primary business goals. I’m pretty sure that the stakeholders will be satisfied with it. Therefore we are in a very favourable situation where we can kill two birds with one stone.

It's cheaper

There is no need to invest so much time and money in architecture designing, researching, supporting tools, etc. You need to be aware that microservices architecture requires a lot of additional work, especially at the start. Decisions which you will make in the designing phase could determine future work for years. It’s crucial - that is why it requires experience and domain knowledge to be done well.

Faster onboarding

Monolith architecture is not so complicated as microservices, so preparing new developers to be fully productive also takes less time. We can say that this also eliminates some of the potential mistakes which may occur in intricate architectures (frequently made by new devs in the project).

Less painful refactoring

When we start putting our business logic into the code, it may happen that our first thought is not the best one, especially if we are not well familiar with the domain. Sometimes we even don’t know what we don’t know. So refactoring, in my opinion, is something which should not be avoiding or postponed to later. Lets to be honest, if we don’t do this right away, it may not happen soon, and we would be forced to work with harmful code for a long time.

If we decide to perform a monolith-first strategy, we should carefully design our monolith architecture, paying particular attention to modularity within the software, both at the API layer and about how the data is stored. Assuming we do this well, switching to microservices should be relatively straightforward.

So when microservices should come into play?

I’m far from saying that microservices is the only right way which we need to follow. From my perspective, microservices architecture is a pattern, or as I wrote earlier, style, which may help handle the specific issues. A good question would be here: Ok, but when we should use it? In this section, I would try to answer it but first, let me present some problems that microservices architecture may solve.

Reducing system complexity

Over time our system may become very complex and the same very hard to maintain. Compiling, running, developing and testing this kind of system may consume plenty of time, and as we know, time is money. So the reasonable solution would be here splitting it into smaller, better understandable, loosely coupled pieces. So, as you can guess, microservices would be the right choice. So to quote Martin Fowler

“…don’t even consider microservices unless you have a system that’s too complex to manage as a monolith …”

Using different technologies

Each technology has its pros and cons. So this can bring us to the conclusion that one problem could be better to solve using one technology, another using different. You may say: “Oh, thank you, captain obvious”, but please think it over. How many times would you be able to implement something better using a different tool? How many times do you build workarounds only to meet the requirements of technology to which you are limited? In a microservices architecture, there is no such limitation. We are developing each microservice independently, giving you the chance to choose the best tool to solve the presented issue.

Splitting responsibilities in a big team

I enjoyed being a part of a small developers’ team and a big one in my career. So, based on my personal experience, I can say that the microservice approach works much better in teams with a higher number of members. Splitting responsibilities is much easier (sometimes happens naturally), in result of which the developers’ work may be performed simultaneously and delivering/realising may be done much faster. Of course, the solution architect position is, in this case, crucial. We have to remember that we need someone who understands and keeps the system as a whole.
So if you need to solve the mentioned issues or you will have to do that soon, microservices architecture could be the right choice. However, please be aware that, without in-depth domain knowledge and experience in this kind of architecture, it will be tough to create the proper microservices architecture design.

Conclusions

Personally, I’m always trying to find a solution which fits my needs — no more, no less. In my opinion, we should see the right balance: covering all business cases and predicting behaviours without trying to be a fortune teller in the long run. I still keep in mind that architecture design is a process that goes on as long as the application/system is working. Following this, we should always prepare a design open to changes.

I treat time spent on choosing and designing architecture as a necessary investment. You will need to bear this cost, one way or another. At the beginning of the project (before the implementation starts) or later, but as they say “the more you get into it, the more complicated it becomes “.

Need a helping hand with desigining your sofware architecure, adopting microservices or scaling your systems?
We can help! Contact us.