Monolith First (2015)

> I feel that you shouldn't start with microservices unless you have reasonable experience of building a microservices system in the team

Well, yeah... obviously. That's not the same thing as it being bad to start with microservices generally.

I just don't agree with this at all. The designer of the architecture clearly does need to know how to design service-based architectures and needs to have a very strong understanding of the business domain to draw reasonable initial boundaries. These are not unusual traits when starting a company as a technical founder.

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.

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.

The reality though is that the team now has multiple problems, which include:

- 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.

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?

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.

> These are not unusual traits when starting a company as a technical founder.

Its actually not unusual to have technical cofounders who have no prior software engineering work experience.

You can still build a "monolith" but in a very modular way. Can't scale independently like microservices, but what if you don't need scale! Compile times are higher but what if you don't need to compile that much code! One error can bring down all "monolith services" but what if your app is not that big!

I'd wager, something like 90% of software projects in companies can just get by with monoliths.

You know...there are monoliths that are well architected, and then there are monoliths that are developed for job security.

I've worked in two major microservices environments. The one was a new application where everything was sloppily wired together via REST APIs and the code itself was written in Scala. A massively weird conflict there where the devs wanted a challenge on a code level but nobody wanted to think about the bigger picture.

The other was an attempted rebuild of an existing .NET application to a Java microservices / service bus system. I think there was no reason for a rebuild and a thorough cleanup would have worked. If that one did not move to the microservices system, the people calling the shots would not have a leg to stand on because the new system would not be significantly better, and it would take years to reach feature and integration parity.