Software Architecture for DevOps and Continuous Delivery

6,010 views
5,739 views

Published on

Talks from Continuous Lifecycle 2013 in Germany about the influence of DevOps and Continuous Delivery on Software Architecture,

Published in: Technology, Business

Software Architecture for DevOps and Continuous Delivery

  1. 1. Software Architektur
 für DevOps
 und Continuous Delivery Eberhard Wolff Freelance Consultant / Trainer Head Technology Advisory Board adesso AG http://ewolff.com
  2. 2. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules
  3. 3. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules
  4. 4. Eberhard Wolff - @ewolff DevOps Development + Operations =DevOps Organizational change No more silos
  5. 5. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules
  6. 6. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules
  7. 7. Eberhard Wolff - @ewolff Continuous Delivery:
 Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release
  8. 8. Eberhard Wolff - @ewolff Continuous Delivery
 Needs Deployment Automation •  But it is not the same •  Many test systems required •  Automation less error prone
  9. 9. Eberhard Wolff - @ewolff Continuous Delivery
 Releases •  Blue / Green Deployments •  New version on separate production environment •  Canary Releasing •  Release to a few servers in the cluster
  10. 10. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules
  11. 11. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules
  12. 12. Eberhard Wolff - @ewolff Architecture: Wikipedia Set of structures needed to reason about the software system Comprises software elements relations between them properties of both
  13. 13. Eberhard Wolff - @ewolff Why Architecture? •  System too large to understand •  Understand components in isolation •  Understand how components interact
  14. 14. Eberhard Wolff - @ewolff Architecture & Non- functional Requirements •  Architecture defines technical foundation •  Technical foundation influences •  Performance •  Security •  Scalability •  Etc
  15. 15. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules
  16. 16. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules
  17. 17. Eberhard Wolff - @ewolff Example Order Warehouse Customer Functional decomposition Technology independent
  18. 18. Eberhard Wolff - @ewolff Order Warehouse Customer Database Libraries e.g. jar, dll Method calls One deployment unit
  19. 19. Eberhard Wolff - @ewolff Architecture Simple High performance
  20. 20. Eberhard Wolff - @ewolff Change •  Modify order process slightly •  Customer & Warehouse unchanged Order Warehouse Customer Database
  21. 21. Eberhard Wolff - @ewolff Order Warehouse Customer Database
  22. 22. Eberhard Wolff - @ewolff Continuous Delivery:
 Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Order Warehouse Customer Database
  23. 23. Eberhard Wolff - @ewolff Build Pipeline •  Just one component changed! •  Lots of unneeded work •  Takes much too long
  24. 24. Eberhard Wolff - @ewolff Order Warehouse Customer Database Call Center Payment Provider No retesting for new versions
  25. 25. Eberhard Wolff - @ewolff Order Warehouse Customer Database Libraries e.g. jar, dll Method calls One deployment unit
  26. 26. Eberhard Wolff - @ewolff Order Warehouse Customer Database Services Service calls Three deployment units
  27. 27. Eberhard Wolff - @ewolff Components = Services •  Independent deployment •  REST/JSON •  ProtoBuf •  MessageBus •  Micro Services: even smaller?
  28. 28. Eberhard Wolff - @ewolff Order Warehouse Customer Database
  29. 29. Eberhard Wolff - @ewolff Continuous Delivery:
 Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing ReleaseOrder
  30. 30. Eberhard Wolff - @ewolff Release •  Just a single component •  Much easier to do Blue/Green •  or Canary Releases •  Rollback of single service also easier
  31. 31. Eberhard Wolff - @ewolff Other Benefits •  Might use different technologies per component •  For specific requirements •  For specific developer skills
  32. 32. Eberhard Wolff - @ewolff #1 Small Deployment Units Less testing Faster deployment Less waste Easier rollback
  33. 33. Eberhard Wolff - @ewolff Change •  Optimized algorithm for warehouses •  Additional information must be passed in from order
  34. 34. Eberhard Wolff - @ewolff Order Warehouse Customer Database Interface changes Order must also be deployed
  35. 35. Eberhard Wolff - @ewolff Problems •  Order and Warehouse must be deployed together •  Hard to coordinate •  More complex pipeline •  Harder rollback
  36. 36. Eberhard Wolff - @ewolff Solution •  New warehouse version supports old interface •  Warehouse can be deployed first •  …and then Order •  Old interface must be phased out
  37. 37. Eberhard Wolff - @ewolff Robustness Principle •  aka Postel’s Law •  Be conservative in what you send •  be liberal in what you accept •  e.g. accept calls to the old version of the interface •  Better interoperability
  38. 38. Eberhard Wolff - @ewolff #2 Interface Backwards Compatibility Faster deployment Deploy components independently Less waste
  39. 39. Eberhard Wolff - @ewolff Order Warehouse Customer Database Bug Fix Warehouse must be deployed again
  40. 40. Eberhard Wolff - @ewolff Problems •  Warehouse stores current state in RAM •  Information lost during update
  41. 41. Stateless
  42. 42. Eberhard Wolff - @ewolff Stateless •  Keep components stateless •  Might store state in database etc.
  43. 43. Eberhard Wolff - @ewolff #3 Stateless Easier to update State e.g. in database
  44. 44. Eberhard Wolff - @ewolff Order Warehouse Customer Database Component failure Domino effect
  45. 45. Eberhard Wolff - @ewolff Component Interfaces •  Design for Failure •  I.e. do not fail if other component fail •  Default values •  Simpler algorithm •  Graceful Degradation
  46. 46. Architecture deals with Failure
  47. 47. Resilience
  48. 48. Eberhard Wolff - @ewolff Resilience &
 Small Deployment Units •  Downtime during deployment might be acceptable •  More flexibility for deployments
  49. 49. Eberhard Wolff - @ewolff Circuit Breaker •  Do not call a broken system •  Instead throw exception •  Retry after some time •  Protect broke system •  Do not call it in vain
  50. 50. Eberhard Wolff - @ewolff #4 Design for Failure More stable Better for Ops Better for new releases
  51. 51. Eberhard Wolff - @ewolff Change •  SEPA •  Additional customer information
  52. 52. Eberhard Wolff - @ewolff Order Warehouse Customer Database Column must be added to database
  53. 53. Eberhard Wolff - @ewolff Database Changes Are Hard •  Schema changes •  Converting existing data •  Potential lots of data •  Hard or even impossible to rollback
  54. 54. Eberhard Wolff - @ewolff 1 - Keep database schema stable 2 - Database = component
  55. 55. Eberhard Wolff - @ewolff Keep Database Schema Stable •  Change database before components use it •  Change database seldom •  i.e. schema changes not part of deployment •  No rollback
  56. 56. Eberhard Wolff - @ewolff #5a Keep database schema stable No rollback Less agile
  57. 57. Eberhard Wolff - @ewolff Databases = Component •  Support old “interface” •  i.e. schema
  58. 58. Eberhard Wolff - @ewolff Order Warehouse Customer Database Database must support different data structures V42 V43
  59. 59. Eberhard Wolff - @ewolff Dealing with
 Database Changes •  Add an abstraction layer •  Stored procedures •  No direct access to tables •  Persistence layer in the database •  Database is another component with an API
  60. 60. Eberhard Wolff - @ewolff Dealing with
 Database Changes •  Support previous version schema •  Default value for new columns •  Remove column only if not used any more •  Use views •  …
  61. 61. Eberhard Wolff - @ewolff #5b Databases = Component Need to be backwards compatible Probably even more important than for components
  62. 62. Eberhard Wolff - @ewolff NoSQL •  Schema changes much easier •  Can support different schemas in parallel •  Still need to convert data •  Same rules for compatibility apply
  63. 63. Eberhard Wolff - @ewolff Change •  Support for new logistic partner •  Won’t start until next month
  64. 64. Eberhard Wolff - @ewolff Feature Branch •  Additional instance of the delivery pipeline •  Deployment must be synced to start of new partner
  65. 65. Eberhard Wolff - @ewolff Feature Toggle •  Implement the feature •  Can be activated by feature toggle •  i.e. part of the configuration
  66. 66. Eberhard Wolff - @ewolff Feature Toggle •  Implementation & deployment independent •  Can deploy early – less risk •  Can evaluate in production •  A/B testing •  Slow ramp up possible •  Probably one toggle: Old / new version
  67. 67. Eberhard Wolff - @ewolff Feature Toggle •  Add another dimension to the architecture •  Must eventually be cleaned up
  68. 68. Eberhard Wolff - @ewolff DevOps •  Support for new logistics partner crashes system •  Feature toggle allows Ops to disable feature •  One toggle per feature •  Resilience
  69. 69. Eberhard Wolff - @ewolff #6 Feature Toggle Decouple release / new features Resilience: Provide fallback
  70. 70. Eberhard Wolff - @ewolff After the Change •  New logistics partner •  Revenue declined •  Some orders were lost
  71. 71. Eberhard Wolff - @ewolff Business Monitoring •  Provide metrics with business meaning •  i.e. revenue •  #orders •  #registrations •  etc •  Feed into monitoring / metrics
  72. 72. Eberhard Wolff - @ewolff #7 Monitoring Dev provides (business) metrics Ops provides monitoring infrastructure
  73. 73. Eberhard Wolff - @ewolff •  #1 Small Deployment Units •  #2 Interface Backwards Compatibility •  #3 Stateless •  #4 Design For Failure •  #5a Keep database schema stable •  #5b Databases = Component •  #6 Feature Toggle •  #7 Monitoring
  74. 74. Eberhard Wolff - @ewolff Thank You!

×