F5 : How Declarative Interfaces Democratize Infrastructure

APIs are the new CLI. But declarative rules the roost when it comes to what kind of API you're building.

An API - an application programming interface - is a critical capability today. Organizations have them at the business layer, to promote partner integration and innovation by so-called 'citizen developers'. Applications have them, to ease integration and decouple business logic - which may change frequently - from interfaces - which should not change as frequently. And infrastructure has them. From switches to routers, from application services to middleware and databases, the infrastructure that comprises the delivery and deployment pipelines are enabled with APIs.

That, in itself, should be reason to pause and reflect on what that means for the up and coming NetOps community. Because while organizations tend to standardize on a few key application infrastructure components, they are not as likely to standardize on just a few key network and application services infrastructure components.

Of the average sixteen different application services organizations use to make their apps go faster and safer, it is a certainty that they are delivered by more than a handful of infrastructure components. If we generously assume the ratio is three application services per component, that's still five different devices - with five different APIs.

The problem with this is that it is often the case that infrastructure providers took the statement, 'The API is the new CLI' a little too literally. That is, the API is merely a REST-enabled reflection of the CLI.

Anyone who's worked with CLIs across infrastructure components understands that CLI navigation maps very closely to the infrastructure's object model. APIs often fail to do more than lift and shift this design to HTTP. Which means those attempting to take advantage of the API must necessarily also learn the object model of the device in question.

This level of abstraction is impeding forward movement of automation and orchestration, because we now need to find not only automation talent, but automation talent with some measure of expertise in five or more different network infrastructure models. The level of expertise required often demands domain knowledge as well, spanning from rudimentary understanding of VLAN configuration and routing to the relationships between virtual servers, virtual IP addresses, nodes, members, and pools.

Exposing the underlying complexity of infrastructure is detrimental to encouraging adoption and enabling automation. The purpose of interfaces should be to abstract away the models and logic to shield users and operators from its complexity. The GUI does this, by eliminating the need to navigate object hierarchies to configure a simple service.

Which is why it's often frustrating to find that the API has reintroduced this navigational nightmare.

This problem is not peculiar to network and application infrastructure. To wit, MuleSoft in its 'The Rising Value of APIs ' research found that the highest demand - 47% of respondents - from customers and partners for API integration was 'customized APIs that fit a specific business need.' Behind it came better documentation (19%), 'no code' integration templates (19%), and SDK wrappers for APIs they need and use (13%).

All of which can be summed up as a plea for simplification. And in technology, simplification means abstraction.

And that brings us to the point of this post, which is that declarative interfaces are that abstraction. By simplifying the interfaces used to provision, configure, manage, and integrate infrastructure today, declarative interfaces democratize infrastructure and open up opportunities.