Distributed Monolith Instead of Microservices

Martin Fowler wrote in 2015 that almost all the successful microservice stories started with a monolith that got too big and was broken up, and that systems built as microservices from the start have usually run into trouble.

You describe a team that was hired to decompose a monolith and produced a distributed monolith instead of real microservices. Fowler's article, "Monolith First," says his advice is tentative because the evidence is limited, and notes that some colleagues favor starting with microservices, especially teams that have done it before.

The architecture patterns I work from come from Martin Fowler's Patterns of Enterprise Application Architecture and Gregor Hohpe's Enterprise Integration Patterns.

Fowler's observation is about order: the successful stories began with a single application that grew too large and was then divided. Knowing what the original application did, and how it was structured, shows what each new service was supposed to take over.

Company B's first version cost about $15K but was so buggy it could not deliver key features, so a team of American contractors rewrote it. That second version cost about $37K a month for three years, about $1.3M in total, and was still unstable and unmaintainable. Both versions had no proper application architecture.

In that case the same architecture problem was in both versions, and the fix was a rebuild of the backend and frontend, not a change to how the pieces were deployed. Over 14 months, I kept about a quarter of the existing code, and maintenance fell to under $2K a month.