Designing microservices part2
•Download as PPTX, PDF•
3 likes•1,292 views
This session describes how to align business domain with microservices and other design principles.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Designing microservices part2
Similar to Designing microservices part2 (20)
Recently uploaded
Recently uploaded (20)
Designing microservices part2
- 1. Designing microservices part 2 Masashi Narumoto Principal Lead PM AzureCAT patterns & practices
- 2. Do I need it?
- 3. 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
- 4. Process of implementing microservices Analyze business domain Design services around business domain Implement services on platform Business alignment Technology alignment
- 5. 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?
- 7. 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 failure
- 9. Identifying services – bounded context Core service Service A Service C Service B Data access service Business logic service API service
- 10. 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
- 12. 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 assets Code Data model Infrastructure Bounded context A Bounded context B Shared kernel pattern Shared assets
- 13. Anticorruption layer (ACL) Your context Other context Anti-corruption layer Adapter Translator facade Façade: Alternative interface to other context Adapter: Make requests to other context Translator: Translate the semantics Existing system Infrastructure Protocol Data model API signature Other semantics
- 14. 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
- 16. 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
- 18. Exposing service interface Domain Model Application Adapter Adapter Client Client HTTP HTTP AdapterClient AMQP
- 19. 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.
- 20. 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
- 22. Data model • Central schema is no longer a good practice • Each bounded context has its own schema • It may lead to data consistency issue Customer Name Age Gender Company Date Registered Sessions signed up Mail address Customer Name Mail address Registration context Shipping context
- 23. Data consistency - Level of consistency Strong ConsistencyEventual ConsistencyNo consistency
- 24. Does it need to be consistent? Customer management Shipping history Customer Customer mail address updated Do we update?
- 25. 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
- 27. Options to implement microservices on Azure • Service Fabric • Azure Container Service • Azure functions • Docker cloud (supports Azure) • Docker on Virtual Machine • App service
- 28. Implementing microservices on Service Fabric SPA or Mobile GW GW Stateless Service Stateless Service Stateful Service Reverse Proxy VMSS VMSS Stateful Service
- 29. Implementing microservices using Containers DevOps User Application Gateway Application Host Master Image Registry Nginx /HA proxy App GW Docker Hub ACR Docker engine on Virtual Machines Kubernetes Marathon Swarm Request Repository Validation Cluster state store Etcd Consul Zookeeper Administor Docker imageDocker image Node state tracking Discovery Leader election Deployment Cluster management Routing Load balancing Offloading Run services
- 30. 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
Editor's Notes
- So far we discussed benefits and challenges of MSA. Those benefits wouldn’t come for free. You need to design your app in a way that you get most out of it. Same as challenges, you can design your app to deal with them. Let’s talk about how we can design your application. You can copy&paste code or script but not design.
- Let’s not jump on something just because it’s popular.
- Service should be modeled around business domains. MSA is the highest degree of distributed system - data consistency, partial failures, messaging etc. You don’t get benefit w/o DevOps culture - automation, CD, self-provisioning, autonomous team Monitoring: distributed tracing w/ correlation ID is key for RCA Not everybody is jumping on microservices bandwagon https://blog.openshift.com/not-ready-microservices-evolutions-and-alternatives/ Let’s assume that we need it and are ready for it.
- Industry 4.0 can be implemented by IoT-Hub and Service fabric? There’s a huge gap between business and technology. We need to fill in that gap. How can we translate business into technology? We need to capture business intent into software design then, implement it using technology.
- In design process, you need to answer these questions.
- Design principles influence on all other aspects
- Decentralize repository, build process, LB, data shema, and governance Don’t do layering across business domains which causes dependency No shared Library, configuration, framework. Everything needs to be self-contained so it can be deployed independently Don’t leak implementation details to other services which causes dependency Data must be private to its service meaning anybody else can’t directly access other’s data N times of deployment for N services. Automation is the key to solve that issue. All techniques that we discussed in resiliency session can apply here. Circuit breaker, bulkhead, retry, timeout etc. We’re expanding the notion of high cohesion loosely coupling to DevOps area such as build, test, deploy for faster evolution How can we design these principles in your system? Let’s take a look.
- Functional partitioning, not horizontal layering N-Tier is still a valid architecture style, but not in MSA With N-Tier, you can’t independently deploy each service.
- BC is linguistic boundary. It makes natural service boundary. Customer in a BC should clearly mean XXX. There shouldn’t be unbiguity. It doesn’t need to be 1:1 mapping between BC and service. Team size = 2,3 upto 5,6 Lock-step deployment
- If you have a single gigantic DB, most likely you see this. I don’t even know if I can change the schema or stored procedures.
- Design time: Build, test, release If you expose language specific format or custom class/interface, it creates dependencies If you share data schema, library package, framework, etc. it creates dependencies If you share messaging infrastructure, storage it creates dependencies We should mitigate the area of shared kernel. Published language = Open API doc. You can mitigate the shared area by using nuget package etc.
- Semantics between two context are often different, especially with old system. New model would corrupt by dealing with lots of old models in ad hoc fashion. 3 logical components in implementing ACL. Façade is normally given as framework/platform
- Managing dependency is the key for independent deployment Every service uses its own schema Encapsulate domain logic to service not client Test against contract (Postman, Pact) Append only, Don’t delete field Keep old version until all clients get updated http://tutorials.jenkov.com/ood/understanding-dependencies.html Use mediator as parameter between
- Natural tendency is to convert 3 tier into different microservice which leads to this anti-pattern The reason why it’s so important is that if you leak domain knowledge to clients, then it becomes impossible to change that afterwards.
- Hexagon architecture instead of layering
- Private is the ones internal to the organization Hypermedia as the Engine of Application State Client can cancel the order whenever the ‘cancel’ link is returned. Vs. wondering when/how I can cancel the order? Rich Tools, easy to understand, monitoring, tests, Don’t leak service internals
- Ambassador = outbound proxy, that does routing, CB, monitoring(latency), protocol translation, etc.
- De-normalization, redundant replica with subset of schema We compromise integrity, consistency for independent deployment
- Natural tendency is to think that every data needs to be consistent but that’s not always true. There’s a number of use cases where you don’t need consistency at all.
- Two BC have different entities.
- ACID vs. BASE transaction: Basic Availability Soft state Eventually consistency It’s OK to use stale data, and it’s OK to give approximate answers for higher availability How ’eventual’ is it? e.g. CouchDB has MVCC
- There’re a number of options that you can choose from to implement MSA on Azure. ACS lets you provision a cluster using DC/OS, Docker Swarm or Kubernetes. Service Fabric is another Microsoft offering for hosting MSA If you want to go down serverless path, then Azure functions is the right one for you. It becomes GA yesterday. Docker cloud is the service from Docker. You can choose a provider from Azure, AWS, digital ocean etc. You can provision VMs and install Docker yourself App Service is another PaaS from MSFT Docker streamlines deployment, isolation, standardize API (environment valiables, networking) for applications Dev/Test benefit
- Inter service communication via reverse proxy IService (remoting ) Application – Service Multiple services in one node Placement constraints
- Container is the standard format to host apps, that’s it. The critical part is the orchestration. It’s very competitive area right now. There’re Kubernetes, DC/OS, Docker Swarm, Nomad, now Hyper.sh is getting popular. When I started learning containers a couple of years ago, I was always wondering which service does what? From logical point of view there’s a set of components in the container orchestration. You can register your container image into public/private registry. Scan the image to validate security policy etc. Master node takes care of cluster management such as scheduling, recycling, deployment It works with cluster state store which know what’s running where and who’s the leader Requests from users would go through gateway and load balanced and routed to the service Actual services are running on the app host
- There’re numerous great materials. These are best ones among them.