Basic Definitions
Microservices – This is a broken down and loosely coupled architecture that allows for independent updating and deployment of the various features that make up the entire application. An example of this would be the breakdown of an application to services like authentication service, notifications service and whatever other features that may make up the entire application.
Monolith – The entire system is deployed as one huge deployment. One change in the ecosystem means downtime depending on the setup of the deployment system and multi-hour deployments.
A major defining difference is the communication form between the features/services. In microservices architecture, the communication is through network calls – apis, gRPCs and whatever other methods that utilize network calls. On a monolith setup, the modules communication is done using function calls.
Why switch from Monolith to Microservices?
The speed of deployment on a monolith gets really slow especially with multiple teams working on the same codebase (This is really subjective). If well architected, a monolith can be deployed just as fast as microservice architecture. The idea is that most organizations have legacy code that is not well architected and hard to deploy without going into maintenance mode and having deployment windows that last hours due to the nature of the rollout.
Ease of scaling (very subjective as well) – scaling a monolith more often than not revolves around vertical scaling. Horizontal scaling is possible but often challenging to implement. (A separate post on types of scaling may be written depending on vibes).
Fault detection and isolation. When a monolith is deployed (more often than not a culmination of multiple months of work from multiple teams), errors and faults may occur (despite sleepless nights from the QA team). It is not always easy to detect where the fault came from and may result in rollback of the entire system to deal with the issue.
Difficult to use features that are not part of the language type/version that has been used to build the code base. This from my experience would be the biggest reason to switch. If you have had to manage a security update project that consisted of rewriting entire applications because the language is no longer supported….
Advantages of Monolith vs Microservices
There is an up-side to using monolith as compared to using microservices.
Monoliths are easier to understand and onboard new software engineers. A reduced learning curve with the process as it’s just one codebase.
The monoliths may be faster, may being the operating key word. Monoliths rely on function calls as opposed to network calls(see apis and grpc) this makes them faster
With controls and measures in place, deployments and hot reloading may be possible. With certain features being moved to production and only activated at the right time. Automated regression tests on code, also ensures that the features being continuously pushed are working correctly within the entire application enhancing reliability.
Conclusion
There is no right or wrong architecture approach, it all depends with the organization and the needs in terms of team structure, velocity and feature scalability.