Microservices Architecture Handbook: Non-Programmer’s Guide for Building Microservices

by Stephen Fleming

Problems of Monoliths Large-size monoliths are hard to maintain and evolve due to their complexity. Finding bugs requires long perusals through their code base. Monoliths also suffer from the “dependency hell,” in which adding or updating libraries results in inconsistent systems that either do not compile/run or, worse, misbehave. Any change in one module of a monolith requires rebooting the whole application. For large projects, restarting usually entails considerable downtimes, hindering the development, testing, and maintenance of the project. Deployment of monolithic applications is usually suboptimal due to conflicting requirements on the constituent models’ resources: some can be memory-intensive, others computational-intensive and others require ad hoc components (e.g. SQL-based, rather than graph-based databases). When choosing a deployment environment, the developer must compromise with a one-size-fits-all configuration, which is either expensive or suboptimal with respect to the individual modules. Monoliths limit scalability. The usual strategy for handling increments of inbound requests is to create new instances of the same application and to split the load amongst said instances. Moreover, it could be the increased traffic stresses only a subset of the modules, making the allocation of the newer resources for the other components inconvenient. Monoliths also represent a technology lock-in for developers, which are bound to use the same language and framework...

Problems of monolithic