Download as PDF, PPTX
Uploaded byEberhard Wolff
Microservices: Architecture to Support Agile
1. Microservices architecture divides applications into small, independent components called microservices that can be developed, deployed and scaled independently. 2. This architecture aligns well with agile principles by allowing individual teams to focus on and deploy their microservice without coordination, enabling faster feedback and continuous delivery of working software. 3. By structuring the organization around business domains rather than technical components, microservices help drive organizational communication patterns that mirror the architecture, avoiding misalignment over time.
More Related Content
![[WSO2Con Asia 2014] Accelerating Mobile App Development with MBaaS](https://cdn.slidesharecdn.com/ss_thumbnails/mbaas-wso2conasia-2014-140325234640-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Microservices: Architecture to Support Agile
Microservices: Architecture to Support Agile
- 1. Microservices: Architecture for Agile SoftwareDevelopment Eberhard Wolff Fellow, innoQ @ewolff
- 3.
- 4.
- 5.
- 6. Server Server Microservices: Definition > Small >Independent deployment units > Separate VM / process > Any technology > Any infrastructure Micro Service Micro Service
- 7.
- 8. Microservices > Component Model >Component… > Individual deployment unit > GUI+Logic?
- 9. Layered iOS Android Web OrderSearch Catalog BillingCustomer Backend Backend Backend
- 10. Layered > Reusable BackendServices > Mobile client / Web App as frontend > Backend for frontend (BFF): Custom backend services > ...to implement frontend specific logic
- 11. Layered: Issues > AllBFF support the same processes > BFF contain most relevant logic > Change to a business process means changing many services > Lots of communication
- 12.
- 13. Self-contained Systems (SCS) > SCS:Autonomous web application > Optional service API (e.g. for mobile clients) > Includes data & logic > Might contain several microservices > No shared UI > No shared business code > E.g. Otto, Kaufhof ...
- 14. SCS: Benefits > Businesslogic for one domain in one SCS > Change usually local to one SCS > Less communication between SCS > I think this should be the goal > http://scs-architecture.org
- 15.
- 16. Online Shop Elasticsearch Spring Batch Oracle SpringMVC MongoDB Order Catalog Search Billing
- 17.
- 18. Agile Manifesto > Individualsand Interaction > Over processes and tools > Working Software > Over comprehensive documentation > Customer Collaboration > Over contract negotation > Responding to change > Over following a plan
- 19.
- 20.
- 21.
- 22. Does Your Architecture Take IndividualsInto Account?
- 23. Conway‘s Law Architecture copies communication structures ofthe organization
- 24. Conway‘s Law: Impact Architecture and communicationstructures in the organization are the same thing.
- 25. Conway’s Law asa Limit > Organization drives architecture > I.e. GUI, logic & database team > Three technical artifacts
- 26.
- 27. time DB Team Sprint Backend Team Sprint UI TeamSprint 3 sprints
- 28. Deployment Monolith Deployment Monolith Stories TechnicalCoordination Coordinating Releases
- 29. Order SearchBilling Team foreach business feature Let architecture drive the organization Order Billing Search
- 30. Deployment Monolith + Conway’sLaw Deployment Monolith Stories Technical Coordination Coordinating Releases StoriesStories Order Billing Search
- 31. Microservices + Conway’s Law >Let architecture drive the organization > Team for each Microservice > Team responsible for business features > Ideal: Independent features
- 32. Order SearchBilling Order BillingSearch Team can deploy without integration Changes can be deployed independently & quickly Strong & enforced modularization Technology stack per Microservice One or many Microservices per Team Synergy Microservices / Conway’s Law
- 33.
- 34. How to scaleagile?
- 35.
- 36. One team canbuild and deploy features independently!
- 37. Team must be responsiblefor a sensible set of functionality
- 38.
- 39.
- 40. Scrum > PSI > Potentiallyshippable increment > Why?
- 41. Principles behind the AgileManifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 42.
- 43.
- 44.
- 45. Build Pipeline: Complex Infrastructure >Huge database > 3rd party integration
- 46. Build Pipeline: Slow Feedback >Slow feedback > Test everything for each commit > Huge deployment unit > Deployment slow
- 47. Monolith: Deployment > Huge deployment >Risky > Hard to mitigate risk > Blue / Green: Create a separate environment > Canary: Deploy to one server first
- 48.
- 49.
- 50.
- 51. Build Pipeline for Microservices >Independent deployment > Build pipeline per Microservice > Small > Easier to set up > Less features (3rd party systems) > Faster Feedback: Less tests
- 52. Microservice: Deployment > Small deployment >Less risky > Other Microservices resilient to failing microservice > Easy to create new environments > E.g. for Blue / Green or Canary
- 53. Quick Deployments Time Size &Risk Manual Deployment Pipeline Continuous Delivery Pipeline Monolith Microservices
- 54.
- 55.
- 56.
- 57.
- 58. Microservices & Departments StoriesStories Stories CustomerBilling Order Process Product Owner Product Owner Product Owner Department Department Department
- 59. Microservices & Departments > Ideal:One team per department > Ideal: Change local to one team / Microservice > Otherwise: Coordination needed
- 60.
- 61.
- 62. Monoliths > Architecture rot >…not maintainable any more > …and can’t be rewritten / replaced
- 63. Deployment Monolith > Cyclicdependency > …because the IDE suggested some class > Might not even be noticed Module Class Module Class Class Class
- 64. Microservices > Need touse the API > Different team > More effort - will think about it > Rot less likely Microservice Class Microservice Class Class Class
- 65. Global Refactorings? > Movecode from service to service > Might be a port to a different language > Separate in a new service > Harder than in a Deployment Monolith
- 66. Microservices > Small > Easyto change > Architectural problems in Microservice unlikely > Can be replaced Microservice Class Class
- 67. Microservices – Easy toRecycle
- 68.
- 69. Conclusion: Microservices & Agility >Individuals over tools > Architecture drives organization > Scale by architecture not process > Working software > Actually ship software > Continuous Delivery
- 70. Conclusion: Microservices & Agility >Customer collaboration > Customer should own services > i.e. organization beyond the project = architecture
- 71. Conclusion: Microservices & Agility >Responding to change > Individual Microservices small > Easy to change > …and replace > Unwanted dependencies won’t sneak in > But: Global refactoring hard, too
- 72.
- 73. How To ThinkAbout Architecture > Process has an impact on architecture > Software architecture & organization are the same > Build recyclable software!
- 74. Microservice > Agile Achitecture StrongModularization Scaled Agile Architecture Sustainable development speed Replaceable Services Continuous Delivery Choose best technology for job! Handle Legacy more efficient Independent Scaling Robustness
- 75.