SDNs: 8 key considerations before you make the leap

Software-defined networks aren't for everybody. Through programmability and automation, they promise to make IT life easier. But depending on your IT shop, the benefit may not be worth the effort... or investment.

[MORE:12 tips for SDN IT buyers

RELATED:SDN: The user view]

There are eight considerations for IT shops evaluating SDNs, according to IT management software company SolarWinds. The checklist was compiled from interactions with customers considering or inquiring about SDNs:

1) The industry in which the organization is operating

SDNs work for cloud providers or for any organization that experiences dramatically scaling workloads, says Sanjay Castelino, vice president and market leader of SolarWinds' network management business. Financial services companies and retail fall into that category, where "the dynamic nature of the business drives IT to be flexible," Castelino says.

Some that do not fit this mold are publishing and healthcare, he says, two industries that are relatively stable, and not launching or moving around application workloads every day. "Their environments are not as dynamic," Castelino says.

[TIPPING POINTS:12 tips for SDN IT buyers]

2) The size of an organization's network

While there is not a distinct bare metal server or virtual machine threshold for implementing an SDN or not, the rule of thumb is hundreds of IP addresses.

"For 50 IP addresses, it's not worth the change," he says. "For hundreds of IP addresses, you might need the automation."Castelino recommends doing capacity planning before considering SDNs.

3) The level of complexity of an organization's network

If there are requirements for a lot of network slicing or segmentation for security and isolation, you might be a good candidate for an SDN. If there are lots of virtual LANs to configure and manage, or there are VLANs that require more automation than others, SDNs might be a good fit.

But change shouldn't be made just for the sake of it, Castelino says.

"You don't want to make changes that break things," he says. "Policy is not a simple task to go implement. Have to have someone deeply steeped in network engineering."

And you have to validate and test the environment multiple times, he adds.

4) The Dynamic nature of an organization's applications and workloads

This goes back to consideration No. 1: Are you a cloud operator or a hardback book publisher? How often are you launching new applications and closing others? How often are you moving workloads around? Is your environment static and predictable, or always changing, always moving and unpredictable?

5) The number of virtual machines within an organization's network

"If you're not at a few hundred, you're probably early," Castelino says. He reiterates that if an organization is running hundreds of workloads, it might be worth taking a look at SDNs. Below that level, and with SDN's immaturity, it might be "way too early" to look at.

6) The organization's need for agility, flexibility and scalability within the network

See Nos. 4 and 1: If you have a business or IT environment that scales quickly and changes dynamically, you want SDN. But the eventual ease of operations will come with some initial work. The time it takes to get into SDN is not small today, Castelino notes -- it's still at the bleeding edge of the technology curve.

"Network engineering skills and capital resources are going to be key," he says. "It could be an expensive proposition so you need to ensure value on the other side."

7) The organization's need to simplify security measures and control access to applications

The benefit of SDN is that things get done the same way all the time, through policy, even though the environment is dynamic and always changing. Security and network access control in a dynamic environment can be a nightmare. It's important to get policy enforcement right in this regard not only to ease operation but to ensure information stays where it should.

8) The organization's access to personnel and capital resources

If an IT shop doesn't have network engineering expertise, or personnel is stretched thin, SDN is not the project to undertake, Castelino says.

"There will be lots of bumps in the road," he says. "It's going to be a lot of work and take time."

SDN deployments are done in parallel with the production environment, test, evaluated, validated and tested again before they are cut over to the production network. It takes time, people and money.

In summary, SDN holds a lot of promise. There are a lot of problems it can solve... but also a lot it can start if the environment is not conducive to the effort and undertaking to transition to an SDN-programmable and automated IT operation.

"The hype cycle can sometimes lead to an ugly bursting of the bubble," Castelino says. "SDN has its purpose. But if it is marketed as a panacea for everything under the sun, you'll see a lot of dramatic failures. It's not ready for everyone but some can get a lot of value out of it. You just need to go in with eyes open."

Jim Duffy has been covering technology for over 25 years, 21 at Network World. He also writes The Cisco Connection blog and can be reached on Twitter @Jim_Duffy.

Read more about lan and wan in Network World's LAN & WAN section.