Impediments in Microservices Transformation Journey 

• We decoupled the system into components, divided it into smaller pieces.

• So how will versioning and testing work? Components should talk to each other with consistent versions.
• What if an instant network split occurs in one of the parts in the system?
• What if an unexpected error occurs in a part of the components, where and in which conditions?

• We scaled the teams, and also we said that we can develop and deploy applications quickly.

• Most times the teams are unaware of each other.
• When we think of the system as a microservice, how will this system act in a reactive way? The A team's API is under the heavy load, but the B team's API still sending requests to the A. Then what will happen?

• What about monitoring and logging?

Of course,

Generally,

But,

Distributed monolith
architecture?

Synchronous dependencies.

E.g:

just like dominoes

We can avoid:

• Unnecessary use of system resources (combining with bulkhead isolation)
• Cascading failures

Some tools:

In most cases, the failed operations can be performed successfully in the 2nd or 3rd retries.

Linear retry policy

It is a great mechanism against the transient faults in a distributed architecture.

Some tools:

What if things don't go as planned?

It is our backup strategy, especially in microservice architecture.

For example:

• An e-commerce payment operation.
  • Maybe we can process it asynchronously.
  • Maybe we can do payment operation on another bank.
  A fetch operation of product catalog on a search engine.
  • Maybe we can be returned a cached response?

Unavailable?

It is great enabler because of:

• It provides us to create a single entry point to the system and create uniform experiences.

• End-user just talk with a single point.
• We can route an API to different points as we want without affecting to an end-user.
• We can log all requests and responses from a single point.
• We can manipulate requests and responses.
• Authentication.
• Caching...

• Reliable processing using policies (API level retry, throttling).

It is great enabler because of:

• Request shadowing

• It is a great feature in order to test an API under the real user traffic.

With distributed tracing, we can debug and optimize code.

End-to-end health status.

Application Insight

Prometheus

Metrics: