As we've all read, the top DevOps practitioners are 10-100 times more productive and are able to deploy code 30 times more frequently, with 50 percent fewer failures than legacy IT departments (2014 State of DevOps Report). What that means for all of us is that if we don't shift our operations to achieve the agility that is now possible - with the right culture, tools, and automation - our competitors will exterminate us. "Software is eating the world" and unless we all move quickly, we will be lunch.

However, embracing DevOps - even with the help of event driven automation to wire your operations together from StackStorm - can be challenging, and having a sense of what's in store can help, so here is a summary of what approaches we have seen prove effective.

1. Integrate DevOps with the existing culture
Adoption of the qualities that make DevOps successful - agility, teamwork, and cross-silo automation - does not always happen smoothly. There will be some bumps in the road as traditional IT silos are broken down. Therefore, the first step for broader enterprise adoption of DevOps is to understand that even the "best" DevOps shops experience difficulties in achieving industry-changing levels of productivity. Set both your own and your organization's expectations accordingly. To get things started, bring in more cross-functional stakeholders to the process. I recommend getting the security engineers and the operators involved fairly early, along with their peers in storage, compute, networking and application development.

We are seeing successes by enterprises that have formed cross-silo working groups and then slice off, integrate, automate, and collaborate around workflows horizontally (as opposed to vertically within a particular group and technology), just after a first lab or test or dev proof of the value of DevOps.

2. Embrace automation
Automation is the heart of DevOps, and when done right it can help you to share and borrow operational patterns, boost productivity, and automate away the routine.

The operators we have seen achieve good outcomes consider both automation and the management of that automation together, while integrating the broader environment. That environment includes monitoring, code repositories, chat, ticketing systems, configuration management, security event management, as well as, various compute environments such as Amazon, OpenStack, and much more. As the James White manifesto puts it - there is only one system. It is your responsibility to understand how it all works, together, and how you can maintain, scale and extend this system over time.

A common anti-pattern is that the tying together of the system - your orchestration - becomes the constraint. Avoid this by adopting an approach to the orchestration that leverages infrastructure as code, open source solutions, and that allows you to share integrations with a broader community.

3. Make the transition from continuous integration to continuous delivery
Continuous delivery can follow naturally from continuous integration, with developers ensuring that every change to the system is releasable. This transition can enable enterprises to act like agile startups, adapting software in line with the demands of their operations and their business strategy. This is where the rubber hits the road, where organizations achieve step function boosts in their ability to respond to customer needs and to counter competitive threats.

But moving from continuous integration to continuous deployment and delivery can be challenging especially in larger enterprises that necessarily have more structure than greenfield start-ups.

This CI/CD workflow can best be designed as a generic packaging and deployment pipeline, with the aim of creating a pipeline flexible enough to be able to push code of any type through, and prepare it for rapid deployment and management. To be truly successful the transition needs to model and automate entire pipelines while treating each automation and integration as code that can be changed and controlled to fit the needs of the business.

4. Establish agile development and operations practices like ChatOps
DevOps is about much more than tools. It is fundamentally about a better way of designing, building and operating businesses. It all comes down to people working better together as a team in an agile environment.

While not yet broadly adopted, top operators have embraced ChatOps. ChatOps is both a powerful technology and a radically transparent means of operating your team or company. With ChatOps, your tools for running your environment are made available to you and your team - in the context that they use for all aspects of their work. In one moment you may be reviewing a blog or an article - like this one - and then in another a message may appear in chat indicating that a build is completed and is being deployed to production.

GitHub perhaps deserves the most credit for embracing and extending ChatOps, having open sourced their Hubot, which provides a means of integrating into many chat clients, including Hipchat, Campfire and everyone's new favorite, Slack. Rackspace's DevOps services team now uses ChatOps to support customers, leveraging Slack as a communications method and StackStorm as their underlying automation platform.

Two features of ChatOps perhaps explain its prevalence in highly successful operators:

• Transparency enabling knowledge capture and transfer:
  • With ChatOps, you can look over the shoulder of your colleagues as they deploy and operate environments. You can even replay their actions, and cut and paste their exact commands. Over time, developers learn to self-provision and troubleshoot and scale, for example, while the SREs or those responsible for automation focus on running and extending the orchestration and tooling including the ChatOps itself.
• Automation becomes a peer, even a friend, and so is trusted:
  • The literature on control theory is filled with warnings of automation that leaves the human operators behind. Some have argued that the Three Mile Island disaster was due in part to automation that did not have good human factor design and, specifically, that only involved the humans when the situation was beyond the capability of the automation. In other words, automation would run along silently until crises and then throw its hands up and alert the humans.

Many packaged proprietary orchestration packages unfortunately also fall into this anti-pattern. Experts arrive, code in automations for your environment, and then depart. By contrast, today's DevOps friendly automation and orchestration solutions often can start with scripts that already exist and in some cases can combine these into ever more powerful automations via workflow and rules engines and community contributed integrations and automations. Automation today - including incredibly powerful pipelines enabling auto scaling, auto remediation and complete and controlled CI/CD - can emerge from an operating environment over time. This orchestration is at least as powerful as legacy packages automation but it remains trusted in part because the practitioners themselves contribute a little bit to enhancing the automation every day.

With ChatOps, your automation is in constant contact with you and even logs into your chat as if it is a member of the team. This limits the risk of automation atrophying the understanding of the humans and also builds trust in the automation. In this context, the "pug me" and other unusual commands many ChatOps operators use appear as not just silly but also useful.

5. Accommodate legacy systems where necessary
Let's be real about legacy systems. They run much of the IT systems of companies throughout America and they aren't going away anytime soon. Because of their continued value, heterogeneity is a fact of life in the enterprise. So when conducting your trials and planning for the broader automation and collaboration of DevOps, think about how to integrate the management of not just a few systems, but a few dozen systems or even more; one large investment bank recently told me they estimate they have approximately 70,000 applications that together comprise much of the intellectual property upon which they run their business. With that many applications and systems, the N ^2 problem is far from theoretical and contributes to an environment that humans literally cannot manually manage due to its complexity. This investment bank has embraced event driven automation both as a means to orchestrating their environment and as a method simply for documenting, as code, all of the integrations and dependencies.

In conclusion, start where you can start - often with special purpose teams for a period of time - in order to achieve initial victories. Do not assume that legacy systems cannot be automated and that you need to wait for some all Docker future to arrive. Layer in as much transparency via tools like ChatOps as possible. And don't forget that there is one system - and embracing the integrations and conditional logic that ties all the components into that one system - is fundamental to achieve the agility and hence competitive advantage achieved by top DevOps operators.