Is Monolith Dead?
As the popularity of Microservices and fine-grained services grows, is this truly the end of Monolith.
Monolith architecture has been very successful in shaping the software world the way we see it today. However, the last few years have seen a sharp decline in its adoption, especially with the advent of Microservices. The popularity of microservices was caused by the need for scalability and changeability which in turn is caused by the penetration of IT in almost every entity, animate or inanimate. Modern applications see no boundary when it comes to scaling and these applications are fond of change and this is where Monolith doesn’t fit at all.
Microservices, at least in theory, is “The Silver Bullet” that will solve all the problems and will serve humankind till eternity, but it doesn’t happen. Microservices bring lots of challenges that were nonexistent earlier. Still, what it does, it does it beautifully and efficiently and most importantly serves the purpose.
The popular idea is to have very fine-grained services where each service is responsible for a single task. Practitioners give a contempt look to coarse-grained services as it is deemed against the philosophy of Microservices and this is where Monolith is left for a slow death. Is monolith really that bad and if so then how it was one of the most successful architecture for years?
Monolithic and Microservice
Fine-grained microservices have their own challenges e.g. transactions or latency. To make matters worse, the management overhead is overwhelming, and agreeing to the fine-ness is no easy job. Fine-grained microservices are preferred because there is no single point of failure, the possibility to scale independently, the ability to change and deploy often, and the list goes on. However, if you look at these goodies carefully, all of this can be achieved only by complex design patterns and development discipline. On the flip side, there are challenges like unavoidable network latency which in turn results in degraded performance (unless it uses additional complex systems like caching), huge management overhead, complex transactions, and many more.
A monolith by definition is a system that consists of every part of a system, but for ages, organizations have been building monoliths that at least have different processes for UI and backend and these parts integrate via interfaces. This segregated model is referred to here.
Monolith systems have the edge when it comes to simplicity. If the development process can somehow avoid turning it into a big ball of mud and if a monolith system (as defined above) can be broken into sub-systems such that each of these sub-systems is a complete unit in itself, and if these subsystems can be developed in a microservices style, we can get best of both worlds. This sub-system is nothing but a “Coarse-Grained Service”, a self-contained unit of the system.
A coarse-grained service can be a single point of failure. By definition, it consists of significant sub-parts of a system and so its failure is highly undesirable. If a part of this coarse-grained service fails (which otherwise would have been a fine-grained service itself), it should take the necessary steps to mask the failure, recover from it and report it. However, the trouble begins when this coarse-grained service fails as a whole. Still, it is not the deal-breaker and if the right mechanism is in place for high availability (containerized, multi-zone, multi-region, stateless), there will be very bleak chances for it. On the flip side, it takes away the complexity of failure management for sub-parts like needing to employ circuit breakers. There is a trade-off but it is worth evaluating.
Scaling a coarse-grained service is not very different from a fine-grained one. If its boundaries are defined carefully and if it is developed as a stateless, scaling these services is trivial. They can run inside containers and can even be deployed in a serverless manner on the cloud (e.g. AWS Fargates).
One of the challenges a coarse-grained service faces is to react to change. In the past, during the Monolith era, the journey from code to production was manual and tedious. However, with modern methodologies, it can be automated easily. A coarse-grained service is not very fine, still, it is not supposed to be of the scale of a Monolith and so reacting to this change is not that challenging as it seems. There can still be some trade-offs but it is worth considering them.
A coarse-grained service is often a complete unit in itself and so it can take advantage of running in a single process, which means network calls can be replaced with method calls which not only improve performance but also simplify management of components.
Conclusion
Quite evidently, there is a need for an amalgam between a Microservice and Monolith. In fact, microservices is not really about building very small services but it is an architecture style to build software as a service app that can be built independently and that interact via interfaces. All of this can be weaved into a monolith or a coarse-grained service which allows reaping benefits of both the architecture style.
And so, Monolith is not dead but it just incarnated into a different form to serve for time to come.
We Provide consulting, implementation, and management services on DevOps, DevSecOps, Cloud, Automated Ops, Microservices, Infrastructure, and Security
Services offered by us: https://www.zippyops.com/services
Our Products: https://www.zippyops.com/products
Our Solutions: https://www.zippyops.com/solutions
For Demo, videos check out YouTube Playlist: https://www.youtube.com/watch?v=4FYvPooN_Tg&list=PLCJ3JpanNyCfXlHahZhYgJH9-rV6ouPro
If this seems interesting, please email us at [email protected] for a call.
Relevant Blogs:
Recent Comments
No comments
Leave a Comment
We will be happy to hear what you think about this post