In this short article, I would like to share my thoughts very briefly about probably the most popular modern software architectural approach, microservices. We will go through what really microservices architecture is, what is it for, and why they are a lot more complex than they look on the surface.
If I have to give one sentence about what microservices architecture is, would be; it is a distributed systems architecture.
A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system. (Wikipedia)
So only by saying the "distributed" term, this means complexity to it and a lot of challenges that you get by default automatically.
Only 3 challenges are listed below:
- Since nodes, machines, or services need to communicate over the network with each other it means you must build a reliable and secure communication model. You need to define precisely also the coordination between them.
- Since hardware can fail, the software can crash, memory can leak, etc, you must build a resilient distributed system that will continue to do its job even when failures happen.
- Since a distributed system is harder to test, needs to be maintained, continuously delivered, and continuously deployed, a lot of effort must be put into monitoring (metrics, alerts, dashboards, logs, service-level indicators, service-level objects, etc).
A mistake that is usually taken for granted when trying to describe microservices, is that despite the name that implies, a microservices architecture is not all about a set of small services. Restful APIs do not define microservices, it is simply one of the several techniques that are used by microservices in order to communicate. Microservices can also use asynchronous messaging, Function as a Service, RPC, gRPC, JSON, etc.
This brings to the main characteristics of microservices (again only 3 points are listed below):
Microservices architecture encourages you to break the application into smaller components, that focus on one task (when being viewed from outside), and do it well.
They embrace the concept of sovereignty and decentralized data management. So each microservice should own its related domain data model and domain logic. And there won't be a monolithic database containing all the data belonging to the application.
Microservices are self-contained, independently deployable, and autonomous services that take full responsibility for a business's capability and its execution. Made simply, it means they must be able to operate and be maintained without relying on other microservices.
Why almost everyone wants to use them?
Shortly, a microservice architecture gives you a lot of flexibility as you continue to evolve your system and they provide long-term agility.
Conclusion
Microservices offer great benefits but also raise huge new challenges. It is important to remind that a bad decision in architecture would lead to not reaching the desired goal, that's why a lot of knowledge and experience is required. And how I see it, for a startup, for a company with a small team, or for a relatively non-complex project, starting with a microservices approach could be overwhelming and the benefits don't superior the drawbacks. Anyway, I would argue that the best architecture depends on the use cases, and would recommend looking at the business and its needs, and then deciding what you need to modularize and distribute to optimize your processes.