DevOps Beyond the BuzzwordsWhat 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 Conflicting Objectives

• Developers’ sole reason for being: drive change

• Better support organization’s objectives

• Hopefully increasing funds available to organization in the process

• Market/field isn’t immutable; failure to adapt is death

@MkHeck

Historically Opposed Due to Conflicting 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 fix 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 infiltrating 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 (defined 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

Scenario: NEW SYSTEM! (Old Approach)

• 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

Scenario: NEW SYSTEM! (Old Approach)

• 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 first-mover advantage, market share, money (revenue/profit or grants, etc.) - and could make all the difference

Ok…but why DevOps?

@MkHeck

Why DevOps?

• Speed

@MkHeck

Why DevOps?

• Agility

@MkHeck

Why DevOps?

• Accuracy

@MkHeck

Keep CALMS and DevOps

@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 superficial 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 fix 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

• Dockerfiles, 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]ufficiently 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/Profit 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.”

Let’s Take a Walk(through)

@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