SDN for the common nerd

What the heck is SDN?

So what is SDN really?  Unless you have lived under a rock and have not gone on any tech blogs, or gone to any conferences, or talked to any technical human lately, you have heard of SDN or “Software Defined Networking”.  I recently had to describe what SDN really was to some limited-technical folks recently, people who wanted to know what this concept ment directly and also in-directly.  What does it mean to them today, and what is it trying to accomplish.  I’ll be honest, today is the “easy” part, what i personally think we’re all heading to is the harder part, and a lot more foggy.

Let us start simple.  What is SDN?? Wikipedia states it “is an approach to computer networking that allows network administrators to manage network services through abstraction of lower level functionality. This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane).” (source)

That is absolutely a mouthful.  The first sentence states that we want to let our network admins manage their network at a higher-level, not directly on each device.  The second sentence states that we can accomplish this by splitting the network “devices” into two different types or functions.  One is the Control plane (the brains, or device that makes the decisions about the traffic), the other is the Data or Fowarding Plane (this is the actual Layer 1 system where the packets will actually travel on).  So basically we want to take the brains out of a switch/router/firewall and centralize it, and then just have a bunch of dumb devices out there to be controlled by said brains.   In most cases this is at least pretty close to what people/vendors are envisioning, or at least some variation of.

This is not THAT different from the things we’ve been doing in the compute world with hypervisiors such as VMware.  We are letting software define how we will setup, carve up and configure our computing resources.  In fact we’re excellent at that, been doing it for years.  Storage isn’t that far behind compute.  There are plenty of products out there that can interact with the APIs presented from storage arrays to carve up and serve storage to whatever device we need.  Now all we’re doing is we’re allowing a centralized device/software have control over all the networking nodes.  This allows for a lot of really simple and also some really neat things.

So why do we want SDN?

Well we can now do some really cool things.  We can provision things like VLANs, QoS, Security ACLs, etc on an much more granular and dynamic way.  For example we have have these items follow a VM that is vmotioning around the environment.  Ok, so you say you can do that already within VMware, and that is mostly true.  But can you do that when you vMotion across datacenters, or in a DR situation.  This also allows for super easy provisioning.  In your centralized tool you can create all of these “profiles” and use them when your creating your workload.  Now you can have the network configured correctly, including things like firewall ACLs, automagicly.  Now this will not eliminate the network admins job, it will just change it slightly.  Now instead of running cables and logging into 100 devices to perform a task, you will login to the centralized software/hardware and perform your tasks.

Where do we stand today?

SDN today is very much a still evolving concept and product.  Many different companies are releasing or have released products that speak to the SDN space.  VMware’s NSX is a huge example of this.  It is a product that has been deployed at some very large customers and has a good following.  Another big release is Cisco’s ACI products.  I won’t compare them in this article, that will be upcoming as its a bit muddy as they aren’t exactly apples to apples, more apples to pears.  Anyway there is also open standards, the largest being OpenDaylight.   To me, right now looks a lot like when “Cloud” or “VDI” was the big buzzwords.  Some people are picking a solution and going with it, however many others are waiting to see how the market better defines itself.  Unless there is a major need or a company is driven by the “pie in the sky” type architects, i see many people just watching and waiting.

Where do i see this going?

So where do i eventually see us heading??  Now i like VMware’s NSX, it works really pretty well.  However, I see us moving towards an “Application-Centric Datacenter”.  This is more of the approach Cisco is going for and speaking about.   While some people say Cisco is not going for a true SDN like NSX is, since hardware is involved.  I can understand that argument, however at the end of the day you still need hardware, cables need to connect somewhere and there needs to be some sort of hardware involved.

Overall, the end solution is that the end user is no longer has their applications or workloads constrained to certain hardware, or certain sections of a datacenter because that’s the hardware that supports it.  No longer will it take a while to provision your resources to do a new rollout or “balloon” during periods of peak usage.  I can see this centralized “Orchestration” engine at the center of it all, using various standards and APIs that are only just now starting to become more standard, to provision your compute, storage and now network for a workload.  No longer will an application owner have to make calls to multiple teams to get something done.

Now i’m also quite aware that there needs to be limitations and quotas and things of the like, many times as a VMware guy i’ve heard the “i need as many vCPUs and Memory as i can”.  Now things like vCloud did a great job of allowing quotas and access to only a certain amount of these resources.  Things like this will become necessary on the network side.  We don’t need people wanting huge chunks of network “just because”.  Either way the next 12-18 months will be very very interesting to watch and be a part of.

Leave a Reply

Your email address will not be published.