Devops, a term coined to describe the expanding reach of developers into areas typically considered operations tasks, is still viewed as a trend impacting early adopter enterprises – but for how long? What can you do to prepare what should you look for in technology that enables the devops model?

The developer land grab that is devops
The desire to release new functionality faster to end users is high on every developer’s wish list. However, most enterprises have multiple layers of processes, assigned to separate roles, which often increase the time between a new feature being developed and made available to users. However, most IT managers would agree that these processes and separation of roles were instituted to increase the quality and uptime of IT environments, and ultimately the quality of the end user experience.

The growing access to automated, self service, provisioning of IT resources and environments is enabling developers to flatten the roles, if not processes, between a developer and the end user.

RedMonk’s Michael Cote suggests that devops can be viewed as a land grab by developers. Cote writes, “after ejecting every function except writing code, development teams have been bringing those roles back to the core team, starting with QA, then product management, and now operations.”

Not surprisingly, devops is taking hold primarily in startups or smaller companies where the separation of developer versus operations roles is ill-defined by necessity.

The changing role of operations in a devops world
In larger enterprises with established separation of roles between developers and operations teams, the devops term may in fact be counter productive. It can suggest that as developers undertake tasks previously owned by the operations team, operations staff become less critical to the IT organization.

In fact, the reality underlying devops is far from that mistaken belief. Cote describes the changing role of operations staff in a cloud-driven devops world:

Rather, it means that as with QA and product management, their role moves from “keeping the lights green” to “delivering good, productive experiences.” Operations becomes one of the product owners, not just the “monkeys” who hook up wires to servers and increase disk-space.

The451 Group’s Jay Lyman shares a similar view in his research on devops, concluding:

However, in the larger picture and in the long run, particularly at greater scale, there is undoubtedly need for system administrators. One of the bottom line findings of my research on devops is that the trend is very much about a dramatically changed purpose and role for system administrators, who are typically freed up of mundane OS maintenance and other tasks, but who must also embrace openness and transparency in their operations and scripts, which can be very foreign.

Far from developers replacing operations staff, and thereby accepting some of the manual tasks required to keep an environment up and running, new cloud technology removes the need for these manual, and at times mundane, tasks in the first place. As these tasks are removed, operations teams are able to better contribute to the value that their business and end users perceive to be coming from IT.

Transitioning towards a devops model
Much of the transition required by the devops model involves changes to organizational design, processes and a revised definition of roles. These types of transitions can be lengthy in duration and often face resistance initially.

It is for exactly this reason that vendors must offer both an evolutionary and revolutionary option in their cloud and PaaS offerings targeted at enterprises.

An evolutionary approach is required to help IT organizations gain value while they transition to tomorrow’s more responsive and productive IT organization. Without this evolutionary step, the desire to protect one’s sphere of influence in the overall IT process will encourage IT staff to resist change before they can see the benefit of a cloud-enabled devops model.

A revolutionary approach also needs to be delivered in the same cloud-focused tool or product. This choice enables enterprises to shift gears between evolution and revolution in their IT processes without having to acquire separate products with separate skills requirements. More importantly, this choice allows enterprises to shift between evolution and revolution in their IT processes at their own rate and pace.

VMware’s open source-based Cloud Foundry beta and IBM’s Workload Deployer are two PaaS offering that attack the devops opportunity from two ends of the spectrum.

VMware’s beta offering appears targeted at enterprises ready for revolution, with a developer in control of the overall development to deployment process. It’s too early to tell if this is by design, or simply didn’t make it into the developer targeted marketing surrounding the beta. Knowing VMware’s long history with enterprises, one would expect VMware to address the spectrum of stakeholders whose roles are impacted by cloud and PaaS in a devops model.

IBM’s offering assumes that enterprises want to select between both evolution and revolution in their IT processes on a project by project basis while. This choice enables IT organizations to secure buy in from IT employees after proving out the benefits of more closely aligned developer and operations functions in a given project.

Preparing for a devops future
Like any major change in processes or role definition, IT decision makers need to allocate sufficient time for the shift to occur.

Successful transitions will most likely occur if there are proof points, relevant not only to the business, but to developers and operations staff, from a handful of smaller projects. Selecting projects, developers and operations staff that would be best suited for a new way of doing things would be a good fist step.

Additionally, determine the degree to which your IT organization can accept the revolutionary changes to roles and processes as codified by the cloud and PaaS tools you consider. Select your cloud and PaaS tools based on your organization’s unique needs.

Whatever you do, starting to think about devops models sooner rather than later, is the right approach for building tomorrow’s IT department.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

This Wired story has some very interesting comments on Amazon’s Web Services (AWS) business. The first point was news to me:

“And the idea that AWS is mostly about wringing extra bucks (especially off-season) out of Amazon’s data centers? “We’ve far exceeded the excess capacity of our internal system,” Amazon’s Jassy says. “That ship sailed 18 months ago.”


“I’d be surprised if no one else does this,” Bezos says, pausing for effect. “It’s a really good idea!” And there may be an ace up his sleeve. Any economist will tell you that a commodity business — storing and processing data, for instance — is a mug’s game, with prices that plunge inevitably toward the cost of production (in the case of bits, pretty close to zero). That’s music to Bezos’ ears. “Commodity businesses don’t scare us,” he says. “We’re experts at them. We’ve never had 35 or 40 percent margins like most tech companies.””

Wall Street’s best guesses for AWS’s 2007 revenue don’t even reach $100 million.

I scoured Amazon’s 2007 annual report to see if there was any additional data on the size of the AWS business. No luck. About all I could find is that Amazon’s expenses for “Technology and content”, which is where AWS expenses would be counted, were up to $715M ($818M if you include the cost of stock compensation to employees in the “technology & content” group). If the AWS business has grown beyond using the excess capacity of Amazon’s internal systems, it wouldn’t surprise me if 5-10% of that figure was associated with AWS. And based on the comment from Bezos, I’d probably uplift the expense estimate on AWS by < 25% to represent gross profit. All told, we’d be around [717M x ((5% + 10%)/2) x 125% =] $67M in revenue by my back of the envelope estimate. Not bad for 2007 (if my math is close to reality)…would love to know how big 2008 is considering that all the cool kids are using AWS.