Impediments in Microservices Transformation Journey 

Barış GÜLMEZ - Gökhan GÖKALP

13.04.2019

Devnot Developer Summit 2019 - http://summit.devnot.com/

Who am I?

Gökhan GÖKALP
Software Architect


 

http://www.gokhan-gokalp.com

E-mail: gok.gokalp@yahoo.com
LinkedIn: in/gokgokalp

Twitter: @gokgokalp
GitHub: gokgokalp

Agenda

  • Key Characteristics of Microservices
  • Resiliency Patterns (Circuit Breaker, Retry Mechanism, Fallbacks)
  • The Role of API Gateways in Microservices
  • Tracing!
  • Health Monitoring
  • Contacts

Key Characteristics of Microservices

  • It decouples the system from each other as components (it divides the problem into small pieces).
  • Since it also scales the teams, it allows us to develop and deploy applications quickly.
  • Facilitates maintenance and testability.
  • It allows us to scale our system as a pinpoint.

Key Characteristics of Microservices

  • 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?

Key Characteristics of Microservices

  • 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?

Key Characteristics of Microservices

Of course,

there are a lot of benefits of microservice architecture.

Generally,

we assume the system will be more elasticity while designing it.

But,

we are increasing fragility as distributed.

Key Characteristics of Microservices

Distributed monolith
architecture?

If we are not careful:

Synchronous dependencies.

E.g:

just like dominoes

Resiliency Patterns

Circuit Breaker

Like fusebox in our house.

Cascading failures

Applications communicate with each other continuously:

  • Network splits
  • Timeouts
  • Higher loads of traffic​

Resiliency Patterns

Circuit Breaker

Resiliency Patterns

Circuit Breaker

We can avoid:

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

Some tools:

Resiliency Patterns

Retry Mechanism

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.

Resiliency Patterns

Retry Mechanism

Some tools:

Resiliency Patterns

Fallbacks!

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?

Resiliency Patterns

Circuit Breaker, Retry Mechanism
and Fallbacks!

The Role of API Gateways in Microservices

An API Gateway is one of the must-have parts of a microservice architecture.

The Role of API Gateways in Microservices

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).

The Role of API Gateways in Microservices

It is great enabler because of:

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

Tracing!

Due to the nature of microservice architecture, they are independent of each other.

Which request, where does it go?

How long does a request spend time?

We need to a distributed tracing mechanism.

Tracing!

With distributed tracing, we can debug and optimize code.

Health Monitoring

Which service is up? Which service is down?​

This is the question.

Services also have databases and different external services.

Health monitoring also important like tracing in order to see the health of the infrastructure.

Health Monitoring

End-to-end health status.

Health Monitoring

Application Insight

Prometheus

Metrics:

Contacts