WIXLIB

Introduction byDave HarrisonThis book comes from two of my greatest failures, one personal and theother professional.The first came in fall of 2013, as I was being unceremoniously cut by a sportingapparel company after a disastrous stint as a project manager. It was a miserable trip out to my car, with rivulets of rain streaming off my jacket onto mysoggy box of belongings. I felt like I’d been hit on the back of the head with a2x4. What happened?Just a year earlier, working at a great company in the same market just downthe street, I had managed a team of developers and had enjoyed some greatwins in adopting Agile. I had expected this assignment to be the next rung onthe ladder and build on this success; after all, I had so much more to workwith at this new company. I had a bigger team, which meant more firepower.And the team looked like the perfect group to build on; they were bright,experienced developers with very deep-level expertise in modern web development. My new manager understood Agile and backed my vision 100%. Ifelt confident, fully expecting a glorious victory; instead, ignominiously, I washaving to start over.The fact remained that though I had been successful with Agile at one company, the same recipe and approach had not gained any traction at another.I remember gripping the wheel in frustration as I drove home that evening,thinking; Dave, you missed your off-ramp.The off-ramp I had missed wasn’t made of concrete. Looking back, I hadmissed opportunities to really drive a better vision for the team that wouldhave been less risky, incorporated quality as a first-class citizen and built incrementally on success. I had engaged with the testing community and even –halfheartedly – tried to inject some quality initiatives within our team. But thetwo teams still remained very separate; QA was always lagging by a significantmargin behind development, our manual testing took days to complete andleaked like a colander. We had missed several very embarrassing issues thatrequired all-out efforts to mitigate, costing me points in rep that I now realized I couldn’t afford to lose. Our poor reliability and lengthening technicaldebt hurt team morale and was nakedly exposed to the end user community.

xivIntroduction by Dave HarrisonWorse, we were dropping stones into a pool with our releases. Operationswas also siloed from development. We had no idea what features were working as expected and were often the last to know when key services wentdown. Our releases were joined at the hip with an older web site that wasin even worse shape. We had the capability to roll out multiple times a day,but as we were chained to this old manually tested system, we were forcedinto a torpid multi-month release timetable. Our weekend releases becamecrucibles of forced overtime with bad catered food, terrible cat picture slideshows, and short tempers as we had to choose between forcing a humiliatingrollback or trying to patch things together in place.As personally painful as the experience had been for me, one experiencestood out that started some wheels turning. I inherited on the team an IT/infrastructure liaison whose main assignment was to write Chef recipes soinfrastructure could be rolled out alongside code releases. This was the firstexperience I had had with Chef and automated infrastructure – and it was areal eye-opener. I remember watching templated environments get rolled outwith a single command and being absolutely floored by the repeatability andreliability of that one pocket of our release lifecycle.This same infrastructure person pulled me aside once and told me – “Dave,sometimes you have to go slow to go fast.” In the mad chaos of day-to-dayproject management, I brushed that aside. Now, thinking back, I realized thatI had missed something.Years went by; I found a great job that was incredibly challenging technically,writing a shop floor application as part of a small three-man team supportinga manufacturing process of large-screen touch sensitive monitors. The daysof big battalions and 20-person teams were behind me; here I worked as partof a very tight, close-knit group. Everyone contributed to design and implementation, and we proudly watched our little code baby grow in strength andcapability.But even on this tiny team, the same problems with coordinating releasesremained. Most of our releases failed, as the big batches of code that wechecked in every few days or so failed to integrate. As a result, several criticaldemonstrations to our customers abended, and we were forced to scrambleto patch together a working fallback. In the end the project succeeded, butonly with a lot of unnecessary friction and waste.Then, I moved into Microsoft as a senior consultant and began working withcustomers throughout the western United States on their development challenges. However, I never forgot my earlier experiences and kept thinkingabout better ways of making software releases safer and more predictable.

Introduction by Dave HarrisonIncreasingly, I could see that the problems I had faced trying to scale Agile inthe real world was not an anomaly.Then, in December of 2017, just as I was beginning to think about what thisbook would look like, my second great life failure happened. My new doctorrequired an in-person checkup, so I made a routine visit, had some blooddrawn, and left. Two days later I got a call – I needed to come in, as soon aspossible. My blood sugar level was through the roof, as was my bad cholesterol levels and blood pressure. In short, I had Type 2 diabetes and wouldneed to change my diet, exercise, and be on medication, for the rest of my life.I was hit with waves of guilt. Type 2 diabetes is a lifestyle disease; the hecticand stress-filled pace I had set in my life – and the food and drink I used as fuelin coping with it – had finally caught up with me.This was a different and very personal crisis, but I felt the same reaction– what happened? I thought I was healthy; I had tons of energy, a great gigwithout too much stress, and a wonderful family life. But as my colleagueAaron Bjork has pointed out – “Just because you’re not sick, doesn’t meanyou’re healthy.” I had ignored several critical warning signs with my health andnow was saddled with a life limiting condition to manage – the physiologicalequivalent to a disabling car crash.Looking back, I’m grateful for my failures most of all. I’ve learned so muchfrom them. My professional failure as a project manager got me thinking aboutbetter ways of writing software and coordinating releases, which led directlyto discovering DevOps and a brilliant and selfless community of professionals with a powerful mission. Failing at managing my health made me resetthe pace of my life and the way I was using and abusing food and drink. I’mcalmer now, more empathetic, less focused on “getting stuff done” – moreconcerned with safety and a sustainable pace.Giving away the ending of our novel here – but our hero Ben ends the storywith a talk about humility, patience, and trust. I’ve had a great opportunityto share time with some great leaders in our community; they were acrossthe spectrum in terms of their personality types, their favorite choices withtechnology, and the resources at their command. But those three qualitieskept appearing in our conversations, a common thread.There is no single roadmap to success in DevOps. But, if you get only onething from this book, remember this – if you make it about learning, and demonstrate humility, patience and trust in your personal behavior, you won’t befar off from success.xv

Introduction byKnox LivelyWe live in a time of instant, or at least near-instant gratification with information at out fingertips within 200 milliseconds or less. After reading a booksuch as this one, or any book for that matter, the reader often assumes thatthe tightly woven narrative that is portrayed has always been such. It couldn’tbe further from the truth. A book, as with a career, or anything worthwhiledoing is the culmination of many months, and even years of concentratedeffort, often by multiple parties. This book was such. Dave and I workedcountless hours while managing relationships, families and our day jobs tofollow a goal that we thought worthwhile of sacrificing the better part of ayear to.My career, just as with this book, was the product of daily effort multiplied bytime. It didn’t appear overnight, there were no fireworks, nor did I even realize I had a career until years down the road.As I suspect how many of the readers careers began did, mine began in thetrenches of IT. Helpdesk Tier 1 to be exact. It was my first salaried positionright out of college, and I couldn’t have been happier. “I made it!” I thought tomyself. I couldn’t believe they were going to pay me 35,000 no matter howmany hours I worked! Let’s just say it didn’t take long until I began to strivefor more.From helpdesk I began to teach myself programming and worked my way intomore of a Junior Sysadmin-type role at the same company. After learning acouple of programming languages and seeing the power it had to transformmy career, I was hooked. From there, I continued to work my way up tomy first traditional Systems Administrator position. In my career path, andmy limited understanding of the field, Senior Systems Administrator was theculmination and ceiling for my career path. After a couple of more years I’dlanded at just that, a Senior Systems Administrator role. “This is it, I made it.”Once again, I thought. But the truth was it didn’t really feel any different frommy first position working on the Helpdesk. Instead solving one-off problemswith people and their desktops, I’d simply migrated to solving one-off problems with servers. My workflow was still entirely push-based. Work came to

xviiiIntroduction by Knox Livelyme, and typically at the worst time possible. I was a technical firefighter forall tense and purposes.Enter my “there’s got to be a better way” moment. Sick and tired of legacysystems, legacy thinking, and legacy people I pulled up my stakes and set mysight on new career horizons. I spent months of looking for and researchingmy next career move.Luckily, not too long into my research I stumbled my way into a DevOps rolein Los Angeles. I’d barely heard of the term DevOps, what did it mean? Wasit the beta-max of development methodologies, or was there some stayingpower to this new concept? I wasn’t sure, but I sure as hell wasn’t about tocomplain. The money was good enough that I figured I could make myselfexcited about it for the foreseeable future.My second stroke of luck was being able to work under a brilliant DevOpsengineer. The company was small, so it was just us two. I had landed basicallywhat seemed a paid mentorship. A mentorship is something not easy to findanywhere these days, much less getting paid for it. I learned the ins and outsof configuration management tools, proactive monitoring suites, as well asdeploying infrastructure as code. This was everything my career had beenmissing up to this point, a way for me to proactively design my way aroundfuture potential problems. Problems that all legacy systems were plaguedby. Problems like, snow-flake systems, or rather systems that needed special hands on maintenance due to drifts in configuration practices across theenvironment. Other problems like only finding out systems were down onlybecause customers called, or simply trying to keep up with all of the systemswe owned seemed to be a thing of the past.It seemed too good to be true; there had to be a catch. And there was acatch. It required a shift in mindset, specifically the mindset of an engineeror an architect to properly implement and build such systems. The cowboycoder and the typical grump legacy systems administrator mindset was 100%incompatible with this new methodology. I fell into those camps. I hacked myway through every cookbook, recipe, task, you name it. I did so with, notsurprisingly, limited success.I wish I could say I read a couple of books and BAM! I saw the DevOps light,and everything was happily ever after. That couldn’t have been further fromthe truth. It took me the better part of my DevOps career to shift my perspective. Only through diligently reading, educating myself, and working withgreater engineers on a daily basis was I able to reshape the way I thoughtabout IT, DevOps, and Software engineering as a whole.My education and understanding of DevOps is now quite simple. Ask mea few years ago if you came to me looking for a definition of DevOps andwhat it is I do I would have told you to “google it.” Not because I’m a jerk,well maybe, but rather because the concept was so elusive to me. It means

Introduction by Knox Livelysomething different to each person you ask. So, I’ll give you my definition ofDevOps.Firstly, and foremost, DevOps is a mindset. It’s not some new-fangled toolmade by some trendy software company of which everyone sports theirt-shirt. It’s a way in which you approach a problem. The tools are, well justthat, tools. Pick whichever ones suit you and your organization best. Themindset, however, is the real asset. DevOps, when applied correctly, will helpyou and your organization architecturally plan around problems before theyhappen. DevOps, its accompanying methodologies, and tools should help youarchitect infrastructure that is iterable, scalable, and version-able. No different than software development methodologies such as Agile. Agile for infrastructure if you will.Secondly, DevOps should empower you and your organization to take onany project no matter how large through the process of breaking large tasksinto smaller tasks, delegation, automation, and lastly by using the multiplierof time. Any successful company, no matter the sector, will tell you that thisabove all is how you build empires.Thirdly, and perhaps the most important concept DevOps has to offer, is theidea of closing or integrating feedback loops within a tech department, oreven across an organization. For far too long departments have been siloed,forced into throwing work over the fence to another, each operating in independence. Even within the tech department processes and technologies aresiloed in a way that didn’t offer an easy way to see the whole picture. DevOpsoffers a way of integrating all the various systems and closing the feedbackloop for rapid learning, iterating, and re-integration of knew knowledge tosystems and processes. DevOps is an organic approach to systems design thathas been missing in the tech landscape until now.My hopes and wishes for the reader are that they understand that DevOpsis not only a set of tools and practices, but rather a mindset. A mindsetthat informs each and every decision for their work and the direction of theorganization as a whole. However, in reality, we are dealing with conceptslarger than DevOps itself. On a more global scale, whether it be creating afamily, growing a garden, or writing a book, each can be achieved by using thesame fundamental principles. The principle that through small, incremental,yet measurable changes applied daily can create long and lasting change.My other greatest wish for the reader is that this book, although loadedwith information, quells their fears of mobilizes them to take action on whatseems an Everest of tech debt. We all have stared down this mountain andwondered “How can I ever hope to achieve half of what is being asked of me?”Not enough resources, not enough time, lack of knowledge, etc. The excusesare endless. However, they are not unique to any one individual or organiza-xix

xxIntroduction by Knox Livelytion. There is no DevOps “Never-Never Land” where everything works asit should, no practice ages, nor has any consequences upon its failure. Noteven the “big guys” you hear about from your favorite Tech blogger operatein a sandbox. They each got to where they were by adopting a certain setof tools and practices, as well as a mindset that worked for them and theirorganization. They took these resources and simply started. Each and everyday chipping away at the mountain. It’s the only way anyone could ever hopeto achieve what is being asked of them and their department.

What You’ll Learnfrom This BookIn the preface to Lean Enterprise1, the authors noted that the biggest painpoint they saw came from people working at organizations that only couldspeak for part of the whole:Everyone finds it difficult to implement these ideas successfully. Inmost cases it was impossible to realize anything more than incrementalimprovements because only part of the organization changed – and thatpart still needed to work with the rest of the organization, which expectedthem to behave in the traditional way.This same pain point exists today, and it’s killing us. We find motivated, brightpeople at every level of the organization and from all walks of life – IT, QA,development, InfoSec. These early adopters catch fire and love the conceptsof DevOps from the first day; but as they only can change part of the organization, the underlying issues of end to end delivery remains unchanged. Afterreturning from a great conference, or reading inspiring books like The Goal,Continuous Delivery, or The Phoenix Project, a common reaction seems to be –oddly – depression.It’s what we like to call a “now what?” moment. Unlike the heroes in thesestories, we aren’t blessed with a magical, all-wise advisor who can lead us inthe right direction; we may also not have a small army of bright, capable directreports that can follow our lead as we try to turn things around.It’s almost cruel. We’re being shown a shiny, beautiful car – but we’re notallowed to take it for a spin. In conferences and in meetings with customers,we constantly hear from people that love the principles underlying DevOps,but then are slapped in the face with the ugly reality – my place just doesn’twork like that. I don’t have the kind of authority we’d need to pivot like this.Jez Humble, Joanne Molesky, Barry O’Reilly; Lean Enterprise: How High PerformanceOrganizations Innovate at Scale, O’Reilly Media, 20151

xxiiWhat You’ll Learn from This BookSo, what to do?In Portland, a few years ago, Dave was asked by a good friend to speak at aconference about this shiny new object called DevOps. The auditorium wasfull, and the audience was engaged and interested in th

tion of DevOps at Microsoft: DevOps is the union of people, process and products to enable the continuous delivery of value to our end users. —Donovan Brown, Principal DevOps Manager, Microsoft The key here is continuously delivering value. That is the ultimate end goal. We have always said that compa