Software-defined: Quest for the perfectly browned toast

SOURCE: Citrix blog

Around the beginning of this year I had offered some predictions about where networking might venture in 2012. Perhaps a tad behind schedule, but as if on cue, software-defined networking (SDN) has emerged at the front and center of networking this year, with VMware’s acquisition of Nicira.

In this blog post, I am here to suggest that over a billion dollars later, this marriage’s ability to realize the software-defined networking vision remains, shall we say, incomplete. But you gotta start somewhere.

Software-defined-ness: To understand this better, let us begin by temporarily separating the words software-defined from networking. The phrase “software-defined” is a beautiful one. It can be applied to all manner of things, and it makes one think, usually, of useful qualities. For example, say software-defined-security or software-defined-identity. Or a software-defined-automobile. Or a software-defined toaster.

What is this notion of software-defined-ness, really? Sometimes, it is abused – as in – a small matter of programming. And the proponent of the software-defined-widget would cite wonderful (wonderland) use cases, that are all “a small matter of programming” away. “Anything is possible!”, they would exclaim.

However the real-world benefits of software-defined-ness come from automation and replicability. What do I mean by that? Consider the software-defined-toaster once again. Now, I’m a finicky toast eater. My toast has to be just the right level and the right kind of brown. I have found that it needs to be cooked first at 375F for a minute then cooled quickly, but not too quickly. I have bought a toaster. But my investment really has been in the recipe of how I use it.

When I’m at a hotel away from home, wouldn’t it be great if in the morning, the toaster at the breakfast buffet can cook up a toast precisely to my taste. To my recipe. With a regular old toaster, I’d have to hit and trial and experiment to get the toast I want. Or settle for cereal instead. But, if they had a software-defined toaster, I would simply wave my recipe over it, out would pop that perfect toast. Automation and replicability.

But, back to the world of networking. Your routers, switches and other networking gear – that is your toaster. You have made an investment to make this network work just right for your workload. The “hotel” is a different data center. The cloud even. Before SDN, the networking was in the way of deploying your application on a different infrastructure. It was either outright infeasible or a painstakingly, time-consuming-ly manual process to get the network in the new location to match up to the requirements of the application.

With software-defined networking, however, the requirements of the application travel with the application. As software. These requirements – the recipe – can then be expressed to the networking infrastructure in the new place, which can then provide a network that perfectly matches the application’s needs. Automatically. And replicably.

The considerable investment that goes into the creation of this recipe is now preserved. You don’t need to make this investment every time you change location. So you can move locations more often – suit your needs better. Agility. You could even choose to maintain copies of your application in many places. High availability and disaster recovery. And maintain many different applications in the same location. Multi-tenancy.

Needless to say, software-defined-ness is a simple but very powerful concept. One worthy of pursuit.

Networking ≠ Connectivity

Software-defined networking is possibly the biggest change to emerge in the core network in recent times. Connectivity – enabling machines to talk to each other – is the foundation of networking. But the network environment in which a typical application lives is far more complex than mere connectivity.

Connectivity is about managing who can talk to whom, and just as importantly, who must not be allowed to talk to whom. Layers 2 and 3 of the network — switching and routing — deal with this. It is about offering the “ethernet service model”, some say. Practically every major networking switch-n-router vendor today, offers some capabilities for software-defined connectivity. With Nicira, we can now add VMware to this list.

The discussion around SDNs has largely been focused on how the technology will have an impact on connectivity. It is a bottom up, “I need to get this packet from A to B”, L2-L3 perspective. The trouble is that networking needs of an application go beyond connectivity.

In addition to connectivity, what apps require is the ability to software-define their application level networking needs. Defining how the network deals with users, and requests and transactions. Optimizing and load balancing application sessions. Securing and encrypting transactions and attributes. Looking for maleficence in the application’s payloads. Application level networking things. The kind of things that load balancers, application delivery controllers, firewalls, IDSes and IPSes do. Applications invest significantly in crafting, configuring and tuning the policies that get deployed onto their application level networking gear. And it is this investment that SDNs must preserve and provide leverage for.

Completing the SDN Vision

To create an SDN strategy that is both pragmatic and useful, requires three additional ingredients beyond connectivity.

• Application-focus: A meaningful SDN vision requires a top-down (L7 down) look at application networking policies, and the application networking service environment that needs to be enacted around the application before one can lay claim to automation and replicability – the promises of SDN. Limiting the SDN discussion to just switching and routing where Nicira and others play, under-delivers on the promise SDN.
• A pragmatic path forward: To get to SDN – the destination – it is just as important to identify a viable path that would lead to this destination. Paths that require the physical networking equipment to be substantially forklifted to get to SDN, lack practicality. A pragmatic path to SDN requires an approach where new technology can leverage existing networks, can co-exist and interoperate with the existing infrastructure and can be adopted progressively.
• Orchestration: To fully realize the potential of SDN, you need a world-class orchestrator. Something that can orchestrate the movement of the networking cogs in precise coordination with the rest of the application machinery.

We believe the real path to SDN is going to begin application-first, from the top down, without forklift, in an application-aware manner that works in conjunction with existing enterprise L2-L3 networks. The benefits of SDN will multiply when combined with a full cloud-grade orchestration solution.

The day isn’t far when I would be able to have that perfectly browned toast in any hotel when I am on the road. Just not yet.