The DevOps Adoption Playbook by Sanjeev Sharma


125966d8b655f32-261x361.jpg Author Sanjeev Sharma
Isbn 9781119308744
File size 8.13MB
Year 2017
Pages 416
Language English
File format PDF
Category software



 

The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT Enterprise Published by John Wiley & Sons, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2017 by John Wiley & Sons, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-1-119-30874-4 ISBN: 978-1-119-31052-5 (ebk) ISBN: 978-1-119-31076-1 (ebk) Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/ permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or website may provide or recommendations it may make. Further, readers should be aware that Internet websites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services please contact our Customer Care Department within the United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley .com. For more information about Wiley products, visit www.wiley.com. Library of Congress Control Number: 2016962068 Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. IBM, the IBM Press logo, UrbanCode, uDeploy, System z, Rational, IBM Watson, WebSphere, Bluemix, InfoSphere, Optim, PureApplication, DB2, SoftLayer, and Blue Box are trademarks or registered trademarks of International Business Machines Corporation in the United States and/or other countries. A current list of IBM trademarks is available on the web at “copyright and trademark information” as www.ibm.com/legal/copytrade.shtml. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book. To my wife Ritika, for always motivating me to do more, be more, and never be satisfied with the status quo. And my children, Saransh and Shreya, for being the ones I am motivated to do and be more for. About the Author Sanjeev Sharma is an internationally known DevOps and cloud transformation thought leader, technology executive, and published author. Sanjeev’s industry experience includes tenures as CTO and Worldwide Technical Sales Leader, Acquisition Integration Technical Leader, and IT Architect. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of the exclusive core of technical leaders at IBM. Sanjeev provides core leadership to drive the adoption of cutting-edge solutions, architectures, and strategies for DevOps and the cloud. His experience as the Global CTO for DevOps Technical Sales at IBM, combined with his deep insight and ability to understand both business and IT needs, drives a unique perspective for any business. This perspective allows Sanjeev to advise and mentor C-level and senior technical executives on achieving DevOps and cloud transformations, across industries and geographies. Sanjeev is a frequent speaker on the international tech scene, as a cloud and DevOps expert. He regularly publishes articles, blog posts, and videos for leading tech publications and his own blog, at http://bit.ly/sdarchitect. Sanjeev tweets as @sd_architect. About the Technical Editor Lee Reid has more than 30 years’ experience in software engineering, architecture, product development, technology innovation, and team leadership in both manufacturing and information technology domains. Lee is an engineering graduate of General Motors Institute (BME) and the University of Michigan (MSE) and holds four U.S. patents. He has recently transitioned into higher education, where he leads IT and is introducing Lean and DevOps practices at St. Norbert College. Credits Project Editor Adaobi Obi Tulton Business Manager Amy Knies Technical Editor Lee Reid Executive Editor Jim Minatel Production Editor Rebecca Anderson Project Coordinator, Cover Brent Savage Copy Editor Marylouise Wiack Proofreader Kim Wimpsett Production Manager Katie Wisor Indexer J&J Indexing Manager of Content Development & Assembly Mary Beth Wakefield Cover Designer Wiley Marketing Manager Lorna Mein Professional Technology & Strategy Director Barry Pruett Cover Image ©traffic_analyzer/Getty Images Acknowledgments This book is an effort to put to paper countless conversations and (sometimes heated) discussions and debates on DevOps and IT optimization and innovation that I have had with my customers, co-workers, and peers in the DevOps community. Through these conversations and discussions, dozens of people have contributed to this book, not to mention all those whose blogs, articles, books, webinars, videos, meetings, and presentations I learned from. The key contributors include my fellow DevOps subject matter experts and technology thought leaders at IBM. These include (in alphabetical order by first name): ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ Al Wagner Albert Ho Alex Abi Khaled Ana Lopez-Mancisidor Andy Moynahan Ann Marie Somerville Anshu Kak Anujay Bidla Ava Hakim Bala Rajaraman Bernie Coyne Bill Higgins Bob Bogan Brian Naylor Chris Lazzaro Chris Lucca C. J. Paul Claudette Hickey Cliff Utstein Dan Berg David Curbishley David Leigh ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ David Ziskind Dibbe Edwards Eric Minick Erik Anderson Greg Wunderle Hayden Lindsey Helen Dai Jagan Karuturi James Pierce Jeff Crume Jim Fieseler Jim Moffitt John Lanuti John Wiegand Kay Johnson Kedar Walimbe Kristof Kloeckner Kyle Brown Leigh Williamson Mahendra Pingale Maneesh Goyal Mark Borowski xii Acknowledgments ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ Mark Meinschein Mark Roberts Mark Tomlinson Meenagi Venkat Michael Elder Michael Samano Mike McNamee Mustafa Kapadia Paul Bahrs Paul Meharg Peter Eeles Peter Spung Randy Newell René Bostic Rick Weaver Rob Cuddy ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ Robbie Minshall Roger Snook Rosalind Radcliffe Sal Vella Saleem Padani Steve Abrams Steve Kagan Steven Boone Sudhakar Frederick Swati Moran Tony Doyle Tim Hahn Tim Pouyer Varban Vassilev Wendy Toh Some contributors who were formerly at IBM include the following: Alan Sanie Ashok Reddy ■■ Bowman Hall ■■ David Grimm ■■ David Myers Jan Svoboda Mike Lundblad ■■ Murray Cantor ■■ Steven Pogue ■■ Walker Royce ■■ ■■ ■■ ■■ Several key customers, business partners, and experts also contributed, as real-life examples of leaders who led DevOps transformations at their own companies and organizations. Their stories from the trenches are the best sources of lessons learned. In many cases, they were at the other end of the conversations that led to the lessons learned and practices documented in this book. Because I met most of these people in a professional capacity as an IBM employee, I cannot list them all here. I will list the few who also co-presented at conferences, meetings, and webinars with me, or co-authored articles or blogs with me. They include the following (along with their current employers): Alan Shimel, DevOps.com Antony Morris, Monitise ■■ Ben Chodroff, CloudOne ■■ ■■ Acknowledgments ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ xiii Brad Schick, Skytap Carmen DeArdo, Nationwide Insurance Chris Lepre, Wells Fargo Gareth Evans, Monitise James Governor, RedMonk Jayne Groll, DevOps Institute John Comas, NBCUniversal Media John Kosco, Blue Agility J. P. Morgenthal, CSC Mark Howell, Lloyds Banking Group Tapabrata “Topo” Pal, Capital One I would be remiss to not acknowledge separately Gene Kim, the überguru of DevOps, with his contributions through his books and his DevOps Enterprise Summit Conference. I personally had multiple opportunities to talk to him one-on-one, including a video interview I recorded in 2014 (https:// youtube/6QK2Mt-KPo4). I would also like to give a special thanks to Lee Reid. I have worked with Lee for more than a decade. He was also my “partner in crime,” leading the Worldwide DevOps architect team at IBM for two years. We developed the DevOps Value Stream Mapping workshop techniques together, and I personally bounced tons of ideas off of him. It was only fitting that I had the opportunity to leverage Lee’s talents and mind, despite his having left IBM for St. Norbert College, by having him be the technical editor of this book. There is no way the book would have made it to its final refined and well-structured form without Lee’s insights, critique, and feedback. Lastly, I would like to thank the wonderful editing staff at Wiley: Adaobi Obi Tulton, whose skills certainly live up to her Jedi-sounding name, and Marylouise Wiack for her complete mastery of language and prose (and yes, punctuation—my nemesis). The book is light-years ahead of what I originally put to paper because of their hard work and painstaking correction of my meek attempt to put words together into coherent sentences. Contents at a Glance Introduction ����������������������������������������������������������������������xxiii 1 DevOps: An Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Adopting DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3 Developing a Business Case for a DevOps Transformation. . . 67 4 DevOps Plays for Optimizing the Delivery Pipeline. . . . . . . . . 87 5 DevOps Plays for Driving Innovation. . . . . . . . . . . . . . . . . . 189 6 Scaling DevOps for the Enterprise. . . . . . . . . . . . . . . . . . . . 261 7 Leading DevOps Adoption in the Enterprise. . . . . . . . . . . .  307 Appendix  Case Study: Example DevOps Adoption Roadmap �������������������������������������������������������������������������� 331 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Contents Introduction ��������������������������������������������������������������������� xxiii 1 DevOps: An Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 DevOps: Origins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 DevOps: Roots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Addressing Dev versus Ops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 DevOps: Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Continuous Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Continuous Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Supporting Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Shift Left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Architecture and Risk Mitigation . . . . . . . . . . . . . . . . . . . . . . . . .31 Continuous Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Business Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 DevOps: Culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 2 Adopting DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Developing the Playbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Identifying the Target State (Business Goals and Drivers). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Assessing the Current State. . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 Choosing the Transformation Plays . . . . . . . . . . . . . . . . . . . . . . .60 Adopting the Transformation Plays . . . . . . . . . . . . . . . . . . . . . . .61 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 3 Developing a Business Case for a DevOps Transformation. . . 67 Developing The Business Case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Completing The Business Model Canvas . . . . . . . . . . . . . . . . . . . . . .71 xviii Contents Customer Segments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 Value Propositions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Customer Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Revenue Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Key Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Key Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Key Partnerships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 Cost Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Line of Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 IT Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 4 DevOps Plays for Optimizing the Delivery Pipeline. . . . . . . . . 87 DevOps as an Optimization Exercise. . . . . . . . . . . . . . . . . . . . . . . . . .88 Business Intent: Optimization versus Innovation. . . . . . . . . . . . . 89 Contents xix Core Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Minimizing Cycle Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Reducing Batch Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 Establishing the Right Culture . . . . . . . . . . . . . . . . . . . . . . . . . .102 The DevOps Plays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 Play: Establishing Metrics and KPIs . . . . . . . . . . . . . . . . . . . . . .106 Play: Agile Adoption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Play: Integrated Delivery Pipeline. . . . . . . . . . . . . . . . . . . . . . . . 117 Play: Continuous Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Play: Continuous Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Play: Shift Left—Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Play: Shift Left—Ops Engagement. . . . . . . . . . . . . . . . . . . . . . .149 Play: Continuous Monitoring and Feedback. . . . . . . . . . . . . . . . 155 Play: Release Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Specializing Core Plays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 Play: DevOps for Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 Play: DevOps for Mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Play: DevOps for Internet of Things. . . . . . . . . . . . . . . . . . . . . . 177 Play: DevOps for Big Data and Analytics . . . . . . . . . . . . . . . . . .180 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186 5 DevOps Plays for Driving Innovation. . . . . . . . . . . . . . . . . . 189 Optimize to Innovate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190 The Uber Syndrome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Innovation and the Role of Technology . . . . . . . . . . . . . . . . . . . . . . 192 Innovating for New Business Models. . . . . . . . . . . . . . . . . . . . . 193 Business Model Experimentation. . . . . . . . . . . . . . . . . . . . . . . .194 Innovating for New User Engagement Models. . . . . . . . . . . . . . 195 Core Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198 Achieving Multi-Speed IT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198 Building the Right Thing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202 Enabling Experimentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . .206 Delivering Antifragile Systems. . . . . . . . . . . . . . . . . . . . . . . . . .208 IT Systems and Antifragility. . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 xx Contents Play: Build a DevOps Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Application Delivery and Antifragile Systems. . . . . . . . . . . . . . . 218 Environment Abstraction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Cloud-Hosted DevOps Platform. . . . . . . . . . . . . . . . . . . . . . . . .221 Infrastructure as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 OpenStack Heat as an Abstraction Layer . . . . . . . . . . . . . . . . . .232 Platform as a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233 Containers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238 Play: Deliver Microservices Architectures . . . . . . . . . . . . . . . . . . . . . 241 Microservices Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 12-Factor App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245 Cloud Native. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Microservices and Containers . . . . . . . . . . . . . . . . . . . . . . . . . .249 Migrating to Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . .249 Play: Develop an API Economy. . . . . . . . . . . . . . . . . . . . . . . . . . . . .253 Deployment Automation and APIs. . . . . . . . . . . . . . . . . . . . . . .255 DevOps Platform and APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . .255 Play: Organizing for Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . .257 Developing an Innovation Culture in Large Organizations. . . . .259 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260 6 Scaling DevOps for the Enterprise. . . . . . . . . . . . . . . . . . . . 261 Core Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263 Organizational Culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263 Standardization of Tools and Practices. . . . . . . . . . . . . . . . . . . .264 Organized Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265 Breaking Down Organizational Silos. . . . . . . . . . . . . . . . . . . . . 266 Play: DevOps Center of Competency. . . . . . . . . . . . . . . . . . . . . . . .267 Capabilities and Goals of a DevOps CoC. . . . . . . . . . . . . . . . . .268 Core CoC Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 The DevOps Coach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270 Setting Up a CoC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272 Play: Developing Culture of Innovation at Scale. . . . . . . . . . . . . . . .273 The Offering Management Team. . . . . . . . . . . . . . . . . . . . . . . .276 Contents xxi Play: Developing a Culture of Continuous Improvement. . . . . . . . . .278 Developing an Adoption Roadmap . . . . . . . . . . . . . . . . . . . . . .280 Continuous Improvement and Value Stream Mapping. . . . . . . .282 Play: Team Models for DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . .284 Play: Standardization of Tools and Processes. . . . . . . . . . . . . . . . . . .287 Standardization of an Integrated DevOps Platform . . . . . . . . . .289 Play: Security Considerations for DevOps. . . . . . . . . . . . . . . . . . . . .291 Managing Security-Related Risks. . . . . . . . . . . . . . . . . . . . . . . .292 Addressing Security for DevOps Processes and Platforms. . . . . .295 The API Economy and Security. . . . . . . . . . . . . . . . . . . . . . . . . .299 Play: DevOps and Outsourcing. . . . . . . . . . . . . . . . . . . . . . . . . . . . .301 Strategic Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302 IT Supply Chain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303 Enabling DevOps with Outsourcing. . . . . . . . . . . . . . . . . . . . . .304 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304 7 Leading DevOps Adoption in the Enterprise. . . . . . . . . . . .  307 Play: DevOps as a Transformation Exercise. . . . . . . . . . . . . . . . . . . .309 Compelling Reasons to Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 DevOps Transformation Anti-patterns. . . . . . . . . . . . . . . . . . . . 312 Play: Developing a Culture of Collaboration and Trust . . . . . . . . . . . 315 Visibility Enables Trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 It’s All about the People. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Play: DevOps Thinking for the Line of Business. . . . . . . . . . . . . . . . . 318 Line of Business–IT Engagement . . . . . . . . . . . . . . . . . . . . . . . . 319 Engaging in the DevOps Transformation. . . . . . . . . . . . . . . . . .321 Move Shadow IT out of the Shadows. . . . . . . . . . . . . . . . . . . . .321 Play: Starting with Pilot Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . .322 Pilot Project Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324 Executive Sponsorship. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325 Play: Rearing Unicorns on an Aircraft Carrier . . . . . . . . . . . . . . . . . .325 Fostering Ideas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 xxii Contents Appendix  Case Study: Example DevOps Adoption Roadmap �������������������������������������������������������������������������� 331 Organization Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Roadmap Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 DevOps Optimization and Innovation Workshop. . . . . . . . . . . . 333 Background and Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334 Adoption Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336 Business Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336 Existing IT Initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Bottlenecks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338 Root Causes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340 DevOps Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341 Roadmap Adoption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Introduction What’s in Your Playbook? In April 2016, the Villanova Wildcats played the North Carolina Tar Heels in the 2016 NCAA Basketball National Championship Game. The game was the greatest ever, and it all came down to one last play, with just 4.7 seconds left on the clock. Joel Berry II hit a three-pointer to tie the game at 74 apiece, and Villanova Coach Jay Wright called his final timeout. In the NCAA, you have to go down the entire length of the court after a timeout. Immediately, Kris Jenkins of Villanova inbounded the ball to point guard Ryan Arcidiacono. Arcidiacono dribbled down the court past Berry, but it was the design of the play on both sides that made for the great ending. UNC played a 1-3-1 man-on-man press to Arcidiacono, to hopefully force a turnover, but if Arcidiacono got past Berry, they had Justin Jackson, Isaiah Hicks, and Brice Johnson, all who could stop the three-point shot. Villanova had designed a play to make sure that Arcidiacono got the ball off the inbound in a position in which he could get past half-court and find someone on the three-point line. Arcidiacono got past Berry, UNC collapsed, and Arcidiacono popped it back to Jenkins on the three-point line to get an almost-uncontested three-pointer to win the championship, and boy did it pay off. #Win! —By Saransh Sharma (Sharma, 2016) A Playbook for Adopting DevOps at Scale Teams that excel do so not just because they have the best members, the best tools, the best training, the best processes, or the best leaders and coaches. They excel because they, as a team, have all of the above but also know what to do when they face various situations and challenges. They have a playbook of potential solutions (plays) for a variety of scenarios. When faced with a unique situation or challenge, the players and coaches come together as a team to pick the right play from the playbook, and then, xxiv Introduction most importantly, they execute it. My alma mater, Villanova University, won the national championship when it came down to the final play, with seconds on the clock, because they had plays they had practiced before. They read the situation, picked the right play, and executed with precision to win. Had they not had the play that would catch North Carolina off guard, there may have been a different outcome. In the same way, IT organizations need plays to execute. For day-to-day application delivery and operations, these so-called plays are captured in their development, delivery, and operational processes. IT organizations that succeed have good processes and execute them with excellence. However, transforming IT organizations is another story. Most organizations struggle with transformations, not having well-defined, winning plays that can overcome cultural and organizational inertia. This book captures a set of proven, repeatable plays for adopting DevOps at the enterprise scale and for transforming a large, complex, distributed IT organization to adopt DevOps. These plays come from my experience over several years in the trenches as I helped dozens of organizations, of myriad sizes and maturity levels, in a variety of industries and geographical locations, to adopt DevOps. Since the early days of DevOps, as the Worldwide CTO of DevOps Technical Sales and Adoption at IBM, I have had a front-row seat to see the evolution and maturation of DevOps from a set of practices pioneered by startups to a cultural and technological transformation effort in large enterprises. I was a pioneer and thought leader for DevOps at IBM, and I became the face of DevOps to IBM’s clients. This book distills patterns of success that I have observed among hundreds of clients working, struggling, and succeeding at adopting DevOps at organization or enterprise-wide scale. Adopting DevOps in a small, co-located organization, without a lot of cultural memory, is not difficult. Even in large organizations, small teams— the proverbial two-pizza1 teams—regularly succeed at attaining the business results promised by DevOps. In most organizations, you see many such efforts made, and most succeed. It is taking that success from an individual, isolated team level and scaling it to an enterprise that is a challenge. It is like having a series of small dance squads around the organization. However, these dance squads are all unique; some are doing the salsa, some jazz, some are ballroom dancing, while yet others are doing something my daughter tells me 1 Amazon CEO Jeff Bezos claims that a team that cannot be fed with two pizzas is too big to be a productive team. Introduction xxv is “hip-hop.” They cannot combine and grow to a massive dance ensemble that can perform at the next halftime show, filling up the entire paying field of a football stadium. For that they need to be dancing not only to the same music but also be performing the same dance form, in unison. Similarly, small unique teams cannot impact the entire organization. These teams need to make the effort to standardize practices, processes, platforms, and tools in order to allow them to be replicated in other parts of the organization. The organization, in turn, needs to set the right environment for DevOps adoption by sponsoring transformation efforts, by enabling change to rigid legacy processes, and by a top-down push to overcome cultural inertia. NOTE A bottom-up practitioner-led effort allows extremely productive individual teams to adopt DevOps and thrive. A top-down executive leadership-led effort enables these individual successes to scale. The engagement of the business is imperative for these scaling efforts to succeed. IT organizations exist to deliver the capabilities a business needs in order to deliver business value to its customers. The business is asking the IT organization for optimization—to be more agile, to be resilient to change, to be more responsive, to do more with less, to be more productive, to increase throughput, to deliver faster, to deliver at higher quality, to be reactive to the market, to accelerate past the competition, to keep up with an ever-changing regulatory and compliance regime, and, yes, to reduce expenses. In addition, it may also be asking for innovation—to allow the company to enter new markets, to enable exponential growth, to engage and grow the customer base, to be responsive to customers’ needs, and, again, to reduce expenses. Delivering on these asks (hopefully not all of them at the same time) is what drives the need for change. It is what creates the motivation to work toward achieving the benefits that come from adopting DevOps. NOTE You do not just adopt DevOps because it is cool. You need to have a business reason. The need for agility or velocity is the number-one reason that DevOps exists. The maturing and wide adoption of DevOps over the last few years is a reflection of today’s dynamic marketplace, of customers’ expectations. Thus, in order for IT to undergo a transformation, this change has to improve and enhance IT’s ability to deliver business capabilities in a manner xxvi Introduction that, in turn, improves and enhances the business value delivered. Proper partnering between the business and IT is imperative so that the transformation IT undergoes by adopting DevOps delivers what the business needs the most by properly balancing optimization and innovation. Business goals have to drive why IT transforms, which will in turn drive how IT transforms. This book will categorize DevOps adoption plays as follows: DevOps for optimization DevOps for innovation ■■ Scaling DevOps adoption for the enterprise ■■ Driving DevOps transformation in the enterprise ■■ ■■ It will include lessons learned, examples, success patterns, and antipatterns for each adoption play. Like a sports playbook, this book is designed to deliver certain plays that can be executed for different scenarios and situations—depending upon your organization’s current maturity and state— when it comes to transforming to a high-performance application delivery organization by adopting DevOps. An organization will need to take those plays and execute them in a tactical manner, based on the projects and teams that are adopting DevOps. Just as no battle plan ever survived contact with the enemy, these plays will need to be executed with an action plan or a broader adoption roadmap designed for each organization. Furthermore, no organization is monolithic or homogenous in nature. Some parts of the organization may be more mature in some areas, but less mature in others. Some teams and groups may have already achieved agility and velocity, whereas others may be experiencing tremendous cultural inertia, all within the same organization, sometimes in the same building; they all need to work together in order to get scale. An organization may have an innovation lab that is using modern agile and DevOps practices, while core systems teams may still be delivering in a rigid waterfall manner. Thus, these patterns of adoption will apply differently to different parts of the same organization and will need to be customized to suit the needs of various teams. To help with this customization effort, this book will also apply the technique of value stream mapping, used for decades as a component of Lean practices, that can be used to develop a custom adoption roadmap from these plays for an organization’s business goals, current maturity, and capabilities.

Author Sanjeev Sharma Isbn 9781119308744 File size 8.13MB Year 2017 Pages 416 Language English File format PDF Category Software Book Description: FacebookTwitterGoogle+TumblrDiggMySpaceShare Achieve streamlined, rapid production with enterprise-level DevOps The DevOps Adoption Playbook provides practical, actionable, real-world guidance on implementing DevOps at enterprise scale. Author Sanjeev Sharma heads the DevOps practice for IBM; in this book, he provides unique guidance and insight on implementing DevOps at large organizations. Most DevOps literature is aimed at startups, but enterprises have unique needs, capabilities, limitations, and challenges; “DevOps for startups” doesn’t work at this scale, but the DevOps paradigm can revolutionize enterprise IT. Deliver high-value applications and systems with velocity and agility by adopting the necessary practices, automation tools, and organizational and cultural changes that lead to innovation through rapid experimentation. Speed is an advantage in the face of competition, but it must never come at the expense of quality; DevOps allows your organization to keep both by intersecting development, quality assurance, and operations. Enterprise-level DevOps comes with its own set of challenges, but this book shows you just how easily they are overcome. With a slight shift in perspective, your organization can stay ahead of the competition while keeping costs, risks, and quality under control. Grasp the full extent of the DevOps impact on IT organizations Achieve high-value innovation and optimization with low cost and risk Exceed traditional business goals with higher product release efficiency Implement DevOps in large-scale enterprise IT environments DevOps has been one of IT’s hottest trends for the past decade, and plenty of success stories testify to its effectiveness in organizations of any size, industry, or level of IT maturity, all around the world. The DevOps Adoption Playbook shows you how to get your organization on board so you can slip production into the fast lane and innovate your way to the top.     Download (8.13MB) DevOps on the Microsoft Stack IBM Data Engine for Hadoop and Spark Leaders and Innovators : How Data-Driven Organizations Are Winning with Analytics Implementing DevOps on AWS IBM Reference Architecture for Genomics, Power Systems Edition Load more posts

Leave a Reply

Your email address will not be published. Required fields are marked *