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

•  Architecture

•  7 Rules

DevOps Development + Operations

=DevOps

Organizational change

No more silos

•  Architecture

•  7 Rules

•  Architecture

•  7 Rules

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

•  7 Rules

•  Architecture

•  7 Rules

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

•  Architecture

•  7 Rules

•  Architecture

•  7 Rules

Example

Warehouse Customer

Functional decomposition Technology independent

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

Warehouse Customer

Database

Warehouse Customer

Database

Commit Stage

Testing

Manual Explorative

Testing

Release Order

Warehouse Customer

Database

Build Pipeline •  Just one component changed!

•  Lots of unneeded work

•  Takes much too long

Warehouse Customer

Database

Call Center Payment Provider

No retesting for new versions

Warehouse Customer

Database

Libraries e.g. jar, dll Method calls

One deployment unit

Warehouse Customer

Database

Services Service calls Three

deployment units

Components = Services •  Independent deployment

•  REST/JSON •  ProtoBuf •  MessageBus

•  Micro Services: even smaller?

Warehouse Customer

Database

Commit Stage

Testing

Manual Explorative

Testing

Release Order

Release •  Just a single component

•  Much easier to do Blue/Green •  or Canary Releases

•  Rollback of single service also easier

Other Benefits •  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

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

Warehouse Customer

Database

Bug Fix Warehouse must be deployed again

Problems •  Warehouse stores current state in

•  Information lost during update

Stateless

Stateless •  Keep components stateless

•  Might store state in database etc.

#3 Stateless Easier to update

State e.g. in database

Warehouse Customer

Database

Component failure Domino effect

Component Interfaces •  Design for Failure •  I.e. do not fail if other component

•  Default values •  Simpler algorithm •  Graceful Degradation

Architecture deals with

Failure

Resilience

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

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

Warehouse Customer

Database

Database must support different data structures

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

Dealing withDatabase 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

Technology

Continuous Delivery + DevOps = Awesome

Agile, Continuous Delivery & DevOps in perspectief

Continuous Delivery and DevOps at Rabobank

Analyst Keynote: Continuous Delivery: Making DevOps Awesome

Making DevOps and continuous delivery a reality

How to choose tools for DevOps and Continuous Delivery - DevOps Cardiff

The DevOps Journey from waterfall to Continuous Delivery · PDF fileTHE DEVOPS JOURNEY: FROM WATERFALL TO CONTINUOUS DELIVERY Implementing an agile, DevOps-centered workflow involves

Zero downtime release through DevOps Continuous Delivery

Continuous Delivery & DevOps in the Enterprise

How to choose tools for DevOps and Continuous Delivery - DevOps Manchester meetup

DevOps Roadshow - continuous delivery and release management

DevOps - Continuous Delivery Program Guide - ca.com

Practicing Continuous Integration and Continuous Delivery ... · Practicing Continuous Integration and Continuous Delivery on AWS Accelerating Software Delivery with DevOps June 2017

Continuous Delivery: Making DevOps Awesome

Continuous Delivery - DevOps · Continuous Delivery Jez Humble, ThoughtWorks Studios @jezhumble #continuousdelivery DevOpsDays, Hamburg

[DevOps Summit]Importância de testes automatizados para sustentar Continuous Delivery & DevOps

Continuous Delivery & DevOps - Datalogforeningen · Continuous Delivery & DevOps experts and evangelists Tools & Automation experts. We help customers with practical implementation

Blockchain in DevOps - assets.ey.com · Blockchain in DevOps Implementing transparent continuous delivery | 3 Auditable Bimodal DevOps delivery Transition from “waterfall” to

DevOps and Continuous Delivery with CloudFoundry

DevOps Campus Overview eBook FINAL - ITSM Academy Campus Overview e… · CONTINUOUS DELIVERY DEvops TEST ENGINEER- ARCHITECT DEVSEcops ENGINEER- CONTINUOUS DELIVERY ARCHITECTM DevOps