There seems to be a popular desire to use Microservices to build anything and everything. While Microservices are great and scalable solutions, they address a very specific requirement: A need to decouple teams and solutions from each other when build a loosely-coupled polyglot environment whilst keeping things cohesive. You use it when you have multiple teams are working on a single and complicated product environment, and you want to keep each team in charge of autonomous product features. Yes, it’s a broad solution style that can be applied to anything, but let me remind you one of the golden rules of life: Just because you can, doesn’t mean you should.
Anything you can solve with Microservices can also be solved in some other way. What should have you lean towards it is the need to scale the dev teams. It’s a specific organisational requirement as part of non-functional requirements. This particular requirement should drive you to have independent teams that work together to create a cohesive product whilst keeping their products (or same product’s parts) separate. Each team should have the ability to build and ship their own features and manage their own product backlog, whilst work in tandem and make sure their products/features are integrated well enough to create a cohesive big picture.
If you’re choosing Microservices without having this particular requirement, I have bad news for you: You’re making a mistake. It’s difficult to maintain a Microservices environment and it’s damn difficult to develop in one. Oh, it’s fancy, I’ll give you that. It’s a white whale that everyone chases, just to build something with it at least once in their career. But because that’s not the requirement, you’ll be doing it the wrong way. You’ll be choosing the solution first and then will try to retrofit the requirements to make it work. That will certainly hurt everyone, especially your business.
A Microservices app that’s messaging based can be done with a single app that subscribes to multiple queues. You can scale it very well, too. API based Microservices can also be done with a few good API apps with an API Management layer in front of it. You won’t need containers, Kubernetes, or sidecars to build any of it. You don’t need to use Event Sourcing, Materialised Views, or CQRS to start building something. Believe me, the majority of the effort you’ll be spending will go to keeping the system upright instead of adding new features to it.
That’s because distributed systems, especially the ones that doesn’t need to be distributed, require a lot of manpower to maintain. If you don’t have the resources maintain one, stay away from Microservices.