Microservices and Self-contained System to Scale Agile
1 like1,869 views
The document discusses microservices and self-contained systems as approaches to scaling agile development, emphasizing independent deployment units and reducing dependencies. It outlines the architecture's benefits, such as improved robustness, faster feedback, and the ability to handle legacy systems more efficiently. The author advocates for using these methods in large projects to enhance sustainable development and continuous delivery.
Microservices and Self-contained System to Scale Agile
- 1. Microservices & Self- Contained Systems to Scale Agile Eberhard Wolff Fellow, innoQ @ewolff
- 6. Server Server Microservices: Definition > Independent deployment units > E.g. process, VMs, Docker containers > Any technology > Any infrastructure Micro Service Micro Service
- 8. Layered Microservices iOS Android Web Order Search Catalog BillingCustomer Backend Backend Backend
- 9. Layered Microservices > Reusable Backend Services > Mobile client / Web App as frontend > Backend for frontend (BFF): Custom backend services > ...to implement frontend specific logic
- 10. Layered: Issues > BFF might contain the same logic – same processes > BFF might contain most relevant logic > Change to a business process means changing many services > Lots of communication
- 12. Deployment monolith Graphics by Roman Stranghöhner, innoQ http://scs-architecture.org
- 14. … wrap domain in separate web application …
- 16. SCS = user interface+ business logic+ data storage
- 17. Each SCS contains all layers.
- 18. Self-contained Systems should be integrated in the web interface
- 19. Synchronous remote calls inside the business logic should be avoided.
- 20. Asynchronous Remote calls reduce dependencies and prevent error cascades.
- 21. Every SCS brings its own data storage with its own (potentially redundant) data
- 22. Domained scoped SCS enables the development, operation and maintenance of an domain by a single team. Team 1 Team 2 Team 3
- 23. 1 SCS = 1 Domain = 1 Web App = 1 Team = 1-n Microservices
- 24. Why create such a complex system?
- 25. Legacy Apps
- 26. HTTP New Stuff Links No legacy code Any technology J Small code base
- 28. Monoliths > Architecture rot > …not maintainable any more > …and can’t be rewritten / replaced
- 29. Microservices > Distributed system of small units > Architecture violations harder > Architecture won’t rot > Small units > Easy to replace > Service rotten? Replace!
- 30. Robust > One failing Microservice doesn’t crash the system > However, Microservices must deal with failing Microservices
- 32. Principles behind the Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 35. Build Pipeline: Problems > Complex infrastructure > Huge database > 3rd party integration > Slow feedback > Test everything for each commit > Huge deployment unit > Deployment slow
- 39. Build Pipeline for Microservices > Independent deployment > Build pipeline per Microservice > Smaller > Easier to set up > Less features (3rd party systems) > Faster Feedback: Less tests
- 40. Independent Scaling > Can scale each Microservice indenpendently > Much easier than for a Deployment Monolith
- 41. Technology Freedom > No meetings for introducing a bug fix in a library! > No big migration away from outdated technology > Easier experiments > Higher motivation
- 42. Scaling Agility
- 43. Scaling Agility > Do more > Get more stories implemented > ...and running in production TODO IN PROGRESS DONE
- 44. Scaling Agility > Add more people > Let the work in parallel > Build more teams
- 45. What is the problem?
- 46. Communication > Agile means communication > Instead of written requirements > ...story cards > + direct communication
- 47. # Persons vs. Potential Links 0 100 200 300 0 10 20 30
- 48. Communication is great! Need more persons
- 49. Challenges for Scaling Agile > Dependencies cause delays > Too much communication about functionalities,... > ...releasing software, > ...and technologies
- 50. Challenges for Scaling Agile > Dependencies cause delays > Too much communication about functionalities... > ...releasing software, > ...and technologies
- 51. Conway‘s Law Architecture copies communication structures of the organization
- 53. time DB Team Sprint Logic Team Sprint GUI Team Sprint 3 sprints
- 54. Domained scoped SCS enables the development of a domain by a single team – no coordination Order Team = UI+Logic+Database
- 55. Challenges for Scaling Agile > Dependencies cause delays > Too much communication about functionalities... > ...releasing software, > ...and technologies
- 58. Technical decisions can be made independently from other systems (programming language, frameworks, tooling, platform)
- 59. SCS Stories Technical Coordination Stories Technical Coordination Stories Technical Coordination Order Billing Search Release Release Release
- 60. Why Microservices/SCS? Sustainable development speed Continuous Delivery Choose best technology for job! Handle Legacy more efficient Independent Scaling Robustness Scaling Agile
- 61. Conclusion
- 62. Conclusion: SCS & Microservices > Microservices have many advantages > SCS are a way to use Microservices > …for large projects > …to scale agile
- 64. EMail slidesjugsaxony@ewolff.com to get: Slides + Microservices Primer + Sample Microservices Book + Sample of Continuous Delivery Book Powered by Amazon Lambda & Microservices