Benefits of Microservices Architecture and How to Implement It Effectively
•
15 j'aime•4,993 vues
This presentation shows some advice how to be successful with micro services: Which size is right? How shall a project start? What about refactoring?
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Benefits of Microservices Architecture and How to Implement It Effectively
Similaire à Benefits of Microservices Architecture and How to Implement It Effectively (20)
Plus de Eberhard Wolff
Plus de Eberhard Wolff (20)
Dernier
Dernier (20)
Benefits of Microservices Architecture and How to Implement It Effectively
- 1. Micro Services Smaller is Better? Eberhard Wolff Freelance consultant & trainer http://ewolff.com
- 2. Eberhard Wolff - @ewolff Who has seen a system that was too large?
- 3. Eberhard Wolff - @ewolff Who has seen a system that was too small?
- 4. Little programs are delightful to write in isolation, but the process of maintaining large-scale software is always miserable. Jaron Lanier
- 6. Eberhard Wolff - @ewolff Micro Services: Definition • Small • Independent deployment units • i.e. processes • Any technology • Any infrastructure Micro Service Server Micro Service Server
- 7. Eberhard Wolff - @ewolff Components Collaborate Micro Service Micro Service Link Data Replication REST Messaging
- 8. Eberhard Wolff - @ewolff Why Micro Services? Strong modularization Replaceability Small units Sustainable Development speed Continuous Delivery Deployment less risky Free Choice of technology
- 9. Eberhard Wolff - @ewolff Micro Service = Micro?
- 10. Eberhard Wolff - @ewolff 10-100LOC http://yobriefca.se/blog/ 2013/04/28/micro-service-architecture/ Smaller modules better
- 11. Eberhard Wolff - @ewolff 10-100LOC http://yobriefca.se/blog/ 2013/04/28/micro-service-architecture/ Smaller modules better
- 12. Eberhard Wolff - @ewolff Game of Life
- 13. Eberhard Wolff - @ewolff life←{ ⍝ John Conway's "Game of Life". ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ ⍝ Expression for next generation. } Game of Life in one line of APL dyalog.com LOC is really a bad metric
- 14. Eberhard Wolff - @ewolff Larger? • Micro Services have an overhead • Build & deployment pipeline • Version control
- 15. Eberhard Wolff - @ewolff 1st Law of Distributed Objects • Don’t Distribute Your Objects! • Too much remote communication & overhead • Lesson learned from CORBA etc • http://martinfowler.com/bliki/ FirstLaw.html
- 16. Eberhard Wolff - @ewolff Request Response Processing Latency Round Trip: 0,2-0,5 ms = 600.000-1.500.000 instructions@3GHz
- 17. Eberhard Wolff - @ewolff 1st Law of Distributed Objects & Micro Services • Small Micro Services = lot of communication • Violates the 1st Law • Seems to work, though • http://martinfowler.com/articles/ distributed-objects- microservices.html
- 18. Eberhard Wolff - @ewolff Too small = too much communication
- 19. Eberhard Wolff - @ewolffL
- 20. Eberhard Wolff - @ewolff Again: Why Micro Services?
- 21. Eberhard Wolff - @ewolff The main reason
- 22. Eberhard Wolff - @ewolff Business relevant
- 23. Eberhard Wolff - @ewolff How to scale agile? Implement more feature
- 24. Eberhard Wolff - @ewolff Conways Law Architecture copies communication structures of the organization
- 25. Eberhard Wolff - @ewolff Conway’s Law as a Limit • Won’t be able to create an architecture different from your organization • I.e. mobile, GUI & database team • Three technical artifacts
- 26. Eberhard Wolff - @ewolff Conway’s Law as an Enabler • Desired architecture = project structure • Team for each Micro Service • Team should be responsible for meaningful features • Ideal: Independent features
- 27. Eberhard Wolff - @ewolff Each team can build and deploy features independently!
- 28. Eberhard Wolff - @ewolff Micro Services must provide a sensible set of functionality
- 29. Eberhard Wolff - @ewolff Conway’s Law & Micro Service Size • Upper limit: What a (small) team can handle • …and a meaningful set of features • Probably not too small • Lower limit: Depends on overhead / technology
- 30. Eberhard Wolff - @ewolff Micro Service = Micro? • Size doesn’t matter too much • Teams must be able to work independently • Small enough for one team • Not too much overhead
- 31. Eberhard Wolff - @ewolff Conway’s Law Product Owner Service Feature Service
- 32. Eberhard Wolff - @ewolff Bad architecture? Still can’t be avoided!
- 33. Eberhard Wolff - @ewolff Conway’s Law Product Owner ServiceService Feature Product Owner Communication Priority? Slow
- 34. Eberhard Wolff - @ewolff Conway’s Law • Software Interface = Team Communication • Too much communication if you get the architecture wrong. • Slows down the process
- 36. Eberhard Wolff - @ewolff Conway’s Law Product Owner ServiceService Feature Product Owner Change Review Pull Request
- 37. Eberhard Wolff - @ewolff Micro Service & Collective Code Ownership • Team might change any service • Reviews can still be done • …or use Pull Requests • More devs can work on a services • Resilience against personnel turnover • Faster
- 38. Eberhard Wolff - @ewolff Micro Service & Collective Code Ownership • Team must understand bigger parts of the code • Technology freedom?
- 39. Refactoring
- 40. Eberhard Wolff - @ewolff Refactoring ServiceService Different libraries Different language Possibly a rewrite
- 41. Eberhard Wolff - @ewolff Limited Technology Set • Easier Refactoring • Easier to follow standards for deployment, monitoring etc • Easier to implement e.g. resilience • Netflix uses a lot of Java
- 42. Eberhard Wolff - @ewolff Refactoring ServiceService Library Releases must be coordinated Hard to implement really reusable code Enforces same language / platform Like: really, really hard …and we want independent releases
- 43. Eberhard Wolff - @ewolff Refactoring ServiceService Service Remote communication Unreliable network Slower calls Not great But best option
- 46. Eberhard Wolff - @ewolff Start BIG • Conway’s law: Upper size = what a team can handle • Refactoring inside a service easier • …needed for agile environments • …where Micro Services are used • Number will increase anyway • Tear apart easier than join
- 47. Eberhard Wolff - @ewolff If You Start Small… • You will get the architecture wrong • Functionality hard to move • Services not too large at the beginning anyway • Fast deployment still possible
- 49. Systems grow.
- 50. Guide growth.
- 51. Sum Up
- 52. Eberhard Wolff - @ewolff Faster Time-to- Market Micro Services Refactoring Conway’s Law Collective Code Ownership Start BIG or
- 53. Eberhard Wolff - @ewolff Leseprobe: http://bit.ly/CD-Buch
- 54. Eberhard Wolff - @ewolff Leading Micro Services Conference Berlin, 2015-2-12/13 http://microxchg.io/
- 55. Eberhard Wolff - @ewolff Thank You!