Tomorrow’s Networking Decisions Will Revolve Around APIs
November 6, 2013 1 Comment
- In a software defined data center, APIs will be the defining functions differentiating one product from another.
- Enterprise IT will need to learn about the pertinent aspects of APIs application development to make informed product decisions.
Are APIs part of your checklist when investigating networking products? If not, they should be. In market segments like switching and, speeds and feeds have become a non-issue because networking manufacturers are reaching performance parity fairly quickly. The majority of switch and router features are also fairly uniform across product lines as well. The differentiators are found in SDN features such as overlay or OpenFlow support, automation capabilities, and integration features.
APIs are critical when making a networking purchase because everything else in the data center depends on them. The so-called southbound stuff like overlay protocols and OpenFlow are going to be checkmark items when evaluating switches and controllers—yes, you are getting a controller whether you call it that or not. The APIs define how everything in the data center will interact and interoperate, including switches, routers, firewalls, load balancers, controllers, orchestration and automation systems, cloud platforms, and management and monitoring systems.
Good APIs are needed to keep everything running. The question is what makes a good API? I’m not a programmer, though I have slung more spaghetti code than I care to admit, and I bet you probably aren’t a programmer either. Migrating to an SDN doesn’t mean you or your networking staff have to become programmers, but you do have to learn some programming concepts and most importantly, what a good API looks like.
Christian Reilly, manager of EPC systems for Bechtel, said in the forward to George Reese’s The REST API Design Handbook, “Deliver a well-defined, well-structured API and you will provide the keys that unlock the door, enabling a new paradigm for accessing large complex systems while conveniently shielding that complexity from your audience.” The book, and Reilly’s statement, is aimed at developers, but the message applies to the audience of SDN API’s. That’s you.
To me, a good API is:
• Easily accessed by external systems like controllers and cloud platforms without having to incorporate software libraries into applications.
• Easy to use. For example, I want to send a minimal set of commands to create a path between two locations and let the “network” figure out the details. I don’t want to program the individual steps to configure routing systems or manage routing tables.
• Not going to have deprecated functions removed in favor of new ones because doing so puts existing applications at risk of lost functionality if they are not updated.
• Exposes 100% of their product functions via APIs, which guarantees integration without exception, because an unimportant function to a vendor could be critical to your data center and without 100% coverage, someone has to work around the exception. In a software defined anything, exceptions add complexity and brittleness—two things you don’t want.
• Will have native capabilities to generate audit logs and to reverse changes in the event of an error.
Those requirements are a tall order and while certainly not exhaustive, but I think they are a starting point in getting you to think about the kinds of requirements SDN will place on your purchasing and deployment plans.