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.
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.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
