Member-only story
Microservices Are Not the Next Step After a Modular Monolith
Why Architecture Must Follow Business Needs and Organizational Reality
Microservices are one of the topics that continues to spark debate. One idea in particular keeps catching my attention: the notion that a team must first learn to develop a good modular monolith before creating microservices. This may sound reasonable at first, given that distribution adds real costs. Remote communication can fail, consistency becomes harder across independently managed data, and operating many deployable units requires more automation and monitoring. Those are valid reasons to choose microservices carefully. They do not establish a mandatory sequence in which every system must begin as a modular monolith.
The problem is the framing. It turns an architectural decision into a maturity ladder. Microservices are not a next level of developing software. They are not a reward for experienced teams, and a modular monolith is not the training phase that must be completed first.
James Lewis and Martin Fowler described microservices as services built around business capabilities and independently deployable through automated delivery. Their description also includes decentralized control, decentralized data management, product ownership, and designing for failure. A…
