I was recently approached by a consultancy looking for Software Defined Networking (SDN) migration case studies. I was unable to provide much help; in H2 2014, precious few organisations claim to use SDN in production. However an interesting question was raised, What are the steps to an SDN Migration?

A better question is:  “What is SDN?” Like virtualization and automation, SDN is a strategy; it there is no specific SKU or end-game. If you are looking towards SDN to solve operational woes, reduce costs, or increase flexibility you could start with; “We will deploy technologies that fit into our strategy of Software Defined Networking.” I feel obliged to point out that most strategies are borne from reverse-justifying tactical decisions already made. For your SDN strategy to be a success, it must fit with tools and skills you already have.

SDN is not for everybody, customers with static user, capacity and complexity requirements are unlikely to find much incentive. They may be better off continuing to order take-out; finished goods ordered and delivered to specification.

Steps to SDN

Assuming that you still perceive value in Software Defined Networking strategy, what are the steps? I believe there are relatively few, and they will be more familiar than you imagine.

1. Virtualization – Today you’d struggle to find a organisation that wasn’t using Virtualisation a little, whilst many use it a lot. This breaks the hardware and software interdepencies, allowing applications and services to be moved around.
2. Automation  – Languages like Python and Perl can be used with existing vendor APIs cheaply, but tools such as Ansible, Puppet, and Chef can make the process easier and scalable. Just getting your Firewall to talk to your SIEM vendor properly is a step in the right direction.
3. Delegation of control. Handing over day-to-day operation control of the network is not achieved lightly. Taking the administrator almost completely out of the loop for resource and security management will require a change in mindset and procedures, especially for ITIL environments.

Challenging the channel

For anything other than simple or small networks, this will be challenge to traditional IT service providers. Step 3 requires a deeper business and application knowledge than a third party integrator would typically have. As a result, it will be driven by the customer themselves; it doesn’t really fit the traditional IT services model. It is no coincidence that earliest adopters of SDN are service providers.

If you have any serious virtualization deployment, you are already on the path to SDN. Automating security policy management, server deployment, and patch release should be aggressively pursued. Once the business is comfortable with automation as a reliable mechanism, it will become clear as to whether progression to a full-blown SDN deployment is desirable.

Bigger Questions

The next question most asked is: “How much will SDN cost?” There is no meaningful answer. Cash rich organisations can look to Cisco and others for a prepackaged SDN, but this will carry heavy upfront costs. Organisations rich in skills can look to OpenStack, OpenFlow, and OpenContrail. The average enterprise is somewhere in the middle; finite budget and resources are available and a visible return is expected..

Enterprise organisations are comfortable with selecting and deploying technologies – they are used to rolling out, migrating to, or upgrading the next big thing enterprise IT. SDN doesn’t fit this mould. Software defined networks are not bought or migrated to; they are developed. Not in the sense of “hire a bunch of Devs and let them get on with it”, a better analogy is homemade Pizza. You take a basic ingredients and adjust to them to your preference; higher quality, faster too cook, cheapness etc.

Vendors such as Cisco, Juniper, Plexxi, and VMware have many of the ingredients for software defined networking, but you are ultimately are baking your own pizza. The toughest question may be “What kind of Pizza would I like?”;  the answer can only come from within.