Microservice architecture design principles

Microservice Architecture Design Principles

Sanjoy Roy

sanjoykr78@gmail.com

Let’s take the inspiration from biological cells before talking about Microservice:• They are small and single purpose• They are many of them but they work in

concert with one another• Each cell is able to respond to its

environment• They communicate with each other using

messages• They can replicate• They keep outside out• Death is natural and expected

Microservice architecture advocates creating a system

from a collection of small, isolated services, each of

which owns their data, and is independently isolated, scalable and resilient to

failure.

Divide and ConquerA divide and conquer algorithm works

by recursively breaking down a problem into two or more sub-problems of the same (or related) type (divide), until these become simple enough to be

solved directly (conquer). The solutions to the sub-problems are then combined

to give a solution to the original problem.

In Microservice Architecture we use

Divide and Conquer: the decomposition of the system

into discrete and isolated subsystems communicating over

well-defined protocols.

Microservice

Single Responsibility Replaceable Organized around business capabilities

Single Responsibility Principle

Single Responsibility Principle (SRP) states that a class or component should “only have one reason to

change.”

Do One Thing, and Do It Well

This is the Unix philosophy: Write programs that do one thing and do

it well. Write programs to work together.

—Doug McIlroy

“Micro” should refer to scope of responsibility.

A service has only one single reason to exist and should provide a single composable piece of functionality.

A service should do one thing and do it well.

Focus should be on business capability.

What about state?

Microservices are often stateful entities:

they encapsulate state and behavior.

ProductService

CustomerService

OrderService

PaymentService

SearchService

DB

This is still a monolith.

Oracle Couchbase Oracle

Customer Service

Customer Service

Customer Service

Customer Service

ProductService

ProductService

ProductService

ProductService

OrderService

OrderService

OrderService

Bounded Context Bounded Context Bounded Context

A microservice owns its data.

Business Capability Business Capability Business Capability

Decentralized Data Management

• Each microservice manages it’s own database: either different instances of same database technology or completely different database system (polyglot persistence)

• Eventual consistency

Microservices encapsulate state and behaviour.

Model each service as a Bounded Context.

Each service usually defines its own domain, each with its own Ubiquitous Language.

State(Data)

Behaviour(Business Rules) Business Capability

Search Service

Search Service

SearchCache Couchbas

e

ProductService

ProductService

ProductService

ProductService

Bounded Context

Bounded Context

Client

Business Capability Business Capability

IsolationIsolation is a prerequisite for resilience and elasticityEmbrace Share Nothing ArchitectureFailure Isolation (Bulkheading)Isolation between services makes it natural to adopt Continuous Delivery Isolation also makes it easier to scale each service, as well as allowing them to be monitored, debugged and tested independently Isolation is a prerequisite for autonomy

An autonomous service can only promise its own behaviour by publishing its protocol/API.

All information needed to resolve a conflict or to repair under failure scenarios are available within the service itself, removing the need for communication and coordination.

APIs need to be well-defined and composable.

Autonomous Service

Communicate through APIs

Service B

Couchbase

Service A

Oracle

APIinvoke expose

Contract

Shared understanding

API Client/Server Guidelines REST level-3 with HAL+json Use proper HTTP techniques Base design on application states and transitions

Forward compatibility over versioning Drive documentation from code Don’t write smart clients

Autonomy through Messaging

Service A(Pub)

Service B(Sub)

Service C(Sub)

Message Bus1 2 3

•Only publish business events and IDs – avoid mutable data• Implement proper error handling• Beware of added complexity

Message Publisher Guidelines

• Cater for duplicate message delivery through idempotency•Don’t rely on ordering• 1C late-commit pattern over 2PC• Implement proper error handling• Beware of added complexity

Message Receiver Guidelines

Microservice benefits

• Strong module boundaries• Independent

deployment• Technology diversity• Failure isolation• Improves time to market• Reduced cost of change

and costs

• Distribution• Eventual consistency• Operational complexity

General Microservice Architecture Principles

• Small and focused on a specific business capability• Eventual consistency • availability is more important than global and instant

consistency• Polyglot persistence• Pick most appropriate data and consistency model

• Async communication over sync• Failure resilient• Avoid SPOFs

Thank you