The microservice architecture structures the application as a collection of services that are independent components, and so are:
- Higly maintainable, testable and well organized, because each microservice has its purpose, and so it’s possible to solve a bug on a single microservice without taking in consideration the integrity of the whole application;
- Loosely coupled;
- Independently deployable, meaning that it’s possible to update a single microservice without touching the rest of the application.;
- Owned by a small team.
Microservices add a dimension in the scalability, since it’s not only possible to scale in the usual vertical and horizontal dimensions, by upgrading the hardware or adding more nodes, but it’s also possible to decompose the system in more microservices that allow more scalability.
For example a single microservice can be decomposed in more instances, in order to load balance the traffic. This because some microservices may be more requested than others, and so the scalability is needed only on that particular service.
Difference with the Monolithic architecture
The classical monolithic architecture is simple to develop and deploy. It also makes it easy for radical changes, since we don’t have to rethink all the single services.
It’s easy to scale when the complexity of the application is not big, but when it reaches a certain critical point every aspect became more difficult to manage.
Another principal aspect of the microservice architecture is that each service has its own database, with all the data it produces, differently for the central database in the monolithic architecture.
In general, microservices are a good idea since they allows high maintainability, scalability, and independent develop and deployment. They also allow easy experimenting and adoption of new technologies, because of the independence from the other parts of the application.
On the other side, finding the right set of services in order to decompose a certain application is not an easy problem, and so it doesn’t have a standard solution.
Deploying features that span multiple services happens most of the times, but it has to be done carefully, and it needs coordinations between the various teams.
system-architecture related: