Software Defined Networks should make IT execs think about a lot of key factors before implementation.
Issues such as technology maturity, cost efficiencies, security implications, policy establishment and enforcement, interoperability and operational change weigh heavily on IT departments considering software-defined data centers. But perhaps the biggest consideration in software-defining your IT environment is, why would you do it?
"We have to present a pretty convincing story of, why do you want to do this in the first place?" said Ron Sackman, chief network architect at Boeing, at the recent Software Defined Data Center Symposium in Santa Clara. "If it ain't broke, don't fix it. Prove to me there's a reason we should go do this, particularly if we already own all of the equipment and packets are flowing. We would need a compelling use case for it."
[WHERE IT'S ALL GOING:VMware adds networking, storage to its virtual data center stack]
And if that compelling use case is established, the next task is to get everyone onboard and comfortable with the notion of a software-defined IT environment.
"The willingness to accept abstraction is kind of a trade-off between control of people and hardware vs. control of software," says Andy Brown, Group CTO at UBS, speaking on the same SDDC Symposium panel. "Most operations people will tell you they don't trust software. So one of the things you have to do is win enough trust to get them to be able to adopt."
Trust might start with assuring the IT department and its users that a software-defined network or data center is secure, at least as secure as the environment it is replacing or founded on. Boeing is looking at SDN from a security perspective trying to determine if it's something it can objectively recommend to its internal users.
"If you look at it from a security perspective, the best security for a network environment is a good design of the network itself," Sackman says. "Things like Layer 2 and Layer 3 VPNs backstop your network security, and they have not historically been a big cyberattack surface. So my concern is, are the capex and opex savings going to justify the risk that you're taking by opening up a bigger cyberattack surface, something that hasn't been a problem to this point?"
Another concern Sackman has is in the actual software development itself, especially if a significant amount of open source is used.
"What sort of assurance does someone have particularly if this is open source software that the software you're integrating into your solution is going to be secure," he asks. "How do you scan that? There's a big development time security vector that doesn't really exist at this point."
Policy might be the key to ensuring security and other operational aspects in place pre-SDN/SDDC are not disrupted post implementation. Policy-based orchestration, automation and operational execution is touted as one of SDN's chief benefits.
"I believe that policy will become the most important factor in the implementation of a software-defined data center because if you build it without policy, you're pretty much giving up on the configuration strategy, the security strategy, the risk management strategy, that have served us so well in the siloed world of the last 20 years," UBS' Brown says.
Software Defined Data Center's also promise to break down those silos through cross-function orchestration of the compute, storage, network and application elements in an IT shop. But that's easier said than done, Brown notes interoperability is not a guarantee in the software-defined world.
"Information protection and data obviously have to interoperate extremely carefully," he says. The success of software defined workload management aka, virtualization and cloud in a way has created a set of children, not all of which can necessarily be implemented in parallel, but all of which are required to get to the end state of the software defined data center.
"Now when you think of all the other software abstraction we're trying to introduce in parallel, someone's going to cry uncle. So all of these things need to interoperate with each other."
So are the purported capital and operational cost savings of implementing SDN/SDDCs worth the undertaking? Do those cost savings even exist?
Brown believes they exist in some areas and not in others.
"There's a huge amount of cost take-out in software-defined storage that isn't necessarily there in SDN right now," he said. "And the reason it's not there in SDN is because people aren't ripping out the expensive under network and replacing it with SDN. Software-defined storage probably has more legs than SDN because of the cost pressure. We've got massive cost targets by the end of 2015 and if I were backing horses, my favorite horse would be software-defined storage rather than software-defined networks."
Sackman believes the overall savings are there in SDN/SDDCs but again, the security uncertainty may make those benefits not currently worth the risk.
"The capex and opex savings are very compelling, and there are particular use cases specifically for SDN that I think would be great if we could solve specific pain points and problems that we're seeing," he says. "But I think, in general, security is a big concern, particularly if you think about competitors co-existing as tenants in the same data center -- if someone develops code that's going to poke a hole in the L2 VPN in that data center and export data from Coke to Pepsi.
"We just won a proposal for a security operations center for a foreign government, and I'm thinking can we offer a better price point on our next proposal if we offer an SDN switch solution vs. a vendor switch solution? A few things would have to happen before we feel comfortable doing that. I'd want to hear a compelling story around maturity before we would propose it."
Read more about lan and wan in Network World's LAN & WAN section.
This story, "Weighing the IT implications of implementing SDNs" was originally published by Network World.