- A software defined data center is nothing without a software defined network. Programmability and API support are more important than speeds and feeds in making a purchasing decision.
- Enterprises have to assess a networking vendor’s software plans as thoroughly as hardware specifications.
There are three critical features of data center switching that you need to keep in mind on your next refresh: overlay support, programmability, and APIs. Speeds and feeds, table sizes, and other data sheet specs are table stakes, and most data center networking vendors are keeping pace on the important parts. Seriously now, how many of you are going to make a purchase decision based on MAC table size? Do you really need more than 256,000 entries? Hardware is keeping up. Software impacts the integration and interoperation of your switching hardware with the rest of your data center, so much so that it becomes the most critical set of features that can make or break a fully automated data center.
Overlay support is practically table stakes and I suspect in a year or so, they will be. Openflow 1.0 with 1.3 starting to show up in products, VXLAN, NVGRE, shortest path bridging and TRILL are all viable and can be supported in hardware simultaneously, and simultaneous support will grow. Still, no vendor supports all the various protocols today, but what we will see is that enterprises will settle on one or perhaps two of those protocols. This will then become the low water mark for entry into an RFP.
Beyond that, the critical features are software based whether it’s on the hardware or in the management station. An all-software defined data center is a pipe dream proposed by vendors who want to sell you all that expensive software. If you could move to a 100% software defined data center complete with an overlay, then networking gets easier. However, because some applications simply work better on their own hardware, the reality is that most enterprises will need a mixed environment for the foreseeable future. That means network hardware has to support both traditional networking and physical networking on the same switch simultaneously – and maybe even on the same port – which in turn requires more intelligent software to manage the dynamism in the network quickly and reliably.
Some of that intelligence will reside in the switch’s firmware or configuration choices and through scripted events. Some of that intelligence will reside outside in a controller or orchestration systems. In either case, the switch’s behavior is programmable, which opens a number of opportunities to optimize networking on a per host or per application basis. The amount of programmability—and I don’t include easier firmware updates or field reprogramming FPGAs—on the switch will be a big differentiator in the future.
Switch vendors have been developing APIs allowing programmatic control of their hardware and have been integrating with hypervisor and orchestration systems. What’s important is that the APIs are publicly available with good documentation; the APIs cover 100% of all features; and the vendor has a roadmap to support changes in the future. They need a software strategy. When evaluating any vendor, assess their software development lifecycle capabilities as thoroughly has you do hardware specs.