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.
Best Answer
If your company has been doing microservices for a while, some pieces might already be built and you simply need to incorporate them. Likely examples might be authentication as a service or storing blob data. In that case, you've already defined the boundaries and you are reusing code in a new application. That's a good thing.
For new code where you are unsure of where the boundary needs to be, build it up in one service. If you keep it modular, you can split off microservices from it as necessary. Particularly as you find pieces of your service that need to scale differently than the rest.
The benefit of microservices is that you can add instances to scale the work being done on demand. If some of your work comes in bursts, it might make sense to seperate that off into it's own microservice.
In general:
You have to take statements like that in the spirit of how they are meant. Martin Fowler is trying to save people from paralysis by analysis and tell them to build something that works first. You can always break it apart later, when you know more about how your application really works.