Here’s the thing about SDN. We’ve had software defined networks for many years. In fact, some would argue that networks have always been software defined. I’ve been in networking for 18 years starting as a protocol engineer writing – guess what – SOFTWARE that created virtual private networks over a common infrastructure that abstracted the hardware layer very nicely into a set of standard protocols and APIs that controlled configuration and – albeit rudimentarily – how flows were forwarded across the network. Multi-tenant: check; Standards-based externally controllable flow management: check; Standards-based externally controllable provisioning: check. That was 1994. Everyone in the industry has similar stories.
The tortured conversations I glibly referenced in my last post reflected my own discomfort with how hard it is to express why it’s different, and more directly – why the leaders of our industry – at the pre-eminent gathering of thinkers (i.e. Open Networking Summit) in this domain – cannot either.
So I started down a path determined to say something about SDN without repeating what has already been said before, and to hopefully dissect, deconstruct, and disambiguate the current state-of-the art thought, as I know it, into something more instructive. But instead of subjecting you to another vendor’s diatribe on what SDN is and what it isn’t, I’ll just give you my conclusion – SDN ought to be a means to an end, not an end in itself. In fact, the obsessive focus on SDN as something in itself (to obsess over) is what is driving many of us crazy. What if we all just accepted that we’re in a period of transition (i.e. an evolution) from one plateau of productivity to another – and whatever you want to call it or however you want to define it, the only thing that really matters is that something is different about networking.
What’s really different is that software is more advanced than it’s ever been. Look at how applications can be built today on platforms like dotcloud.com or heroku.com (and many others) and you’ll see what I mean. Software is now assembled like pre-fabricated homes, on-site and to spec, affording developers more time to focus on workflows, usability, and core functionality than infrastructure. We also now talk about “apps” instead of large complex software suites, reflecting a new workflow mentality – a specialized app for every task, delivered when it’s needed to whatever computing device needs it.
Just witnessing state-of-the-art software development and the resulting “app-ification” of everything we do should make anyone pause for a second to think what might actually be possible if that same type of development infrastructure was applied to networking products. Instead of being confined to embedded processor environments that limit real-time operating systems and constrain memory and CPU cycles, networking software developers could build real apps that provision, control, orchestrate, visualize, and analyze the network in ways not possible before. The software could compute network topologies in real time or pre-compute all possible topologies and failure scenarios. And it could do all this while leveraging data, analytics and policies from anywhere to make its answers that much more relevant. Just from purely a vendor’s perspective, SDN means Software with a capital S and the ensuing opportunity to build real tools.
The fact is, if you were to set out to build a new type of network solution today, you would do things differently. So, maybe instead of trying to define SDN, we should ask the question: how different could networks be if we leveraged modern day software and built products based on today’s realities? At the end of the day, networks can really only do two things: connect machines together, or keep them apart. But the real hard part, the part we pay for in the complexity of systems, manual labor, and collective hair pulls, is the shades of connectivity, both in quality and transience, in between. The application with stringent latency requirements; the backup process that needs mega bandwidth; the sensitive application that shouldn’t leak data; or the business continuity requirement for everything — it’s where we spend most of our time inventing new workarounds, new protocols, or new administrative barriers that are easier to construct than actually solve the problem.
It’s in these shades of connectivity that our networks are at their most vulnerable. The rich applications that back-end our fancy phone apps, that power our enterprise productivity systems, or that connect us to one another are more complex, more dynamic, more connected, and require more of the network than they ever have. This ‘SDN transition’ is not happening just because it can, but because it must in order to enable the network to be a truly automated part of the new application ecosystems. SDN and its related discourse may be defined today by OpenFlow APIs, networking protocols and services extracted to edge virtual machines, software fabrics and hardware fabrics, but those mechanisms are likely just steps on the way to a different type of network altogether: one that leverages the principles and constructs afforded by modern day software working in concert with extremely capable hardware to achieve many, many shades of connectivity. Something is different about networking but it’s not SDN; it’s where it’s taking us.