Definition
A microservice is the smallest unit of functionality in a system that can be scaled and deployed independently.
This software architecture allow teams to develop a system as a small units of services running on their own and communicating with each other through a lightweight mechanism like an API.
Microservices vs Monolithic
To better understand the microservices architecture let’s compare it with the classical monolithic approach.
I’m using WordPress to write this blog post and it’s a fantastic tool for this job but it’s a monolithic system that can reach it’s limits when the business requirements outreaches the borders of WordPress capabilities.
WordPress is one box of tools that contains everything from the database to the client-side interface to the server-side application all coupled to each other. In this case any change to the application requires a deployment to the whole system also when a failure occurs in the database this means that the client-side and server-side parts of the system are prone to errors.
All those limitations to the monolithic approach lead to the microservices architecture to be adopted within engineering teams.
Benefits of the Microservices architecture
Scalability
Because the functionalities of the system are deployed independently with their own resources allocated to them, they can be scaled independently (horizontal scalability) on demand.
Fault tolerance
Going back to our WordPress example, in a microservice architecture, a failure in the database will not lead to complete system shutdown but rather only the part that is failing will go down. In this case an error in the server-side functionality will not affect the client-side application, maybe it will show an outdated results but it will continue to deliver back results to the user.
Observability
Using microservices architecture with event-sourcing enables auditability of the system, which is usually a requirement of most the financial services, because all the events of the system flows through a central event bus.
Decisions to make when designing a Microservices architecture
No shared databases
Microservices should own their own databases and not use each others databases. This approach allows loose coupling and avoids changes in the database that leads to failures in other microservices when sharing a database.
In the case of microservices that needs to share database of important informations, we should keep the informations in one database and rely on the database transactions to keep the data consistent.
Handling security
The old approach for authenticating a microservice would be to verify the request against a database or an identity server.
A better approach would be to use the token based approach. Microservices can encompass calling a database, be a middleware against the data store or serve the UI to the user. Therefore authenticating the microservices in a distributed system is a crucial part in securing the microservices design.
Some common approaches to secure the communications between the microservices is to use the SSO (Single Sign-On) approach that allows the user or identity to gain access to multiple services or the JSON Web Tokens (JWT) approach that allows sharing multiple properties from a client to a microservice in a secure way. read more about the approaches in this article.
Handling microservices flow
We need to arrange the microservices workflow so that they can return the needed result to the user. Two approaches that are common are: 1. Drive flow from client or 2. Choreography.
Avoid microservices dependencies
Avoid designing the microservices in a coupled dependencies structure so tht you endup with a monolithic microservices. read more about dependency hell in this post.