API growth forcing vendors to take notice or risk losing out
The API is fast becoming a must-have in modern networking. But API growth is forcing vendors to rethink how they want their devices to be configured and managed.
Just a few years ago, APIs were something of a white rhino in the network engineering world.
Engineers had heard the term, and possibly had a passing familiarity with the idea, but largely thought of them as a piece of the software development sphere. Yet, with the advent of software-defined networking, the concept of API growth as a viable alternative to the tried-and-true command-line interface (CLI) had begun to stick. Indeed, in 2017, the API is seen as a minimum barrier to entry for networking vendors of all shapes and sizes, regardless of age or market penetration. The API has become the coin of the land in networking, without which vendors are increasingly marginalized and risk losing their proverbial seats at the table.
Very generally speaking, an API is a means for software to interact directly with a device in question, bypassing whatever built-in methods the manufacturer might have traditionally delivered -- things like its own CLI or graphical user interface. In other words, an API allows me to write my own interface programmatically. That's the idea, but in many cases, the reality does not deliver in the way we expect or desire -- or, in fact, deliver in any meaningful or useful way at all.
Vendors caught flatfooted by API growth and adoption
The problem is the idea of programmatically interfacing with network devices, while not particularly new at its core, is just recently reaching critical mass. As a result, many vendors were struck by the speed at which industry views pivoted. In many cases, the vendors caught the most flatfooted by API growth were the big, established players. Broadly speaking, the nascent companies, the startups, had their eyes on this movement much earlier, or were actually driving it from the beginning. Many of the big boys, it seems, were watching and waiting to see what happened, and kept on with the watchful waiting for far too long.
Broadly speaking, the nascent companies, the startups, had their eyes on this movement much earlier, or were actually driving it from the beginning. Many of the big boys, it seems, were watching and waiting to see what happened, and kept on with the watchful waiting for far too long.
Another challenge for vendors seems to be developing an API that is fully open or exposed and fully functional. I should be able to write code against a particular device and completely control every aspect of that device -- at the same or better level -- as using the native CLI or GUI. If I instead receive only a random percentage of control that is not 100%, then you as a vendor have not achieved the level of sophistication within that API that I as an end-user engineer require.
As I operate ostensibly as a consultant, I visit a large number of large-scale data centers and companies. I talk to engineers on the ground, the CIO setting the organization's direction and everyone in between. It is rare these days to wind up in a discussion around network automation or programmability. That should not surprise anyone, really.
The other, more interesting side of that coin is companies are now asking about those concepts as they make purchasing decisions. Let that sink in for a minute. Companies are actively directing their purchases based not only on overall fitness to the problem at hand, and the monetary cost overall, but also on the openness and robustness of the system. That should keep some vendors up at night.
API growth feeds maturation of ecosystem
The faster and more openly companies release APIs to the public, the quicker the overall user ecosystem becomes. Companies like Glue Networks and SolarWinds -- though not device makers -- are fairly ubiquitous players in the network space, and they have very robust ecosystems. Users freely contribute custom code to the respective repositories, interact with one another to solve problems and generally put back into the ecosystem as much as they take out. Open source software such as Puppet, Chef, Ansible and SaltStack are additional examples.
Hardware vendors like F5 Networks, meantime, opened up their own API access. In F5's case, that allowed anyone with some programming chops to shape and manage the notoriously difficult-to-configure BIG-IP box from their own systems. As a result, there are hundreds of examples on the F5 developer network showcasing people configuring a BIG-IP box using tools like Ansible and Python.
Making APIs more valuable
The writing on the wall is clear: API growth is forcing the network industry to move -- being dragged, in some cases -- toward full programmability as the primary method to not only configure devices, but also as the means through which they can strategically manage those devices.
While the capabilities of any network device are obviously a primary concern, the robustness of the software interfaces underpinning that device is increasingly becoming the pivot point in any sales decision.
And with that comes the question of how big the ecosystem for that device and manufacturer is, realizing that is a large predictor of success in the market. Remember, Sony didn't lose because Betamax was the subpar technology -- far from it. Sony lost because VHS was essentially open-sourced, while Sony kept Betamax locked and closed. The market is littered with examples like this, and current networking vendors would be wise to take note and act accordingly.
