Microservices: Architecture for Agile Software Development
20 likes4,748 views
This document discusses microservices architecture and how it enables agility. It defines microservices as small, independent units that can be developed and deployed autonomously. The document argues that microservices align with the principles of the Agile Manifesto by allowing teams to work independently, facilitating continuous delivery, and making the architecture adaptable to change. Some benefits outlined are improved scalability, maintainability, and ability to replace services easily. The conclusion is that by structuring an organization and software architecture around microservices, greater agility can be achieved compared to a monolithic architecture.
Microservices: Architecture for Agile Software Development
- 1. Microservices: Architecture for Agile Software Development Eberhard Wolff Fellow, innoQ @ewolff
- 3. Code
- 5. Server Server Microservices: Definition > Small > Independent deployment units > Any technology > Any infrastructure > UI + Logic Micro Service Micro Service
- 8. Online Shop Elasticsearch Spring Batch Oracle Spring MVC MongoDB Order Catalog Search Billing
- 9. Agility
- 10. Agile Manifesto > Individuals and Interaction > Over processes and tools > Working Software > Over comprehensive documentation > Customer Collaboration > Over contract negotation > Responding to change > Over following a plan
- 14. Does Your Architecture Take Individuals Into Account?
- 15. Conway‘s Law Architecture copies communication structures of the organization
- 16. Conway‘s Law: Impact Architecture and communication structures in the organization are the same thing.
- 17. Conway’s Law as a Limit > Organization drives architecture > I.e. GUI, logic & database team > Three technical artifacts
- 19. time DB Team Sprint Logic Team Sprint GUI Team Sprint 3 sprints
- 20. Deployment Monolith Deployment Monolith Stories Technical Coordination Coordinating Releases
- 21. Order Billing Search Order Search Billing Team for each business feature Let architecture drive the organization
- 22. Deployment Monolith + Conway’s Law Deployment Monolith Stories Technical Coordination Coordinating Releases StoriesStories Order Billing Search
- 23. Microservices + Conway’s Law > Let architecture drive the organization > Team for each Microservice > Team responsible for business features > Ideal: Independent features
- 24. Order Billing Search Order Search Billing 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
- 25. Microservices Microservice Stories Technical Coordination Microservice Stories Technical Coordination Microservice Stories Technical Coordination Order Billing Search Release Release Release
- 26. How to scale agile?
- 27. Use a process to scale agile?
- 28. Individuals & interaction over processes and tools
- 30. One team can build and deploy features independently!
- 31. Team must be responsible for a sensible set of functionality
- 34. Scrum > PSI > Potentially shippable increment > Why?
- 35. Principles behind the Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 39. Build Pipeline: Complex Infrastructure > Huge database > 3rd party integration
- 40. Build Pipeline: Slow Feedback > Slow feedback > Test everything for each commit > Huge deployment unit > Deployment slow
- 41. Monolith: Deployment > Huge deployment > Risky > Hard to mitigate risk > Blue / Green: Create a separate environment > Canary: Deploy to one server first
- 44. Build Pipeline for Microservices > Independent deployment > Build pipeline per Microservice > Small > Easier to set up > Less features (3rd party systems) > Faster Feedback: Less tests
- 45. Microservice: Deployment > Small deployment > Less risky > Other Microservices resilient to failing microservice > Easy to create new environments > E.g. for Blue / Green or Canary
- 46. Quick Deployments Time Size & Risk Manual Deployment Pipeline Continuous Delivery Pipeline Monolith Microservices
- 48. SHIP!!!
- 52. Microservices & Departments StoriesStories Stories Customer Billing Order Process Product Owner Product Owner Product Owner Department Department Department
- 53. Microservices & Departments > Ideal: One team per department > Ideal: Change local to one team / Microservice > Otherwise: Coordination needed
- 55. Agile Manifesto: Responding to change
- 56. Monoliths > Architecture rot > …not maintainable any more > …and can’t be rewritten / replaced
- 57. Deployment Monolith > Cyclic dependency > …because the IDE suggested some class > Might not even be noticed Module Class Module Class Class Class
- 58. Microservices > Need to use the API > Different team > More effort - will think about it > Rot less likely Microservice Class Microservice Class Class Class
- 59. Global Refactorings? > Move code from service to service > Might be a port to a different language > Separate in a new service > Harder than in a Deployment Monolith
- 60. Microservices > Small > Easy to change > Architectural problems in Microservice unlikely > Can be replaced Microservice Class Class
- 61. Microservices – Easy to Recylce
- 62. Conclusion
- 63. Conclusion: Microservices & Agility > Individuals over tools > Architecture drives organization > Scale by architecture not process > Working software > Actually ship software > Continuous Delivery
- 64. Conclusion: Microservices & Agility > Customer collaboration > Customer should own services > i.e. organization beyond the project = architecture
- 65. 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
- 66. Meta-Conclusion
- 67. How To Think About Architecture > Process has an impact on architecture > Software architecture & organization are the same > Build recyclable software!
- 68. Microservice > Agile Achitecture Strong Modularization Scaled Agile Architecture Sustainable development speed Replaceable Services Continuous Delivery Choose best technology for job! Handle Legacy more efficient Independent Scaling Robustness
- 69. Microservice Training > Stefan Tilkov / Eberhard Wolff > Frankfurt / Main > 26.-27.10.2015 > https://www.innoq.com/de/trainings/ microservices-training/