I'm learning the microservices architecture and it's a bit unclear for me when I should wrap a piece of functionality into a microservice and when it's better to keep it in a separate component installing the component in the dependent microservices.
Examples:
Symfony Security ACL component (symfony/security-acl). I could wrap it into a microservice which would only add a layer of abstraction in the form of the REST API on the top of the Symfony Security ACL API. Apart from that, I would be going to need a service agent component which gets installed on the dependent microservices and provides access to the ACL microservice. What's the point? Isn't it easier to install symfony/security-acl where it's needed and give it a separate database connection?
Payment System. In this case it's more clear that it needs wrapping into a microservice. It contains a huge volume of business logic which is just asking for separation.
Basically the questions are:
What criterion should I consider when deciding to put a piece of software in a microservice rather than into a module?
Is it a good idea to wrap symfony/security-acl into a very thin microservice (isn't it good for a microservice to be thin)?
Non-official, non-scientific reasons for microservices based on my experience:
- Horizontal scalability: If your services do not scale evenly, you might want to have 10 servers with service A, but only 1 with service B.
- Faster deployment: Having a separate deployment process per service allows you to deploy smaller pieces on-demand instead of deploying a big thing just because of a small change.
- Independent development style and lifecycle: When a project grows bigger, you might want to have other people take it over. This obviously works better with a microservice that has less dependencies than a module. Contributors and teams can develop how they want with whatever they want. Every team can use a different language, different pipelines, testing tools, editors etc. The only common denominator is formats, protocols and conventions of the resulting API.
- Simpler dependency management: Upgrading or changing libraries that depend on other libraries can lead to complications, because obviously not all of your dependencies will be updated at the same time and there will be incompatibilities.
- Clearer API: Documenting all public classes and functions can be a nightmare. On the other side having APIs with incomplete or outdated documentation is a reason to abandon projects. Microservices do not offer anything out of the box in that regard, but the interfaces are clearly defined, usually as URL endpoints and HTTP methods. This gets easier if you're following the REST paradigm.
In your particular case it's hard to say what to use because you do not give enough context. Some of the relevant questions:
- Are you developing with a team?
- Is this part of a framework?
- What are the module's dependencies?
- Is it designed with parallel access to the DB in mind?