Microservices

About

A software design choice, that breaks a single application design choice (Monolith) into several pieces (Services).

Each of these services are:

Independent from each other:

• Will have their own databases.

• Will have it's own scalability parameters.

You should be able to completly shutdown a microservice and this should not bring down any other microservice.

Will communicate with each other by an Event Bus (API's, Queues, Streams, etc.)

Meaning that they also won't directly access other services databases.

Will have eventual consistency, because of this async communication.

One of it's major advantages is the possibility to scale each service independently.

Each service can be developed by it's own separate team, and this:

• This makes teams more autonomous.

• Accelerates development and deployment.

Having a Microservice Architecture with:

• Scalability, Service independence, Fail tolerance and Resilience.

Requires:

• Good Strategic Modeling.

• Async communication between services.

• Event-Driven Architecture.

• CQRS.

Dont't have your services depend on each other.

Having dependency between services is the worst case scenario.

Example

When use it

When you have to scale your teams, or the application independently.

When you have well defined contexts/business areas.

When you have maturity in deployment processes. (Like CI/CD)

Communication Between Services

Synchronous

In this way, a microservice makes a HTTP request directly to another microservice to do something.

Mainly used for communication for operations that require an immediate response, like data query or actions that need an immediate confirmation.

Major downside that one service is tightly coupled to the other.

Asynchronous

Over Messaging

In this way, microservices communicate over asynchronous messages that are place over queues or topics.

Mainly used for events and background processes, where an immediate response is not required.

Increases microservice independence.

Choreography vs Orchestration

Choreography

It is a decentralized way of setting up communication between services, where the own services knows what other services they depend on.

This is a Pattern of Event Driven Architecture, Choreographed SAGA.

Death Star

In some extreme cases, where you have thousands of microservices you may end up with a topology like Death Start.

Mitigate Death Star - with Mini API Gateway

You add API Gateways in front of a group of Services. (That usually are in the same Context)

It is also possible to add rules, like Limits, Transformations, and other resources available by an API Gateway.

Orchestration

It is a centralized way of setting up communication between services, where a Mediator is used to handle which service should be called after another.

And if something goes bad between a transaction, the Mediator can undo all in the correct order.

This is a Pattern of Event Driven Architecture, Orchestrated SAGA.

Resilience

At some point every system will fail, so how can I mitigate these risks of data and transactions loss.

A system in a distributed architecture should adopt auto-preservation mechanisms to garantee its operation.

Also a system should not be selfish in doing non-stop requests to another failing system.

Indepotence & Fallback policies

Indepotence is the ability to detect and deal with duplicity. (Ex.: Duplicated requests sent to Queues)

Fallback policies to define what should happen or what should be done when something is unavailable.

Observability

Help alot with APM (Application Performance Monitoring).

Allows easy tracing of errors with Distributed Tracing.

Personalized metrics.

Healthcheck

A mechanim to check the health of systems.

An unhealth system have a chance to recover, if traffic can be redirected out of it.

A good healthcheck also tests the system's dependencies.

Active healthcheck

In active mode, the system itself will self ping and check its health.

Passive healthcheck

In passive mode, the system will only know its health after someone else checked for him.

Rate Limiting

Can protect a sytem based on the limits it was supposed/build to handle.

Circuit Breaker

It protects a system, making all requests to it to be blocked.

Closed Circuit

Requests arrive normally.

Opened Circuit

Requests are blocked.

Semi Opened Circuit

Allows limited amount of requests, for system check reasons.

Retries

Policies for retrying to reach services if they fail.

Linear - No Backoff

Retries are done within a contant time between tries.

Exponential Backoff

The time between tries increase exponentialy.

Exponential Backoff with Jitter

Again the time between tries grows, but an additional mount of time (Jitter/Noise) is added.

Choose this policy, since it decreases the probability of different requests, retry at the same time.

API Gateway

It is a single point of entry for a group of services.

It can garantee that inappropriate requests don't hit internal services. (Like unauthenticated users)

Healthcheck, Rate Limiting, Auth, and etc, can be implemented by API Gateway.

It also help us to organize our microservices in contexts.

API Gateways can be stateless or stateful.

Ex. of API Gateways:

Kong

Service Mesh

It can control and monitor the entire network, by using Proxies in front of the services.

The Service Mesh handles, Rate limiting, Healthchecks, Circuit Breakers, Retries, etc..