Mike Fratto

Network Computing Editor


Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

See more from this blogger

Four Signs of SDN Support to Watch for from Vendors

While the hype around software-defined networking (SDN)reaching a fever pitch, a common complaint is that network admins are not programmers, nor would they let programmers loose on the network. Both of these complaints are distractions. SDN isn't going to force network admins to become programmers any more than SNMP made them ASN.1 notation experts.

Adopting SDN won't mean your programmers will be coding the network higgledy-piggledy, but it may mean your developers will be slipstreamed into your change control process. Regardless, you will need to get up to speed on development concepts. SDN is coming, one way or another.

More Insights

Webcasts

More >>

White Papers

More >>

Reports

More >>

As I already noted in "Searching for an SDN Definition: What Is Software-Defined Networking," there are many definitions of SDN. What I want to focus on now is how SDN will be supported in network equipment and what you need to look for. The approaches that vendors are taking are early stage, but once they get on a track, they are locked in for a long time. If you buy their equipment, you're committing to their long-term strategies. You may want to look for the following:

APIs, Not SDKs: First and foremost, does your vendor use application programming interfaces (APIs) or software development kits (SDKs)? SDKs are composed of a bunch of programming-specific language libraries that you need to download and integrate into your environment; APIs are methods and variable declarations placed on the equipment or management server and then called remotely from your own code (or another vendor's).

You want to see a plan for APIs. Much of the development work in cloud computing, automation and orchestration is moving to APIs because they're language-agnostic. Utilizing APIs also shifts the responsibility for version maintenance to the vendor writing the API.- This isn't the case with SDKs--if you upgrade part of a system, others may break as a result.

No Deprecated APIs, Ever: In The REST API Design Handbook, George Reese, CTO of enStratus, wrote, "As the world becomes entirely API driven, we have to do away with the notion of elegantly deprecated APIs. There's never really been any such thing as elegant deprecation, anyway."

Get a promise from your equipment vendor that it will never deprecate API calls and all versions will be supported. This will be a contentious issue, but the problem with deprecated APIs is that while the vendor may have moved on, you may have other software or systems that rely on older APIs that will break when deprecated. The commitment to API support means the vendor has to really think through its API designs, and any investment you make in the equipment and other systems on which it relies will remain useful.

Vendors will complain that no deprecation isn't possible and will offer any seemingly compelling reasons why that's the case. Tough. You pay vendors for solid, reliable products and as the use of APIs expands and becomes more intertwined with other systems, a reliable API is critical. I know you've lived through forced upgrades and the havoc they can wreak.

100% Feature Coverage: Raise your hand if you have ever worked in a vendor's GUI but had to drop to a CLI to do something. Come on, don't be shy, get 'em up there. If you've worked in IT longer than two weeks and your hand isn't up, you're either forgetful or lying. There is no excuse for anything less than 100% feature coverage. None.

Less than 100% coverage means the vendor hasn't thought through its API strategy well enough, and that will come back to bite you in the tuckus. Either you or some other vendor will want to perform some function that should be supported in the API but won't be, and a workaround will have to be found. Workaround being a euphemism for hack.

Vendors Eating Their Own Dog Food: Does your equipment vendor use its own APIs? One of the things that blew me away when I was getting a demo of Cisco's UCS was that not only does its API have 100% feature coverage, but the UCS manager is also built entirely with the same API that the company exposes to customers. If vendors don't use their own APIs--the same ones they give customers--then they aren't taking them seriously.

If the vendor is using its own API, it means that only does it have some real skin the API game, but that it also likely has a better API overall. It's one thing to file a bug report as one of many customers. It's another thing when Bob the developer can go sit on Alice the developer's desk until a problem is resolved.

These are just a few high-level topics to consider and ask your vendor about. If its reps are is hemming and hawing and saying they can't do them, then you really need to reconsider your acquisition. While I don't think SDN will commoditize networking--there's still plenty of action at the core and edge--a poor integration strategy on your vendor's part will affect what you can do in the future.

And go read Reese's book. While it's aimed at API developers, it's very accessible and he makes a number of good points about how to build an API, giving you questions to ask vendors.

Mike Fratto is editor of Network Computing. You can email him, follow him on Twitter, or join the Network Computing group on LinkedIN. He's not as grumpy as he seems.


Related Reading


Network Computing encourages readers to engage in spirited, healthy debate, including taking us to task. However, Network Computing moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Network Computing further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | Please read our commenting policy.
 
Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

Next Gen Network Reports

Research and Reports

Network Computing: April 2013



TechWeb Careers