A microservice is a small networked service, that has specific responsibilities and an externally accessible API that other services or applications can interact with.
When designing software, you would typically use classes, modules and patterns like SRP to separate concerns and isolate functionality within your codebase.
Microservices effectively perform this same role, but the isolation is introduced at the network level (rather than at the application level), providing a stricter interface for interacting with your application’s business logic.
We see a number of business benefits that microservices can offer, such as improving the autonomy of your development teams, supporting an increased frequency of change, and reducing the complexity of large-scale systems.
However, we also see significant overhead in their use, and a large cost to adopt microservices within a business. Below we’ve included 8 points that you might want to consider before using microservices:
- Microservices enable you to select the most appropriate technology stack for your service. This is incredibly powerful, as you do not need to rely on a framework that tries to do *everything* for you, and can select the framework which is most appropriate to the services requirements.
- Microservices have much smaller codebases when compared to ‘monolith’ applications, so deployment and build times should be much quicker.
- Microservices allow you to release smaller change sets. A one-line change to a hundred-thousand-line monolith application requires the entire application to be deployed. A one-line change to a microservice only requires the service to be deployed.
- Microservices are easier and more cost-effective to scale, as they allow you to focus on scaling just those services that need scaling and not your whole application.
- Microservices significantly increase the development time of new features, as Cloud Infrastructure, Continuous Integration, Build Pipelines, Databases etc need to be configured and deployed to support your new microservice.
- Microservices can make application refactoring difficult, as interfaces and application boundaries are spread across your microservices.
- Techniques like API versioning can be introduced to mitigate this, though this will add complexity into your microservice and to your clients.
- Microservices introduce additional operational complexity, as you have many moving parts that need to be monitored closely. This overhead will increase exponentially as you add more microservices to your application.
To conclude, I would recommend you only consider microservices if your system is so complex that managing it as a monolith would be impossible. For the vast majority of applications, microservices are unnecessary and will end-up adding more complexities into the system than they will remove.