Dijkstra the SDN Prophet: Programs vs. Machines

As I was writing my blog entry for today, a colleague (Nils Swart) sent me an email with a 30-page attachment – a handwritten paper penned by the Dutch computer scientist Edsger Dijkstra (famous for his contributions to distributed computing, and some algorithms that might be important to you if you are in the networking business). The paper is a draft of a speech entitled “On the cruelty of really teaching computer science“.

I have to be honest – when the email came in, I scanned the document and saw that it was 30 pages long. Having never read this before, my first reaction was TL;DR. But after a couple of email exchanges on the merits of the paper, I dug in.

There are two comments that I want to call out in the paper that I think are particularly apropos to where we are today as an industry. In the second paragraph on page 1, Dijkstra writes:

“The usual way in which we plan today for tomorrow is in yesterday’s vocabulary. We do so, because we try to get away with the concepts we are familiar with and that have acquired their meanings in our past experience. Of course, the words and the concepts don’t quite fit because our future differs from our past, but then we stretch them a little bit.”

It’s an interesting challenge to describe the future. When that future is disruptive rather than derivative, that challenge intensifies. I imagine that is a major contributor to the networking industry’s intellectual grappling with SDN over the last several years.

Those that understood implicitly before SDN went mainstream what it is and what it could achieve are cut from a different cloth. The Nick McKeown’s and Scott Shenker’s of the world see things differently. Working in close proximity, they likely developed their own language for describing things, not unlike families adopt their own unique linguistic twists. It is not unsurprising that their thoughts did not translate immediately to something the rest of the populace could consume. And even when it was consumed, many of the details were either morphed, glossed over lightly, or missed entirely.

Dijkstra’s words also resonate with me as I look at how major concepts and company positions are explained. Nicira/VMWare has been quite successful in making the comparison between what they do and server virtualization. Though I suspect Dijkstra would cringe at the abuse of the analogy because it leads to some faulty assumptions and simplifications that likely don’t hold across such different disciplines.

But it raises the question: how will these dialogues evolve over time? As we move past storytelling, through proof of concept, and into deployments, the details will become more clear to a larger part of the user base. An SDN vocabulary that is more organic will emerge. The result should be a simpler, better understood, and very likely more honest dialogue about SDN. We should be able to naturally move past the need to label things, which will make us less interested in definitions and who is SDN-washing their products and more interested in architectural descriptors that actually impact design decisions.

It’s hard to say with certainty when this happens, but certainly real-world deployments will feed the etymological change. And I find this encouraging because a common vocabulary will refocus the industry chatter on the things that matter.

I believe Dijkstra would agree as he concludes: “…in the case of a sharp discontinuity, however, the method breaks down: though we may glorify it with the name “common sense”, our past experience is no longer relevant, the analogies become too shallow, and metaphors become more misleading than illuminating.”

Later in the speech, Dijkstra makes another seemingly prophetic remark:

“It is no longer the purpose of programs to instruct our machines; it is the purpose of machines to execute our programs.”

For decades, we have built bigger and faster routers and switches. We have introduced an unfathomable number of features and capabilities into these devices. And then we have told our operators to specify with ridiculous precision what the behavior should be, on a device-by-device basis. So complex is this web of knobs and doodads that we have built very lucrative businesses around training and certification. And in the end, to be functional in a real-world setting, our network engineers are required to be semantic experts rather than architects. It’s no wonder that the best that most environments can handle are small incremental changes and month-long frozen periods around important dates.

The introduction of even spoonfuls of change to an environment like this is terrifying. If we really want to unlock the power of SDN, we have to change not just our tools and our certifications; we have to change the entire way we think about the devices that underpin our networks.

We need to view the network as a set of machines whose purpose it is to execute our programs. Our programs ought to look less like a collection of knobs and more like a set of behaviors and requirements. These abstractions are the programs of our infrastructure. And the routers and switches – be they physical or virtual – should exist solely to execute these programs.

But this is more than a push for abstraction. As a workforce, are our network architects and network operators prepared to live in a world where they are expected to be articulators of intent rather than masters of implementation? We have become addicted to our knobs. We are drunk with the precise power over behavior that they provide. And complexity is the unfortunately necessary hangover that we all wake up to the next day.

How people cope with the hangover will vary. I believe there are some who can give up the knobs cold turkey and never look back. But I fear there is an entire class of user that will reach for more Hair of the Dog.