The Ripple Effect of SDN

Back when enterprises moved from mainframe environments to the UNIX model, administrators had to change how they thought about capabilities and hardware within their networks. The same thing must happen in today’s organizations as they transition to SDN. “There is a fundamental shift in how people look at networks and devices when you move into an SDN environment,” said Bill Johnson, president of Tallac Networks.

On the macro level, SDN enables enterprises to purchase hardware independently from the software it will support and carefully architect their networks from the ground up to meet their organization’s specific needs. But the move to SDN will also usher in some downstream effects, effects that administrators may not expect.

SDN’s effect on provisioning and deployment

One area where enterprises will likely notice ripple effects is in provisioning. “You can provision new applications or new capabilities into the network without having to do a software upgrade within the devices,” Johnson explained. That’s because SDN separates the control plane from the data plane, an evolution in working within the network that will change how administrators go about tasks at many different levels within the infrastructure.

“You can basically deploy a new application or a new capability or a new service by changing the controller itself,” Johnson said. It’s a major shift from how administrators have traditionally handled provisioning.

Other shifts in provisioning include new functionalities that simply weren’t possible in a hardware-based networking architecture. “The SDN software-centric model really enables, for the first time, thin provisioning,” said Kelly Herrell, vice president and general manager of the software networking business unit at Brocade.

Even though networks don’t run at peak capacity all the time, legacy infrastructures dictated that hardware had to be sized to accommodate peak capacity. The approach resulted in wasted hardware. With a software defined approach, Herrell said, “you’ve got the ability to provision on an as-needed basis.” This may prompt administrators to have more regular touch points on the provisioning side as they adjust the network to closely fit the arc of the organization’s needs.

SDN, sysadmins, and IT workflows

Transitions within the provisioning sector aren’t just about the how. They’re also about the who. Randal Asay, CTO at Catbird, said he’s seen a “change in ownership” of certain operations within the IT sphere once SDN enters the picture. Historically, technical tasks related to networking, such as controlling quality of service and prioritizing traffic, were done by network administrators.

“In software-defined networking, that’s not the case anymore, because you’re able to make these changes at the control plane,” Asay explained. “You can enable all of your system administrators to have these functions and capabilities.” Increasingly, a greater number of people can get involved in network-affecting changes.

But as the base of IT staffers able to make changes widens, tweaks to legacy workflows become necessary. Approvals to implement provisioning modifications or deploy new features may need to be handled in different ways to keep up with the evolution that comes with SDN.

“With software-defined networking, it doesn’t take three or four people to accomplish tasks anymore,” Asay said. But just because a particular function requires fewer people doesn’t mean that other pieces of an organization shouldn’t remain involved in evaluating, approving and perhaps implementing changes. Effective approval and communication processes still need to be followed so that everyone in the IT group stays on the same page.

How SDN will change procurement and asset management

Software-defined networks are also changing how organizations approach asset management, both from a procurement standpoint and an equipment lifecycle perspective. Enterprises with SDN infrastructure spend more time managing licenses and usage-based cost models than buying or disposing of hardware.

“What you’re moving into with this sort of hardware procurement model is something that ends up being much more op-ex,” Herrell said. Capital spending—along with its attendant justifications, depreciation schedules, etc.—is phasing out, the service and license fees aligned with SDN replacing them in the operating expense column. Administrators are now dealing with budgeting for usage patterns that may fluctuate as the organization’s needs change throughout the year.

Purchasing patterns are significantly different in an SDN environment, and may require administrators to modify how they think about the hardware they buy and what it’s going to do.

“Once you get to a pure SDN, you’re really only buying one type of hardware,” Asay said. He sees enterprises preferring more vanilla system hardware, with purchasing decisions driven by the ability to take advantage of virtual software rather than adherence to a locked-in physical architecture.

Keeping track of all that hardware in an SDN environment is significantly streamlined versus a legacy infrastructure. Historically, organizations have spent a lot of money on hardware for the data center, only to later lose track of what’s really there and how (or whether) it’s being used.

“People forget what they have…and vendors are able to charge and charge,” Asay said. But in the SDN world, he explained, nothing is invisible. “Everything is very much there.” Asset management becomes less vague, but administrators need to be ready to move inventorying out of the physical realm and into the software space.

SDN’s impact on networking careers: the value of DevOps

The big money question for many folks in IT is how SDN may change their career path. Herrell said the people rising to the top within organizations are more frequently those with a bit more development operations background, as opposed to traditional CLI-driven network administrators. DevOps skills position networking pros well to handle the new programmable networks.

“It’s not that you don’t need to understand networking, it’s just that what we’re dealing with here is a level of abstraction that comes into play once you enter the software world,” he said. Professionals who can look beyond the CLI—”anything you can do from the CLI you can actually do through the REST API,” Herrell said—might actually find more opportunities in an SDN environment.

Johnson said established IT professionals may be looking at SDN through the prism of their experience and holding onto some skepticism about what the future holds. “They’re wondering how they’re going to be able to apply the knowledge they’ve had for the last 20 years in managing all these devices, and how they’re going to carry that forward in an SDN environment.”

Administrators could see their jobs change with respect to how they manipulate the network, but Johnson believes SDN will ultimately boost the amount of innovation the IT staff can inject into their infrastructure. “Now they can really architect the network as they see fit. It really does change how they look at deploying the network.”

Latest Articles

Follow Us On Social Media

Explore More