Conversational DevOps By Don Jones © 2016 Conversational Geek Conversational DevOps Published by Conversational Geek Inc. www.conversationalgeek.com All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein. Trademarks Conversational Geek, the Conversational Geek logo and J. the Geek are trademarks of Conversational Geek™. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. We cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or programs accompanying it. Additional Information For general information on our other products and services, or how to create a custom Conversational Geek book for your business or organization, please visit our website at ConversationalGeek.com Publisher Acknowledgments All of the folks responsible for the creation of this guide: Author: Don Jones Project Editor: J. Peter Bruzzese Copy Editor: John Rugh Content Reviewer(s): Karla Reina Note from the Author It’s surprising how long this “DevOps” thing has been lurking around the back alleys of the IT world, because only recently have vendors’ marketing folks gotten hold of it and made it a thing. But marketing hoopla aside, it’s a real thing, and it’s actually pretty cool. As a founder of The DevOps Collective (DevOpsCollective.org), a US-based 501(c)(3) educational nonprofit, I’ve made it kind of a personal mission to de-myth-ize and clarify what DevOps really is, and how you can really “do” it. Thanks to Conversational Geek for giving me this opportunity to further that mission! Don Jones The “Conversational” Method We have two objectives when we create a “Conversational” book: First, to make sure it’s written in a conversational tone so that it’s fun and easy to read. Second, to make sure you, the reader, can immediately take what you read and include it into your own conversations (personal or business-focused) with confidence. These books are meant to increase your understanding of the subject. Terminology, conceptual ideas, trends in the market, and even fringe subject matter are brought together to ensure you can engage your customer, team, co-worker, friend and even the know-it-all Best Buy geek on a level playing field. “Geek in the Mirror” Boxes We infuse humor into our books through both cartoons and light banter from the author. When you see one of these boxes it’s the author stepping outside the dialog to speak directly to you. It might be an anecdote, it might be a personal experience or gut reaction and analysis, it might just be a sarcastic quip, but these “geek in the mirror” boxes are not to be skipped. Within these boxes I can share just about anything on the subject at hand. Read ’em! Is This a Real Thing? Yes, DevOps is a real thing. Thanks for reading! Yeah, you probably need a bit more than that. Okay. DevOps has its origin in the world of Agile software development. To criminally oversimplify it, Agile is all about continuously producing small, incremental releases for your applications or other code. Rather than working and working and working, and then releasing some major version every other year or more, you put in a tiny amount of work in a “sprint,” and then release that into the world. The idea is that these short sprints make it easier to adjust to changing market conditions, evolving business needs, and so on. They also make it easier to squash bugs quickly. In theory, because each release changes just a tiny bit from the last one, bugs become easier to identify, because they stand out more. It’s a great theory, but developers aren’t the only players in this game. Once they finish their code, Operations usually has to physically deploy that code – and Operations hasn’t, traditionally, been willing to keep up with the Agile release cadence. “Produce all the code you want, Developers, but we’re on a strict schedule over here, and we can’t deploy more often than about once a year.” This kind of bummed everyone out, and so – to make a very long story very, very short – DevOps was invented. The Phoenix Project, a book by Kevin Behr, George Spafford, and Gene Kim is considered one of the seminal illustrations of what DevOps looks like from end to end. DevOps, the Short Version If you’re not going to have time to read more than this one tiny chapter (of an already short book), then you simply need to know that DevOps is about making Dev and Ops work more smoothly together. It’s about making Ops just as agile as Dev. It’s about everyone working more closely together to achieve the overall goal of getting software and services in front of users more quickly, more efficiently, and more effectively. There are a lot of things that go into making that happen. Automation, for example, is a big piece of the puzzle in terms of bringing DevOps to life, but automation itself is not DevOps. You can end up building or buying a lot of tools to make implementing DevOps easier, but tools themselves are not DevOps. DevOps is, more than anything, an IT management approach that prioritizes a rapid release cadence for software and IT services. In fact, it can sometimes prioritize “rapid” higher than “bug free,” as we’ll discuss in a bit. DevOps as a Culture “Doing” DevOps is really hard for a lot of organizations. Really, really hard. Sometimes impossible. And it’s important to understand that you can’t do DevOps halfway – it’s the whole philosophy or bust. That means it just won’t work for some organizations, because they won’t be able to shift their culture. For example, organizations that really nail DevOps often have unusual looking IT teams. Rather than a Dev team and an Ops team, they might have teams dedicated to specific applications. Each team might have developers, Operations people, and whoever else is needed to make that project succeed. The same Operations people might belong to multiple application teams, lending their expertise to the team to make sure the applications can be deployed and managed efficiently. All the Operations people from all the teams might form a “guild,” meeting occasionally to discuss what’s happening companywide, keeping everyone on track and sharing successes and hurdles from across the different teams. Not every organization can bend and reorganize themselves that way. It’s probably important to figure out, up front, if your organization can do this or not. Maybe you can pull it off for one kind of project to start with, and see where it goes from there. Or maybe you have operational, political, or cultural constraints that just make DevOps the wrong approach for you. That’s okay – it’s just important to recognize that up front. I usually suggest getting management – from the executive level – to buy off on trying DevOps. If they don’t, it’s usually impossible to get things rolling. By the Numbers Puppet Labs, one of the bigger players in the DevOps tooling space, issued a “2015 State of DevOps Report.” It contained a whole bunch of fun numbers they’d gleaned from their customers and from surveying the general audience – and these numbers paint a compelling story: Organizations employing DevOps approaches enjoyed 60 times fewer failures in their environment. When failures did occur, the agile nature of DevOps enabled 168x faster recoveries. That’s like going from a day of downtime to eight minutes of downtime. Using the DevOps approach enabled 30x more application deployments, meaning the business was able to respond more agile-y to changing conditions, and to address bugs quicker. The lead time for deploying an application was 200x shorter. That’s like going from a month of prep time to under four hours. Yeah. Jaw-dropping numbers. Check out the whole report at https://puppetlabs.com/2015-devops-report (registration required). The Big Takeaways DevOps is an approach to IT management that prioritizes rapid releases for software and services. It requires deep cooperation from the entire technology team, and often involves re-organizing that team into project-centric, cross- discipline units. DevOps can involve tools and techniques, like automation, but is itself more than just tools and techniques. A DevOpsian Example What might DevOps actually look like in a for-real-real environment? Well, let’s take an example that supposes a Microsoft-centric organization. I’m only doing that so I can put some real, concrete names to things, rather than being all vague and wishy-washy. In fact, DevOps is bigger outside the Microsoft space, right now, than in it, although it’s making big inroads.