How to adopt a successful DevOps enterprise

Team DevOps

Sometimes having "DevOps" in your title doesn't mean you're a developer who learned ops, or an Ops guy who learned to code. Rather, DevOps refers to a member of a cross-functional team, "where everyone is responsible for everything," said Paul Biggar, founder at CircleCI, a continuous integration and deployment provider.

In practice, organizations don't make a wholesale shift to becoming DevOps shops, said Abner Germanow, senior director of enterprise strategy at New Relic. In the enterprise, it's unusual to find an organization that describes itself as an all-out DevOps shop. Rather, you tend to find a DevOps team aligned with specific applications, such as the mobile team, or the checkout crew, he said.

At Red Hat, an internal DevOps project called Team Inception took this shape: a team leader, a product owner and scrum master, and four engineers with systems administration, information security, development and release engineering skills. "It actually worked out that every person had at least two of those skills on them, so there was enough crossovers that we were able to very quickly work together on stuff," said Steve Milner, a Red Hat IT engineer and Team Inception member.

The Dev side of the coin

The first part of the word DevOps is development, so a cornerstone of a DevOps environment is its chosen development methodology. With DevOps, that means some version of Agile. "It wouldn't make sense to have DevOps without Agile," said Evan Powell, CEO at DevOps startup StackStorm. "If you can't rapidly deploy code, it doesn't matter if you can operate it agilely."

Thus, for many shops, the first step is to pick an Agile-friendly development methodology, typically Scrum or kanban, which helps software development teams define goals, prioritize and assign tasks and identify where in the development process problems occur.

Another mainstay of DevOps is continuous integration (CI) and continuous delivery and/or continuous deployment (CD). CI is about continuously and automatically running tests against a code branch, whereas CD automates the process of getting code into production after testing and approval.

"In the old days, you used to release code into production at set times and off-peak hours," said Brian Doll, vice president of strategy at GitHub, which makes a source code repository platform. But that model of older orchestrated release cycles is "the complete antithesis of DevOps," he said. "The goal is to automate the release cycle."

The code itself is held in a source code repository for safekeeping and version control. These days, that repository is more often than not based on the open source git -- for example, GitHub or Atlassian BitBucket.

Git-based code repositories have largely overtaken older version control systems such as Concurrent Versions System (CVS) or Apache Subversion. Initially written by Linux developer Linus Torvalds, git responded to a need in the open-source community for a decentralized versioning system that could cater to globally dispersed development teams. "It turns out that a decentralized tool works well in the enterprise too, where teams can be large, global and loosely coupled," Doll said. Commercial versions of git add collaboration and policy-based approvals and workflows, plus they work with popular integrated development environments (IDEs), CI/CD and testing tools.

Infrastructure as code

Software code isn't the only thing stored in repositories. Increasingly, repositories also store detailed configuration scripts and templates created with configuration management tools like Puppet and Chef, which are two of the most popular languages in GitHub repositories, Doll said.

Creating automated ways to configure and deploy infrastructure has given rise to the idea of "infrastructure as code." For example, Rally Software, a provider of Agile-inspired project management software, has spent the past year and a half creating Chef recipes for its core services, spread across 60 VMware hosts and Amazon Web Services (AWS) instances.

"Before, everything was configured largely by hand, but that's difficult when you have to scale rapidly," said Jonathan Chauncey, a software engineer at the firm. "It also caused problems when debugging problems that were widespread across a stack of servers."

Rally's engineers already had strong Ruby programming skills, so the company selected Chef as its configuration management tool, giving Rally a consistent, repeatable way to install software, Chauncey said. In fact, Chauncey makes the case to write templates for all your systems -- not just scalable Web services and micro services.

"Infrastructure shouldn't be sentimental," he said. "If your infrastructure dies at 2 A.M. and you need to rebuild it, do you really trust your team to do it right in the middle of the night?"

More to the point, having infrastructure as code means that it can be incorporated into other DevOps processes, namely testing and deployment. Rally stores all its infrastructure recipes in its GitHub repository, which are tested and deployed as part of the same continuous integration and deployment processes that runs dozens of times per day to deliver software features. "Regardless of what they are changing -- software code or infrastructure -- it goes through the same process," Chauncey said.

Another benefit of infrastructure as code is you can always have evergreen systems because it's easy to keep systems up to date with the latest versions and packages, said Alain Gaeremynck, enterprise architect at Yellow Pages Group, Canada, and a DevOps manager.

"We subscribe to infrastructure as code and 'disposable infrastructure' concepts," Gaeremynck said. "Instead of building infrastructure once and mindfully monitoring and maintaining it, we just destroy and rebuild it every time [we put out a new release]." As part of a build process, "we can easily sneak in updates to Java or the latest OS, for example, since it's going to go through the QA cycle anyway."

The cloud connection

What, if anything, does DevOps have to do with cloud? For some, having a cloud infrastructure that you can request and provision resources to and from is integral to DevOps.

"For me, a prerequisite of DevOps is the ability to consume resources as you go, and to detach the infrastructure for the central service," said Ram Akuka, director of DevOps at Deutsche Telekom HBS, a provider of telephony services aimed at small and medium-sized businesses.

That cloud doesn't need to be AWS -- or even public. While Deutsche uses AWS for development resources, it also built an internal private cloud based on Citrix CloudStack and VMware for its production environment. It cobbles that environment together using Jenkins for continuous integration, homegrown scripts, Chef recipes stored in GitHub, and services from Ravello to create developer sandboxes of production on AWS. "It works for us," Akuka said.

However, enterprises attempting to pivot to DevOps struggle with legacy infrastructure, which doesn't always play nice with modern infrastructure automation tools, much less private cloud management stacks.

Some infrastructure automation players such as QualiSystems or CFengine tout their ability to handle legacy infrastructure that the likes of OpenStack don't yet support -- if they ever will. "CFengine can automate anything that can take an embedded agent," said Mahesh Kumar, CFengine vice president of marketing. "We may have to compile an agent for that platform because we don't have it, but it can be modified to work."

StackStorm's Powell has seen some shops develop clever workarounds for legacy infrastructure, such as writing an API layer to translate specific actions. "Then, if you have old EMC stuff with limited bindings, it doesn't really matter. They're not throwing out the legacy stuff, they're putting lipstick on it to make it more DevOps-friendly," he said.