DevOps

"DevOps," as a term, doesn't have a really concrete definition. It's a philosophy, a way of working, and it means different things to different people. For the most part, the DevOps community generally (if reluctantly) accepts the definition from the DevOps article on Wikipedia, which states in part:

...a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.

I don't personally feel that the definition goes far enough; DevOps is far more that a "software development method." However, let's play along for a moment, and recognize that software rules the world. The President of the United States didn't stand up and say, "everyone should learn to subnet," he said, "everyone should learn to code." The massive global Internet, an impressive set of network infrastructure engineering as has ever been seen, is for the most part a dumb pipe used to deliver software. Software's what it's all about. But software doesn't get anywhere, or do anything, without infrastructure. It's the two working together that make technology useful, and that's why DevOps strings together both "Development" and "Operations." So for this book, I'd like to take the liberty of slightly re-defining DevOps as:

...an approach to technology management that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and IT operational ("ops") personnel for the purpose of creating and delivering software applications to their users.

Understanding that DevOps is a big thing is important, because it's actually so big that it's almost impossible to look at all at once. It involves numerous techniques, multiple roles within an organization (that's why "cooperation" is in the description, along with "collaboration"), and lots of intersecting technologies. This book isn't going to try and look at all that.

Some Background

The term "DevOps" was likely coined by Patrick Dubois , inspired by a Velocity 2009 presentation by John Allspaw. Philosophically, it's inspired in large part by the "Lean Manufacturing" teachings of luminaries like W. E. Deming, Taiichi Ono, Eli Goldratt, and others. That's important, because those gents based their thinkings on the premise that most workers want to do a good job. A common thread throughout Lean Manufacturing - and in fact a specific point of Deming's approach - was to end reliance on "QA" as a means of achieving quality. Yes, you put measures in place to help people prevent their own silly mistakes, but you don't put "gates" in place that assume your workers are malicious or incompetent. That one principle often becomes the biggest hurdle in adopting Lean Manufacturing, DevOps, or anything else that derives from that principle.

DevOps, for Ops

Instead, this book will look at the microcosm of DevOps related more specifically to Ops. In any organization attempting to implement a DevOps approach to life, the operational side of the house needs to deliver certain capabilities. In many cases, the operational side of the organization needs to deliver a level of automation and a kind of self-service that allows the Dev side to conduct there business without as much operational intervention. Operations, in that regard, is all about providing Development with safe, manageable, monitor-able ways of getting software to the end user, without it always being a major Operational project. Exactly how you proceed, and what capabilities you provide, will vary greatly depending on your organization.

In providing those capabilities, Operations will itself have to embark on a certain amount of software development, to create units of automation that make the operations side of the organization run more independently. Those software development efforts can themselves be conducted in a very DevOps-centric fashion, and this book will also focus heavily on that activity.

It's a Philosophy

DevOps is a lot like accounting, in that it's a set of abstract principles, approaches, and patterns. In accounting, you've got Generally Accepted Accounting Practices, or GAAP. They're not rules, per se, but they're so generally accepted that they do carry the weight of law in a lot of ways. DevOps is, or may become, like that, in that it can embody a set of practices and approaches that are generally recognized as the best way to go. Accounting also has tools that help you implement its practices. QuickBooks, for example, is a software package that embodies and enforces a lot of accounting practices, making it easier to put those into effect in your organization. Similarly, the DevOps world has a number of tools - many still nascent, but DevOps itself is pretty new - that help you implement DevOps practices and approaches. As the DevOps world tries things, learns from them, and fine-tunes its approaches, you'll find more and more tools being created to help make those approaches easier and more consistent to apply in the real world. In this book, we'll focus far more on practices and patterns than on tools, so that we can stay higher-level and not force you to commit to a particular technology stack.

Unlike accounting, and as I've already mentioned, DevOps is really new. And, unlike accounting, DevOps lives in field that is itself constantly evolving and changing. So don't expect a lot of concrete, "here's what you must do" rules and regulations. Instead, the practice of DevOps is currently 80% theory, 10% what people have experienced so far, and 10% pure guesswork. There are a lot of companies experimenting with DevOps approaches, so as an industry we're still figuring it out. Much of this book will focus on what's been done successfully elsewhere, and look more concretely at what Operations delivers in those situations.

It's an Approach

And understand above all that DevOps is a technology management approach. It suggests ways of managing projects, ways of managing software development, and ways of managing operations. That said, without management buy-in in your organization, you can't do DevOps. So if you're thinking, "well, my organization will never get behind this idea of developers being able to push code into production," then you might as well stop reading right now, unless you're just interested for curiosity's sake. This book, at least, isn't going to make the case for DevOps in a big way - that's been done elsewhere. This book kind of assumes that you've already accepted the benefits of DevOps, and that you're interested in digging a little deeper into what that means for a traditional IT operations team.

There's No Such Thing as a DevOps Team

And let's be very, very clear: you cannot have a "DevOps Team" in your organization. That's nonsensical. DevOps is a management approach that encompasses software development, managers, and operations in a single body. Everyone works together to smooth the creation and deployment of applications. It's possible that only one of many internal projects will be conducted in a DevOps fashion - but given the kinds of changes Ops will need to make in order to facilitate the DevOps approach, it's going to be tricky to "do" DevOps in a piecemeal fashion. Just be aware of that - DevOps is about changing the way you do business, and if you haven't bought off on that idea, then it's always going to feel a little scary and awkward.

You can have specific teams or projects within your organization acting in a DevOps manner, provided that team is sufficiently cross-functional to provide all the disciplines of Dev, Test, Ops, and so on that are needed. So the whole IT estate doesn't need to "go DevOps," but an individual project might. That said, having just one project run in a DevOps fashion can be sticky, because at some point it's going to run up against your "normal" IT operations, and the two might not get along.

So, you very well might have teams that behave according to DevOps principles, and you may call it a "DevOps team" if you have only one. But it's wrong to think that DevOps is implemented by some team dedicated to DevOps implementations. It's not "the team that handles DevOps for us," although it might be "a team that behaves according to DevOps." That's a super-fine line, perhaps, but it's an important distinction.

What DevOps Isn't

Given that DevOps is a philosophy... a management approach... and the combination of multiple IT disciplines... it might be easier to quickly look at some of what it isn't.

• DevOps is not Agile. That said, your teams might indeed use Agile as a development methodology within an overall DevOps-style approach. Agile is certainly DevOps-compatible, and, like DevOps, values short, continual improvement.

• DevOps is not Continuous Integration. That said, CI is often a part of DevOps-style behavior. The two can be really closely related, in fact - so closely that it's hard to tell the difference. I suppose you could argue that it's difficult to practice the DevOps philosophy without using CI as an enabling implementation, but you can definitely have CI without behaving like a DevOps organization, so the two aren't exactly the same thing.

• DevOps isn't "the developers running Operations." If anything, it's Operations automating things to the point where Operations runs itself in response to authorized actions taken by other roles, including developers.

• DevOps isn't a software development methodology. See the first bullet, above. DevOps is what happens while software development is happening, and largely what happens when software development (or a cycle of it), is done. You still need to manage your software development - you just need to use a methodology that's DevOps-compatible.

• DevOps is not automation. However, you can't have DevOps without automation. Automation is perhaps the biggest thing that Operations brings to the DevOps table, in fact.

Further, it actually seems to be an unstated goal of many DevOps champions to avoid the creation of any kind of trademarked, rigid, rulebook of "how to do DevOps," a la ITIL or TQM or something. This book certainly doesn't attempt to provide "rules;" the goal here is to provide some understanding of what DevOps' broad goals are.