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.
About the Author
Related Blog Posts
Why sub-optimal application delivery architecture costs more than you think
Discover the hidden performance, security, and operational costs of sub‑optimal application delivery—and how modern architectures address them.
Keyfactor + F5: Integrating digital trust in the F5 platform
By integrating digital trust solutions into F5 ADSP, Keyfactor and F5 redefine how organizations protect and deliver digital services at enterprise scale.
Architecting for AI: Secure, scalable, multicloud
Operationalize AI-era multicloud with F5 and Equinix. Explore scalable solutions for secure data flows, uniform policies, and governance across dynamic cloud environments.
Nutanix and F5 expand successful partnership to Kubernetes
Nutanix and F5 have a shared vision of simplifying IT management. The two are joining forces for a Kubernetes service that is backed by F5 NGINX Plus.
AppViewX + F5: Automating and orchestrating app delivery
As an F5 ADSP Select partner, AppViewX works with F5 to deliver a centralized orchestration solution to manage app services across distributed environments.
F5 NGINX Gateway Fabric is a certified solution for Red Hat OpenShift
F5 collaborates with Red Hat to deliver a solution that combines the high-performance app delivery of F5 NGINX with Red Hat OpenShift’s enterprise Kubernetes capabilities.