Why Microservices are better than Monoliths

The development effort required to build a monolith could be much more because its not easy to divide and scale the development effort. The different components are tightly coupled and parallel development is a tricky job.

A single wrong commit by a developer can break the build, blocking the entire team, because everyone is dependent on single codebase. Potential & scope for such mistakes is reduced in microservices.

Whenever we want to add/update functionality, developers need to change at-least one of these three components and deploy the new version to production. Any single change to production requires a full redeployment of the entire codebase, which brings risk of production downtime.

There are limitations in choosing technology stack. We can not build one components in Go (performance reasons), another in Node.js (high network handling) and few others in Java (simplicity in design).

When we need to scale a monolith, we deploy the same version of monolith on multiple machines, by copying the big war/ear file again and again. Everything is contained into single executable file.

The complexity of a monolith grows rapidly over the time, because its not easy to create bounded context in monoliths. Shared modals becomes too large and complex over time, which no one easily understand.