Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing microservices
•
5 likes•3,887 views
In order to explain certain astronomical observations, physicists created the mysterious concepts of dark energy and dark matter. Dark energy is a repulsive force. It’s an anti-gravity that is forcing matter apart and accelerating the expansion of the universe. Dark matter has the opposite attraction effect. Although it’s invisible, dark matter has a gravitational effect on stars and galaxies. In this presentation, you will learn how these metaphors apply to the microservice architecture. I describe how there are multiple repulsive forces that drive the decomposition of your application into services. You will learn, however, that there are also multiple attractive forces that resist decomposition and bind software elements together. I describe how as an architect you must find a way to balance these opposing forces.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing microservices
Similar to Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing microservices (20)
More from Chris Richardson
More from Chris Richardson (17)
Recently uploaded
Recently uploaded (20)
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing microservices
- 1. @crichardson Dark energy, dark matter: imperfect metaphors for designing microservices Chris Richardson Microservice architecture consultant and trainer Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson chris@chrisrichardson.net http://adopt.microservices.io Copyright © 2021. Chris Richardson Consulting, Inc. All rights reserved
- 2. @crichardson What you will learn When defining a microservice architecture you must resolve the competing forces of attraction and repulsion between subdomains
- 4. @crichardson Discounts 35% discount ctwmucon21 $120 discount coupon HIDKQIFC http://adopt.microservices.io
- 5. @crichardson Agenda • Dark energy, dark matter and subdomains • Dark energy and repulsion • Dark matter and attraction • Resolving repulsive and attractive forces
- 6. @crichardson Microservice architecture = architectural style Small team Loosely coupled Independently deployable <15 minute lead time Service B Service A Service C API Gateway Owns Owns Owns Deployment pipeline Production
- 7. @crichardson How to define a Microservice Architecture… Application ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪aggregate≫ Order createCustomer() createOrder() findOrder() findOrderHistory() System operations Distill Requirements Event storming Functional requirements As a consumer I want to place an Order So that I can …. As a Restaurant I want to accept an Order So that I can …. User stories • SLA: Reliability/Latency • Scalability • … System quality attributes The “requests” - read/write aggregates
- 8. @crichardson Application … how to define a Microservice Architecture Application ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪aggregate≫ Order createCustomer() createOrder() findOrder() findOrderHistory() System operations Service Service Service ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ How to group subdomains to form services?
- 10. @crichardson Dark energy, dark matter and services ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪aggregate≫ Order Attraction Repulsion Generated by system operations Team-sized services … Dark energy: an anti- gravity that’s accelerating the expansion of the universe Dark matter: an invisible matter that has a gravitational effect on stars and galaxies. https://www.nasa.gov/feature/goddard/2020/new-hubble-data-explains-missing-dark-matter Transactional coupling Runtime coupling Design time coupling …
- 11. @crichardson Attraction vs repulsion at every level Customer Service Order Service Order Service «Subdomain» Orders «Subdomain» Customers VS. «Subdomain» Orders «Subdomain» Customers «Subdomain» Orders «Aggregate» Order «Subdomain» Customers «Aggregate» Customer «Subdomain» Orders «Aggregate» Order «Aggregate» Customer VS. create() reserveCredit() releaseCredit() name creditLimit availableCredit «Aggregate» Customer create() name «Aggregate» Customer reserveCredit() releaseCredit() creditLimit availableCredit «Aggregate» CustomerCredit VS. Team size
- 12. @crichardson Service-specific attraction ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪aggregate≫ Order Process boundary Communication cost Transaction boundary Complexity of Eventual consistency Lock step changes are more complicated Independently deployable Order Service Customer Service
- 13. @crichardson Agenda • Dark energy, dark matter and subdomains • Dark energy and repulsion • Dark matter and attraction • Resolving repulsive and attractive forces
- 14. Dark energy = anti-gravity force https://hubblesite.org/contents/media/images/2001/09/1034-Image.html?news=true https://genius.com/Barenaked-ladies-the-big-bang-theory-lyrics Expected deceleration Unexpected acceleration! Our whole universe was in a hot, dense state Then nearly fourteen billion years ago expansion started….
- 15. @crichardson Repulsive forces subdomains in different services Service Service Module A «Aggregate» X Module B «Aggregate» Y Team-sized services 15 minute lead time Diversity of technology stacks Increasing scalability Different regulatory requirements Different SLAs
- 16. @crichardson Cognitive load of subdomains Simple Complicate Complex Team sized services 5-9 person, cross-functional team Service Own ≥ Simple Complicated Complex Fit Requires focus cognitive capacity cognitive load
- 17. @crichardson Grouping subdomains into team sized services Service Simple Simple Simple Service Simple Complicated Service Complex OR OR
- 18. @crichardson <15 minute lead time @mipsytipsy https://speakerdeck.com/charity/cd?slide=17 Service Service Subdomain Subdomain Subdomain Shorter lead time Simpler build Longer lead time More complex build* * Parallelizing building/testing partially helps
- 19. @crichardson Service Tech. Stack B Service Tech. Stack A Service Tech. Stack Requirement to use different technology stacks Subdomain A Subdomain A Subdomain B Subdomain B Single technology stack Upgrade together Separate technology stacks Right tool for the job Upgrade independently versus
- 20. @crichardson Service Service Service Increasing scalability Subdomain A Subdomain A Subdomain B Subdomain B versus CPU MEM GPU Scale together • Wasteful • Costly CPU MEM GPU Scale separately • Efficient • Cheaper Load Load Load Load
- 21. @crichardson Separate by regulatory requirements • Quality Management System that complies with ISO 13485 • Software development lifecycle processes like ISO/IEC 62304 Obstacles to DevOps continuous integration/deployment Canary deployments are generally a bad idea
- 22. @crichardson Service Service Service Freedom to use different development processes SaMD Subdomain SaMD Subdomain Other Subdomain Other Subdomain ISO 13485 ISO/IEC 62304 ISO 13485 ISO/IEC 62304 DevOps Slower Faster
- 23. @crichardson Infrastructure Service Separate by SLO/SLA Payment processing subdomain Merchant management subdomain chargeCard() registerMerchant() 2.9% + 30c/ request Less important Competing for same resources Integrated development and deployment = Bugs, misconfiguration Revenue loss and penalties
- 24. @crichardson Infrastructure Service Separate loosely coupled services = higher availability Payment processing subdomain Merchant management subdomain chargeCard() registerMerchant() Events Self-contained, No runtime coupling Isolation Isolated development and deployment
- 25. @crichardson Agenda • Dark energy, dark matter and subdomains • Dark energy and repulsion • Dark matter and attraction • Resolving repulsive and attractive forces
- 26. @crichardson About dark matter: orbital velocity of stars https://en.wikipedia.org/wiki/Galaxy_rotation_curve Most mass Violates Kepler’s 3rd law
- 27. About Dark matter It’s invisible Its composition is unknown 85% of the matter in the universe Has a gravitational effect Responsible for stars orbiting at higher velocities Responsible for the formation of galaxies: Early universe was very hot Dark matter was immune to radiation pressure Clumped together https://en.wikipedia.org/wiki/Dark_matter
- 28. @crichardson System operations generate attraction forces between subdomains Create Order() Order Subdomain Customer Subdomain reserveCredit() createOrder() Customer Order Application Runtime coupling Design time coupling Transactional coupling Communication cost Data access cost Generate Forces vary for each operation
- 29. @crichardson Transactional coupling Create Order() Order Subdomain Customer Subdomain reserveCredit() createOrder() Customer Order ACID Transaction Atomic - no partial updates Consistent - always enforced Isolated - handles concurrent updates Durable - commits are permanent = Simple implementation of operations But ACID transactions are simplest when within a service
- 30. @crichardson ACID transactions the span services are problematic => use sagas Order Service Customer Service POST /order Credit Reserved Order created Order events Customer events https://microservices.io/patterns/data/saga.html BUT Sagas are more complex and require: • Compensating transactions • Countermeasures to handle ACD
- 31. @crichardson Service Runtime coupling Create Order() Order Subdomain Customer Subdomain reserveCredit() createOrder() Customer Order Application POST /orders Response 1 2 3 4 SLA: Availability Latency Easier to meet SLA if in a single service
- 32. @crichardson Multi-service command: higher latency and lower availability Customer Service Order Service Order Subdomain Customer Subdomain POST /orders Response reserveCredit() Response Lower availability availability(createOrder) = availability(OrderService) x availability(CustomerService) Higher latency 😢 Synchronous or asynchronous!
- 33. @crichardson Service Inter-service communication Service Order Subdomain Customer Subdomain Customer Order Nano- seconds “High” bandwidth Service Milli- seconds latency Lower bandwidth createOrder() createOrder() Order Subdomain Customer Subdomain Customer Order
- 34. @crichardson Order Service Data access Service Order Subdomain Customer Subdomain Simple efficient join Database select * from customers, orders where … find Recent High Value Customers() Customer Service Order Subdomain Customer Subdomain API Gateway findRecentCustomers() findOrders(customerId) Inefficient 1+N Query
- 35. @crichardson Design time coupling: risk of lock step changes Order Subdomain Customer Subdomain reserveCredit() createOrder() Customer Order Design time coupling Minimize with careful design BUT You can’t always eliminate it Risk of lock step changes API Knows about available credit
- 36. @crichardson Key distributed data patterns involve design-time coupling API Composer Order Service Customer Service Saga Coordinator Order Service Customer Service CQRS View Order Service Customer Service https://microservices.io/patterns/data/saga.html https://microservices.io/patterns/data/cqrs.html https://microservices.io/patterns/data/api-composition.html Coupled to services Coupled
- 37. @crichardson Order Service Minimize design-time coupling between services Service Order Subdomain Customer Subdomain Customer Service Order Subdomain Customer Subdomain 1. Change 2. Change 3. Build 4. Test 5. Deploy 1. Change 3. Build 4. Test 5. Deploy 3. Build 4. Test 5. Deploy API Straightforward Complicated 2. Change 1. Change 2. Change
- 38. @crichardson Agenda • Dark energy, dark matter and subdomains • Dark energy and repulsion • Dark matter and attraction • Resolving repulsive and attractive forces
- 39. @crichardson Example: resolving conflicting forces Complicated Order Mgmt Simple Customer Mgmt Complicated Fulfillment findOrder() createOrder()
- 40. @crichardson Service Non-team sized service Complicated Order Mgmt Simple Customer Mgmt Complicated Fulfillment findOrder() createOrder() Large or overloaded team Local operations
- 41. @crichardson Service Define team sized services but how? Vs. Service Complicated Order Mgmt Simple Customer Mgmt Complicated Fulfillment findOrder() createOrder() Service Service Complicated Order Mgmt Simple Customer Mgmt Complicated Fulfillment findOrder() createOrder() Need to analyze the forces….
- 42. @crichardson Service Service The gravitational forces depend on the (operation, subdomain) Complicated Order Mgmt Simple Customer Mgmt Complicated Fulfillment findOrder() createOrder() Command/ Frequent/ Higher SLA Query/ Less frequent/ Lower SLA Tight Loose Loose reserveCredit() createOrder() createShipment()
- 43. @crichardson Summary ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪aggregate≫ Order Transaction coupling Runtime coupling Design time coupling … Team-sized services … Need to resolve Group subdomains to form services System operations generate Attraction Repulsion