In principle, you are asking the heavily debated question of monolith (everything in one application) vs microservices (splitting functionality up into multiple services). In my opinion, there is no clear answer to that question when it comes to new projects.
What we know from experience is that in the beginning you can get away with having everything in one application. Eventually, you might reach a point where you are forced to break it up for technical reasons (scalability, easier deployments, etc.). The question is when should you start breaking it up?
You can err in both directions. Avoiding multiple services, even though it would reduce the complexity of the system can be a mistake, but also splitting it up too early when you do not know yet what you are building. The latter is not uncommon in the initial phase of a project. On the other hand, not thinking about how functionality could be broken up, can be costly later, as it will get harder and harder to make the necessary changes.
Both monoliths and microservices have different pros and cons. Monoliths win in terms of refactoring (it is easier to change the interface of a function than of a remote API), but micro services are superior when it comes to scalability.
In terms of complexity, microservices tend to be superior even for medium size systems, especially if they are well designed. Otherwise, you can also end up with a distributed mess that can be harder too understand than a well-built monolith. The larger the system becomes, the more it will favor microservices.
In the early stage of a project, my personal recommendations would be:
- If you already have a good understanding of the domain (e.g., if you can build on the experience of an already existing working system), you can more aggressively start with a micro service architecture
- If you are unsure whether functionality should be split up or not, leave it together for the moment, but ideally make it easy to break it up later (Bounded Context is a concept that can help)
- If you are not sure whether your application will be successful, be more inclined to go for the monolith first. (While it is true that all big companies run on micro service architectures, it is also true that most projects will never get even close to the number of users of Facebook or Google.)
Martin Fowler looked into the subject in this Monolith First article:
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.
But he although points out that not everyone agrees: Don’t start with a monolith