Microservices done right or SOA lessons learnt - Sean Farmar - Codemotion Milan 2016
•Download as PPTX, PDF•
2 likes•699 views
SOA has been around for a while, now microservices is the new black, that’s cool, but lets look at what we learnt when we failed and succeeded implementing SOA.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Microservices done right or SOA lessons learnt - Sean Farmar - Codemotion Milan 2016
Similar to Microservices done right or SOA lessons learnt - Sean Farmar - Codemotion Milan 2016 (20)
More from Codemotion
More from Codemotion (20)
Recently uploaded
Recently uploaded (20)
Microservices done right or SOA lessons learnt - Sean Farmar - Codemotion Milan 2016
- 1. Microservices Done Right (or SOA Lessons Learnt) Sean Farmar MILAN 25-26 NOVEMBER 2016
- 2. Microservices Done Right (or SOA Lessons Learnt) Sean Farmar @farmar
- 3. My journey to SOA Tried all “Best Practices” Layers and Tiers Distributed monoliths using Web Services … and failed
- 4. So I went to my master
- 5. Solve the problem you want? mmmm… Coupling your problem is…
- 6. Coupling
- 7. Temporal (time, synchronous communication) Spatial (physical, deployment, endpoint address) Platform (protocols, .Net Remoting) Coupling Dimensions
- 8. Fallacies of Distributed Computing var svc = new MyService(); var result = svc.Process(data);
- 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) 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)
- 10. The Fallacies EBook • Go to: http://go.particular.net/codem16 • Ted Neward’s blog: http://blogs.tedneward.com/post/enterpri se-computing-fallacies/
- 11. Why Microservices? Break down the monolith
- 12. Why SOA / Microservices? “Address coupling in our software design by building loosely coupled and highly encapsulated components” Udi Dahan
- 13. Encapsulation Autonomy Decomposing business entities SRP (Single Responsibility Principle) Be explicit Keep your vertical slice thin, top to bottom
- 16. Vertical Slicing UI BL DAL DB Referential Integrity Tight Coupling Loose Coupling Re-introduces Coupling Sales Conten t CRMOps
- 17. Lessons learnt It’s hard (er) Messaging: Asynchronous fire and forget, Pub/Sub CQ(R)S: Separating data writes and data reads Use messaging only if it suites
- 18. Lessons learnt(cont.) Decomposing your business domain is hard, no framework/tools will magically fix that Data (write) ownership Referential integrity and GUIDS Data reads and eventual consistency
- 19. Lessons learnt(cont.) Monitoring - Lights on Testing is HARD Deployment - Automate everything Organization and people, trust Be pragmatic but keep the paradigm
- 20. 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 • Decomposing your business domain and entities • You can do it on .Net platform using NServiceBus • Blog post: http://particular.net/blog/goodbye- microservices-hello-right-sized-services • Fallacies EBook: http://go.particular.net/codem16
- 21. Q&A Thank You! Sean Farmar twitter: @farmar Particular.net
Editor's Notes
- Microservices done right or SOA lessons learnt
- 2 My name is Sean Farmar and I’ve been hacking code for a living in the last 20 years in the last 8 years I've been doing SOA using NServiceBus. I work at Particular Software (the creators of NServiceBus) as a Solution Architect supporting customers for the last 3 years. Disclaimer I like the idea behind the microservices movement and it sounds like SOA 2.0, however, we are seeing, what is very common in our industry, we don’t really like to learn form the past… Microservices is the new black, the buzzword everyone wants to join in, jump on the band wegon. I hope I can share with you the lessons we learnt when doing SOA so your journey will be a good one.
- 6 In 2007 (November) I started a new project I was looking for a way to do software better and made a move to Service Oriented Architecture using NServiceBus, it was a paradigm shift that changed the way I do software forever. Let me tell you my story We all probably been there Start with a green field, small monolith, clean design Then the business succeeds, we add features and our clean code gets littered with more code to cater for more features We soon find ourselves dreading change anything…
- 7 YODA! What am I doing wrong? I’m doing everything by the book, n-tier, layers and tiers. I even tried web services… Nothing seams to work!
- 7
- 7.5 You will always have some amount of coupling…
- 12 High level
- 14 The fallacies of distributed computing describe common assumptions that are made by developers and architects building distributed systems.
- 16 The fallacies of distributed computing describe common assumptions that are made by developers and architects building distributed systems. In 1994 Peter Deutsch wrote down seven fallacies. In 1997 James Gosling added another fallacy. These fallacies are known as “The eight fallacies of distributed computing”. In the year 2006 Ted Neward added three more fallacies, which are not so widely known. The system is atomic/monolithic. (Ted Neward) The system is finished. (Ted Neward) Business logic can and should be centralized. (Ted Neward)
- 17
- 18
- 20
- 25 Achieving encapsulation means getting a high coupling in a bounded context But we gain autonomy when we look at the system level 1: Boundaries are explicit 2: Services are autonomous 3: Services share schema & contract, not class 4: Service compatibility is based upon policy
- 26
- 27 Monolith and layers We will end up with very high coupling between the layers
- 29
- 32
- 36
- 38
- 40