Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

SDNs: 8 key considerations before you make the leap

Jim Duffy | July 3, 2013
Despite the hype, software defined networks aren't for everybody. Does you shop fit the profile?

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.

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.  

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.


1  2  Next Page 

Sign up for Computerworld eNewsletters.