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. 

Declarative versus Imperative

Generally speaking, both declarative and imperative can be thought of as types of APIs. Imperative APIs are the ones you think of when someone says API. It tells the target system exactly how to do something. If you're going to add a virtual server, then you're going to tell it exactly how to do that - even if it takes five or ten or more separate API calls.

That means telling it to create a specific object with the appropriate attributes, say a node with an IP address. Then you separately have to tell the system to create the pool to which it will be assigned, with a name. Then you have to … well, you get the point by now. Imperative APIs place a burden on its user to not only understand the system and its object model, but the steps required to achieve the intended results.

That's the API tax you pay with imperative.

Now, imperative APIs are not a bad thing overall. They are very important when you're building a GUI or integrating with other systems that need the kind of granularity you get with an imperative API. We need imperative APIs, too just not for NetOps and DevOps facing automation and integration.

But for the rest of us, we don't need to know that level of detail. And in fact, requiring that depth of knowledge can be off-putting and slow down automation and orchestration efforts. It certainly doesn't lend itself to democratizing infrastructure and enabling self-service models for DevOps and developers, let alone NetOps outside the specific infrastructure domain.

That's where declarative APIs come into play.

Declarative interfaces specific what you want to do and leaves the logic and workflow to the system to figure out. So rather than specifically telling the system to create a node and a pool and performing all the right logic on the required objects, you describe them and their relationships instead.

Some declarative interfaces use JSON, others XML, and some even still fall back to simple form data. What they all share is that they assume the data describes the objects in a simple, straightforward fashion that requires very little understanding of object models and system hierarchies.

For example, this declaration is fairly human readable. It assumes a basic level of object model understanding, but not so much as to require a certification in a specific product to write the declaration: 

"web_pool": {
     "class": "Pool",
     "monitors": [
         "http"
     ],
     "members": [
         {
             "servicePort": 80,
             "serverAddresses": [
                 "192.0.1.10",
                 "192.0.1.11"
             ]
         }
     ]
 }

This is where the value of declarative interfaces becomes evident; in the reduction of domain knowledge and complexity of provisioning and configuring infrastructure. By reducing the level of expertise required, not only can NetOps work faster and more efficiently, they can now encourage DevOps and developers to take advantage of the capability.

Adopting declarative interfaces as a standard method of managing infrastructure immediately broadens the pool of talent from which you can draw to deliver self-service and advanced automation capabilities. The above declarative interface needs very little explanation for DevOps and developers to understand and be able to use. On the other hand, an imperative interface would require a great deal more attention to learning the infrastructure specific model and workflows before results could be expected.

Declarative interfaces democratize infrastructure by simplifying the provisioning, configuration, and management necessary to automate deployment pipelines and integrate systems with other infrastructure services. And democratizing infrastructure means faster, smarter automation and the ability to encourage the collaboration and cooperation across operational domains necessary to realize benefits from the NetOps and DevOps movements.