Post on 10-May-2015
description
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!