Integration an Obstacle to Achieving Continuous Deployment
APIs are not integration. They are a means to implement integration. And by the challenges we’re seeing cited by ITOps, they aren’t enough for IT to get continuous.
In the realm of application development, integration has always been a four-letter word. From DLLs to shared libraries, from ESBs to message queues, we have explored myriad means of integrating applications with other apps and services.
In the domain of network management, it has been especially important. Integration has been key to manage the complexity inherent in the multi-vendor, heterogenous pipeline of network devices and application services that deliver and secure applications.
Today, that pipeline is increasingly automated. Developers and DevOps have successfully surmounted the challenge of integration to build out a continuous development pipeline. They now expect - nay, demand - that IT do the same with the deployment pipeline.
IT is responding. According to "NetOps Meets DevOps: The State of Network Automation", a significant percentage of production pipelines are at least partially automated.
But the adoption of continuous deployment does not come without challenges.
Typically, we see 'culture' highlighted as a top inhibitor of DevOps and DevOps-related practices in surveys. In the State of Network Automation survey, culture was one of the top three. However, it was not the number one frustration. Neither did it claim second place. Those spots were occupied by frustration with a skills gap and my favorite four-letter word, integration.
These two challenges are, in fact, related. It is the skills gap in part that drives integration as a significant source of frustration. This is because NetOps are not - and this will surprise you - developers.
This is the real rub. One of the reasons DevOps has been so successful with its efforts to enable continuous delivery is that it's comprised primarily of developers. Developers who live and breathe code. They have the know-how to integrate what needs integrating. NetOps doesn’t necessarily have that skill set. The deployment pipeline is comprised primarily of devices and systems that integrate via protocols. Well-defined, RFC-based protocols that don't require code-based integration because they were designed not to.
This is a completely new challenge for NetOps, and one they aren't necessarily prepared - or skilled - to meet.
This challenge cannot be addressed by APIs. While API-enabled infrastructure remains important - identified as such by three-quarters of respondents to our State of Application Delivery 2018 survey - APIs are not integration. They enable integration, but the actual work of plugging-in and hooking-up disparate devices and systems with management consoles and controls remains the responsibility of IT. Who do not necessarily have the skills necessary to do so. These challenges have a profound impact on day-to-day operations, as they wind up dictating a very manual approach to the deployment pipeline.
This explains the predominantly "CLI / script-based, per-device" management methodology used by more than half (52%) of NetOps. The disparity between multi-vendor, orchestrated operational approaches cited by DevOps and NetOps was stark. 29% of DevOps use a multi-vendor, orchestration approach while a meager 12% of NetOps do the same.
The disparity speaks loudly to the need for a better approach to integration for NetOps and the same kind of fervent zeal applied by the community and the market to overcoming the integration challenge.
If you’re seeking to understand this new world of automation and orchestration, check out our free and online Super-NetOps program. In addition to focusing on applying automation and orchestration to F5 technologies, it also provides the foundational knowledge you need to work with REST APIs, use tools like Postman, and craft automation playbooks.