I've been researching microservice architectures trying to get a high level overview of all the pros and cons, whens and whys, etc. A lot of the information I'm reading/watching is coming from ThoughtWorks (Martin Fowler, Neal Ford, et al).
Most of Martin Fowler's work on the subject is a few years old, when Microservices (as a household name in programming, if not in general practice) was still young, thus I take much of it with a grain of salt.
One thing in particular is this:
As I hear stories about teams using a microservices architecture, I've noticed a common pattern.
- Almost all the successful microservice stories have started with a monolith that got too big and was broken up
- Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .
(ref: https://martinfowler.com/bliki/MonolithFirst.html - emphasis theirs)
Now, 3 years later and with microservices a more ubiquitous term, is it generally agreeable that a new system is typically better served by having larger(-than-microservice-but-smaller-than-monolith) service chunks to start with, and making them more granular as part of an evolutionary measure?
Or, is there a norm to begin a project from scratch with a granular microservice architecture, in contrast to the statements above?
Seems like a sane general approach, but curious of the community's thoughts.