The virtualization fairy won’t create APIs out of thin air, but a visit from her may kick-start a necessary (re)evaluation of the role of the API in the new network.

The way some people talk about the “virtualization of the network” and how it’s necessary for cloud computing and automation and creating a flexible infrastructure you’d think that the transformation from physical form factor to virtual form factor was a magical one that conferred not only the ability scale on-demand but the APIs, as well.

There are actual two misconceptions here that need correcting and you know me - I’m going to correct them. First seems to be the erroneous belief that in order to fit into a dynamic data center a network infrastructure component must be virtualized. The thought here seems to revolve around a belief that only by becoming a virtual network appliance (VNA) can a hardware component suddenly be imbued with the control plane, the API, required to be automated and orchestrated in a dynamic, on-demand way. In other words, to have its capabilities delivered as a service.

Not true at all. Many network infrastructure components have been control-plane enabled for years, since 2001 or so, in fact. These control-planes are standards-based, almost always leveraging HTTP and SOAP or POX (Plain Old XML), and provide the means by which these components have been integrated into third-party management applications for many, many years. That management API, the control plane, is what confers flexibility, programmability, and integration with the rest of the infrastructure and management systems that ultimately enable a dynamic data center. 

Second is what seems to be the belief that the transformation from physical to virtual somehow births an API that did not before exist. That’s simply not true. While moving from one form factor to another inherently allows management at the container level, i.e. of the virtual machine, it does not magically confer the ability to manage what’s running inside the container, i.e. the actual networking component.

That requires an API of some kind, whether that’s SOAP or REST or whatever. If the API didn’t exist before “virtualization” there is no guarantee it will suddenly exist after the process of virtualization is complete. Sometimes the process of virtualization seems to result in an API. That’s not because of the process, it’s because (a) the organization realizes that be a part of the new infrastructure an API is going to be required and (b) as long as they’re mucking around in the code-base to virtualization the solution it’s a really good time to add an API.

It’s more a matter of “well, we’re in here anyway…let’s just do it” than anything else. This isn’t a “cause –> effect” chain but more a coincidence, albeit perhaps a logical and financially smart one. If the API existed before the virtualization-fairy showed up, well, it’s almost certainly still going to be there after it’s virtualized.

That said, it’s important to look at those APIs with an eye toward how they fit into modern virtualized and dynamic data centers. Because many of the APIs were developed at a time when everyone was high on SOAP they are generally based on SOAP. Standards are good, but standards and programmatic methodologies change – especially in the world of development and integration. Over the past decade the mood of development has shifted from extreme to agile, from SOAP to REST, from static to interactive. But the APIs that existed nearly ten years ago to manage networking components still exist, and they can’t really be changed.

That’s right, they can’t be changed. Not because it’s technically infeasible but because of the number of third-party solutions that have been built based on those APIs. It’s a business decision, a matter of support for partners and the developer ecosystem. You simply don’t rip an API out from under an organization’s nose when they rely upon that API for operational stability and resilience. Those network infrastructure components have not been previously endowed with an API are in luck as they can be enabled with an API that’s more in line with modern development paradigms. Although how long that will last is of course not something upon which I’d be willing to bet as the mood could shift yet again quite dramatically and unexpectedly. Technology is like that, it evolves in fits and starts rather than on a slow, predictable curve.

For solutions already enabled with a standards-based API it may be necessary to layer a more business or task-oriented API, a more RESTful one by design if not implementation, API atop the existing API. This will actually likely be an imperative in the future as IT begins to figure out that there is a new IT discipline emerging that will be essential to successfully implement and manage a modern dynamic data center.” Development skills will combine with operational skill sets, but it will do so lightly. The ‘development’ required for automated operations and management will need to be more thorough and programmatic than the scripting traditionally employed by operations but less heavy than the full enterprise architecture framework development done by developers. This means a more RESTful, resource-centric, API is required as opposed to a heavy, function-centric SOAP API implementation.

So while the virtualization-fairy can’t drop her magic virtualization dust on components and confer APIs on network infrastructure components, a visit from her will likely kick-start vendors into considering (or reconsidering) the makeup of their current API support.