The DevOps Revolution And Beyond

Agile, Innovation & Beyond!

The DevOps RevolutionAnd Beyond…


Chris SterlingFriday, 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 DEBThttp://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

https://hbr.org/1986/01/the-new-new-product-development-game


EMPIRICAL PROCESS CONTROL

INSPECTION

ADAPTATION

VISIBILITYAny 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

StoryofmeetingwithTunde,anauthorofbookabove,atDupontfromKenSchwaberhttps://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 PROJECTGene 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 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

CONFLICT

Time to Market Code Quality Features

CONCERNS

Efficiency Uptime Consistency

CONCERNS


Project Management Programming Quality Assurance Requirements Analysis Build Automation Architecture Script Automation Production Support Monitoring/Alerting Configuration Management 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 Requirements Analysis Build Automation Architecture Script Automation Production Support Monitoring/Alerting Configuration Management 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 DELIVERYhttp://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

SatelliteUIApproach

APIRouting

Service1

Authorization

Data

Service4

Authorization

Data

Service3

Authorization

Data

Service2

Authorization

Data

IdentityManagement

MessagingPlatform


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








ROUTING

INITIAL VERSION (1.0)

UPDATED VERSION (1.1)








ROUTING




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

Technology

The DevOps Revolution And Beyond