I often see DevOps presented in the context of startups focused around a single web app or in stirring manifestos on agility. There seem to be very few concrete tips for a "normal" IT guy who is taking care of some vSphere boxes running Exchange and other COTS software. But at the same time companies such as VMware like to present the final destination of cloud as "IT as a Service," which sounds pretty DevOps-y. @bgracely talks about DevOps and IT here: cloudsofchange.com

Is DevOps relevant to "normal" IT departments?

In a word yes.... Devops is about transforming IT to be better, faster, cleaner, funner .. all things 'er :) Seriously, although the genesis is rooted in startups many of the principles apply to 'Normal IT" or what some would call legacy IT. The transformation is however, much harder there.

I believe it is very relevant.

But there is a difference between DevOps processes and DevOps toolsets which can sometimes confuse the adoption/understanding.

The process is important to define and plan first. It can come in many variations. You can start in greenfield projects or try and migrate existing departments out of silos. As a customer I did the latter way before I ever messed around with a single toolset. What is important here is the understanding of *agile* infrastructure for operations. The new DevOps Cookbook by Gene Kim is going to be a great resource for this discussion.

The second piece is DevOps tools sets. Getting the above understood opens the gate for toolsets to fill the gaps needed.

The most important feature of DevOps is accelerated change where it is most valuable without losing accountability or communication.

Does the consumption of more monolithic packaged software from MS, vs. source accesible .WAR style deployments have a big impact here? It seems to me it must. Even if you say devops is just a cultural shift having a less permeable barrier between ops and MS as a vendor than in-house developers is material.

I think everybody in this Branch is going to be violently in favor of DevOps. But what *concrete* things can a typical IT practitioner start doing today? I like the conceptual split between tools & processes - because surely this isn't as easy as "start using Puppet/Chef." Or is DevOps only applicable, as James asks, to in-house development, and is indeed not very relevant to a old-school silo'd sysadmin?

ps Thanks for jumping in, by the way. This is my 2nd weekly Branch experiment. I appreciate being able to borrow your brain cells.

Nick and I talked about this a little bit before he got geek-famous, thecloudcast.net.

If you compare the DevOps teams are large-scale web companies to traditional IT Ops, it would look a lot like comparing a dropback passing (football offense) to a fast-pace spread (football offense). Very different mindset, very different approach to teamwork, very different skills of the people.

I'd be very interested in @botchagalupe's take on how to transition existing IT teams, but I suspect it would lead to a definition battle like "private cloud vs. public cloud" and "real cloud vs. fake cloud", so I'm not sure it's right to talk about DevOps with existing environments.

Nice plug @Brian :)

To answer John's *concrete* things, or rather a first for any DevOps hopeful team would be mini-townhalls across said teams. You need to breed transparency - it won't develop on its own.

Definition of Normal IT aside I think the DevOps conversation really comes to play as groups are getting more responsibilities without more resources and/or being asked to provide services to their consumers.

The transition from "keep the lights on" to "make this easier for consumers" has been a considerable shift. The miracles of virtualization have set new expectations that make a DevOps mindset a requirement. Lab Manager was tip of the iceberg.

Interesting point about the difference between toolsets and processes. Most 'normal' IT shops are going to grab DevOps toolsets but will never really succeed unless they invest the time to learn and then change their culture. I hope they get more people cause it's a whole new role. :)

DevOps = Absorbing Scale and Complexity
Yea?

In answer to John's concrete example:

You first have to define the goal or the problem. If existing IT processes moving through the SLDC (en.wikipedia.org) are hindered by slow moving controls and people; then you might be a candidate to explore DevOps.

The patterns that created Agile Methodology and Extreme Programming were based on the goal of being better reactive to changing business goals. DevOps has the same core principle.

(p1)

So in exploring existing problems you can find the same pain points. Stuff like communication issues arising from throw-it-over-the-fence style patterns. Issues of knowledge-demigods (senior infra-people) becoming bottlenecks to change in patterns of protecting their value. And the creation of the them vs. us mentality when in reality everyone is working for the same goal.

You can address these directly by doing several things:
1) Moving software development to more agile patterns -> better link business needs to developers
2) Integrating operations people into development teams earlier -> Make them a part of the process. See ops problems early. Opp. to solve them early.

(p2)

3) Force knowledge-demigods into training of core knowledge to ops & dev. Rate/review them on their mentoring success instead of their ability to control a project. -> Break up old infra-silos.
4) Openly accept DevOps toolsets as options to accelerate. Dedicate a percentage of time for teams with a mix of dev & ops people. Give them accountability and time to solve old problems in a more effective way. -> Builds cross knowledge, implements DevOps.

This is just one example of an approach. There are many. DevOps is the pattern of breaking silos down and creating collaborative, accountable, and accelerated implementation of business value.

A proper DevOps movement within an organization should reward the innovators, the communicators, the hard workers, and those hungry to grow. The fearful of change, the knowledge curmudgeons, and solo-artists will not find a place.

Nice Nick. You're going to get scooped up by someone like VMware talking like that! :)

I really like your point #3 The key comes down to the push to commit from management. We're seeing IT needing to move from a tech management team to also being a business enablement team. How can you manage your infrastructure in such a way that you increase your ease and time to deliver? I see Cisco both succeeding and finding challenges with this. The management has the vision but the plan to execute is often a bit grey. Sometimes this is tool set, other times it may be lack of product to meet the needs.
The ones I see excelling are the ones who either find or build the tools to help meet the goals. The rest are left reading the wiki.

Oh NO! I killed the discussion!