7 things you should know about devops

1Executive Summary

The move to devops is on. The philosophy holds that software developers and IT operations people at a company work better in concert rather than separately, and devops devotees say the process cuts deployment time from months and weeks to days or even hours. Constant Contact, a big devops shop, can now deploy a 72-node Cassandra cluster in about an hour, a job that took days before, according to company systems manager Mark Schena.

In the old model, software developers would write code for the features and functions users demanded. But they didn’t include in their calculus whether the plumbing needed to deliver those capabilities was up to the task. In a devops shop, developers write with infrastructure constraints in mind, and because operations guys are in on the process, they know what’s coming down the pike.

In this Web 2.0 era, users won’t wait for features. If they don’t get them from IT, they will go elsewhere, often using their credit cards to buy a SaaS solution or to get what they need from another provider. That demand for speedy updates and fixes is what drives even more traditional companies that might have endured long release cycles in the past to make the devops leap now.

So whether you’re a smaller Web 2.0 company or an existing big business, here are some things you should know about devops.

1. It’s people, not technology 

Moving to devops is more about people and culture than technology. The primary hurdle is getting two groups to meld into a single team that thinks holistically about the application and its impact on operations. Key to that is demonstrating that they share a common customer and a common goal: successful implementation of technology to serve those customers.

Heroku’s COO, Oren Teich, said he hates job titles, because they “keep people divided.” The key is for developers to know more about operations and operations people to know more about dev. It’s as simple — and as complicated — as that.

2. But tools are important

While devops folks will tell you it’s not about the tools, in the next breath they’ll then tell you about their favorite tools. For configuration management, a process for setting up (or shutting down) servers and other compute resources to handle specific workloads, the fan favorites are Opscode’s Chef and Puppet Labs’ Puppet (see disclosure), or maybe CF Engine.

They use these configuration managers to put that code into a blueprint (for Chef users the term is “cookbook,” and for Puppet users it’s “recipe”) that incorporates configuration information.

“If I’m building a new backend service, I’d write it in Chef or Puppet and create the recipe or cookbook at the same time. When the recipe is written, I deploy to staging with a one-button push,” said Paul Querna, a system architect at Rackspace.

Once testing systems are set up, Jenkins is a crowd pleaser. For gathering computer logs about how the various systems actually run in production and streaming them back to devops, tools like logstash or Fluentd are critical.

And then there are tools like RundeckSalt or MCollective that let devops remotely execute commands on lots of desktop and servers without having to log into each one. This is important in the cloud computing world, where devops can be dealing with thousands of devices that are nowhere near local.

3. Devops is greater than “dev” and “ops”

For devops to work, more stakeholders than just the development and operations teams need to buy into the process, according to Jay Lyman, a senior analyst with the 451 Group. “The trend pretty quickly pulls in database administrators, security pros, QA folks, business intelligence, CRM and sales teams, not to mention CIOs, CTOs and other execs charged with more than app development and/or deployment,” he said. In other words, devops needs support from authority figures who don’t touch code.

The problem is that despite the name of the process, devops projects often get rolled out in operations but not in dev, said Dave Roberts, the SVP of strategy for ServiceMesh.

In their rush, companies that think they’re doing devops may, in fact, just be using popular devops tools like Opscode’s Chef to build what ends up being a release automation system for operations while developers keep using their existing tool chain.

“You’d be surprised how many disconnects happen,” said Roberts. And those gaps obviate the whole notion of devops, in that groups don’t talk as much as they should and aren’t using the same tools.

4. Speed cuts both ways

One oft-claimed benefit of moving from traditional development and deployment is sheer speed. The CEO of a tech company said before devops, it took his team at least eight weeks to perform even a minor software build. That time was cut in half soon after devops came into play, and was further cut as staff became used to the process. Continuous, iterative development means features and functions are available more quickly to users, but if the processes aren’t handled well, haste can make waste.

If automation and quality assurance aren’t treated correctly, a devops project can quickly run into trouble, says an executive with one tech vendor that practices devops but who requested anonymity. On the flip side, it won’t take long to realize and remedy those inefficiencies, since the feedback loop between development and deployment is so much shorter.

As things move into production more rapidly, operations monitoring has to get better. “Chef and Puppet do let you deploy very quickly,” said Querna, “but they do not tell you when things break, so you need log monitoring tools.”

Logging tools are not optional, devops pros say. By collecting log files that tend to be strewn about the system (and thus tend to be hard to find) and streaming them back to devops, operators can quickly see the source of what could become a cascading failure.

5. It’s tough to measure success

Proving how much value a process has by comparing it to what might have happened under the old-world process can be difficult. But there are some things to try.

John Vincent, the director of cloud infrastructure for enStratus, a cloud computing company, said there are ways to assess the situation. “General happiness of your team is a good yardstick, and mean time to recovery is another,” he said.

It’s important to compare apples to apples, if possible. If the company tracked performance based on complaints due to poor code quality or broken deployments before, it should keep using that as its yardstick, he said.

6. Devops comes to Windows (or vice versa)

The devops movement started out as a Linux- and open-source-oriented thing. That’s changing as bigger companies — the types that run a ton of Windows code — want in on the action.

“Windows admins and .NET programmers are [finally] getting some of the same agility and automation capability that Linux admins and open-source programmers have had for some time,” said Lyman. Both Opscode and Puppet Labs are adding more Windows support, which will help bridge the gap for devops to move into the mainstream.

7. Devops isn’t for every job

Still, there will be situations where devops is not the answer.

“If you look at a large-scale SAP deployment or at Exchange Server — if things are pretty much set in stone, then a devops approach even for custom elements may be difficult,” said enStratus’ VP of product strategy, James Urquhart. “If there’s no dev, then it doesn’t make a ton of sense to have devops. There are always ops but if those operations are built in such a way that the software operation is strictly regulated and unlikely to change except glacially, then you’d just stay in an ops-dominant environment.”

Constant Contact’s Schena said the same is true when it comes to hardware-heavy infrastructural changes. “When you touch the underlying storage array or update your switches, devops doesn’t come into play at all.”

Summing up

The benefits of properly implemented devops have been proved in Web 2.0 shops, and now more devops tools are being created for legacy software too. The aforementioned Windows support in the popular configuration management tools is one indicator of the widespread use of devops. And the addition of a new Windows client for GitHub, the code repository and collaborative versioning tool often used by devops, is another sign that devops is growing up. Nothing says mainstream like Windows support.

Disclosure: Puppet Labs is backed by True Ventures, a venture capital firm that is an investor in the parent company of this blog, Giga Omni Media. Om Malik, founder of Giga Omni Media, is also a venture partner at True.

Relevant analyst in iaas
You must be logged in to post a comment.
14 Comments Subscribers to comment
  1. brianmccallion Saturday, October 6, 2012

    Devops sans traditional developers ==noop is one perspective. Yet such an approach falls right into the binary opposition of two categories and simply subsumes one into the role of the other. The real dynamics are far more radical and in the near term will play a far more immediate and profound change in the Enterprise.

    For those of you in the Valley who haven’t visited the enterprise, DevOps without the traditional “Developers” writing application. In the Enterprise the giant opportunity for DevOps lies hidden behind the question: Why do corporate datacenters contain millions of servers that have almost all been built and configured manually? Why does it take two weeks, three meetings, some phone calls to get a little SAN storage going for a funded project. The Dev part in this content means wrapping APIs around processes where not only the configuration of servers and the build of applications are currently a bunch of email, ims, meetings, phone calls, errors, and long pauses. That’s actually why I think DevOps may have gotten some visibility when Cloud got big. APIs wrapped around infrastructure are the real news. If you are thinking of server tco as a significant cost, you are really missing where the real money, and opportunity cost of no automation is being spent in the datacenter every hour of every day.

    DevOps in the Enterprise means flipping the script and for Operations to cease being the consumer of Enterprise software, and rather the Builders of Automated processes for configuring and managing infrastructure. The DevOps people I know like to phrase this transformation as a movement and that movement is from infrastructure as it is today, towards infrastructure as code. The real change is that code originates not exclusively from Developers, but rather in order to remain relevant Operations must develop the ability to code infrastructure.

  2. brianmccallion Saturday, October 6, 2012

    No devs==noop is one perspective. Yet for those who haven’t visited the enterprise, DevOps without the traditional “Developers” writing application. In the Enterprise the giant opportunity for DevOps lies hidden behind the question: Why do corporate datacenters contain millions of servers that have almost all been built and configured manually? Why does it take two weeks, three meetings, some phone calls to get a little SAN storage going for a funded project. The Dev part in this content means wrapping APIs around processes where not only the configuration of servers and the build of applications are currently a bunch of email, ims, meetings, phone calls, errors, and long pauses. That’s actually why I think DevOps may have gotten some visibility when Cloud got big. APIs wrapped around infrastructure are the real news. If you are thinking of server tco as a significant cost, you are really missing where the real money, and opportunity cost of no automation is being spent in the datacenter every hour of every day.

    DevOps in the Enterprise means flipping the script and for Operations to cease being the consumer of Enterprise software, and rather the Builders of Automated processes for configuring and managing infrastructure. The DevOps people I know like to phrase this transformation as a movement and that movement is from infrastructure as it is today, towards infrastructure as code. The real change is that code originates not exclusively from Developers, but rather in order to remain relevant Operations must develop the ability to code infrastructure.

Explore Related Topics

Learn about our services or Contact us: Email / 800-906-8098