Software Architecture for DevOps and Continuous Delivery

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

DevOps
Development
+ Operations
=DevOps
Organizational change
No more silos

Continuous Delivery: 
Build Pipeline
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release

Continuous Delivery 
Needs Deployment
Automation
•  But it is not the same
•  Many test systems required
•  Automation less error prone

Continuous Delivery 
Releases
•  Blue / Green Deployments
•  New version on separate production
environment
•  Canary Releasing
•  Release to a few servers in the
cluster

Architecture: Wikipedia
Set of structures
needed to
reason about the software system
Comprises
software elements
relations between them
properties of both

Why Architecture?
•  System too large to understand
•  Understand components in
isolation
•  Understand how components
interact

Architecture & Non-
functional Requirements
•  Architecture defines technical
foundation
•  Technical foundation influences
•  Performance
•  Security
•  Scalability
•  Etc

Example
Order
Warehouse Customer
Functional decomposition
Technology independent

Order
Warehouse Customer
Database
Libraries
e.g. jar, dll Method calls
One deployment
unit

Architecture
Simple
High performance

Change
•  Modify order process slightly
•  Customer & Warehouse unchanged
Order
Warehouse Customer
Database

Order
Warehouse Customer
Database

Build Pipeline
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
Release
Order
Warehouse Customer
Database

Build Pipeline
•  Just one component changed!
•  Lots of unneeded work
•  Takes much too long

Order
Warehouse Customer
Database
Call Center
Payment
Provider
No retesting
for new
versions

Order
Warehouse Customer
Database
Services Service calls
Three
deployment
units

Components = Services
•  Independent deployment
•  REST/JSON
•  ProtoBuf
•  MessageBus
•  Micro Services: even smaller?

Build Pipeline
Commit
Stage
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Explorative
Testing
ReleaseOrder

Release
•  Just a single component
•  Much easier to do Blue/Green
•  or Canary Releases
•  Rollback of single service also easier

Other Beneﬁts
•  Might use different technologies per
component
•  For specific requirements
•  For specific developer skills

#1 Small Deployment Units
Less testing
Faster deployment
Less waste
Easier rollback

Change
•  Optimized algorithm for warehouses
•  Additional information must be
passed in from order

Order
Warehouse Customer
Database
Interface changes
Order must also be deployed

Problems
•  Order and Warehouse must be
deployed together
•  Hard to coordinate
•  More complex pipeline
•  Harder rollback

Solution
•  New warehouse version supports
old interface
•  Warehouse can be deployed first
•  …and then Order
•  Old interface must be phased out

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

#2 Interface Backwards
Compatibility
Faster deployment
Deploy components independently
Less waste

Order
Warehouse Customer
Database
Bug Fix
Warehouse must be deployed again

Problems
•  Warehouse stores current state in
RAM
•  Information lost during update

Stateless
•  Keep components stateless
•  Might store state in database etc.

#3 Stateless
Easier to update
State e.g. in database

Order
Warehouse Customer
Database
Component failure
Domino effect

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 & 
Small Deployment Units
•  Downtime during deployment
might be acceptable
•  More flexibility for deployments

Circuit Breaker
•  Do not call a broken system
•  Instead throw exception
•  Retry after some time
•  Protect broke system
•  Do not call it in vain

#4 Design for Failure
More stable
Better for Ops
Better for new releases

Change
•  SEPA
•  Additional customer information

Order
Warehouse Customer
Database
Column must be added to database

Database Changes Are Hard
•  Schema changes
•  Converting existing data
•  Potential lots of data
•  Hard or even impossible to rollback

1 - Keep database
schema stable
2 - Database = component

Keep Database Schema
Stable
•  Change database before
components use it
•  Change database seldom
•  i.e. schema changes not part of
deployment
•  No rollback

#5a Keep database schema
stable
No rollback
Less agile

Databases = Component
•  Support old “interface”
•  i.e. schema

Order
Warehouse Customer
Database
Database must support different data
structures
V42
V43

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

Dealing with 
Database Changes
•  Support previous version schema
•  Default value for new columns
•  Remove column only if not used
any more
•  Use views
•  …

#5b Databases =
Component
Need to be backwards compatible
Probably even more important than
for components

NoSQL
•  Schema changes much easier
•  Can support different schemas in
parallel
•  Still need to convert data
•  Same rules for compatibility apply

Change
•  Support for new logistic partner
•  Won’t start until next month

Feature Branch
•  Additional instance of the delivery
pipeline
•  Deployment must be synced to start
of new partner

Feature Toggle
•  Implement the feature
•  Can be activated by feature toggle
•  i.e. part of the configuration

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

Feature Toggle
•  Add another dimension to the
architecture
•  Must eventually be cleaned up

DevOps
•  Support for new logistics partner
crashes system
•  Feature toggle allows Ops to disable
feature
•  One toggle per feature
•  Resilience

#6 Feature Toggle
Decouple release / new features
Resilience: Provide fallback

After the Change
•  New logistics partner
•  Revenue declined
•  Some orders were lost

Business Monitoring
•  Provide metrics with business
meaning
•  i.e. revenue
•  #orders
•  #registrations
•  etc
•  Feed into monitoring / metrics

#7 Monitoring
Dev provides (business) metrics
Ops provides monitoring
infrastructure

•  #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

Thank You!

Software Architecture for DevOps and Continuous Delivery

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Software Architecture for DevOps and Continuous Delivery

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

More from Eberhard Wolff

More from Eberhard Wolff (20)

Recently uploaded

Recently uploaded (20)

Software Architecture for DevOps and Continuous Delivery