3. Microservices Architecture

Introduction

What is microservice architecture?
Microservices architecture enables large teams to build scalable applications that are composed of many loosely coupled services.

What is a Microservice?

In Microservices Architecture Services are loosely coupled. Each Service handles a dedicated function inside a large-scale application. For Example ,In Amazon Shopping app, Shopping cart, Billing, Profile, Push Function, and Orders are managed by a microservice having their own Databases.

Microservices communicate with each other via well-defined interfaces with small surface areas. The small surface areas limit the blast radius of failure and defects. It makes each service easier to reason about in the context of the entire application. Microservices talk to one another over a combination of remote procedure calls (RPC), RPC-like gRPC provides faster response, but the blast radius, or the impact to other microservices, would be larger when the service goes down. Event Streaming provides better isolation between services, but they take longer to process.

Independent Deployment

In Microservices Architecture services 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. Microservices provide more flexibility to scale up individual microservices independently. The operational flexibility is invaluable.

Strong Information Hiding

Well-architected microservices practice strong information hiding. This often means breaking up a monolithic database into its logical components and keeping each logical Component well hidden inside its corresponding microservice. By logical component, it could mean a separate schema within a database cluster or an entirely separate physical database.

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. The burden of maintaining data integrity is now moved into the application layer.

Critical Components

API Gateway

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 authorize each request through the API gateway. To route an incoming request to the service, the API gateway consults a service registry and discovery service. Microservice registers with this service registry and discovers the location of other microservices through the discovery service.

Monitoring

In a distributed Microservice Architecture we need to monitor different microservices for key parameters such as –

• Health
• Performance
• Interactions
• Stability
• Efficiency
• Resource Allocation
• Failures

Most widely used tools are Prometheus and Grafana

Alerting

While Monitoring any microservice architecture we need to generate alerts in case of failures and alerts.
All of these alerts will be visible to support teams on grafana dashboards. Which help them to track any real time failures in any of the parameters

Devops

Microservice Architecture works on a key principle of Independent deployment of smaller services managing a key function/area.
This can be only achieved only with CI/CD (Continuous Integration/Continuous Deployment) enabling faster deployment and updates.

To Enable completely automated pipelines Jenkins is the widely used open source tool for build, test and deployment.

Deployment

Microservices Architecture Deployment needs deploying independent services.
So we need to pack all application code and dependencies in a single unit and this can be achieved by using docker and Containers.

When To Use

Microservices cost money to build and operate. It makes sense only for larger teams. Each Domain and function can be independently maintained by a dedicated team. In a well-designed microservice architecture, these independent teams can move fast, and the blast radius of failure 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.