SDN May Not Turn Out the Way You Expected
It’s been said that most major events throughout history resulted from unintended consequences. Every act of discovery, it seems, unleashes random elements into previously staid environments, causing outcomes that defy even the most reasonable expectations.
This isn’t necessarily detrimental to the grand scheme of things, mind you. It’s just that the unexpected often has a much greater effect on how things turn out than the expected.
We’ll probably see a lot of this phenomenon as SDN technology makes its way from the lab to full production environments. It isn’t hard to find a wealth of opinion regarding SDN’s ability to flatten network architectures, foster dynamic network configuration, and generally move a lot of the drudgery of network management away from IT and into the hands of developers.
But if you look carefully, you’ll find some forward thinkers who are starting to envision a future SDN not simply as a newer, better version of today’s network environment, but as an entirely new data ecosystem, one beholden to no one but the people who use it. And, more often than not, these visions tend to downplay the needs of not just the network engineer, but the enterprise itself.
A case in point is Vodofone’s Michael Burger, who envisions an SDN architecture optimized to place APIs, services and even applications as close to the user as possible, thereby cutting down on network complexity and vastly increase response times and overall performance, even in broadly distributed architectures. He sees greater and greater functionality pushed to the network edge, perhaps crossing over from the enterprise edge into the carrier edge, where it can be more easily disseminated to distant endpoints wired and wireless. SDN in this vision resembles the levees in a canal system that allow water (data and services) to reach the people who need it without spilling into other channels.
Indeed, CIMI President Tom Nolle says many IT professionals still don’t see the networking forest through the trees. They view SDN deployment in terms of largely disconnected product changes, rather than the beginning of an entirely new cooperative networking environment. This could come back to bite many organizations in the you-know what, because a single-layer network/IT environment turns crucial functions like security and availability on their heads. With everything now lodged in a vast network resource pool, what’s to stop someone from, say, joining that pool and slipping into someone else’s application? And how do you protect the pool itself from being hacked with fake status messages that could bring the entire system down?
No matter how you look at it, SDN is poised to unleash some major disruption on the IT status quo, says IT analyst John Fruehe, and it isn’t likely to be as quick and painless a transition as server virtualization was. For one thing, network upgrades move at a much slower pace than in the server room, where new processors produce a flurry of hardware changes every 18 months. And despite the widespread acceptance of open standards like OpenFlow and OpenStack, the fact is that establishing the kind of broadly distributed, highly dynamic infrastructure that has captured the imagination of IT will be very difficult to do in a multivendor environment. It’s like trying to build a Big Data architecture using Oracle, SAP and Microsoft products.
But as software developers know better than anyone else, every change in the underlying work environment will come with a certain amount of “technical debt” as certain elements fail to adjust to the new state in a timely manner. As PhaseIT’s Cameron Laird points out, not all systems will conform to developments like SDN, but these are problems to be worked out (aka, paying the technical debt) rather than used as an excuse to hold back progress. And in the end, this is often a net positive for the organization because it can lead to some pretty nifty innovation.
Fear of the unknown, then, is irrational. But that doesn’t mean a healthy dose of caution isn’t warranted at the dawn of a new era. Right now, networking professionals have a pretty good idea of what they want SDN architectures to look like, but it is far from clear whether the development community and, more importantly, the users, share that vision.