Image shows a component view with bounding free hand drawings, conveying how the same architecture can be deployed in different ways

Monolith or Microservices? Stop Choosing Sides: Why Your Software Architecture Success Lives in the Details

“Everything that is not a microservice architecture is a monolith!” That is utter nonsense, and I am tired of reading the comparison.

Framing the discussion as a battle between monoliths and microservices creates a false dichotomy. There’s a whole spectrum of architectural choices, with plenty of shades of grey in between.

Let’s break down why this comparison is misleading:

● Microservices describe both architecture and deployment. They are a specific architectural style where an application is broken down into small, independent services, each handling a single business capability.  These services are loosely coupled and communicate through APIs. The independent nature of microservices allows for each service to be developed and deployed independently from other microservices in the system.

● Monolith, on the other hand, is primarily a deployment term. It refers to an application packaged and deployed as a single unit. While a monolith might often have a tightly coupled architecture, the term itself doesn’t inherently describe the application’s internal structure.

Therefore, it’s inaccurate to compare these two concepts directly. Say we have an N-tier service-based architecture. We can choose to deploy these tiers to a single compute unit (and I would be ok with calling this a monolith), but we can also deploy each layer to a different compute unit. What if we add load balancers in between layers?

In short, I think we have lost the richness of the discussion if we focus on microservices or monolith. Even more so, for me this is like apples and oranges, a microservices are an architectural style (let’s compare them with N-Tier, event-driven, pipelines and filters, etc.). Separately, we can discuss how we deploy these architectures.

Footnote: I’ve seen these dichotomic discussions before in software development (i.e anything that is not Agile has to be a waterfall). We seem to like them, mainly because they simplify the complexities inherent in the terms. Yet same way that I have seen teams who claim to be agile when they are not, I’ve seen architectures that claim to be microservices when they are not!

Leave a Comment

Your email address will not be published. Required fields are marked *