The basic school of thought, I don't think I am mistaken in saying, is that agile principles of the sorts that have been adopted successfully in the software development community can also be applied, with some modification, to IT operations management.
Agile Operations basically stops there (and grows out of more diverse roots, besides). The focus is on identifying agile practices and principles that can be applied to operations, irrespective of where the software and hardware involved is coming from or how it is developed. I see Agile Operations as being IT-centric, largely ignoring the question of cooperating with development, and including approaches to deployment only as ancillary aspects of the overall challenge of running an agile IT department.
I think of DevOps as primarily addressing the concerns and difficulties of developers, and particularly of those in larger organizations with considerable custom internal software, who have become frustrated at the inability of operations to keep up with the faster pace and somewhat increased requirements for communication that their agile development practices demand. That's obviously the motivation offered by many proponents. More rare are those who disconnect the two and describe it only as the application of agile development principles to operations. There are certainly ops folks who are a part of the movement, but on the whole most of them seem to also have a foot in the development world; not surprisingly, many seem to be involved with website operations, an area that has always suffered from the friction between the dev and ops worlds. If a "webmaster," that poor, abandoned title describing a role that nonetheless has never really disappeared, is not an amalgamation of the developer and the administrator, then I don't know what is. DevOps is a natural evolution for anyone in such a position.
The DevOpsday website reinforces this perspective, inviting "developer(s) with a interest for system administration, or a sysadmin(s) interested in development..." to participate, leaving out sysadmins who really just want to run their own systems more efficiently.
Personally, I don't find any real issues with this overlap. Not all that DevOps can offer will apply to IT department operations in environments where interaction with developers is not a regular feature... and I think this is an increasing number of departments as SaaS and cloud-based, targeted services become more viable options for off-the-shelf procurement of software and services. At the meta-level of IT management, if you are going to be true to the principle of Simplicity, then your first choice for solutions is probably going to be fast, easily adopted off-the-shelf products of that sort rather than specifically (and often expensively!) custom developed software. In smaller IT shops, which is most of them, in-house development has never been a significant or reliable resource and outsourced development has often been untenable and interactions with outside developers not necessarily amenable to agile practices. None of that prevents any sysadmin or IT manager from taking from DevOps what works for them, and such an approach has much to recommend it since many of the more practical agile solutions for ops are coming from DevOps practitioners right now.
James Turnbull's recent treatise "What Devops means to me" is an excellent a representation of what DevOps is about and what issues it seeks to address as you will hope to find on the net.
(Aside: I find it interesting that the four quadrants Turnbull identifies as representing DevOps are roughly congruent to the four principles of Agile Operations; both include Simplicity and Process, and I find his Relationships roughly analogous to People, and Continuous Improvement to Communication)
DevOps seeks to address the epic and historic gulf between developers, many of whom have been moving toward agile methodologies for some time now, and operations staff, a more conservative bunch who are often caught out and feeling put upon by the rapid changes introduced by agile development. The realization that changing the development side of the equation without addressing the equally important deployment side (the realm of operations) was only changing where the roadblocks were at in between coders and customers led devs to gently lead ops in a similar direction. But as Turnbull says,
DevOps is also more than just software deployment – it’s a whole new way of thinking about cooperation and coordination between the people who make the software and the people who run it. Areas like automation, monitoring, capacity planning & performance, backup & recovery, security, networking and provisioning can all benefit from using a DevOps model to enhance the nature and quality of interactions between development and operations teams.
In other words, it started to become obvious that not only could the deployment of software benefit from a continuation of agile practices after the development cycle, but that ongoing operations could as well. This is where Agile Operations picks up on the thread.
In my mind, Agile Operations deals almost wholly with the people who run the software and not at all with those who make it. In environments where it is possible to cooperate and coordinate with developers, then of course doing so is an excellent idea. But many IT departments don't have, and never will have, that option; their developers are, for all practical purposes, Microsoft, and have you ever tried to cooperate and coordinate with Microsoft? Agile Operations recognizes that most IT departments have little say in the development side of the equation, and that the focus of their operations is not only independent of the development cycle, but in fact attempts to consciously isolate its effects on operations.
AO also looks at more than simply transferring Agile Development (AD) principles to operations; the principles are more deeply rooted and come as much from lean manufacturing concepts as AD concepts (although those are, in and of themselves, closely related). This level of focus is more relevant to the holistic management of the IT department, taking in procurement, support, and service in addition to the still important, but less central, issue of development integration and deployment.
I think both approaches are valid and valuable, and I'll certainly be following, commenting on, and participating in DevOps discussions, but I'll also continue to keep Agile Operations distinct from DevOps, and oriented primarily at the IT support and service management organizations.
I would consider myself such an admin, but also being part of this devops thingy in the sense that my sysadmin work becomes more and more developer-like.
With virtualization and clouds, my infrastructure gets an API. With puppet, my configuration gets an API. With APIs all around me, I become an infrastructure developer, learning from old school software developers. I consider this "the other side" of DevOps.
You are right that people use DevOps and Agile Operations as interchangeable terms, but I don't think it's because one is primarily for developers and the other is for systems administrators.
DevOps is about removing the disconnects, inefficiencies, and bottlenecks that seem to form between Development groups and Operations groups. In other words, DevOps is all about improving the handoffs.
Agile Operations, as you do a great job pointing out repeatedly on your blog, is about bringing the lessons of Agile development practices to your Operations. In other words, DevOps is all about improving what happens after the handoff.
Why do people lump them together? I'd have to wager that some percentage of folks don't know enough about these emerging topics to make the distinction. But I'd also wager that the majority of the time it's simply because DevOps and Agile Operations share the same high-level business goal... to make the business more agile and efficient.
At the end of the day you need both DevOps and Agile Operations to run your business:
Agile Development (build it) + DevOps (transition/handoff) + Agile Operations (run it) = end-to-end Agile lifecycle
When you referenced my "What is DevOps?" post, I'm not sure why you thought I considered DevOps "as primarily addressing the concerns and difficulties of developers". If you could, I'd like to hear more about how you came to that conclusion... because it sure sounds like I need to do a followup post to clarify!
DevOps should be everyone's concern. It's a rallying cry that we are all part of the same end-to-end business process and need to work together to fix that process.
Keep up the great work on the Agile Operations front! We're all working together to hopefully improve the lives of developers and systems administrators... while simultaneously making the business run better.
-Damon Edwards
http://dev2ops.org
To me, DevOps encompasses a pretty broad church - both developers and operations people can learn something from the concepts involved. DevOps is also broader than just cooperation between developers and operations people. It's about working together but it is also about working smarter on both sides. Here, the development world is far from perfect in adopting agile principles too - agile development principles are not universal and development teams who haven't learnt those lessons can be equally flawed as their operations counterparts.
As DevOps is broader than just laying out a path to cooperation between development and operations I see it also having relevance to organisations who have little influence over development (here assuming those organisations who implement a pre-built vanilla stack from Microsoft, Oracle, etc). To them I say - there are useful lessons agile principles can offer - be that TPS or Scrum or one of a hundred other industry or development frameworks. If your vendor doesn't play ball? Then all the more reason to introduce practises that promote good process, help protect your organisation from silo behaviour and hence help to reduce risk.
Whether you call that DevOps or Agile Operations or "Ma Barker's Patent Guide to Running a Smooth Operation and Making the Best Moonshine in Georgia"? shrugs Not sure it matters. I see a broad church with many members who all care about the outcomes: a better functioning, more efficient, more profitable organisation with happy employees and happy customers.
Nikolai and Damon, I am afraid I gave the wrong impression that "DevOps is all about development" or "for developers" in my attempts to differentiate the two. I certainly recognize much of value in DevOps for the Ops side as well; what I really meant is that it so far seems to be primarily a movement of developers, who are understandably focused on those aspects of operations that are most relevant to development, namely deployment and change management. But there is a lot more to operations than that, and as things stand, however beneficial DevOps is to admins in those respects, it gives short shrift to other elements of operations... elements I feel can also be managed with agile principles. I'm not saying individual admins won't take those lessons and apply them elsewhere, but no one seems to really be discussing that yet, as far as I have seen. And, considering the origins and focus, that seems entirely appropriate. No complaints here; I'm just saying there's more around the corner, which doesn't necessarily have any relationship to development whatsoever, and it deserves to be explored as well.
To James, I would say that we probably just disagree on how the term is being applied; I haven't seen, even in your article, anyone suggesting that DevOps encompasses more than the relationships between development and operations. I certainly agree with you that the applications of the principles involved can be broader than that, but I don't in all honesty see where you have suggested it; in fact, I thought you article was quite representative of the developer perspective in that it focused so much on the dev/ops relationship, and so little on the broad panoply of other functions that operations undertakes. That's exactly the point I am getting at, and I can't see how it contradicts or undermines the general idea that lean principles can be a good thing. On the other hand, I don't see how you are applying them to operations aspects other than deployment and communications with development. If DevOps is really something broader than that, I just haven't seen it yet.
Thank you all for the feedback, and again, I apologize for any misunderstandings.
I guess I'd see Simplicity, Process and Continuous Integration as being broader than just developer/operations interactions and in fact if you read those sections in my post they do mention DevOps cooperation but they are primarily about operating models, for example:
"Don’t underestimate the power of process and automation. Many shops do process engineering – ranging from hand-written lists to ISO9001. Those processes generally have one key flaw: they focus on the outcome and its inevitability...."
But just because you describe principles that apply to both, I don't think that means you have really covered them equally, or that it's simply a question of "branding." That's a bit like saying that, since those principles have already been well-articulated for years now by proponents of agile development, that DevOps can really just be called agile development and there is little distinction between the two; or that in turn, agile development's core principles had already been described by lean, so it can just be called lean manufacturing.
I think DevOps and agile operations, despite having similar philosophical underpinnings and sharing some close similarities in many respects, still represent different disciplines, and I think the distinction is worthwhile because, as I identified in the original post, most of what you find when you Google "DevOps" speaks specifically to developer/admin relations... and that embodies a class of issues that aren't going to strike a chord for the majority of admins out there. There is much that can be done with agile principles in the operations realm that has little or nothing to do with developer relations and ought not be lost within that scope.
Of course none of this is to say that your articulation of those principles aren't valuable generally, and in fact that's why I linked to your post in the first place; it's some of the clearest writing I have found on those principles, and on their realization in the DevOps movement.
The first is the techniques of agile - mainly iterative development focused on interim working and tested deliverables.
The second is the collaboration of agile - where crossfunctional teams, including their business counterparts, all sit and work together.
Note that descriptions of agile development incorporate both!
http://en.wikipedia.org/wiki/Agile_software_development
http://agilemanifesto.org/
However in practice people often adopt the tools and techniques of agile and ignore the collaboration part (something that the agile manifesto specifically warns against!).
I'll be honest, that's a common failing at my company - a team starts developing in sprints, but their requirements are still tossed down on high from a business analyst they seldom see.
I think the percieved difference between the terms "agile operations" and "devops" are an intuitive attempt to explain the difference. I also feel that the usual connotation of "agile operation" is more about using an agile process/methodology and "devops" is more about dev/ops cooperation. (And there's an unfortunate side meaning of devops which is "doing ops via more development" that is kinda-but-not-exactly like agile operations).
On the one hand, I think that having different terms from the technique part and the collaboration part is useful, if only because in the real world the two don't always go together and it provides more precision as to meaning.
On the other hand, I think it's an antipattern to implement one without the other, and we need to stress both aspects as part of a comprehensive whole.
My proposal:
- "Agile Operations" as the umbrella term that incorporates both, for parallel meaning with agile development.
- "DevOps" meaning "dev and ops collaboration" for the collaborative aspect specifically
- Some new term like "Programmable Infrastructure" or "Infrastructure Automation" to mean the tool/process automation part specifically
Though upon further reflection, I think there may be three distinct things people are actually lumping in. The "collaboration" part, the "automation" part, and the "process" part.
Collaboration - dev and ops working together (and if dev and business are working together as part of agile development, really this becomes a trifecta of bus/dev/ops).
Process - as in discussions about "kanban vs iterative development", using user stories and burn down charts and all that
Automation - all the tech stuff.
The wikipedia entry on agile development has sections on "agile methods" and "agile practices" - practices are things like test driven development that apply across methods, which are flavors of process (XP, Scrum, Lean). I would tend to argue our "automation" things like build automation/deployment/config management are practices, in this sense. And it's an open field to come up with combos of collaboration and process into different flavors of agile operations methods!