Software Architecture for DevOps and Continuous Delivery

1. Software Architektur  für DevOps  und Continuous Delivery Eberhard Wolff Freelance Consultant / Trainer Head Technology Advisory Board adesso AG http://ewolff.com

2. Eberhard Wolff - @ewolff Overview •  DevOps •  Continuous Delivery •  Architecture •  7 Rules

4. Eberhard Wolff - @ewolff DevOps Development + Operations =DevOps Organizational change No more silos

7. Eberhard Wolff - @ewolff Continuous Delivery:  Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release

8. Eberhard Wolff - @ewolff Continuous Delivery  Needs Deployment Automation •  But it is not the same •  Many test systems required •  Automation less error prone

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

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. Eberhard Wolff - @ewolff Why Architecture? •  System too large to understand •  Understand components in isolation •  Understand how components interact

14. Eberhard Wolff - @ewolff Architecture & Non- functional Requirements •  Architecture defines technical foundation •  Technical foundation influences •  Performance •  Security •  Scalability •  Etc

17. Eberhard Wolff - @ewolff Example Order Warehouse Customer Functional decomposition Technology independent

18. Eberhard Wolff - @ewolff Order Warehouse Customer Database Libraries e.g. jar, dll Method calls One deployment unit

19. Eberhard Wolff - @ewolff Architecture Simple High performance

20. Eberhard Wolff - @ewolff Change •  Modify order process slightly •  Customer & Warehouse unchanged Order Warehouse Customer Database

21. Eberhard Wolff - @ewolff Order Warehouse Customer Database

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. Eberhard Wolff - @ewolff Build Pipeline •  Just one component changed! •  Lots of unneeded work •  Takes much too long

24. Eberhard Wolff - @ewolff Order Warehouse Customer Database Call Center Payment Provider No retesting for new versions

25. Eberhard Wolff - @ewolff Order Warehouse Customer Database Libraries e.g. jar, dll Method calls One deployment unit

26. Eberhard Wolff - @ewolff Order Warehouse Customer Database Services Service calls Three deployment units

27. Eberhard Wolff - @ewolff Components = Services •  Independent deployment •  REST/JSON •  ProtoBuf •  MessageBus •  Micro Services: even smaller?

28. Eberhard Wolff - @ewolff Order Warehouse Customer Database

29. Eberhard Wolff - @ewolff Continuous Delivery:  Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing ReleaseOrder

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. Eberhard Wolff - @ewolff Other Beneﬁts •  Might use different technologies per component •  For specific requirements •  For specific developer skills

32. Eberhard Wolff - @ewolff #1 Small Deployment Units Less testing Faster deployment Less waste Easier rollback

33. Eberhard Wolff - @ewolff Change •  Optimized algorithm for warehouses •  Additional information must be passed in from order

34. Eberhard Wolff - @ewolff Order Warehouse Customer Database Interface changes Order must also be deployed

35. Eberhard Wolff - @ewolff Problems •  Order and Warehouse must be deployed together •  Hard to coordinate •  More complex pipeline •  Harder rollback

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. 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. Eberhard Wolff - @ewolff #2 Interface Backwards Compatibility Faster deployment Deploy components independently Less waste

39. Eberhard Wolff - @ewolff Order Warehouse Customer Database Bug Fix Warehouse must be deployed again

40. Eberhard Wolff - @ewolff Problems •  Warehouse stores current state in RAM •  Information lost during update

41. Stateless

42. Eberhard Wolff - @ewolff Stateless •  Keep components stateless •  Might store state in database etc.

43. Eberhard Wolff - @ewolff #3 Stateless Easier to update State e.g. in database

44. Eberhard Wolff - @ewolff Order Warehouse Customer Database Component failure Domino effect

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. Architecture deals with Failure

47. Resilience

48. Eberhard Wolff - @ewolff Resilience &  Small Deployment Units •  Downtime during deployment might be acceptable •  More flexibility for deployments

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. Eberhard Wolff - @ewolff #4 Design for Failure More stable Better for Ops Better for new releases

51. Eberhard Wolff - @ewolff Change •  SEPA •  Additional customer information

52. Eberhard Wolff - @ewolff Order Warehouse Customer Database Column must be added to database

53. Eberhard Wolff - @ewolff Database Changes Are Hard •  Schema changes •  Converting existing data •  Potential lots of data •  Hard or even impossible to rollback

54. Eberhard Wolff - @ewolff 1 - Keep database schema stable 2 - Database = component

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. Eberhard Wolff - @ewolff #5a Keep database schema stable No rollback Less agile

57. Eberhard Wolff - @ewolff Databases = Component •  Support old “interface” •  i.e. schema

58. Eberhard Wolff - @ewolff Order Warehouse Customer Database Database must support different data structures V42 V43

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. 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. Eberhard Wolff - @ewolff #5b Databases = Component Need to be backwards compatible Probably even more important than for components

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. Eberhard Wolff - @ewolff Change •  Support for new logistic partner •  Won’t start until next month

64. Eberhard Wolff - @ewolff Feature Branch •  Additional instance of the delivery pipeline •  Deployment must be synced to start of new partner

65. Eberhard Wolff - @ewolff Feature Toggle •  Implement the feature •  Can be activated by feature toggle •  i.e. part of the configuration

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. Eberhard Wolff - @ewolff Feature Toggle •  Add another dimension to the architecture •  Must eventually be cleaned up

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. Eberhard Wolff - @ewolff #6 Feature Toggle Decouple release / new features Resilience: Provide fallback

70. Eberhard Wolff - @ewolff After the Change •  New logistics partner •  Revenue declined •  Some orders were lost

71. Eberhard Wolff - @ewolff Business Monitoring •  Provide metrics with business meaning •  i.e. revenue •  #orders •  #registrations •  etc •  Feed into monitoring / metrics

72. Eberhard Wolff - @ewolff #7 Monitoring Dev provides (business) metrics Ops provides monitoring infrastructure

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. Eberhard Wolff - @ewolff Thank You!

Software Architecture for DevOps and Continuous Delivery

You are reading a preview.

Check these out next

Software Architecture for DevOps and Continuous Delivery

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Similar to Software Architecture for DevOps and Continuous Delivery (20)

More from Eberhard Wolff (20)

Recently uploaded (20)

Software Architecture for DevOps and Continuous Delivery