• 08/04/2014
    7:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Real-World SDN, Lesson 1: Management Up Front

Learn how Microsoft runs its own software-defined network in this series from Symon Perriman. First, he advises setting realistic goals and focusing on management.

There's a lot of industry posturing and debate about software-defined networking (SDN). Most of it is academic, which is unfortunate for users who want to understand what SDN can really help them do and to see real-world examples of it in action. Enterprises want the ability to run their own private clouds, offer self-service networking capabilities to tenants, provide isolated and secure networks, and simplify the integration of company acquisitions.

Microsoft's SDN operates Azure, Office365, and 200 other cloud services across more than 1 million servers for hundreds of millions of customers. Azure has tens of thousands of network changes every day, so "Big SDN" is living and breathing in our cloud. Lessons learned from this experience can help demystify SDN and provide some guidance about how to make it possible in your own data center.

I'll spell out the top best practices in a series of blogs to show you how you can meet the common business goals that SDN is trying to achieve: agility, so the business can be flexible and grow with its customers' needs; efficiency, in order to provide the lowest possible cost of ownership; and predictability through reliable SLAs between key stakeholders.

SDN step by step
Though this statement may seem obvious, I recommend setting and achieving your SDN goals one at a time, rather than trying to change multiple networking capabilities in a single project. It would be nice just to turn on your SDN management solution and have it aggregate your networking resources, standardize your configurations, expand your network's capacity, maximize scale, increase performance, provide automation, ensure tenant isolation, improve workload mobility, cut operational complexity, reduce costs, and cure world hunger. But the reality is that you will be setting yourself up for failure.

The network is like the central nervous system of the data center, because it provides the communication fabric for its members to function together as a unified yet distributed system. An essential component of SDN is a highly available, centralized brain for the system. This is provided by SDN management software.

Today I see many customers with segmented networks and multiple administrative tools for each of their different networking devices. In the animal world, a colony of separate organisms that appear to function as a large single animal is called a siphonophorae, such as the jellyfish-like creature known as the Portuguese man-of-war. But just like the man-of-war, if one of the network segments breaks down, the entire solution will gradually cease to function. If you have ever had to restore a service after a distributed networking outage, you will probably wish you were swimming with the man-of-war instead of struggling with miles of networking cables.

One of the first goals should be to deploy SDN management and pool your networking resources so they can be software-controlled. This SDN management software can centrally govern your devices, such as switches, load balancers, or even gateway servers. This may involve adding every networking device to the software individually, or even controlling the current management system of those networking resources, so that your SDN software becomes a "manager of managers."

Test this configuration for a while until you can control the necessary networking devices in your data center from this software. Then you can start thinking about the next goal, whether that is standardization, high availability, automation, self-service, or multi-tenancy.

Now that you are on the journey toward SDN, you should also be extra selective when purchasing network devices. Ensure that the component can be controlled through a programmatic interface (API) such as REST, OMI, or SNMP. This will allow the SDN management software to control that device automatically, which can free up time for the IT department while reducing human error.

To summarize today's lesson, Symon says to set clear goals, take them one at a time, and don't be a siphonophorae. Next, I will discuss the biggest internal challenges that lie ahead on your journey to SDN.



That is a very unique analogy for a lot of corporate networks!

Re: siphonophorae

Haha, kind of an interesting 'animal' huh?  I bet a lot of people will be checking that out on Wikipedia :)


Agreed! That is a unique analogy and one that definitely sticks in your brain.

Question for Symon: What if an organization chooses not to buy into an SDN management solution from the beginning? In my experience, a large percentage of companies has always pushed back against implementing large-scale "manager of managers" platforms unless they had no otehr choice. If a company doesn't have this software, how should they approach management?

Re: Sino...whatever

Hi Susan,

In my opinion, the question about centralized management is broader than just centralized network/SDN management, so I'd recommend aligning with your corporate strategy.  The two SDN management solutions I'm most familiar with (Microsoft's System Center Virtual Machine Manager and VMware's vCenter) can also support centralized VM and software-defined storage management.  This means that investing in one of these solutions can help more than just your networking management.

The big advantage of centralizing this is to have a single location where you can deploy, manage and monitor the health of your virtualized networks.  If you're using a de-centralized model you need to provide some type of coordination between the different networking functions yourself so that they are current and matintain a consistent view of the environment.  It may also be harder to aggregate and view real-time information about the health of the environment.  Ultimately the entire solution needs to stay in sync, whether you do that ad-hoc or using a centralized management solution is up to the organization, but it will be much easier if you are centralizing it.

Hope this helps!


Re: Sino...whatever

Symon, thanks so much for your feedback. I understand that to adopt SDN, you need to be able to ccordinate across the network. I'm wondering if it's possible to do that without buying a big software package from a vendor, or if network engineers can put together their own management system with available tools and create a "homegrown" management system. I know this is often the case for enterpises that are not using SDN, but I'm not sure what exactly is available for SDN management.

Re: Sino...whatever

Hi Susan,

Sorry for the delayed response, I've been taking a long holiday and just returned.

You are correct, "homegrown" (custom) SDN solutions are certainly possible, and they may be cheaper if they are basic.  One advantage to using a vendor is that they will support the product for several years and continue to update it, whereas with a "homegrown" solution, once your SDN expert leaves the company, you may lose the unique knowledge required to run your custom solution.