Choosing Between Microservices and Monolithic Architecture - How to Avoid Architecture Disaster?

Microservices are trendy and they’ve become the default architecture for hundreds of companies around the world. Companies like Amazon, Netflix and Uber use microservices. Does that mean that they are good for your project? Don't risk falling into a cargo cult mentality, just assuming that “If microservices are good for Netflix, they’re good for us!

I've always tried to cut through the hype and help companies to decide if microservices are right for them.

Many companies aim to solve the problems that microservices cause, some of them plan to do the migration to microservices but don't know how to start.

Business today is more complex, distributed over the continents, performed 24/7 over the internet, and deals with different currencies and time zones. Applications need to meet business needs which are getting more complex. They are supposed to process huge amounts of data, be mobile, use geo-localization, and communicate with external systems. What to do if you are starting a new project or having an issue?

Starting a new project or planning a migration from monolith to microservices

How do you take an existing system and re-architect it without having to stop all other work? How do you break apart existing systems into a microservice architecture? - Those are everyday questions for companies who plan migration to microservices.

My clients face challenges when starting with microservices, and clients with existing architectures (non-microservice-oriented) struggle with adapting microservice architecture, thus I decided to create a series of blogs that will hopefully help answer those questions.

Before we dive into working with microservices we need to make sure that we're speaking the same language. It's important that we have a common, shared understanding of what microservices are.

What is a monolith?

When all functionalities in a system are deployed together (one unit of deployment), we consider it a monolith. It's a single integrated application most of the time written all in one programming language. There are many types of monolithic systems, the most popular and commonly used are the single-process, modular, and the distributed monolith.

The Single Process Monolith

The most common example of monoliths is a system where all of the code is deployed as a single process. All code is packed into a single process and all processes read or store data from a database.

Figure 1. A single-process monolith: all code is packaged into a single process.

These single-process monoliths represent the vast majority of the monolithic system that I can see people are struggling with.

The Modular Monolith

The single process consists of separate modules, each module can be worked on independently but still need to be combined for deployment as shown in Figure 2. The concept of breaking down software into modules is well known in the history of building software applications.

Figure 2.?A modular monolith: the code inside the process is broken down into modules

If module boundaries are well defined, it can allow for a high degree of parallel working. For many companies, the modular monolith can be a good choice. Shopify is a great example that has used this approach as an alternative to microservice decomposition. One of the challenges of this technique is that the database tends to lack the decomposition we find at the code level. I have seen some teams having the database decomposed along the same lines as the modules, as shown in Figure 3. This can be very challenging even if you are leaving code alone. We will explore those patterns in further blogs.

Image 3:?A modular monolith with a decomposed database

The Distributed Monolith