The microservices architecture is one of the modern architectural patterns that allows us to build loosely coupled software solution by dividing the solution into various small components or services. Each service handles a dedicated responsibility inside a large-scale application and it is completely independent of the other services.
For example, shopping cart, billing, user profile, push notification can all be individual microservices. These functional areas are sometimes called domains. The following diagram shows the microservices architecture:
As per the preceding diagram, we can see that the microservices architecture consists of a collection of independent services. Each service is self-contained and should provide a single business capability within a business domain.
Microservices can be independently deployed. Since each service is small, easier to reason about, and has a smaller blast radius, this gives the operators peace of mind and confidence to deploy often.
Let’s check the characteristics of this architecture pattern:
- Microservices are small, autonomous, and loosely coupled services. Each service has its own codebase, and it can be developed and maintained by a small team of developers.
- Each service should be self-contained and deployed separately. Updating one service won’t require you to redeploy the entire solution.
- The services are responsible for having their own data access layer as each service has its private database.
- The internal implementation of each service is not visible nor accessible by any other service.
- The Client app has no direct access to the services. Consuming these services is achieved through the API gateway which forwards the call to the appropriate services.
Microservices provide more flexibility to scale up each individual microservice independently. The operational flexibility is invaluable.
Microservices talk to one another over a combination of remote procedure calls (RPC), event streaming, or message brokers.
RPC like gRPC provides faster response, while the event streaming provides better isolation between services but they take longer to process.
However, one big drawback of microservices is the breaking up of the database. By breaking up a database into separate logical units, the database can no longer maintain foreign key relationships and enforce referential integrity between these units. Therefore, the burden of maintaining data integrity is now moved into the application layer.
Let' take a look at the API gateway which is another critical key component required for a successful implementation of microservices architecture. API gateway handles incoming requests and routes them to the relevant microservices. The API gateway relies on an identity provider service to handle the authentication and authorization of each request coming through the API gateway.
There are other useful components in a microservices architecture like monitoring and alerting, DevOps for deployment, and troubleshooting.
Let's wrap up by discussing when to use microservices architecture
Microservices cost money to build and operate. It really only makes sense for large teams.
For large teams, it enables team independence. Each domain, or function, can be independently maintained by a dedicated team. In a well-designed microservices architecture, these independent teams can move fast, and the blast radius of failures is well-contained.
Each service could be independently designed, deployed, and scaled. However, the overhead of a sound implementation is so large that it is usually not a good fit for small startups. One advice for startups is to design each function in the application with a well-defined interface. One day if the business and team are growing fast that microservices architecture starts to make sense, it would be more manageable to migrate.