Is my Microservice actually a Distributed Monolith in disguise?
Has your app modernization exercise gone wrong?
Application redevelopment into microservices-based architecture can result in apps that incorporate the complexity of microservices with the shortcomings of a monolith — the worst of both worlds! This is called a Distributed Monolith.
Proper microservices-based architecture creates distinct units with clearly defined inter-service boundaries. The application is fragmented into individual business services, each of which functions independently of the other, communicating through APIs. Each can even be hosted on a different server.
On the downside, they are much more complex and require more tech support. However, since they use fewer resources and are more scalable, and enable an organization to more easily evolve its technology stack, microservices-based architecture is the future of application development and application modernization.
A distributed monolith, on the other hand, combines the worst part of microservices-based architecture — the complex containerized structure — with the lack of scalability, slow processing and complex editing of a monolithic application.
Deployed like a microservice, the application is structured like a monolith in a single package of source code, configurations, libraries, and every other dependency in a single container.
As a result, artifacts are large, slow and are very resource-intensive. Even worse, failures cascade from one container to the next, and any change on any service can require a complete rebuild and redeploy.
The whole point of microservices-based architecture is that a DevOps team should be able to add “just one thing”, without redeploying the entire codebase.
Distributed monoliths are also not designed for distributed systems, so horizontal scaling is inefficient.
What are the signs that you’ve ended up with a distributed monolith?
- Are your functions too dependent on each other?
Tight coupling of services is a classic sign of distributed monolith architecture. Since the different functions in a distributed monolith can share a common code base, this results in extremely tight coupling and low differentiation between functions. As microservices are not tightly coupled, they offer rapid and reliable delivery of applications.
- Can you easily and efficiently scale your apps?
Distributed monoliths exhibit inefficiency in scaling. A major advantage of microservices-based architecture is ease of scaling. Microservices-based architecture helps keep costs low while handling sudden changes in demand and prevent system overload.
- Can you update your application easily?
This is the big one! With distributed monoliths, updating applications is much more difficult. This is because there is too much data sharing between distributed systems. As a result, any change in one distributed monolith begins a cascading effect and can result in errors or failure across multiple functions.
A good illustration of this concept is the popular blogging platform and content management system, WordPress. WordPress uses a MySQL database to store data, which means a page load can generate multiple MySQL queries.
WordPress, therefore, works best with a low-latency database connection, but this creates a temporal dependency.
In Kubernetes, one can deploy WordPress and MySQL in the same Pod, but this ends up creating a pod that serves multiple functions, needs greater system resources, has an increased start-up time, and is owned by both the application and database team. In short, it is a monolith packaged as a microservice.
Moving to microservices is therefore more than just repackaging monolithic applications. When companies move to microservices, it can add complexity to the overall development process. The right service provider can help make the deployment smoother.
CloudNow delivers both custom development of applications and modernization of monolithic applications with Microservices Architecture and Containerization. Interested in our services? Get in touch with us today!
