The term “microservice” emphasizes the fact that applications should be composed of services small enough to truly implement a single role. Each has described contracts (API contracts) for other microservices to communicate and share data with it. Microservices must also be able to version and update independently of each other. This loose coupling the key to supporting rapid and reliable evolution of an application. What would have been a single tier of a monolithic application decomposes into several discrete microservices, each independent and isolated.
Graphics for monolithic app:
A monolithic app contains domain-specific functionality and is generally divided by functional layers, such as web, business, and data. You scale a monolithic app by cloning it on multiple servers/VMs/containers.
Graphics for microservices:
A microservice application separates functionality into separate smaller services. This approach scales out by deploying each service independently, creating instances of these services across servers/VMs/containers.
Based on a NGINX survey, 70% of companies are using microservices in PoC, development or production.
Why build microservices?
Microservices can provide several useful benefits:
1. Agility:
Because microservices are deployed independently, it’s easier to manage bug fixes and feature releases. You can update a service without redeploying the entire application and roll back an update if something goes wrong. In many traditional applications, if a bug is found in one part of the application, it can block the entire release process; as a result, new features may be held up waiting for a bug fix to be integrated, tested, and published.
2. Small code, small teams:
A microservice should be small enough that a single feature team can build, test, and deploy it. Small code bases are easier to understand. In a large monolithic application, there is a tendency over time for code dependencies to become tangled, so that adding a new feature requires touching code in a lot of places. By not sharing code or information stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features. Small team sizes also promote a greater agility. The “two-pizza rule” says that a team should be small enough that two pizzas can feed the team. Obviously, that’s not an exact metric and depends on team appetites! But the point is that large groups tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.
3. Mix of technologies:
Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.
4. Resiliency:
If an individual microservice becomes unavailable, it won’t disrupt the entire application, if any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).
5. Scalability:
A microservices architecture allows each microservice to be scaled independently of the others. That lets you scale out subsystems that require more resources, without scaling out the entire application. If you deploy services inside containers, you can also pack a higher density of microservices onto a single host, which allows for more efficient utilization of resources.
6. Data isolation:
It is much easier to perform schema updates, because only one microservice is affected. In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.
