The Frankenstein MonoMicroLith

Getting Independent Deployment Wrong

The warning of faux-microservices has made rounds in the community in recent years. A cursory reading of authoritative sources (e.g., https://microservices.io, Building Microservices) will tell you one of the central ideas of a microservice architecture is independently deployable services. Many organizations exhibit some form of the distributed monolith, incurring the costs of operating distributed systems while not benefiting from the objectives of a microservices architecture.

The boxes in the illustration represent different code bases with their own histories, and the colors represent concerns that could be loosely coupled. A modular monolith or properly designed microservices is desired. Avoid the situation in the third box —run-time decoupling with verification-time (the process of taking a change from a developer’s environment to production) coupling. Requiring any change to go through a process involving everything else fundamentally contradicts independent change implied by decomposing concerns into separate services. Such confusion is an example of cargo cult programming. If you don’t have good justifications and don’t understand the costs that come with micro-services, don’t do it.

Threedots has a good article on how modular software can be achieved with microservices and monoliths.