Let’s not demonize Monolithic architecture

In vocabulary, a Monolith means a large single upright block of stone, especially one shaped into or serving as a pillar or monument.

What is a Monolithic architecture?

Monolithic architecture refers to how your code is designed to be deployed.

No matter your application follows an n-tier architecture, or a clean architecture model;

if you deploy all of your entire application as a single binary dump that contains all of your features and functionalities, you are following a monolithic architecture.

Microservices vs Monolith

The alternative to monolithic architecture is the Microservice Architecture, where each of the features your application offers is split into light weight services and is each deployed independently as required.

Microservice architecture offers decoupling and faster delivery than a monolith, and the chance of failure is limited to that single microservice that is modified.

Agreed.

Microservices are Complex, Monolith is Simple

But Microservice architecture also adds a lot of design time complexity to the application codebase.

Let's say you have two different entities which are dependent on one another and are being represented by different microservices. Any change to the state of this entity needs to be notified across the services.

Although we apply a variety of patterns to do this, such as Event bus or Message queues, it still adds up to the complexity.

Monolithic doesn't need all this, as all the functionalities are built into the same codebase and are coupled together.

Microservices add to Cost, Monolith is cheaper

Another scenario is the service discovery - each of the service is deployed in different domains and ports. You need to know which service runs where so that interservice communication could be made.

This we do with service discovery frameworks (such as Eureka) or apply any other patterns such as API Gateways.

Monoliths don't need all this - you deploy the entire service stack under a single domain and interservice communication is just class object calls.

And with all these service discoveries and separate deployment pipelines, microservices add to cost. Monoliths are cheaper - you just need one deployment pipeline and one target for all the functionalities.

Most importantly - Do you really need to go that far?

Finally and the most important point - the necessity. Not all applications need services that run independent of one another.

Let's say I am building a Banking application where if any of the features of the Application (Account, Transfer or Reports etc) fails then you're not supposed to let other functions work. Monolith deployment is the best choice it.

Or say you're developing a simple blog website that does have some features like an Admin section and Newsletters.

(Speaking of Newsletters, please do join my newsletter and stay updated)

Do you need to go so far for a Microservice architecture or just build and deploy as a monolith?

Conclusion

Somewhere I read that Stackoverflow.com is built and deployed as a Monolith.

If such a high traffic website does a Monolith, do you have a specific reason to go for microservices?

Monolith and Microservice designs have their own pros and cons. It's like a debate between a Public Transport or driving self.

Before deciding on which architecture to use, make it a practice to take cognizance of what the requirement is, the opportunities and the future state.

If you don't see much, just simply start small with a Monolith and instead focus on performance.