chris - Fotolia


The right place to jump in with a DevOps methodology

The potential changes that come with DevOps can scare operations personnel. But a good starting point to introduce the methodology will mitigate those fears.

The DevOps methodology can make any IT operations staff anxious.

A central idea of DevOps is to break down traditional corporate barriers and fundamentally alter the developer/operations relationship, changes that can be difficult and cause plenty of headaches. Such dramatic changes are challenging, so many firms want to know the best place to introduce the DevOps methodology.

Many businesses have yet to implement the DevOps methodology because they struggle with how to make the switch. In fact, 22% of companies are not sure where to start, according to a 2013 research study conducted by IDG Research Services on behalf of CA Technologies.

Barriers to DevOps adoption emerge

Organizations need to start by assessing where the development process stands. While DevOps has been discussed for years, many organizations are still neophytes: 25% of Global 2000 organizations will adopt DevOps in 2016, according to market research firm Gartner.

In some cases, the challenges of switching to a DevOps methodology for application release and management are intimidating for managers. For instance, well-entrenched department silos can resent each other: 19% of enterprises labeled the relationship between operations and development as "uncollaborative," according to the IDC survey.

One big change is how the operations staff interacts with developers. DevOps focuses on short development cycles and quickly integrated feedback rather than prolonged requirements definitions and plodding releases.

DevOps can scare IT operations engineers, especially those who thought they had left coding behind long ago, only to see it now come back into their jobs. Many ops engineers have not written code in years and have little interest in doing so; DevOps pushes them out of their comfort zone.

In addition, the DevOps methodology extends development to new areas. "Business unit managers play a big role in DevOps," noted Stephen Elliot, vice president at research firm IDC.

Start small and expand

So where should a business begin to retool its business process? "Corporations should start in a place that is likely to succeed," said David Paul Williams, a research vice president at Gartner. Ideally, particular developers and operations staff already work well together. If not, conduct group brainstorming sessions and identify individuals who are open minded and willing to look at new ways of interacting.

With any new technology, analysts recommend starting small. Retooling the entire development cycle of an existing application is difficult because there are so many touch points -- and potential problem spots. Instead, pick out a small part of the development process as a test bed for this new DevOps methodology and gradually scale out from there.

Sifting through the possibilities

There are plenty of potential DevOps starting points in the technology stack.

Configuration management is an important part of operations. Traditionally, operations manually installed hardware as it was allocated for testing. Tools emerged to automate that process, such as Chef, Puppet, Pallet and Bcfg2. Configuration automation solutions always deploy hardware exactly the same way, so system configurations are more consistent and generate fewer errors.

Infrastructure automation builds on configuration management. Here, the IT operations group monitors changes to existing applications, hardware and networks. They build test systems that developers use, change them as needed and then break them down once the application deploys. Increasingly, corporations rely on the cloud for DevOps infrastructure services.

Is cloud a DevOps prerequisite?

Do companies need cloud to move to DevOps? Cloud eases the allocation constraints often seen in iterative, test-often DevOps development. However, the flexibility comes with a price, one a business must decide if it is willing to pay.

The self-service nature of cloud computing helps developers quickly provision new hardware. In many cases, they can allocate computer services with little or no reliance on operations administrators. With DevOps, an organization may run a test for a while, find problems and go back to the drawing board.

With public cloud, the allocation occurs with no effect on local IT resources. The challenge is that fluctuating requirements often send expenses yo-yoing.

Private or hybrid cloud computing provides companies with more control over cloud expenses, but fluctuating needs can affect the overall IT systems' performance. In some cases, the rapid provisioning of test environments for DevOps slows the performance of mission-critical systems on production servers. IT managers should segment applications on the infrastructure to avoid such problems.

Performance monitoring is about ensuring the network and application provide suitable response time to users. Performance monitoring is another potential starting point for implementing the DevOps methodology's key tenet of fast feedback. Products for full-stack monitoring come from the systems-level and application-level monitoring suppliers, as well as specialists, such as AppDynamics and NodeWeaver, among others.

System monitoring and alerting is a crucial piece of operations. DevOps teams must be notified whenever infrastructure-related problems arise. Consider tools from vendors such as BMC Software, IBM and Microsoft as well as open source solutions, such as Nagios.

After choosing a starting point, develop metrics to determine what improvements the DevOps methodology delivers over how the group operated before. Look critically at the results; celebrate successes, but also deduce how to continue to improve the application lifecycle in the future.

Next Steps

Set boundaries in a DevOps organization

Listen in for some DevOps advice

How to put DevOps to work

Dig Deeper on DevOps and IT Certifications and Training