Software Architektur

für DevOps

und Continuous
Delivery
Eberhard Wolff
Freelance Consultant / Trainer
Head Technology Ad...
Eberhard Wolff - @ewolff
Overview
•  DevOps
•  Continuous Delivery
•  Architecture
•  7 Rules
Eberhard Wolff - @ewolff
Overview
•  DevOps
•  Continuous Delivery
•  Architecture
•  7 Rules
Eberhard Wolff - @ewolff
DevOps
Development
+ Operations
=DevOps
Organizational change
No more silos
Eberhard Wolff - @ewolff
Overview
•  DevOps
•  Continuous Delivery
•  Architecture
•  7 Rules
Eberhard Wolff - @ewolff
Overview
•  DevOps
•  Continuous Delivery
•  Architecture
•  7 Rules
Eberhard Wolff - @ewolff
Continuous Delivery:

Build Pipeline
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity...
Eberhard Wolff - @ewolff
Continuous Delivery

Needs Deployment
Automation
•  But it is not the same
•  Many test systems r...
Eberhard Wolff - @ewolff
Continuous Delivery

Releases
•  Blue / Green Deployments
•  New version on separate production
e...
Eberhard Wolff - @ewolff
Overview
•  DevOps
•  Continuous Delivery
•  Architecture
•  7 Rules
Eberhard Wolff - @ewolff
Overview
•  DevOps
•  Continuous Delivery
•  Architecture
•  7 Rules
Eberhard Wolff - @ewolff
Architecture: Wikipedia
Set of structures
needed to
reason about the software system
Comprises
so...
Eberhard Wolff - @ewolff
Why Architecture?
•  System too large to understand
•  Understand components in
isolation
•  Unde...
Eberhard Wolff - @ewolff
Architecture & Non-
functional Requirements
•  Architecture defines technical
foundation
•  Techn...
Eberhard Wolff - @ewolff
Overview
•  DevOps
•  Continuous Delivery
•  Architecture
•  7 Rules
Eberhard Wolff - @ewolff
Overview
•  DevOps
•  Continuous Delivery
•  Architecture
•  7 Rules
Eberhard Wolff - @ewolff
Example
Order
Warehouse Customer
Functional decomposition
Technology independent
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Libraries
e.g. jar, dll Method calls
One deployment
unit
Eberhard Wolff - @ewolff
Architecture
Simple
High performance
Eberhard Wolff - @ewolff
Change
•  Modify order process slightly
•  Customer & Warehouse unchanged
Order
Warehouse Custome...
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Eberhard Wolff - @ewolff
Continuous Delivery:

Build Pipeline
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity...
Eberhard Wolff - @ewolff
Build Pipeline
•  Just one component changed!
•  Lots of unneeded work
•  Takes much too long
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Call Center
Payment
Provider
No retesting
for new
versions
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Libraries
e.g. jar, dll Method calls
One deployment
unit
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Services Service calls
Three
deployment
units
Eberhard Wolff - @ewolff
Components = Services
•  Independent deployment
•  REST/JSON
•  ProtoBuf
•  MessageBus
•  Micro S...
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Eberhard Wolff - @ewolff
Continuous Delivery:

Build Pipeline
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity...
Eberhard Wolff - @ewolff
Release
•  Just a single component
•  Much easier to do Blue/Green
•  or Canary Releases
•  Rollb...
Eberhard Wolff - @ewolff
Other Benefits
•  Might use different technologies per
component
•  For specific requirements
•  F...
Eberhard Wolff - @ewolff
#1 Small Deployment Units
Less testing
Faster deployment
Less waste
Easier rollback
Eberhard Wolff - @ewolff
Change
•  Optimized algorithm for warehouses
•  Additional information must be
passed in from ord...
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Interface changes
Order must also be deployed
Eberhard Wolff - @ewolff
Problems
•  Order and Warehouse must be
deployed together
•  Hard to coordinate
•  More complex p...
Eberhard Wolff - @ewolff
Solution
•  New warehouse version supports
old interface
•  Warehouse can be deployed first
•  …a...
Eberhard Wolff - @ewolff
Robustness Principle
•  aka Postel’s Law
•  Be conservative in what you send
•  be liberal in wha...
Eberhard Wolff - @ewolff
#2 Interface Backwards
Compatibility
Faster deployment
Deploy components independently
Less waste
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Bug Fix
Warehouse must be deployed again
Eberhard Wolff - @ewolff
Problems
•  Warehouse stores current state in
RAM
•  Information lost during update
Stateless
Eberhard Wolff - @ewolff
Stateless
•  Keep components stateless
•  Might store state in database etc.
Eberhard Wolff - @ewolff
#3 Stateless
Easier to update
State e.g. in database
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Component failure
Domino effect
Eberhard Wolff - @ewolff
Component Interfaces
•  Design for Failure
•  I.e. do not fail if other component
fail
•  Default...
Architecture
deals with
Failure
Resilience
Eberhard Wolff - @ewolff
Resilience &

Small Deployment Units
•  Downtime during deployment
might be acceptable
•  More fl...
Eberhard Wolff - @ewolff
Circuit Breaker
•  Do not call a broken system
•  Instead throw exception
•  Retry after some tim...
Eberhard Wolff - @ewolff
#4 Design for Failure
More stable
Better for Ops
Better for new releases
Eberhard Wolff - @ewolff
Change
•  SEPA
•  Additional customer information
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Column must be added to database
Eberhard Wolff - @ewolff
Database Changes Are Hard
•  Schema changes
•  Converting existing data
•  Potential lots of data...
Eberhard Wolff - @ewolff
1 - Keep database
schema stable
2 - Database = component
Eberhard Wolff - @ewolff
Keep Database Schema
Stable
•  Change database before
components use it
•  Change database seldom...
Eberhard Wolff - @ewolff
#5a Keep database schema
stable
No rollback
Less agile
Eberhard Wolff - @ewolff
Databases = Component
•  Support old “interface”
•  i.e. schema
Eberhard Wolff - @ewolff
Order
Warehouse Customer
Database
Database must support different data
structures
V42
V43
Eberhard Wolff - @ewolff
Dealing with

Database Changes
•  Add an abstraction layer
•  Stored procedures
•  No direct acce...
Eberhard Wolff - @ewolff
Dealing with

Database Changes
•  Support previous version schema
•  Default value for new column...
Eberhard Wolff - @ewolff
#5b Databases =
Component
Need to be backwards compatible
Probably even more important than
for c...
Eberhard Wolff - @ewolff
NoSQL
•  Schema changes much easier
•  Can support different schemas in
parallel
•  Still need to...
Eberhard Wolff - @ewolff
Change
•  Support for new logistic partner
•  Won’t start until next month
Eberhard Wolff - @ewolff
Feature Branch
•  Additional instance of the delivery
pipeline
•  Deployment must be synced to st...
Eberhard Wolff - @ewolff
Feature Toggle
•  Implement the feature
•  Can be activated by feature toggle
•  i.e. part of the...
Eberhard Wolff - @ewolff
Feature Toggle
•  Implementation & deployment
independent
•  Can deploy early – less risk
•  Can ...
Eberhard Wolff - @ewolff
Feature Toggle
•  Add another dimension to the
architecture
•  Must eventually be cleaned up
Eberhard Wolff - @ewolff
DevOps
•  Support for new logistics partner
crashes system
•  Feature toggle allows Ops to disabl...
Eberhard Wolff - @ewolff
#6 Feature Toggle
Decouple release / new features
Resilience: Provide fallback
Eberhard Wolff - @ewolff
After the Change
•  New logistics partner
•  Revenue declined
•  Some orders were lost
Eberhard Wolff - @ewolff
Business Monitoring
•  Provide metrics with business
meaning
•  i.e. revenue
•  #orders
•  #regis...
Eberhard Wolff - @ewolff
#7 Monitoring
Dev provides (business) metrics
Ops provides monitoring
infrastructure
Eberhard Wolff - @ewolff
•  #1 Small Deployment Units
•  #2 Interface Backwards
Compatibility
•  #3 Stateless
•  #4 Design...
Eberhard Wolff - @ewolff
Thank You!
Upcoming SlideShare
Loading in...5
×

Software Architecture for DevOps and Continuous Delivery

4,385

Published on

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

Published in: Technology, Business
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,385
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
107
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide

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!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×