Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices: Architecture to Support Agile

1,828 views

Published on

What Microservices are and how Microservices help to support agile software development.

Published in: Technology

Microservices: Architecture to Support Agile

  1. 1. Microservices: Architecture for Agile Software Development Eberhard Wolff Fellow, innoQ @ewolff
  2. 2. http://microservices-buch.de/ http://microservices-book.com/
  3. 3. http://microservices-book.com/primer.html FREE!!!!
  4. 4. Microservice Definition
  5. 5. Server Server Microservices: Definition > Small > Independent deployment units > Separate VM / process > Any technology > Any infrastructure Micro Service Micro Service
  6. 6. Components Collaborate Micro Service Micro Service Link Data Replication REST Messaging
  7. 7. Microservices > Component Model > Component… > Individual deployment unit > GUI+Logic?
  8. 8. Layered iOS Android Web Order Search Catalog BillingCustomer Backend Backend Backend
  9. 9. Layered > Reusable Backend Services > Mobile client / Web App as frontend > Backend for frontend (BFF): Custom backend services > ...to implement frontend specific logic
  10. 10. Layered: Issues > All BFF support the same processes > BFF contain most relevant logic > Change to a business process means changing many services > Lots of communication
  11. 11. Self-contained Systems Order Search CatalogBilling Web Web Web Web
  12. 12. 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 ...
  13. 13. SCS: Benefits > Business logic 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
  14. 14. Online Shop Order Catalog Search Billing Customer HTML / HTTP
  15. 15. Online Shop Elasticsearch Spring Batch Oracle Spring MVC MongoDB Order Catalog Search Billing
  16. 16. Agility
  17. 17. 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
  18. 18. Agile Manifesto: Individuals and Interactions
  19. 19. Software Architecture & Individuals
  20. 20. Software Architecture & Individuals Unrelated?
  21. 21. Does Your Architecture Take Individuals Into Account?
  22. 22. Conway‘s Law Architecture copies communication structures of the organization
  23. 23. Conway‘s Law: Impact Architecture and communication structures in the organization are the same thing.
  24. 24. Conway’s Law as a Limit > Organization drives architecture > I.e. GUI, logic & database team > Three technical artifacts
  25. 25. E Commerce Shop Change Order Process! UI Backend DB
  26. 26. time DB Team Sprint Backend Team Sprint UI Team Sprint 3 sprints
  27. 27. Deployment Monolith Deployment Monolith Stories Technical Coordination Coordinating Releases
  28. 28. Order SearchBilling Team for each business feature Let architecture drive the organization Order Billing Search
  29. 29. Deployment Monolith + Conway’s Law Deployment Monolith Stories Technical Coordination Coordinating Releases StoriesStories Order Billing Search
  30. 30. Microservices + Conway’s Law > Let architecture drive the organization > Team for each Microservice > Team responsible for business features > Ideal: Independent features
  31. 31. Order SearchBilling Order Billing Search 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
  32. 32. Microservices Microservice Stories Technical Coordination Microservice Stories Technical Coordination Microservice Stories Technical Coordination Order Billing Search Release Release Release
  33. 33. How to scale agile?
  34. 34. Define architecture to limit communication needs
  35. 35. One team can build and deploy features independently!
  36. 36. Team must be responsible for a sensible set of functionality
  37. 37. Less Technical Coordination
  38. 38. Agile Manifesto: Working Software
  39. 39. Scrum > PSI > Potentially shippable increment > Why?
  40. 40. Principles behind the Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  41. 41. Potentially Shippable Increment Continuous Delivery
  42. 42. Monolith ECommerce System 3rd party systems Database
  43. 43. Continuous Delivery: Build Pipeline ECommerce System Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release
  44. 44. Build Pipeline: Complex Infrastructure > Huge database > 3rd party integration
  45. 45. Build Pipeline: Slow Feedback > Slow feedback > Test everything for each commit > Huge deployment unit > Deployment slow
  46. 46. Monolith: Deployment > Huge deployment > Risky > Hard to mitigate risk > Blue / Green: Create a separate environment > Canary: Deploy to one server first
  47. 47. Microservices ECommerce System 3rd party systems Database
  48. 48. Microservices 3rd party systems Database Order Catalog Billing Search
  49. 49. Order Billing Customer 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
  50. 50. Build Pipeline for Microservices > Independent deployment > Build pipeline per Microservice > Small > Easier to set up > Less features (3rd party systems) > Faster Feedback: Less tests
  51. 51. Microservice: Deployment > Small deployment > Less risky > Other Microservices resilient to failing microservice > Easy to create new environments > E.g. for Blue / Green or Canary
  52. 52. Quick Deployments Time Size & Risk Manual Deployment Pipeline Continuous Delivery Pipeline Monolith Microservices
  53. 53. Potentially shippable increment?
  54. 54. SHIP!!!
  55. 55. Agile Manifesto: Customer Collaboration
  56. 56. Customer Collaboration & Architecture?
  57. 57. Microservices & Departments StoriesStories Stories Customer Billing Order Process Product Owner Product Owner Product Owner Department Department Department
  58. 58. Microservices & Departments > Ideal: One team per department > Ideal: Change local to one team / Microservice > Otherwise: Coordination needed
  59. 59. Customer should own Microservice
  60. 60. Agile Manifesto: Responding to change
  61. 61. Monoliths > Architecture rot > …not maintainable any more > …and can’t be rewritten / replaced
  62. 62. Deployment Monolith > Cyclic dependency > …because the IDE suggested some class > Might not even be noticed Module Class Module Class Class Class
  63. 63. Microservices > Need to use the API > Different team > More effort - will think about it > Rot less likely Microservice Class Microservice Class Class Class
  64. 64. 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
  65. 65. Microservices > Small > Easy to change > Architectural problems in Microservice unlikely > Can be replaced Microservice Class Class
  66. 66. Microservices – Easy to Recycle
  67. 67. Conclusion
  68. 68. Conclusion: Microservices & Agility > Individuals over tools > Architecture drives organization > Scale by architecture not process > Working software > Actually ship software > Continuous Delivery
  69. 69. Conclusion: Microservices & Agility > Customer collaboration > Customer should own services > i.e. organization beyond the project = architecture
  70. 70. 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
  71. 71. Meta-Conclusion
  72. 72. How To Think About Architecture > Process has an impact on architecture > Software architecture & organization are the same > Build recyclable software!
  73. 73. 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
  74. 74. Thank You! @ewolff https://github.com/ewolff/microservice https://leanpub.com/microservices-primer http://microservices-buch.de/ http://scs-architecture.org

×