SOA Lessons learnt Dublin Microservices 20160525
•Download as PPTX, PDF•
4 likes•648 views
Service Oriented Architecture has been around for a while, now Microservices is the new black, that’s cool, but can we learn from when we failed and succeeded implementing SOA? There are some really useful lessons we can take and avoid the pitfalls.
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
SOA Lessons learnt Dublin Microservices 20160525
- 1. SOA Lessons Learnt (OR Microservices Done Better) Sean Farmar @farmar
- 2. Agenda • My journey to SOA • The SOA / Microservices promise? • Some concepts • Lessons Learnt • Q&A
- 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 calls) Spatial (deployment, endpoint address) Platform (protocols, .Net Remoting) Coupling Dimensions
- 8. Encapsulation Autonomy Decomposing Business entities SRP Keep your vertical slice thin, top to bottom
- 10. Vertical Slicing UI BL DAL DB Referential Integrity Tight Coupling Loose Coupling Re-introduces Coupling Sales Conten t CRMOps
- 11. 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)
- 12. The Fallacies EBook • Go to: http://go.particular.net/DMUG16
- 13. Why SOA / Microservices? Address coupling in our software design by building loosely coupled and highly encapsulated components
- 14. Lessons learnt It’s hard (er) Decomposing your business domain, is hard, avoid the pitfalls of standard design methodologies Messaging: Fire and forget CQS: Separating data writes and data reads Data (write) ownership Referential integrity and GUIDS
- 15. Lessons learnt(cont.) DATA: separate OLTP and reporting, eventual consistency Monitoring - Lights on Testing is HARD Deployment - Automate everything Organization and people, trust
- 16. Summary • Avoid all dimensions of coupling • No 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/DMUG16
- 17. Q&A Thank You! Sean Farmar twitter: @farmar Particular.net
Editor's Notes
- The fallacies of distributed computing describe common assumptions that are made by developers and architects in 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)