• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Software Architecture for DevOps and Continuous Delivery
 

Software Architecture for DevOps and Continuous Delivery

on

  • 1,994 views

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

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

Statistics

Views

Total Views
1,994
Views on SlideShare
1,982
Embed Views
12

Actions

Likes
3
Downloads
42
Comments
0

3 Embeds 12

https://twitter.com 10
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Software Architecture for DevOps and Continuous Delivery Software Architecture for DevOps and Continuous Delivery Presentation Transcript

    • Software Architektur
 für DevOps
 und Continuous Delivery Eberhard Wolff Freelance Consultant / Trainer Head Technology Advisory Board adesso AG http://ewolff.com
    • 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 Testing Manual Explorative Testing Release
    • Eberhard Wolff - @ewolff Continuous Delivery
 Needs Deployment Automation •  But it is not the same •  Many test systems required •  Automation less error prone
    • 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
    • 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 software elements relations between them properties of both
    • Eberhard Wolff - @ewolff Why Architecture? •  System too large to understand •  Understand components in isolation •  Understand how components interact
    • Eberhard Wolff - @ewolff Architecture & Non- functional Requirements •  Architecture defines technical foundation •  Technical foundation influences •  Performance •  Security •  Scalability •  Etc
    • 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 Customer Database
    • Eberhard Wolff - @ewolff Order Warehouse Customer Database
    • Eberhard Wolff - @ewolff Continuous Delivery:
 Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Order Warehouse Customer Database
    • 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 Services: even smaller?
    • Eberhard Wolff - @ewolff Order Warehouse Customer Database
    • Eberhard Wolff - @ewolff Continuous Delivery:
 Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing ReleaseOrder
    • Eberhard Wolff - @ewolff Release •  Just a single component •  Much easier to do Blue/Green •  or Canary Releases •  Rollback of single service also easier
    • Eberhard Wolff - @ewolff Other Benefits •  Might use different technologies per component •  For specific requirements •  For specific developer skills
    • 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 order
    • 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 pipeline •  Harder rollback
    • Eberhard Wolff - @ewolff Solution •  New warehouse version supports old interface •  Warehouse can be deployed first •  …and then Order •  Old interface must be phased out
    • 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
    • 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 values •  Simpler algorithm •  Graceful Degradation
    • Architecture deals with Failure
    • Resilience
    • Eberhard Wolff - @ewolff Resilience &
 Small Deployment Units •  Downtime during deployment might be acceptable •  More flexibility for deployments
    • 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
    • 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 •  Hard or even impossible to rollback
    • 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 •  i.e. schema changes not part of deployment •  No rollback
    • 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 access to tables •  Persistence layer in the database •  Database is another component with an API
    • 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 •  …
    • Eberhard Wolff - @ewolff #5b Databases = Component Need to be backwards compatible Probably even more important than for components
    • Eberhard Wolff - @ewolff NoSQL •  Schema changes much easier •  Can support different schemas in parallel •  Still need to convert data •  Same rules for compatibility apply
    • 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 start of new partner
    • Eberhard Wolff - @ewolff Feature Toggle •  Implement the feature •  Can be activated by feature toggle •  i.e. part of the configuration
    • 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
    • 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 disable feature •  One toggle per feature •  Resilience
    • 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 •  #registrations •  etc •  Feed into monitoring / metrics
    • 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 For Failure •  #5a Keep database schema stable •  #5b Databases = Component •  #6 Feature Toggle •  #7 Monitoring
    • Eberhard Wolff - @ewolff Thank You!