preface

I’m an avid reader of things related to the DevOps space. I came up in the technology field in a regional insurance office in upstate New York. The company was a pretty good size for the local economy but wouldn’t exactly be considered a powerhouse in the world of technology. Many of my friends worked in similar companies where technology was important, but it wasn’t the product the company sold. It was a means to deliver the goods and services that their customers paid for.

Fast-forward 10 years. I’ve moved to Chicago and become involved in the local technology scene. There are a lot more companies in Chicago that have technology as the product. As a result, many of the companies are more technologically sophisticated and at the forefront of new ideas and practices than I’d previously experienced.

But in these tech circles, you’re surrounded by people who are in a similar space. This homogeny creates a sort of bubble or echo chamber. You quickly begin thinking everyone is at the same stage of evolution in their journey. That couldn’t be further from the truth. That disconnect is what inspired this book.

People read blog posts from Facebook, Apple, Netflix, Uber, and Spotify and assume that because these wildly successful and popular companies are doing things in a certain way, matching that success requires following the same pattern. The same is happening with regards to DevOps practices. After having a few conversations with people doing DevOps, you conclude that you need to be running Docker in a public cloud provider, deploying 30 times per day in order to be doing DevOps right.

But DevOps is an iterative journey. The journey starts similarly in most companies, but where it ultimately heads depends greatly on your situation and circumstances. Maybe deploying 30 times per day isn’t the end goal for your organization. Maybe your company can’t adopt Kubernetes because of problems running legacy applications. That doesn’t mean that you can’t achieve some of the benefits of a DevOps transformation.

DevOps is as much about people as it is about technology and tools. I wanted to write this book as a toolkit to show how some of the common problems that besiege teams have DevOps solutions that don’t require rewriting your entire technical stack. You can find positive change in DevOps by modifying the way teams interact, communicate, and share goals and resources. I hope that you recognize these patterns in your organization and that the book provides you with the tools necessary to break them.

acknowledgments

There are so many people in my life who have contributed to this book in ways both large and small. I’ll start by thanking my biggest fan, my best friend, and my partner in life. My wife, Stephanie, endured my absenteeism, my frustrations, and my doubts with support, love, and understanding. You are my rock, and this book doesn’t exist without you. I love you deeply.

I’d like to thank my mother, Evelyn, for all that she has done and continues to do for me. For seeing my love for computers and encouraging it. For stretching our checking account to buy me my first computer. For not getting angry when I kept the phone line busy for hours at a time. For teaching me right from wrong. For bragging for me when I was too embarrassed to do it. For making me stand up and speak in church. For making me do all the other things that I hated then but made me who I am now. I am forever grateful.

To my sister, Gloria, for always being in my corner. You carry the weight of our family, and your heart is so large, your love so bottomless that you don’t even realize it. It isn’t your selflessness that impresses me most, but how effortlessly it comes to you. You are the example that drives me to be a better person every single day.

To Debbie Maxwell, my high school math teacher. You wouldn’t give up on me no matter how many reasons I gave you to. I graduated high school because of your tutelage, your support, and continued belief in me. Thank you.

And last but not least, to Mickey McDonald, my first manager and mentor. You saw me reading a book on TCP/IP that I barely understood. But you took a shot. You hired a black kid doing data entry who had no formal schooling, no formal training, but a ton of desire. You helped change my life.

I would also like to thank the awesome team at Manning for making this book possible. In particular, I thank Toni Arritola, the development editor, for her patience and support. I also thank Karl Geoghagen, the technical development editor, for his review and feedback. Thank you also to review editor Aleksandar Dragosavljevic, project editor Deirdre Hiam, copy editor Sharon Wilkey, proofreader Keri Hales, and typesetter Gordan Salinovic.

To all the reviewers--your suggestions helped make this a better book: Adam Wendell, Alain Couniot, Andrew Courter, Asif Iqbal, Chris Viner, Christian Thoudahl, Clifford Thurber, Colin Joyce, Conor Redmond, Daniel Lamblin, Douglas Sparling, Eric Platon, Foster Haines, Gregory Reshetniak, Imanol Valiente, James Woodruff, Justin Coulston, Kent R. Spillner, Max Almonte, Michele Adduci, Milorad Imbra, Richard Tobias, Roman Levchenko, Roman Pavlov, Simon Seyag, Slavomir Furman, Stephen Goodman, Steve Atchue, Thorsten Weber, and Hong Wei Zhuo.

about this book

Operations Anti-patterns, DevOps Solutions was written to help individual contributors and team leads begin a series of actions that lead to a DevOps transformation. It begins by setting up the primary pillars of any DevOps transformation and attempts to frame organizational problems within those contexts.

Who should read this book

This book is intended for engineers from either the operations or development side of the technology team. It’s aimed at team leads and individual contributors. Higher-level managers and senior leaders will find many useful takeaways in this book, but the solutions and the approaches outlined take into account the limited role of the reader. Leaders further up the organization’s hierarchy will have a much wider set of tools available to them that are not covered in this book.

If you’re an executive looking to implement DevOps, this book will be helpful but incomplete. As an executive, you have access to options for cultural change that are beyond my target reader. While I still recommend reading this book (and purchasing a copy for every member of your staff and optionally as stocking stuffers for your friends and family), I’d be remiss if I didn’t point you to other books that take the scope of your hard power into account as an agent for change. Two good options are The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford (IT Revolution Press, 2018) and The DevOps Handbook by Gene Kim, John Willis, Patrick Debois, and Jez Humble (IT Revolution Press, 2016).

How this book is organized: A roadmap

This book is organized around a series of antipatterns that are commonly found in organizations. Each chapter starts with a definition of the antipattern and begins to explain methods and solutions for reversing said patterns:

• Chapter 1 discusses the ingredients of a DevOps organization and sets up common terminology in the DevOps community.

• Chapter 2 presents the first antipattern, the paternalist syndrome, and dives into the impact of low-trust organizations. It examines the role of gatekeepers in processes and their impact on the speed of change. The chapter tackles ways to automate these gatekeeper concerns to empower staff members and increase the rate of change safely.

• Chapter 3 describes the operational blindness antipattern and discusses the need to have operational visibility into our systems. It walks through processes for confirming that systems are working as expected through systems understanding, data, and metrics.

• Chapter 4 covers the data instead of information antipattern. It discusses how data can be structured and presented in a way that makes it more useful to its audience. Sometimes data is useful, but other times it needs to be presented in a way to convey a specific story.

• Chapter 5 introduces the quality as a condiment antipattern and discusses the need for ensuring that the quality of the system is part of all the individual ingredients. Attempting to ensure quality at the complete end of the process leads to a sort of quality theatrics.

• Chapter 6 defines the alert fatigue antipattern. When teams support production systems, they often set up a wide array of alerting. But those alerts can be detrimental when they are noisy without always needing remediation. This chapter discusses approaches to solving for this condition by being more deliberate in alert creation and understanding the alert’s true goal.

• Chapter 7 explains the empty toolbox antipattern. As teams expand in their roles or duties, it’s important that time and energy is invested in the tools they use to perform those duties. The process of adding responsibility without the corresponding tooling results in a general slowdown of the team as they perform repetitive tasks.

• Chapter 8 presents the off-hours deployment antipattern and discusses the fear around the deployment process. Instead of managing the fears, this chapter discusses how your approach to the deployment process can create safety in the process. By using automation, you can create repeatable deployment processes with defined rollback checkpoints.

• Chapter 9 covers the wasting a perfectly good incident antipattern. Many incidents get resolved but never discussed. Incidents occur when our understanding of the system collides with the reality of the system. This chapter gives a structured approach to tackling those moments to create continuous learning in your organization.

• Chapter 10 deals with the information hoarding antipattern. Sometimes information hoarding is accidental, based on permissions in tools, lack of opportunities for sharing, and other innocuous causes. This chapter walks through practices to reduce information hoarding and increase sharing among teams.

• Chapter 11 talks about organizational culture and how it is formed. The culture is created not through slogans and value statements, but through actions, rituals, and behaviors that are rewarded and/or punished.

• Chapter 12 talks about how organizations measure teams and set their goals. Sometimes these measurements create conflict among teams. If one team is measured by stability and another team is measured by a rate of change, you create conflict between the teams. This chapter covers sharing goals and priorities to better align teams.

In general, the chapters can be read individually in any order, although some concepts do occasionally build on others. The focus may sound as if the burden lays more on the operations teams or the development teams, but I encourage you to read all of the chapters at some point in order to understand how their concepts are interconnected across teams.

About the code

This book contains only a handful of code examples, and all of the code is really only for illustrative purposes. The code that is displayed does follow a standard formatting.

liveBook discussion forum

Purchase of Operations Anti-patterns, DevOps Solutions includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the author and from other users. To access the forum, go to https://livebook.manning.com/book/operations-anti-patterns-devops-solutions/welcome/v-6/. You can also learn more about Manning’s forums and the rules of conduct at https://livebook.manning.com/#!/discussion.

Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the forum remains voluntary (and unpaid). We suggest you try asking the author some challenging questions lest his interest stray! The forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.

about the author

Jeff Smith has been in the technology industry for more than 20 years, oscillating between management and individual contributor. Jeff currently serves as the director of production operations for Centro, an advertising software company headquartered in Chicago, Illinois.

Jeff is passionate about DevOps transformations in organizations large and small, with a particular interest in the psychological aspects of problems in companies. He lives in Chicago with his wife, Stephanie, and their two children, Ella and Xander.

about the cover illustration

The figure on the cover of Operations Anti-patterns, DevOps Solutions is captioned “Indien du Mexique en voyage,” or Mexican Indian traveling. The illustration is taken from a collection of dress costumes from various countries by Jacques Grasset de Saint-Sauveur (1757-1810), titled Costumes de Différents Pays, published in France in 1797. Each illustration is finely drawn and colored by hand. The rich variety of Grasset de Saint-Sauveur’s collection reminds us vividly of how culturally apart the world’s towns and regions were just 200 years ago. Isolated from each other, people spoke different dialects and languages. In the streets or in the countryside, it was easy to identify where they lived and what their trade or station in life was just by their dress.

The way we dress has changed since then, and the diversity by region, so rich at the time, has faded away. It is now hard to tell apart the inhabitants of different continents, let alone different towns, regions, or countries. Perhaps we have traded cultural diversity for a more varied personal life--certainly for a more varied and fast-paced technological life.

At a time when it is hard to tell one computer book from another, Manning celebrates the inventiveness and initiative of the computer business with book covers based on the rich diversity of regional life of two centuries ago, brought back to life by Grasset de Saint-Sauveur’s pictures.