Designing microservices

27
Masashi Narumoto Principal PM Lead AzureCAT patterns&practices Designing microservices

Transcript of Designing microservices

Masashi NarumotoPrincipal PM LeadAzureCAT patterns&practices

Designing microservices

Agenda• What is microservices?• Benefits / Challenges• Designing microservices• Migrating to microservices

What is microservices?

Small autonomous services that work together, modeled around a business domain

- Sam Newman -

Loosely coupled service oriented architecture with bounded contexts

- Adrian Cockcroft-

What is microservices?

User Interface

Business Logic

Data Access

Database

SPA or mobile apps

Why microservices? Why not monolith?

Release

Dev team A

Dev team B

Dev team C

Dev team D

Dev team E

Production

.

.

.

Common dependency- Data schema- Message schema- Leaking service internals via API- Framework/Library version- Shared component

Why microservices? Why not monolith?

Dev team A

Dev team B

Dev team C

Dev team D

Dev team E

Production

.

.

.

Release

Production

Production

Production

Production

Release

Release

Release

Release

How many changes each release should include?Integration, E2E test?

DevOps practices

Source: 2016 DevOps pulse

How frequently do you deploy code?

Do you have continuous integration in place?

Do you have continuous deployment in place?

microservices – case studies

microservices - Benefits• Continuous innovation• Independent deployments• Technology diversity• Small focused team• Separate scalability/availability• Fault isolation

microservices - Challenges• Complexity• Network congestion • Data integrity/consistency• Integration and versioning• Testing• Reliability• Service discovery and routing• Monitoring and logging

microservices - Principles• Model services around a business domain• Make each service independently deployable• Decentralize all things• Hide implementation details• Data is private to its service• Automate DevOps tasks• Isolate failureLess dependency more isolation!!

Designing microservices • Service boundary• Granularity

• Gateway• Offloading, Aggregation, Routing

• Inter service communication• Sync/Async, Protocol/Serialization, Messaging

• Data management• Integrity/Consistency

• Distributed transactions• Dealing with partial failure

• Monitoring• Sidecar, Distributed tracing

Finding service boundary • Start with bounded context• Further breakdown per non-functional requirements• Vertical decomposition rather than horizontal (layers)• Also consider• Rate of change• Technology used• Communication overhead• Splitting data is challenge due to consistency issues

• Refactoring across boundary is an extremely expensive operation

API gatewayRoutingAggregationOffloading

Svc A

SvcB

SvcC

SvcD

SvcE

GWContoso.com/api/serviceA

LoggingCachingRetryCircuit breakerThrottlingSSL terminationAuthentication

Contoso.com/api/GetRecommendation?userid=N

Inter service communication

Svc A

SvcB

SvcD

SvcE

GWNorth – South request Ea

st –

Wes

t

Challenges- Endpoint proliferation- East – West chattiness- Overhead by serialization- Different svc lifecycle requires decoupling- Versioning- IP masquerading

Data integrity/consistency

Survey Tenant

Survey ID Tenant ID Questions Tenant ID Tenant Name Survey count

1234 001 001 Fabrikam 99Do you know Surface? Replica of Tenant DB

SurveyEvent

Atomic?

N < 100 ?

YesMessage Broker

100

Single Transaction

scope

Single

Transaction

scope

Decoupling data by CQRS

Survey SurveyAnalysis

Survey ID Tenant ID Answers

1234 001 2.0, 3.5, 4.0, …

Survey ID Tenant Name Answers

1234 Fabrikam 992.0, 3.5, 4.0, …

Mes

sage

Bro

kerWrite model Read model

Eventually consistent

Reversible workflow by Sagas• Sagas is long running transactions that can be written as a sequence

of transactions that can be interleaved with other transactions.- Hector Garcia Molina , et al. 1987-

Svc A

SvcB

SvcC

OrderMgmt

Place an order

Decrease stock level

Delegate shipping

Cancel

Cancel

Retry

Managing StateRetryTimeoutConcurrency

scheduler agent supervisor pattern

Monitoring microservices

Svc A

SvcB

SvcD

GW

- Correlating distributed transactions- Sidecar pattern for cross language env- APM tools- Logging at GW- Monitor system as a whole

Sidecar

Sidecar

Sidecar

Activity #1

Activity #1

Activity #1

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

Container and orchestration

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

Azure Service Fabric

Migrating monolith to microservices• Extract one service at a time• Add glue code that takes care of dirty work• Strangler / Anti-corruption layer in transition period

Monolith(Big ball of mud)

microservicesCoarse grained Somewhat decomposed

Strangler pattern

User Interface

Business Logic

Data Access

Database

Client

Strangler facade

Summary• microservices is not something running on containers• Choose microservices for continuous innovation• Independent deployment is the key• Incrementally migrate from monolith to MSA• Use a few hosting options on Azure

Resources• Microservices with Docker on Microsoft Azure (Trent Swanson, et al.)• Building microservices (Sam Newman)• Microservice architecture (Irakli Nadareishvili, et al.)• 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/• Principles of Microservices by Sam Newman• Adrian Cockcroft on InfoQ• Service fabric training course on MVA