“I confess that in 1901, I said to my brother Orville that man would not fly for fifty years . . . Ever since, I have distrusted myself and avoided all predictions.” — Wilbur Wright, 1908
In SDN in the Enterprise: aligning with business needs I highlighted one of what some people are claiming to be the most disruptive technologies in the networking space in recent memory: Software Defined Networking (SDN), or what I like to call the continuation of the abstraction of everything. Today we’ll explore some of the ways I believe SDN will and will not change networking.
Trying to predict the future in any endeavor is fraught with danger, or at least substantial risk of embarrassment. Winston Churchill once said, “I always avoid prophesying beforehand because it is much better to prophesy after the event has already taken place,” and he was on to something. Technology predictions, in particular, seem to have a funny way of getting away from even the most intelligent and business-savvy among us. Hit the target, and you look like a genius. Miss it, and if you have a high enough profile people will remember it forever. Worse than that, however, is that in business if you miss the target you leave money on the table, or in the worst cases sink the company.
The million dollar question, then, is how do we make the determination as to what is business-enabling, potentially disruptive technology, and what is merely incremental improvement? We look at what the goals of the business are, what challenges we face in getting there, and how any new technology fundamentally solves those challenges. Everything else is ancillary at best, a distraction at worst.
When I look at SDN as it exists today, and I read all of the arguments both for and against, I find that most of everything in this space is conceptual and largely tilting at windmills. Some folks argue that network engineers will go the way of the dinosaurs, with programmers taking over everything, while others argue that the network itself will become nothing more than a commodity to be bought at the lowest price from whomever has a sale that week: the Walmart model if you like.
I don’t accept these, or any of the other more common arguments for or against SDN. To be honest, I see SDN as a natural outgrowth of the abstraction of everything (AoE) and more of an incremental improvement modality than a disruptive technology.
Consider that prior to the virtualization of compute that has occurred over the last 10 years or so, most enterprises were purchasing bare-metal servers from a handful of recognized manufacturers. Today, with a couple of changes (notably, Cisco’s entrance into the market with its Unified Computing System platform), those same manufacturers now sell blade servers. Those servers run one of two or three virtualization platforms, certainly, but how much did the overall modality change? We still have an OS, memory, server hardware, etc. Users still log into their computers, access information or services on those servers, etc. IT departments added skills as time went on, but the fundamental precepts of the system stayed the same at a macro level: providing services to the business.
Will programming become a useful skill for a network engineer to have? Certainly so, I’d argue that it’s already useful, but I don’t think it will ever take over the networking theory side of the job. Think about what happens today when the GUI quits working, or something on a server breaks, or a large-scale ERP system fails. Your engineers, DBAs, and Systems Administrators revert to the lowest common denominator of troubleshooting: the console. Any programatic interfaces you may write or use are abandoned when a problem arises, ostensibly because they may be part of the problem. I don’t see that changing. Your first-level help desk and engineering staff will likely use some higher-level interfaces, perhaps home-grown, on a day-to-day basis, but your more experienced folks won’t.
Another question to consider is what value do I get from writing my own interface when so many good ones already exist? Does anyone really believe that networking and SDN will be much different for 95% of the businesses out there? I don’t believe that most enterprise customers are ever going to get to a place where they buy “white box” networking equipment, then set to writing their own interfaces to that equipment from scratch.
When it comes to business, one of the things we have to evaluate constantly is how IT can contribute to both short and long-term goals. Spending money to get programmatic access to infrastructure, or to separate infrastructure functions under the guise of flexibility in and of itself does nothing to further those goals. If I can save money with a break-even period of less than 18 months, then I’ll spend CapEx to do it. If I can gain efficiencies in process which lead to a reduction of labor or other OpEx costs, I’ll do that as well. Right now, today, none of the competing visions of SDN can offer me that. I have nothing to spend money on that gets me any of these things.
From a pure flexibility point of view, the ability to possibly lower costs by separating the forwarding and control planes of network infrastructure is exciting. The possible cost reductions that can come are exciting as well. Today, however, these things are in their infancy and don’t fundamentally solve any of the problems that I have. It is the quintessential solution looking for a problem. Will that change? I feel fairly comfortable saying “yes it will,” but not for a few years, and even then I think you’ll see the deepest penetration hitting the service provider space first.
Five to ten years from now, in the Enterprise space, I expect that we’ll largely see what we have today but with a lot more openness in APIs. We’ll also see some different choices in architectures, and where the control plane sits in our networks (every device, vs. centralized controllers). What we will not see, however, is a landscape so different from today that it would be unrecognizable.
Change often comes slowly; so slowly that we arrive at it and only recognize it in the context of history. Look me up in 10 years and we’ll compare notes.
Oh, and for fun check out this article on the 10 worst technology predictions of all time.