designing microservices part2
TRANSCRIPT
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