The DevOps Revolution And Beyond...

Agile, Innovation & Beyond!
The DevOps Revolution 
And Beyond…
Chris Sterling
Friday, March 25, 2016

• Global Director of DevOps and Cloud Practices at Luxoft (www.luxoft.com), a
10,000+ person, $2B global technology solution provider with approximately
200 employees in the Pacific Northwest.
• 20+ years of software development and industry experience.
• Author of book “Managing Software Debt: Building for Inevitable Change”.
• Supported change efforts to adopt Lean, Agile, DevOps & Continuous
Delivery behaviors in organization with up to 800+ people.
• Entrepreneur & Lean Startup Practitioner.
• Former Certified Scrum Trainer for 8 years.
CHRIS STERLING
@csterwa linkedin.com/in/chrissterling
Global Director, DevOps & Cloud Practices
MANAGING SOFTWARE DEBT
http://www.managingsoftwaredebt.com

• Where we’ve come from
• Origin of DevOps movement
• Organizational design changes
• New architecture and technical capability needs
• What does this mean for Project, Program & Portfolio Management
WHAT ARE WE GOING TO TALK ABOUT?

THE NEW NEW PRODUCT DEVELOPMENT GAME 
• Built-in Instability
• Self-organizing Project Teams
• Overlapping Development
Phases
https://hbr.org/1986/01/the-new-new-product-development-game
• Multilearning
• Subtle Control
• Organizational Transfer of Learning
TAKEUCHI & NONAKA

EMPIRICAL PROCESS CONTROL
INSPECTION
ADAPTATION
VISIBILITY
Any aspects of the process that affect the
outcome must be visible and known to everybody
involved in the project process.
Various aspects of the process be inspected
frequently enough so that unacceptable
variances in the process can be detected
Adjust the process if one or more aspects of the
process are in an unacceptable range
PROCESS DYNAMICS,
MODELING, AND CONTROL
OGUNNAIKE & RAY
Story of meeting with Tunde, an author of book above, at Dupont from Ken Schwaber
https://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

EXTREME PROGRAMMING
IMAGE VIA RON JEFFRIES
http://ronjeffries.com/xprog/what-is-extreme-programming/

Yes, and there are still plenty of problems to solve…
Why are we running
2 week iterations if
we want to deploy
daily?
We still have to wait
for Operations to
provision and deploy
software and it takes
longer than we’d
like.
We don’t own or
update the
infrastructure that our
apps run on so we
can’t guarantee that
we can recreate the
environment.
Those “agile” teams
keep launching new
app versions and
don’t understand
what a risk that is to
our infrastructure.
Release processes
are still mostly
manual and it is
common to have
errors after
deployment to
production.
HAS AGILE SOFTWARE DEVELOPMENT MOVED US FORWARD?

http://velocityconf.com/velocity2009/public/schedule/detail/7641
ORIGINS OF THE DEVOPS MOVEMENT
http://www.slideshare.net/littleidea/agile-infrastructure-agile-2009
http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/

DEVOPS MEMES

THE THREE WAYS
2. AMPLIFY FEEDBACK LOOPS
3. CONTINUOUS EXPERIMENTATION & LEARNING
1. FLOW & SYSTEMS THINKING
GENE KIM
THE PHOENIX PROJECT
Gene Kim, Kevin Behr, George Spefford
http://itrevolution.com/the-three-ways-principles-underpinning-devops/

CASE STUDY: WEB PROPERTY
• 180+ person “Web 2.0” product organization
• Existing Waterfall SDLC focused on 6 month release cycles
• Delivery taking longer than 6 months in most cases
• Quality issues increasing in production
• Goal: Be more responsive to users & competitive threats
• Transitioned delivery in 3 months to incorporate release management and QA
into Feature Teams
• After 4 months able to release into production every week
• Used Continuous Delivery pipeline to validate product changes daily

DEVOPS CULTURE
http://martinfowler.com/bliki/DevOpsCulture.html
Article by Rouan Wilsenach @rouanw
• Increased collaboration across broader
organizational roles
• Goes beyond requirements analysis,
testing & development
• DevOps adds release engineering,
production monitoring & configuration
management (at least) in a shared
responsibility team
• Self-organizing teams: autonomous,
cross-functional & self-transcendent

• 700+ person organization
• Millions of line of code + hundreds of unique apps & services
• Continuous Integration server involved thousands of jobs & 1M+ builds
per year
• 9-18 month overlapping release cycles
• Found opportunity to not branch in SCM for each overlapping release
• After 2 year transition to Continuous Delivery pipelines and deployment
automation, Ads Platform can released to 20+ data centers globally
every day
• After 4 years, all teams across entire company can release to production
with no human intervention for 100% of deployments
CASE STUDY: ADS PLATFORM

Project Management
Programming
Quality Assurance
Prioritization
Requirements Analysis
Build Automation
Architecture
HANDOFF
DEV TEAM CAPABILITIES
OPS TEAM CAPABILITIES
Configuration Management
Project Management
Monitoring/Alerting
Production Support
Script Automation
ORGANIZATIONAL SILOS
SEPARATE DEVELOPMENT AND OPERATIONS ORGANIZATIONAL MODEL
DEV TEAM DEV TEAM DEV TEAM DEV TEAM
PRODUCTION
OPS TEAM

Project Management
Programming
Quality Assurance
Prioritization
Build Automation
Architecture
HANDOFF
DEV TEAM CAPABILITIES
OPS TEAM CAPABILITIES
Project Management
Monitoring/Alerting
Production Support
Script Automation
ORGANIZATIONAL SILOS
SEPARATE DEVELOPMENT AND OPERATIONS ORGANIZATIONAL MODEL
DEV TEAM DEV TEAM DEV TEAM DEV TEAM
PRODUCTION
OPS TEAM
CONFLICT
Time to Market
Code Quality
Features
CONCERNS
Efficiency
Uptime
Consistency
CONCERNS

Project Management
Programming
Quality Assurance
Build Automation
Architecture
Script Automation
Production Support
Monitoring/Alerting
Prioritization
FEATURE TEAM CAPABILITIES
AUTONOMOUS TEAMS
FEATURE TEAM ORGANIZATIONAL MODEL
Time to Market
Code Quality
Features
Efficiency
Uptime
Consistency
Shared Responsibility
CONCERNSFEATURE TEAM FEATURE TEAM
FEATURE TEAM FEATURE TEAM
CONTINUOUS DELIVERY
PLATFORM
PRODUCTION

Project Management
Programming
Quality Assurance
Build Automation
Architecture
Script Automation
Production Support
Monitoring/Alerting
Prioritization
FEATURE TEAM CAPABILITIES
AUTONOMOUS TEAMS
FEATURE TEAM ORGANIZATIONAL MODEL
Time to Market
Code Quality
Features
Efficiency
Uptime
Consistency
Shared Responsibility
CONCERNSFEATURE TEAM FEATURE TEAM
FEATURE TEAM FEATURE TEAM
CONTINUOUS DELIVERY
PLATFORM
PRODUCTION
This is not easy! New technical capabilities
are needed to work in this manner.!

DEVOPS TECHNICAL VALUES
AUTOMATED
PROGRAMMABLE
SELF SERVICE
Credit goes to Jared Wray, James Newkirk, Gavin McMurdo
and Richard Seroter from my time at CenturyLink Cloud. Thanks!

INFRASTRUCTURE AUTOMATION

INFRASTRUCTURE AUTOMATION
ALWAYS CHECK-IN TO SOURCE CONTROL
TREAT INFRASTRUCTURE AS CODE

8 Principles of Software Delivery
• Create a repeatable, reliable process for releasing software
• Automate (almost) everything
• Keep everything in version control
• If it hurts, do it more frequently, and bring the pain forward
• Build quality in
• Done means released
• Everybody is responsible for the delivery process
• Continuous improvement
CONTINUOUS DELIVERY
http://continuousdelivery.com
JEZ HUMBLE, DAVID FARLEY
CONTINUOUS DELIVERY

MONITORING

What does this mean for…
• Project Management?
• Program Management?
• Portfolio Management?
• Budgeting?
• Organizational design?
Q&A

NEXT… 
GOING ‘CLOUD NATIVE’ 
Going Beyond DevOps & Continuous Delivery…
Towards Microservices, Containers & Platforms
NEXT…GOING ‘CLOUD NATIVE’

Microservices
Satellite UI Approach
API Routing
Service 1
Authorization
Data
Service 4
Authorization
Data
Service 3
Authorization
Data
Service 2
Authorization
Data
Identity Management
Messaging Platform

• Push initial application as live route
(Blue)
• Update application and push with
temporary route (Green)
• Map main route to updated (Green)
application
• Unmap main route from initial (Blue)
application
• Remove temporary route from
(Green) application
BLUE/GREEN DEPLOYMENTS FOR ZERO PLANNED DOWNTIME
ROUTING
INITIAL VERSION
(1.0)

(Blue)
application
application
(Green) application
ROUTING
INITIAL VERSION
(1.0)
UPDATED VERSION
(1.1)

(Blue)
application
application
(Green) application
ROUTING
UPDATED VERSION
(1.1)
UPDATED VERSION
(1.1)

An approach to safely deploy new versions
of software to production and testing its
behavior before committing to full rollout.
• Deploy updated version “Canary”
• Divert some traffic towards “Canary”
either direct or replicated
• Replace previous version with “Canary”
if behaving as expected
CANARY DEPLOYMENT

FEATURE TOGGLES
• Problem: Need to deploy with some
features that are not sufficient or
validated with customers
• Introduce feature behind toggle:
– ON: Show to authorized users
– OFF: Don’t show to users

DEPLOY TO A PLATFORM

The DevOps Revolution And Beyond...

More Related Content

What's hot

Similar to The DevOps Revolution And Beyond...

More from Chris Sterling

Recently uploaded

The DevOps Revolution And Beyond...