Beginning DevOps: How to Bring Your Company Along on the Journey

The concept of DevOps in IT has been around for over 10 years and represents a change of focus in the industry-from engineering practices that center on the construction of software to practices that target both construction and operations. Relatively new source control, software automation, and delivery tooling have been a part of this movement. But DevOps is primarily a way of working that is facilitated by tooling, rather than being defined by it.

Accepted definitions of DevOps therefore tend to focus on the cultural aspects of IT delivery: breaking down team silos and fostering organizationwide collaboration to achieve end goals. They also emphasize investing in automation to improve reliability, as well as collecting metrics to improve awareness of the delivery pipeline.

In this blog post, I discuss the key management challenges involved in moving a team to a DevOps methodology. I also cover the technical and cultural requirements for a transition that achieves your business goals, considering matters such as whether to hire in, how to manage change, and what to focus on as you progress.

DevOps, Agile, or Site Reliability Engineering?

Other new terms that have sprung up in the last 2 decades, often related to DevOps, are Agile and Site Reliability Engineering (SRE). Agile is a set of project management practices that have developed since the original Agile Manifesto was published in 2001. These practices emphasize self-organization and continuous adjustment to delivery teams' working practices. By contrast, SRE is an engineering discipline that focuses on applying software engineering skills and practices to reduce the ongoing cost of operations. Although Agile and SRE practices are closely correlated with high-functioning DevOps organizations, neither is necessary for transitioning to a DevOps way of working.

Transitioning to DevOps

What, then, is required for transitioning to a DevOps team? Is the payoff worth the effort? In this section, I outline some of the factors and best practices you should consider when making the change.

Determine Your Motivators

The best way to start is to determine your motivators. There can be many reasons for moving to a DevOps methodology, including speeding up delivery of new features, reducing the cost of delivery and maintenance, improving quality, or making decisions by applying metrics. Deciding which you want to emphasize early on will help as you proceed.

Communicate Your Goals

After you determine your motivators, it's important to stay focused on these goals as you seek to change the working methods of your teams. 'DevOps' is a broad and loosely used term, so you can easily get distracted by the multiple paths available. Communication is key here, because at many points, the changes you want to make might be misunderstood or questioned. Inevitably, changing the way teams deliver and operate any product will initially incur a cost-and probably change people's roles-so it's vital that they see the bigger picture.

Manage Change

One of the common mantras of the DevOps community is 'You build it, you run it.' This phrase can mean that a single team is responsible for both development and operations, and working practices might alter. For instance, developers might move to an on-call rotation.Another common modification is to replace manual change-control processes and operations with automated processes, such as presenting interfaces as APIs. Implementing either of these changes involves adjustments to working practices. As time goes on, and change gathers momentum, you might find that you need to exercise your management skills, or involve Human Resources, to smooth these transitions.

Prepare for Technical Barriers

Although introducing DevOps is primarily a cultural change, specific technical skills can help facilitate the transition. Most notable among these skills are proficiency in Git, continuous integration tools such as Jenkins, and infrastructure automation tools like Chef and Ansible.

It's generally preferable, when possible, to train your staff in these new skills.Aside from being more cost effective than hiring in new staff, teaching new skills can increase the level of buy-in from the very people that best understand the business already.

To achieve the DevOps goals of automation and improving collaboration across previously siloed teams, you might also need to make technical changes to business processes. For example, many change-control and documentation systems are not conducive to a collaborative way of working, and you might need to replace or upgrade your existing systems to support this aim.

On the Cloud Analytics team at NetApp, for example, we use Atlassian's JIRA and Confluence products, because we've found that they give us the real-time collaboration and culture of open communication that DevOps requires.

Remove Bottlenecks with APIs and Services

Another aid to automation is to use more formal, defined APIs instead of on-demand request systems for services within your business. Typical examples of such services are network firewall changes or requests to install a specific version of software on a server. APIs can be implemented with REST interfaces, for example, if the service that the API is fronting needs to be fully automated and scalable. Alternatively, automation could be webform based if the processes are still maturing or aren't large scale. Whichever path you take, for a true DevOps approach, it's important to depend less on people performing manual steps, and move to a service-based model that reduces bottlenecks.

At NetApp, we make the most of automation in the tools we use, and extend this approach to the tools we build. Our portfolio of cloud services offers integration APIs to support you with your transition.

Technology Is a Means, Not an End

As I mentioned at the start of this blog post, DevOps is facilitated by tooling, not defined by it. One common misstep in pursuing the transition is believing that tools alone will change habit, behavior and bad practice. It matters little whether you use Ansible or Chef, Confluence or SharePoint. Your best path to achieving your goals is through improving communications and automating where possible, rather than adopting a technology with no regard for the context in which the work gets done.

Be Aware of Cultural Barriers

How can you instill the right mindset within an organization that hasn't already embraced DevOps, and what will the barriers to such changes be?

The first major barrier is institutional inertia. Change within any organization can create feelings of instability among staff members. The changes that DevOps can bring to roles, required technical skillsets, team structure, and team relationships can be troubling to many. Both overt and covert resistance can be detrimental to the success of such changes.

Unfortunately, not everyone will want to come along for the ride. But you can increase buy-in and velocity by presenting the changes openly and as opportunities for career development. Involving team members in decision making is also beneficial. Finding key staff members who champion the transition, and supporting them when possible, will also help increase the velocity of change, both technical and cultural.

Even with a supportive team and upper management, changing the way a team works does not come for free, and here you need to watch out for another potential challenge: investing resources in changes well before you see a payoff. If you're not prepared for that fact, you can be blown off course, because the pressure to revert to familiar ways of working can become overwhelming. Unfortunately, DevOps is often presented and perceived as a panacea that reduces cost and improves quality without pain. Of course, no such magic bullet exists in any business.

Finally…

When adopting a DevOps methodology, you have no shortage of choices. These choices can be bewildering, so it's vital to keep in mind what drove you to make the change in the first place. Because technical and cultural challenges will provide headwinds that can be difficult to overcome, it's critical to get buy-in from company stakeholders, both below and above. Moving to DevOps is a process of continuous improvement, so when your changes start paying dividends through the metrics you've defined, make sure that you publicize your successes around the business to keep the momentum going.

As your changes build on one another, you will feel the benefits of an increase in operational control, and predictability of business outcomes. You'll sleep better knowing that your established processes are there to handle any problem and that your engineers have the information they need to resolve issues quickly. And your leadership will be happier, because a faster development cycle reduces time to market.

Among the many choices out there, NetApp offers a range of cloud services built by DevOps for DevOps. Whether you're building applications or managing them, it's worth taking a look at our portfolio of cloud services.