State of Application Delivery 2017: Automation, APIs, and DevOps

The digital drumbeat has picked up its tempo in the past year, driving those responsible for the network and infrastructure that delivers apps to consumer and corporate users to look to automation and the more agile, collaborative perspective brought by DevOps. But even as organizations embrace automation and recognize the importance of programmability (APIs and templates), they’re not quite ready to settle on a single stack to rule them all.

With over 2100 respondents spanning every function within IT – from app developers to CEOs to security and network engineers – our 2017 State of Application Delivery survey discovered that as DevOps shifts further into production, its drivers and perceptions shift as well.

01 | AUTOMATION ADOPTION

Digital transformation requires more than just a corporate API and a hoard of developers. We’re seeing just as much (if not more) focus on the internal changes necessary to enable the business to scale efficiently commensurate with its growth. Throwing more people at tasks is no longer a viable means of scaling business operations because it’s not just about getting things done, it’s about getting things done quickly and efficiently, too.

That means more systems, more things, more apps, more threats, and more identities to manage. Within IT, the same struggle to scale to meet that demand is ongoing, and increasingly responded to with automation and orchestration.

In 2016, only 21% of respondents in our State of Application Delivery survey were using one or more automation frameworks. A year later, that jumped to 52% of respondents, with more than half using two or more systems at the same time.  Every system saw growth, with CIsco, OpenStack, and VMware seeing the largest gains with 19%, 14%, and 22% respectively. As if to prove the point that network and app services automation is important, Cisco ACI is in use by 35% of respondents. Given that it’s relatively new compared to stalwarts like VMware and even OpenStack, that’s a considerable jump in just two years of tracking.

02 | HYBRID-STACK RULES PRODUCTION

While 39% of respondents are using only one system to automate infrastructure and app services, the majority (61%) use two or more. We note that the larger the organization (and perhaps unsurprisingly the more applications under management), the larger that number grows. The average number of automation systems in use is 1.8, but if you’re managing 3000 or more applications, you can expect to see an average of 2.43, instead.

It is fascinating to note that the average number of cloud models in use is also 1.8. It is entirely possible that automation in some organizations is tied exclusively to their adoption and use of cloud computing.

This makes a great deal of sense for enterprises that have long relied on VMware to virtualize their compute infrastructure. There is virtually (apologies, really) no reason for an organization to eliminate existing automation powering their compute provisioning and management. The answer more often lies with additional systems, like Cisco ACI, that expands provisioning and management automation to the network and app service infrastructure.

Nearly half (47%) of those relying on a single automation framework settled on VMware. Cisco garnered 26% of respondents with only one framework, while OpenStack netted 9%.

7% rely solely on Python scripts to realize automation and orchestration, which makes the case for a strong and well-supported customer-facing community around network and app service platform APIs.  

03 | SCALE OVER SPEED

The most often cited benefit of DevOps is speed. Metrics associated with measuring its success revolve around frequency of deployment and time to market. When it comes to network and app service infrastructure, however, scale becomes the driving force behind automation and orchestration. Only 14% of respondents cited Time to Market as the driver behind the use of automation frameworks, settling on scale (37%) and opex reduction (37%) as the reason behind their adoption.

We suspect that OpEx reduction is code for “maintaining the budget quo.” With IT budgets barely moving or stagnant according to Computer Economics latest survey, optimizing budgets is no doubt a significant concern. Scale without adding more staff is difficult, given the already significant device to engineer ratios, so automation and orchestration is one way to scale without dramatically increasing one’s operational budget.

It is interesting to note that automation often has the impact of improving speed of a deployment. When mapping value streams as first step to orchestrating deployment processes, it’s often easy to find the “wait times” causing delays in deployment. Those wait times are often hand-offs between teams or “time in queue” waiting for an engineer to free up to perform a specific task. Automation can reduce those wait times and the time in queues, which has the benefit of speeding up the entire process, thus improving time to market.

A peek at SDN drivers tells a similar story, with 62% adopting SDN to rein in operational expenses.

04 | PROGRAMMABILITY IS CRITICAL

Long before software-defined everything became the status quo, programmability enabled intra-vendor ecosystems by providing the means to integrate products together to offer more comprehensive capabilities to customers. Those same APIs have now blossomed into the Other API economy and enable a wide variety of functions and capabilities both directly to customers and by encouraging broader integration with open source systems.

Whether it’s related to cloud or data center bound infrastructure, programmability is how networks and app infrastructure get automated, processes become orchestration, and scale is ultimately achieved. Programmability is most often associated with APIs and increasingly with the notion of templates. Both saw dramatic spikes in perceived importance in our survey, with clear majorities designating both as “more important” characteristics for infrastructure.  

Less well understood and discussed is data path programmability; that is, the ability to intercept, inspect, and modify data in flight. This enables application layer functions like rewriting URLs, securing cookies, and adding/removing HTTP headers as well as deeper inspection of protocols that lends itself well to security (particularly in the face of a new exploit).

Surprisingly, this capability is considered “more important” than either APIs or templates. While 52% of respondents deem APIs “more important” and 53% say templates are “more important”, 57% tag data path programmability as being “more important”.

The business benefits of data path programmability in terms of agility, particularly in the realm of security, provides ample impetus for respondents to embrace such capabilities.

Programmability, automation and orchestration are not going away, and it’s heartening to see the significant percentage of roles outside app dev embracing these concepts. While they may view automation, orchestration and related concepts as tactical responses to meeting challenges like budgets and scale, they are certainly partaking of the buffet that is DevOps to provide the air cover necessary to enable the business’ digital transformation, inside and out.

Feel free to peruse the data in slide format on SlideShare.