Three Things Holding You Back from Embracing DevOps

No, not you. You. Executives aren’t nearly as giddy over DevOps as those in the trenches, and the answer may be found in one of these three key concerns.

High-performing organizations have not just adopted, but embraced, DevOps. Puppet Labs’ seminal State of DevOps report has shown us this for the last two years, and I imagine it will once again reinforce that relationship in the coming year. Organizations are, according to a number of industry surveys and studies, adopting DevOps. But just as they adopting agile, lean app development methodologies in the past, adopting doesn’t always mean what we think it means. It turned out that what organizations really mean by “adopting agile” for app dev was that a relatively minor percentage of their projects were using agile. It did not mean that they’d gone whole hog and taken the polar plunge by embracing it for every project.

The same seems to be true for DevOps, where respondents are adopting with enthusiasm – and realizing results – but executives on the whole seem to still be lukewarm to the approach, rising only two percentage points in “strategic impact” year over year – from 15% in 2016 to 17% in 2017 according to our State of Application Delivery survey. While cloud architects and self-identified “DevOps” roles might be full bore with their DevOps initiative, and even over the wall in production, executives are still lagging behind in embracing the approach. Which really means that “organizations” are not necessarily all-in (embracing) DevOps.

There are three key concerns that are likely responsible for holding back IT and business leadership from giving DevOps the truly warm welcome it deserves.

1. Time. Internal IT projects of any kind that require a migration mindset – whether traditional to cloud, monolith to microservices, manual to automated – are sometimes viewed as little more than a time wasting proposition. They don’t contribute directly to business growth and thus the time spent on such projects can be onerous for business stakeholders to support. It behooves those supportive of DevOps to illustrate to business leaders a clear set of objectives and expected benefits that will be arise from embarking on such projects. Whether it’s cost savings or a more responsive IT, it’s important for business to understand the anticipated payback on the investment to get them to buy in and support the effort. A penny saved may be a penny earned, but a penny invested is often a dime earned. Investing in DevOps now and organizations will reap the rewards later.
    
2. Disruption.  No IT leader wants to be the cause of business disruptions. Investing in a DevOps initiative now can be disruptive, particularly if it causes a slowdown in the production pipeline when everyone knows you need to be speeding it up. Because enabling production for automation and orchestration often means mucking with the systems responsible for day to day business, any initiative that requires it may cause an undesirable disruption. The reality is that relying on outmoded, manual methods to provision, scale, and manage systems may be the real disruption – if not today, then tomorrow. One of the hallmarks of a frictionless production environment is the ability to respond on-demand to needs for capacity and services. That’s something that becomes increasingly difficult to achieve as IT bows under the weight of growing demand caused by digital transformation efforts. No risk, no reward. Taking on the risk now likely incurs less risk than when your application portfolio has grown by 2x or more.
    
3. Lock In. A common fear of IT leadership is that of being “locked in” by choices. The good news is that the preponderance of network devices and systems supportive of automation and orchestration are based on open standards protocols and concepts like HTTP, REST, and JSON. This is where time spent up front designing and architecting a system that takes advantage of APIs and templates as much as possible will pay off later. Integrating with devices or systems that require step-by-step recreation of CLI-issued commands via an API will almost certainly lead to lock-in. This is one of the biggest benefits of templates – reducing the reliance on device and system-specific APIs and thus limiting your exposure to only a few commands that are easily migrated to a new system or app in the future.  Make sure infrastructure supports a REST-based API and when at all possible, use templates to enable easy extraction from systems and environments later on.

There are other concerns, of course, but primarily these three key concerns resound throughout data centers and across time when it comes to technology and methodology adoption. It takes time, it can be disruptive, and there’s a very good chance of lock-in. Due diligence, and a thoughtful approach to implementation, along with an invest now, benefit later attitude can ease those concerns and engender a better chance at successfully laying a firm but flexible foundation that not only enables but accelerates the digital transformation necessary for business to grow now and in the future.