Designing microservices part 2

Masashi NarumotoPrincipal Lead PMAzureCAT patterns & practices

Do I need it?

Am I ready for microservices?• Prerequisites• Domain knowledge• Skillset for distributed system• DevOps culture• Monitoring capability

• Hints that you don’t need it• Very simple domain• No frequent update

• Monolith works fine in some cases• Make monolith faster by improving tools

Process of implementing microservices

Analyze business domain

Design services around

business domain

Implement services on

platform

Business alignment

Technology alignment

Designing microservices• How can I identify services?• What is the right level of granularity?• How do I capture domain knowledge?• How do we expose service interface?• How can I manage service dependency?• What is the right data model?• How can I deal with data consistency issues?• How to isolate release process?

Design principles

Design principles• Decentralize all things• Model services around a business domain• Make each service independently deployable• Data is private to its service• Hide implementation details• Isolate failureLess dependency more isolation!!

Finding service boundary

Identifying services – bounded context

Core service

Service A

Service C

Service B

Data access service

Business logic service

API service

Bounded context – service boundary• Bounded context is the service boundary• Break down further per each service characteristics

• Lifecycle (Rate of change)• Quality attributes• Technology used• Team (2 pizza rule)

• Other metrics• KPI such as velocity, team productivity, management cost etc.

• Too small granularity causes issues• Communication overhead• Tight coupling• Lock-step deployment• Data consistency

Managing dependency

Context map – managing dependencies• Tightly vs. Loosely coupled mapping patterns• Shared kernel, Partnership, Conformist, Customer-supplier, Big Ball of Mud• Anti-corruption layer, Separate ways, Open host service, Published language

Shared kernel pattern

Shared assets

Anticorruption layer (ACL)

Your context Other context

Anti-corruption layer

Adapter

Translator

facade

Façade: Alternative interface to other contextAdapter: Make requests to other context Translator: Translate the semantics

Existing system

InfrastructureProtocolData modelAPI signatureOther semantics

Managing dependency• No shared assets (schema, infrastructure, package etc.)• Co-locate tightly coupled features (high cohesion)• Reduce coupling between services (loose coupling)• Don’t leak service internals• Develop and test against contract• Separate cross cutting concerns• SxS versioning• Anti-corruption layer

Capturing domain knowledge

Capturing domain knowledge into services

public class BacklogItem {public void commitTo (Sprint Sprint) {

if (some validation ()){throw exception;

}if ( already in different sprint) {

this.UncommitFromSprint();}this.changeStatus

(pbiStatus.Commited);

publish an event;}

}

Public class BacklogItem {public void set_Status (PbiStatus Status) {

this.status = Status;}Public PbiStatus get_Status() {

return this.status;}

}

Anemic domain modelProper domain model

Exposing service interface

Exposing service interface

Domain Model

Application

Adapter

Adapter

Client

Client

HTTP

HTTP

AdapterClientAMQP

Exposing service interface• Public and Private services• REST vs. RPC

• Ease of use vs. Efficiency

• HATEOAS is a way to reducing domain knowledge from clients• DELETE order/{id} vs. POST cancel

• Asynchronous messaging• Good for one way communication

• Serialization often becomes the bottleneck• Don’t leak service internals

• Expose only necessary data to avoid hidden dependency

• Consider BFF (Backend for Frontend) pattern• Different interface for form factor, bandwidth etc.

Managing service interactions• Communication pattern• Fire & forget, Request & response, Broadcast, Aggregation

• Messaging infrastructure• Queue, HTTP, Pub-Sub, Gateway

• Abstraction of infrastructure• Proxy-Stub

• Ambassador pattern• Sub-container or Local service to abstract communication

Data modelingData modeling

Data model• Central schema is no longer a good practice• Each bounded context has its own schema• It may lead to data consistency issue

CustomerNameAgeGenderCompanyDate RegisteredSessions signed upMail address

CustomerNameMail address

Registration context Shipping context

Data consistency - Level of consistency

Strong ConsistencyEventual ConsistencyNo consistency

Does it need to be consistent?

Customer management

Shipping history

Customer

Customer

mail address updated

Do we update?

Dealing with Eventual Consistency• Write operations• Capture a unit of work in a single transaction• Compensate failed transactions• Order of update matters

• Read operations• RYOW in data replication• Degree of ‘eventuality’• SLA – bounded staleness

Implementing microservices

Options to implement microservices on Azure• Service Fabric• Azure Container Service• Azure functions• Docker cloud (supports Azure)• Docker on Virtual Machine• App service

Implementing microservices on Service Fabric

SPA or Mobile

GWGW

StatelessService

StatelessService

StatefulService

ReverseProxy

VMSS VMSS

StatefulService

Implementing microservices using Containers

DevOps

User

ApplicationGateway

Application Host

Master

Image Registry

Nginx /HA proxyApp GW

Docker HubACR

Docker engine on Virtual Machines

KubernetesMarathon

Swarm

Request

RepositoryValidation

Cluster statestore

EtcdConsul

Zookeeper

Administor

Docker imageDocker

image

Node state trackingDiscoveryLeader election

DeploymentCluster management

RoutingLoad balancingOffloading

Run services

Resources• Microservices with Docker on Microsoft Azure (Trent Swanson, et al.)• Building microservices (Sam Newman)• Microservice architecture (Irakli Nadareishvili, et al.)• Implementing domain driven design (Vaughn Vernon)• https://www.nginx.com/blog/introduction-to-microservices/• http://www.vinaysahni.com/best-practices-for-building-a-microservice-architecture• http://www.grahamlea.com/2015/07/microservices-security-questions/• https://www.infoq.com/presentations/ddd-rest• Adrian Cockcroft on InfoQ• Service fabric training course on MVA• http://www.slideshare.net/masashin