software architecture for devops and continuous delivery
DESCRIPTION
Talks from Continuous Lifecycle 2013 in Germany about the influence of DevOps and Continuous Delivery on Software Architecture,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
Release Order
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 withDatabase 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 withDatabase 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!