Monolith First (2015)
A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team.<p>A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of microservices. The team buys into the pitch and looks forwards to a happily-ever-after ending.<p>The reality though is that the team now has multiple problems, which include:<p>- Addressing conceptual debt that hasn't gone away.
- Discovering and migrating what the legacy system got right, which is often not documented and not obvious.
- Dealing with the overheads of microservices that were not advertised and not prominent at a proof-of-concept scale.
- Ensuring business continuity while this piece of work goes on.<p>I would propose alternative is to fix your monolith first. If the team can't rewrite their ball of mud as a new monolith, then what are the chances of successfully rewriting and changing architecture?<p>Once there is a good, well functioning monolith, shift a subset of responsibility that can be delegated to a dedicated team - the key point is to respect Conway's law - and either create a microservice from it or build a new independent monolith service, which aligns more to service oriented architecture than microservices.