DevOpsAn Introduction

Robert SellIT Operations ManagerAeroInfo – Boeing Canada

@robertesell

https://ca.linkedin.com/in/robertsell

AgendaDefinitionComparisonPopularityHistoryDifferenceNext StepsThe SecretReferences

Definition

DevOps DefinedA software development method that emphasizes communication, collaboration, integration, automation and cooperation between developers and operations.

This method acknowledges the interdependence of groups and aims to rapidly produce software products through improved operational performance.

Goals of DevOpsThe goals of a DevOps approach span the entire delivery pipeline and include:

• Improved deployment frequency• Lower failure rate of new releases• Shorten lead time between fixes• Maximize predictability, efficiency, security

(rugged) and maintainability

Other DefinitionsMany DevOps leaders refer to DevOps as a “revolution or movement.”

“DevOps is a culture or professional movement.”- Adam Jacob, CTO at Chef

“DevOps is more like a philosophical movement.”- Gene Kim, Founder of TripWire, CTO, Author

CALMS ModelCulture Changing the way we think nd behave in the

organization. Becoming one. Grassroots. Cooperation.

Automation Configuration items. Infrastructure as Code.Lean A focus on value and customer. Reducing

time spent on non-value activities.

Metrics Measure everything all the time. Show improvement.

Sharing Open sharing. Collaboration. Transparency.

My DefinitionI like the definition in the DevOps Cookbook:

We refer to “DevOps” as the outcome of applying Lean principles to the IT value stream.

Understand the goal (customer), common and shared KPIs to support that goal, mapped work steams then improve.

Allows repeatability, consistency and continual improvement.

DefinitionWhat DevOps is NOT:

DevOps is not a product. You can not buy DevOps.

DevOps is not a title or department.

DevOps isn’t compliance. There is no DevOps certification.

DevOps doesn’t just mean you mix Dev and Ops

Side EffectsNow we know what it is, what its goals are and what it is not.

It’s side effects may include:• Higher employee engagement• Improved productivity• Competitive advantage (includes hiring)• Happier customers

Comparison

StagesTraditional Software Delivery Life Cycle (SDLC) treat all stages equally and often spends too much time on risk mitigating activities that don’t create value.

DevOps focuses on software creation and customer feedback while continually seeking to reduce investment in other stages.

Release MethodsTraditional release methods are huge, costly, disruptive, complicated, time consuming, stressful, manual, rare and often don’t work well.

DevOps release methods focus on small, cheap, easy, automated, instant, frequent and perfect.

TeamsTraditional skill based silos benefit from economies of scale but don’t transfer work. “Thrown over the fence.”

DevOps is a dedicated cross functional team focused on one service or application. No handoffs and misunderstandings. Responsibility and ownership for the larger picture.

SchedulingTraditional software development needs to schedule resources across multiple projects. Ops and Dev hardly communicate let alone schedule. Last minute “urgent” requests are the norm.

DevOps allows collaboration and local team scheduling. Small batches and automated process make this much easier.

ExperienceTraditional software releases are terrible experiences full of issues, escalation and fire fighting. War rooms, pizza and all night fiascos.

DevOps turns software releases into non-events. Code is through daily (or more) code integration, automated testing, built in security, and environment synchronization.

FailureTraditionally there is a huge focus on risk aversion. To fail is a bad thing and often results in blame. The fear of failure and blame cause delays and cost.

DevOps are okay with failure. In fact, “fail early” is one of the mandates. Instead of investing in failure elimination, they choose when and how they will fail. Small, early and fast failure allow fast recovery and future prevention. Ie Chaos Monkey

KPIsTraditional measurements have been on uptime, cost and capacity. Unfortunately, organizations often ignore the fact that salary is a top cost and employee time is often spent on non-value work.

DevOps looks at the element of time in the work flow as an additional metric. This forces us to examine the flow of work from start to finish. Decrease areas of waste, increase productive time and focus on value areas.

ResponsibilitiesTraditionally we were all responsible for completing our incoming tasks so we could hand off to the next team.

DevOps changes the “I did my task” concept to “it is ready to deploy” with the introduction of cross functional teams.

AutomationTraditionally there has been a focus on manual task specialization. Unfortunately this often results in errors, bottlenecks and poor documentation.

DevOps automates as much as possible. Time doing routinized behaviors is freed up for creative and innovative tasks. Instead of outdated documentation we do commenting. We never follow documentation to create an environment!

ComparisonDevOps Culture Matrix

Engaged Employees

Popularity

Google TrendsStarted in 2010 and took off from there.

61 points in Jan 2015 and 100 in Sept 2015.

Compared to…

Compared to Star Wars

Compared to iPhone

Compared to ITIL

Compared to The Daily Show

IoT not as Popular“Internet of Things” isn’t even as popular as DevOps.

90 in Jan 2015 and 100 in Sept 2015

Not Just UnicornsUnicorns

Non-Unicorns

http://www.slideshare.net/fullscreen/danapylayeva/xp2015-devops-and-continuous-value-delivery-with-chocolate-and-lego-half-day-workshop/20

Gene Kim

Forecast“DevOps will shift from being a niche approach to application development and deployment

and move into the mainstream over the next 12 months or so.” – Gartner

“So appealing will this grassroots philosophy prove that it will be taken up by a quarter of Global 2000 organizations”

– Computer Weekly

Why so Popular?

Gene Kim

StatsFor people who like stats:

• Traditional Ops are 41% more time-consuming overall• Traditional Ops spends 21% more time putting out fires• DevOps spends 33% more time on infrastructure improvements• DevOps spends 60% less time handling support cases

After DevOps is implemented:• 63% experience improvement in quality of software deployments• 63% release new software more frequently• 55% notice improved cooperation and collaboration• 38% report a higher quality of code productionhttps://www.scriptrock.com/blog/devops-success-stats

History

OpsIT Operations grew up with BOFH (and enjoyed it)Our KPIs are for stability/uptime. Any change is a risk.Our role is to protect developers from themselves.Viewed by Dev as the Evil Empire

DevDevelopers are creative, happy and care free.If an environment breaks they simply put in a ticket. Can’t understand why Ops makes such a big deal.

Ops vs DevPoor release management, out of sync environments, different KPIs and cumbersome processes have caused many years of conflict.

Structure

TraditionalLet’s start with traditional Operations & Development

Chief Information Officer

PMO/BAs Dev DBAs Test InfoSec Release Infra Support

Head of Development Head of Operations

Silos

Empires

Communications

GrassrootsDevOps begins with anyone. Grassroots.

Chief Information Officer

Head of Development Head of Operations

PMO/BAs Dev DBAs Test InfoSec Release Infra SupportWant to

cooperate?

Oh ya!Coffee?

Product FocusSometimes Product Leads are created. Challenging.

Chief Information Officer

Head of Development Head of Operations

Product A Product B Product C Product D InfoSec Release Infra Support

Embedded OpsOps embedded into Dev teams for DevOps.

Chief Information Officer

Head of Development Head of Operations

Product A Product B Product C Product D InfoSec Release Infra Support

Operations doing DevOps

Want some DevOps?

Dedicated DevOpsSometimes dedicated DevOps team are created.

Chief Information Officer

Head of Development Head of Operations

Product A Product B Product C Product D InfoSec Release Infra Support

DevOps

Total DevOpsOne possible DevOps organizational structure:

Chief Information Officer

Management

Product A Product B Product C Product D Product E Product F Product G Product HI’m focused on Product

I’m practicing “Servant

Management”

I’m building leadership for

scalability

Next Steps

Cross FunctionalCreate cross functional teams with representatives from each of the functional areas of the software delivery process.

Map out the flow of work and look for efficiency opportunities. Reduce time for each step (especially non-value steps).

Share the responsibility for building, deploying and maintaining product. Mix Build and Run teams.

CommunicationsDevelop effective communications that promotes collaboration.

Remove blame from Post Mortems and Project Reviews. Fail fast and expect it.

Stop using email in attempt at collaboration.

Treat failure as opportunities. Failure creators own, publish and teach solutions. Continual improvement.

Share RiskCollaboration allows error checking and guidance. Same idea as ITIL CAB.

Quality, availability, reliability, scalability and security is everyone’s responsibility. Traditional InfoSec does not work because it is after the fact and left to IT to enforce. Must be baked in.

Devs responsible for Prod. No “throw over the wall.”

Align GoalsSilos/Empires only exist when leaders are allowed to have different goals.

Share goals and roll up.

Cross functional teams ensure shared goals.

Include Ops in planning throughout the software dev lifecycle.

InnovationWe must demand innovation otherwise it doesn’t occur. Continual improvement now applies to the individual. Training must now occur on a daily basis.

Time must be allocated to on the job training and idea exploration. KPIs to measure it.

Internal hack days, lunch & learns, mini conferences, awards for innovation, collaboration events, etc.

The Secret

The RevolutionI am bias. I see DevOps as a revolution.

Traditional organizations are very inefficient with layers of bureaucracy, silos, empires, red tape, politics and other non-value time wasters.

DevOps forces us to not only fix Dev vs Ops but also fixes the PMO, Quality, Security and others.

EngagementDevOps is employee engagement and is therefore scalable. Autonomous streams.

DevOps corrects the culture. Share. Trust. Learn. Own.

DevOps will revolutionize Operations (not just Dev). Infrastructure as Code is our next evolutionary step. Combined with monitoring and automation, it is scary cool.

Chang(ed)The world has changed. Traditional disciplines are dead, some people just don’t know that yet.

References

SourcesYouTube (full of good videos)Start here:• Docker and DevOps by Gene Kim• DevOps Demystified by Ben Rockwood

SlideSharehttp://www.slideshare.netLoads of good presentations

TrainingIn the name of the DevOps spirit, IT is sharing all our training:

S:\AeroInfo\Training Training materials include: GIT, Docker, etc.

Join my local DevOps MeetUp: http://www.meetup.com/DevOps-Vancouver-BC-Canada

TwitterJohn Allspaw -@allspaw

Jesse Robbins - @jesserobbines

Gene Kim - @realgenekim

Patrick DuBuis - @patrickdubois

Andrew Schafer - @littleidea

Jez Humble - @jezhumble

John Willis - @botchagalupe

Damon Edwards - @damonedwards

BooksThe Phoenix Project: This book by Gene Kim is used by everyone as the modern version of The Goal and is a good starting point for understanding DevOps and the problems it solves. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon

BooksContinuous Delivery: This book by Jez Humble is used by Boeing and is the default starting point for understanding Continuous Delivery. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon

BooksThe Goal:This book is used to better understand Operations Management and kaizen. It is normally part of an MBA program. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon

ReferencesReinventing Organizations: The way we manage organizations seems increasingly out of date. This book was created after 3 years of research and is a key book in DevOps when looking at organizational change.