Microservices: few considerations

By Maurizio Farina | Posted on November 2017 - DRAFT

In a microservices architecture the applications are developed following modularity approach; the application is decomposed into a set of services, each of which corresponds to a business capability.

This approach allows the teams develop large and complex applications keeping focused on to deliver better software and faster adopting new technology more easily since they can implement each service with the latest and most appropriate technology stack.

Decomposing the application in ten or hunderds of microservices arise few challanges:

  • Interactions: The data model is decompes across the services (Messaging, RPC and REST)
  • Transaction: each service manages only its transactions
  • Discovery: the endpoints of all microservices are not known to everyone

From technical point-of-view in a distribuited architecture with many microservices is possible to use different approaches:

  • Service orchestration: coordination or integration of several services exposing them as a single service
  • Service choreography: exchanging the messages between different services.

Orchestration refers to automated execution of a workflow, i.e., you define workflow using an execution language such as BPEL, and you have an orchestration engine to execute the workflow at runtime. An orchestrated workflow is typically exposed as a service that can be invoked through an API. It does not describe a coordinated set of interactions between two or more parties.

Choreography refers to a description of coordinated interactions between two or more parties. For example, you request a bid, I return a quote, you submit a purchase order, I send you the goods


Orchestration

Orchestration: a single actor, such as a business process management engine or a saga cordinator, has the responsability to involve all the services where each service is not aware for the desired goal. If something goes wrong the ator is responsible for recovering. The actor can:

  • Track and manage workflow
  • process lifecycle: pause, resume and restart processes.
  • Synchronously (or serially) process all the tasks when there is a greater need for control.
  • Process elasticity.

The trade offs in using service orchestrators include:

  • Introduction of tight coupling between the services.
  • Introduces a single point of failure (the orchestrator itself.)
  • Synchronous processing can block requests, which can lead to resource starvation.

Choreography

With service choreography can be defined by exchange of messages, interactions and agreements between two or more services, which translates into decentralized service composition.

Some of the benefits include:

Faster processing as services can be run asynchronously. Adding or updating services is a much simpler operation since they can be simply plugged in or out of the event stream. Since control is distributed, a single orchestrator is no longer needed. Service choreography enables the usage of several patterns, such as event sourcing, command query responsibility segregation (CQRS), to name a few. Some of the trade offs include:

Asynchronous programming is a challenge and a paradigm shift for many engineers. Even though the architecture may look simpler, the complexity has just shifted from a single orchestrator to a flow control that is now broken up and spread across all the individual services.

Which to use

Chris Richardson: If the saga is simple, then use choreography. If it becomes too difficult to understand, then use orchestration.

The choice of microservice interaction should always optimize these broad areas:

Team autonomy: It pays off to have autonomous teams where coordination with external teams is not part of the development process Resiliency: Software systems fail; working with distributed microservices greatly exacerbate these failure scenarios. Make resiliency a design construct from the beginning of any system design. Maintainability: This is the other side of flexibility. Managing many codebases requires having some guidelines and tools in place to ensure devops and C.I. consistency. Automation: Automate all the things! Flexibility: Empower teams with the ability to make choices that match what’s best for their environment and use cases. Development speed: You can save a lot of money by empowering teams to build and deploy services as quickly as possible!