API stands for Application Programming Interface. Over the years, it has evolved from a tightly coupled imperative specification to a loosely coupled declarative model. The most common APIs today are RESTful and used to enable integration. Regardless of implementation and the mode of invocation, APIs tend to be associated with app development.
But another API economy has been steadily expanding. It lies within operations. And in that domain, the “A” in API stands for automation.
What APIs in the operational demesne represent is the ability to automate onboarding, configuration, and operation of infrastructure and application services. Thus, the interfaces—the APIs—needed to support operations needs to focus on simplifying automation.
This focus is important as organizations fully enter the second phase of digital transformation and begin to expand automation across the delivery and deployment pipelines. To scale automation requires the ability to develop consistent, repeatable, and predictable processes that embody the deployment pipeline for an app.
A report from Kentik on the State of Automation in 2019 indicated that more than half of organizations (53%) were already using automation for network configuration, and another 40% automated policy management. Our own research shows that percentage much higher—at a super-majority of 86% automating the network. The same research (the State of Application Services), has also found increasing consistency in the state of automation across the deployment pipeline.
The tools organisations are using, too, are shifting. While Python is still one of the most popular options, we are seeing the influence of DevOps and cloud-native apps on IT. The deployment pipeline is increasingly driven by tools like Jenkins and Ansible and triggered by repositories like GitHub and GitLab Enterprise. Looking into the future, infrastructure and app services will be driven by actionable insights produced by advanced analytics.
It is systems, not people, that will invoke APIs across the deployment pipeline. Thus, there is an imperative to design operational APIs specifically with automation in mind. That means several considerations.
First, it may be necessary to consider the system from which an operational API might be invoked. The data available from Jenkins or a repository will no doubt be markedly different than that coming from traditional network automation tools and services. That might mean obtaining data from elsewhere or defaulting to standardised values where possible.
Second, it is critical that we address the need for ‘credentialed machine’ invocation of APIs as separate from ‘credentialed user’ invocation. Most of our authentication systems today assume a “user” that is human. API keys may be a good option but will require some learning on the operational side of IT to deploy, operate, and manage a system that is designed to maintain machine-only credentials. Still, this is critical as we move toward the third and final phase of digital transformation, where AI-assisted application services and ops will shoulder a larger share of operational burdens.
It’s great that we can use tools to build scripts from which operations can be automated today. But it is important to recognise that in the future, the A in API will almost exclusively refer to automation—at least in the context of operations—because of how it will impact interactions and invocation between machines instead of people.
Discussion about this post