Upload
mark-heckler
View
478
Download
0
Embed Size (px)
Citation preview
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
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
–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
“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
@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
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.”
@MkHeck
An Example of an Enabling Platform: Cloud Foundry
One consistent API
• On-premises • Public cloud • Any provider
@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