Micro Service – The New Architecture Paradigm
•
25 likes•3,844 views
Show benefits and issues of micro services. Presentation from OOP 2015, Munich.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Micro Service – The New Architecture Paradigm
Similar to Micro Service – The New Architecture Paradigm (20)
More from Eberhard Wolff
More from Eberhard Wolff (20)
Recently uploaded
Recently uploaded (20)
Micro Service – The New Architecture Paradigm
- 1. Micro Services – The New Architecture Paradigm Eberhard Wolff Freelancer Head Technology Advisory Board adesso AG http://ewolff.com
- 2. Eberhard Wolff - @ewolff Leseprobe: http://bit.ly/CD-Buch
- 3. Eberhard Wolff - @ewolff GUI Logic DB E Commerce Shop Change Order Process!
- 4. Eberhard Wolff - @ewolff Thou shalt not organize teams by technology!
- 5. Eberhard Wolff - @ewolff Common libraries & technical foundation Order Billing Search Catalog E Commerce Shop Deployment monolith Global code integration & coordination needed Code changes to production takes loooong Architecture can be non-monolithic but dependencies might sneak in How to introduce e.g. Elasticsearch for Search?
- 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 Micro Services • Component Model • Component… • Separate process • Individual deployment unit • GUI+Logic
- 8. Eberhard Wolff - @ewolff Micro Services vs. SOA • Micro Service: 1 service = 1 deployment unit Service + GUI • SOA: 1 deloyment unit = n services Service / GUI separate
- 9. Eberhard Wolff - @ewolff Components Collaborate Micro Service Micro Service Link Data Replication REST Messaging
- 10. Eberhard Wolff - @ewolff Common libraries & technical foundation Order Billing Search Catalog Global code integration & coordination needed Code changes to production takes loooong Architecture can be non-monolithic but dependencies might sneak in How to introduce e.g. Elasticsearch for Search? E Commerce Shop Deployment monolith
- 11. Eberhard Wolff - @ewolff Common libraries & technical foundation Order Billing Search Catalog Global code integration & coordination needed Code changes to production takes loooong Architecture can be non-monolithic but dependencies might sneak in How to introduce e.g. Elasticsearch for Search? Order CatalogSearchBilling Micro Services Team can deploy without integration Changes can be deployed independently & quickly Technology stack per Micro Service One or many Micro Services per Team
- 12. Eberhard Wolff - @ewolff Order Billing Search Catalog Order CatalogSearchBilling Micro Services Team can deploy without integration Changes can be deployed independently & quickly Strong & enforced modularization Technology stack per Micro Service One or many Micro Services per Team
- 13. Eberhard Wolff - @ewolff Online Shop Order Catalog Search Billing Customer HTML / HTTP
- 14. Eberhard Wolff - @ewolff Online Shop Elasticsearch Spring Batch Oracle Spring MVC MongoDB Order Catalog Search Billing
- 15. Eberhard Wolff - @ewolff Deploy & Operate?
- 16. Eberhard Wolff - @ewolff Component Model • No restriction on language etc • Individual processes • + infrastructure (database etc) • JARs, WARs, EARs: No good fit • Monitoring • Logging
- 17. Eberhard Wolff - @ewolff Possible Component Models • Virtual machine • Docker container • Installable software (RPM, deb) • + deployment / config scripts
- 18. Eberhard Wolff - @ewolff Why Micro Services?
- 19. Eberhard Wolff - @ewolff How to scale agile? Implement more feature
- 20. Eberhard Wolff - @ewolff Conway‘s Law Architecture copies communication structures of the organization
- 21. 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
- 22. 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
- 23. Eberhard Wolff - @ewolff One team can build and deploy features independently!
- 24. Eberhard Wolff - @ewolff Team must be responsible for a sensible set of functionality
- 25. Eberhard Wolff - @ewolff Conway’s Law & Size • Upper limit: What a (small) team can handle • …and a meaningful set of features • Probably not too small • Smaller modules might be better • Lower limit: Depends on overhead / technology
- 26. Eberhard Wolff - @ewolff Legacy Apps
- 27. Eberhard Wolff - @ewolff
- 28. Eberhard Wolff - @ewolff
- 29. Eberhard Wolff - @ewolff How can I implement a new feature???
- 30. Eberhard Wolff - @ewolffL
- 31. Eberhard Wolff - @ewolff HTTP New Stuff Links No legacy code Any technology J Small code base
- 32. Little programs are delightful to write in isolation, but the process of maintaining large-scale software is always miserable. Jaron Lanier
- 34. Eberhard Wolff - @ewolff Sustainable Development
- 35. Eberhard Wolff - @ewolff Monoliths • Architecture rot • …not maintainable any more • …and can’t be rewritten / replaced
- 36. Eberhard Wolff - @ewolff Micro Services • Distributed system of small units • Architecture violations harder • Small units • Easy to replace
- 37. Eberhard Wolff - @ewolff Continuous Delivery
- 38. Eberhard Wolff - @ewolff Monolith ECommerce System 3rd party systems Database
- 39. Eberhard Wolff - @ewolff Continuous Delivery: Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release ECommerce System
- 40. Eberhard Wolff - @ewolff Build Pipeline: Problems • Complex infrastructure • Huge database • 3rd party integration • Slow feedback • Test everything for each commit • Huge deployment unit • Deployment slow
- 41. Eberhard Wolff - @ewolff Micro Services ECommerce System 3rd party systems Database Order Catalog Billing Search
- 42. Eberhard Wolff - @ewolff Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Order Billing Customer
- 43. Eberhard Wolff - @ewolff Build Pipeline for Micro Services • Independent deployment • Build pipeline per Micro Service • Smaller • Easier to set up • Less features (3rd party systems) • Faster Feedback: Less tests
- 44. Eberhard Wolff - @ewolff Quick Deployments Time Size & Risk Manual Deployment Pipeline Continuous Delivery Pipeline Monolith Micro Services
- 45. Eberhard Wolff - @ewolff Why Micro Services? • Strong modularization • Small deployment units • Faster & easier deployment • Sustainable development speed • Continuous Delivery • Less risk in deployment • Best technology for each service
- 46. Eberhard Wolff - @ewolff Challenges
- 47. Eberhard Wolff - @ewolff Distributed System
- 48. Eberhard Wolff - @ewolff 1st Law of Distributed Objects • Don’t Distribute Your Objects! • Too much remote communication & overhead • Lesson learned from CORBA etc • Micro Service should include a GUI • http://martinfowler.com/bliki/ FirstLaw.html
- 49. Eberhard Wolff - @ewolff Request Response Processing Latency Round Trip: 0,2-0,5 ms = 600.000-1.500.000 instructions@3GHz
- 50. Eberhard Wolff - @ewolff 1st Law of Distributed Objects & Micro Services • Small Micro Services mean a lot of communication • Violate the 1st Law • Seems to work, though • http://martinfowler.com/articles/ distributed-objects- microservices.html
- 51. Eberhard Wolff - @ewolff Too small = too much communication
- 52. Eberhard Wolff - @ewolff Code Reuse • Reuse across technology stacks hard • Code dependencies are evil! • Deployment dependency • No more independent deployment • Update hell • Avoid code reuse! • Or make it Open Source projects (Netflix) • Service reuse is fine
- 53. Eberhard Wolff - @ewolff Global Refactorings? • Move code from service to service • Might be a port to a different language • Separate in a new service? • More services = more complex • Very hard
- 54. Eberhard Wolff - @ewolff Functional Architecture • Teams should be independent • i.e. one team = one functionality • Otherwise: Coordination hard • Functional architecture much more important
- 55. Eberhard Wolff - @ewolff Refactoring & Code Reuse Individual Technology Stacks
- 56. Eberhard Wolff - @ewolff Refactoring hard Functional architecture much more important
- 57. Eberhard Wolff - @ewolff Need to get architecture right first time Architecture evolves
- 58. Eberhard Wolff - @ewolff Start BIG • Won’t have too much code at the start anyway • Refactoring easier • Can build architecture as you go • Let the functional architecture grow!
- 59. Eberhard Wolff - @ewolff Handling Interfaces • Independent deployments = backwards compatibility • Different versions of the same service run at the same time • Only to allow updates • i.e. transient • Minor issue
- 60. Eberhard Wolff - @ewolff Managing Dependencies Between (>100) Services? • Monoliths can be easily analyzed • Micro Services? • With heterogeneous technology stacks? • Need to come up with your own solution
- 61. Eberhard Wolff - @ewolff Global Architecture? • Manages dependencies • Which service/team does what? • Defines common communication infrastructure • Optional: Common Ops • Very different from usual architecture
- 62. Eberhard Wolff - @ewolff Network? • Micro Services = Distributed Systems • Services & network might fail • Need to deal with failure • Resilience: System must survive failure of parts • Makes system highly available
- 63. Eberhard Wolff - @ewolff Deployment? • One Deployment Pipeline per services • Should be fully automated • Too many services for manual steps • Infrastructure investment needed • Common deployment?
- 64. Eberhard Wolff - @ewolff Infrastructure? • >50 server per system • Resource consumption probably high • Virtualization must be fully automated • Docker might save ressources
- 65. Eberhard Wolff - @ewolff Conclusion
- 66. Eberhard Wolff - @ewolff Conclusion: Micro Services • Micro Services are a new way of modularization • More technological freedom • Easier, faster and less risky deployment
- 67. Eberhard Wolff - @ewolff Use If… • Time to market is important • Legacy systems must be modernized • Sustained development speed • Continuous Delivery should be implemented • Large enough project
- 68. Eberhard Wolff - @ewolff Don’t Use If… • Infrastructure complexity cannot be handled • Architectural complexity cannot be handled
- 69. Eberhard Wolff - @ewolff Thank You!