So what was SDN all about? Ah right, centralized management and control, network programmability as well as vendor interoperability and integration capabilities. So far so good.
The centralized management and control can be implemented via a centralized controller or any other central control plane component in a distributed architecture that enables the programmatic access into the network infrastructure from a single point. For programming and integration, you obviously need an open and accessible API. Various vendors now support some, for sure we do with our OneFabric Connect API and we help our partners and customers to integrate with our OneFabric Connect Dev Central community that also is the platform to exchange new ideas around SDN.
Beside an API itself you probably need more: network abstraction. The level of abstraction depends on what you are trying to achieve. If you just want to expose all of the capabilities of your network devices and your network topology to a networking geek (a.k.a. network administrator), you might not need abstraction at all, but where is the benefit? And this is probably what you experienced when you took a look at the OpenFlow controller approach: You really need to know a lot about networking to make the right decisions. And who outside of the network domain really can claim this?
On the other hand, SDN for me is also about an organizational change and different processes — you do delegate control to lines of business within your enterprise that are outside of the network domain, eventually even outside of IT. That creates real agility. The knowledge about networking in those groups is probably close to zero, and they should not need to care about it — it just should work. But even if you stay inside IT and you let the system administrator deploy applications and workloads in a automated and orchestrated fashion on the network — the typical SDN use case in the data center – the question still comes up: What does the system administrator need and want to know about the network? And how much does the application need to know about the network that it gets deployed on? “Nothing” is not a good answer, as you will end up with the challenges that overlay technologies have today, and “everything” is not either, as you did not gain anything compared to the old operational model.
We did develop OneFabric Connect API exactly to overcome those challenges: providing the appropriate level of abstraction so also other IT teams and even lines of business can programmatically access the network without having to know every little detail. That accelerates innovation and increases agility.