SOA Lessons Learnt (or Microservices done Better) - Sean Farmar, Particular Software
- 1. SOA Lessons Learnt (or Microservices Done Better) Sean Farmar Particular Software @farmar1
- 2. Tried all “Best Practices” Layers and Tiers Distributed monoliths using Web Services and failed ... @farmar My journey to SOA 2
- 3. So I went to my master… @farmar3
- 4. Solve the problem you want? mmmm… Coupling your problem is… @farmar4
- 5. @farmar5
- 6. Coupling Dimensions Afferent (Ca) Efferent (Ce) What depends on you What you depend on @farmar6
- 7. Coupling Dimensions Temporal Time, synchronous communication, logical temporal coupling Spatial Physical, deployment, endpoint address Platform Protocols, platform specific features @farmar7
- 9. Fallacies of Distributed Computing 1. The network is reliable. (Bill Joy and Tom Lyon) 2. Latency is zero. (Bill Joy and Tom Lyon) 3. Bandwidth is infinite. (Bill Joy and Tom Lyon) 4. The network is secure. (Bill Joy and Tom Lyon) @farmar9
- 10. Fallacies of Distributed Computing 5. Topology doesn’t change. (Peter Deutsch) 6. There is one administrator. (Peter Deutsch) 7. Transport cost is zero. (Peter Deutsch) 8. The network is homogeneous. (James Gosling) @farmar10
- 11. Fallacies of Distributed Computing Fallacies ebook(David Boike): http://go.particular.net/CMTA17 Ted Neward’s blog: http://blogs.tedneward.com/post/enterprise- computing-fallacies/ @farmar11
- 12. Why Microservices? Break down the monolith @farmar12
- 14. Vertical Slicing UI BL DAL DB Referential Integrity Tight Coupling Loose Coupling Re-introduces Coupling Sales Conten t CRMOps @farmar14
- 15. Why SOA? “Address coupling in our software design by building loosely coupled and highly encapsulated components” Udi Dahan @farmar15
- 16. Process It’s hard (er) No silver bullet: use messaging only if it suites Decomposing your business domain is hard, no framework/tools will magically fix that @farmar16
- 17. Decomposition Autonomy Decompose business entities by properties/fields Bounded context == high coupling @farmar17
- 18. Design Be pragmatic but keep the paradigm Right size? Logical “Service” /= Physical Process @farmar18
- 19. Communication Asynchronous fire and forget, Pub/Sub Synchronous communications for reads Use massaging where is works @farmar19
- 20. Software Architecture Don’t generalise, be explicit SRP (Single Responsibility Principle) Keep your vertical slice thin, top to bottom @farmar20
- 21. Data Referential integrity and GUIDS Separating data writes and data reads (CQS) Data (write) ownership @farmar21
- 22. Data Data reads and eventual consistency Don’t share your transactional data (OLTP) You can share your view models @farmar22
- 23. DevOps Monitoring - Lights on Testing is HARD Deployment - Automate everything @farmar23
- 24. Organisation Get organization and people buy in Build trust with the business Build your business not a system @farmar24
- 25. Summary Avoid all dimensions of coupling Avoid synchronous communication between components/microservices, Don't share data, use view/read models to share read only data Just do it, NServiceBus @farmar25