DevOps Beyond the Buzzwords: What it Means to Embrace the DevOps Lifestyle

DevOps Beyond the Buzzwords
What it Means to Embrace the DevOps Lifestyle
Mark Heckler
Principal Technologist & Developer Advocate
Pivotal Software, Inc.
www.thehecklers.org
@MkHeck

@MkHeck
Agenda
• What is this “DevOps” of which you speak?
• History/Real Life/Perspective
• Why change?
• Digging into DevOps
• Walkthrough
• Summary

@MkHeck
What IS It?
Simply stated:
• Development (Dev)
• Operations (Ops)
• Dev + Ops == DevOps

@MkHeck
Traditional Relationship

@MkHeck
Historically Opposed Due to Conﬂicting Objectives
• Developers’ sole reason for being: drive change
• Better support organization’s objectives
• Hopefully increasing funds available to organization in the process
• Market/ﬁeld isn’t immutable; failure to adapt is death

@MkHeck
Historically Opposed Due to Conﬂicting Objectives
• Operations’ primary objective: maintain expected level of service
• Risk/reward balance inverse of developers
• Change is a very real threat to an ops organization…and THE
organization (yet so is lack of change…)
• “Don’t touch” policies can be implemented in many ways
(security, risk assessments, etc.)

@MkHeck
Why Mess With It?
• “If it ain’t broke, don’t ﬁx it.”
• But it IS broken…
• Time == Money
• At Stake: SURVIVAL

@MkHeck
–W. Edwards Deming
“It is not necessary to change. Survival is not mandatory.”

@MkHeck
–Steve Jobs (1995)
“Software is inﬁltrating everything we do these days. In
businesses, software is one of the most potent competitive
weapons.”
–Marc Andreessen (2011)
“Software is eating the world.”
–Jeff Immelt, GE (2015)
“…every industrial company has to be a software and analytics
company.”

@MkHeck
“Silicon Valley is coming. There are hundreds of startups with a lot
of brains and money working on various alternatives to traditional
banking…
We are going to work hard to make our services as seamless and
competitive as theirs.”
–Jamie Dimon, CEO of JP Morgan Chase & Co, 2015 letter to shareholders

@MkHeck
Bring Developers and Operations Together
• Shared Objectives
• Shared Pain
• Shared Reward

@MkHeck
“Any organization that designs a system (deﬁned broadly)
will produce a design whose structure is a copy of the
organization’s communication structure.”
–Mel Conway, 1968

@MkHeck
–Werner Vogels, Amazon (2006)
“Giving developers operational responsibilities has greatly enhanced the
quality of the services, both from a customer and a technology point of view.
The traditional model is that you take your software to the wall that separates
development and operations, and throw it over and then forget about it. Not at
Amazon. You build it, you run it. This brings developers into contact with the
day-to-day operation of their software. It also brings them into day-to-day
contact with the customer. This customer feedback loop is essential for
improving the quality of the service.”

@MkHeck
Scenario: NEW SYSTEM! (Old Approach)
• New initiative launched by leadership
• Systems support required
• (wait for it…)

@MkHeck
• Architects begin analyzing, discussing, designing initial architectures of
system
• Software, including integration points (interfaces, protocols, etc.)
• Hardware, including location, physical footprint, bandwidth, power
• Capacity planning, redundancies required (hw & sw) to achieve
availability goals
• This can take weeks…but it usually takes months
• (hold on, we’ll get there!)

@MkHeck
• Hardware is spec’ed, bids obtained, purchase orders issued…wait
• Ops builds systems, installs, tests, gets security authorization…wait
• ETC ETC ETC
• Every day/week/month of delay risks losing ﬁrst-mover advantage,
market share, money (revenue/proﬁt or grants, etc.) - and could
make all the difference

@MkHeck
Why DevOps?
• Agility

@MkHeck
Why DevOps?
• Accuracy

@MkHeck
Culture
• Trust
• No change occurs unless experimentation allowed encouraged
• This underscores and permeates everything else!

@MkHeck
Sometimes when people see gourmet food and ping pong tables,
they only see the most superﬁcial aspects.
They wonder out loud if people won’t abuse the opportunity.
If people can’t be trusted with food and ping pong, what
makes you think they can be trusted with delivering the future
of a company?

@MkHeck
–Andrew Clay Shafer
“If you don’t experiment before you put things into production,
production is always an experiment.”

@MkHeck
Automation
• Continuous Integration
• Automated Builds, Unit & Integration Tests
• Continuous Delivery
• Additional Tests (e.g. functional, load, UAT in prod-equivalent environment)
• Deployment Automation
• Infrastructure as Code
• Tool Support

@MkHeck
–Noah Sussman, Etsy
“If pushing is easy enough, then pushing a ﬁx will be too.”
“Instead of fearing change, we get people used to it. The risks
change, but we take steps to address the risks. It’s a different way
of developing software.”

@MkHeck
Automation Tool Support
• Pipeline
• Jenkins, Travis, TeamCity, Spinnaker, etc.
• Scriptability (repeatable, automated platform/environment builds)
• Puppet, Chef, Ansible
• Dockerﬁles, Cloud Foundry buildpacks
• scripts, any other “platform code”

@MkHeck
Lean
• Incremental development, “nuggets of value”
• Nuggets == small releases
• Small releases facilitate frequent releases

@MkHeck
Lean/Microservices
Loosely coupled service oriented
architecture with bounded contexts
If every service has to be updated in
concert, it’s not loosely coupled!
If you have to know about surrounding
services you don’t have a bounded
context.

@MkHeck
Measurement
• Continual monitoring & measuring for rapid identification of issues
• Tool Support
• Spring Boot Actuator & others covering various aspects
• Netflix Servo, Java Simon, Dropwizard Metrics, etc.
• Compressed develop/test/release & find/fix/test/release loops

@MkHeck
–Ed Keyes, Google
“[s]ufﬁciently advanced monitoring is indistinguishable from
testing.”

@MkHeck
Measurement: The Basics
• Deployment/Change Frequency
• Change Lead Time
• Change Failure Rate
• Mean Time To Recover

@MkHeck
Measurement: A Few More Essentials
• Number & Frequency of Software Releases*
• Volume of Defects
• Time/Cost per Release**
• Mean Time To Recover*
• Number & Frequency of Outages/Performance Issues**
• Revenue/Proﬁt Impact of Outages/Performance Issues
• Number & Cost of Resources
* Addressed previously
** Partially addressed

@MkHeck
Sharing
• Like Culture, this permeates everything else
• Without open collaboration and communication, none of the rest
really happens

@MkHeck
–Noah Sussman, Etsy
“It’s one thing to move fast and take risks. But you’ve got to follow
through and make sure things work out.”

@MkHeck
An Example of an Enabling Platform: Cloud Foundry
One consistent API
• On-premises
• Public cloud
• Any provider

@MkHeck
Other Helpful Components

@MkHeck
Summary
• What is DevOps?
• What is DevOps NOT?
• Not NoOps
• Not (just) about tools - although the right tools are essential
• Not (just) about culture - although it’s an absolute requirement
• Not SSDDR (Same Stuff, Different Day, Relabeled)
• Why DevOps?

@MkHeck
–Derek Sivers, founder of CD Baby
“The most brilliant idea, with no execution, is worth $20.”

@MkHeck
Let’s Keep the Conversation Going!
• www.thehecklers.org
• @MkHeck on Twitter
• Stay in touch, exchange thoughts, and SHARE!
• Thank you for participating

DevOps Beyond the Buzzwords: What it Means to Embrace the DevOps Lifestyle

More Related Content

What's hot

Viewers also liked

Similar to DevOps Beyond the Buzzwords: What it Means to Embrace the DevOps Lifestyle

More from Mark Heckler

Recently uploaded

DevOps Beyond the Buzzwords: What it Means to Embrace the DevOps Lifestyle