Jul 21, 2015
There were over 1,300 attendees at the recent Open Networking Summit (ONS) in Santa Clara making the ONS one of, if not the largest SDN-focused conference in the world. Because conferences such as the ONS provide good insight into what leading-edge users are doing, it’s interesting to ask: What were the leading edge enterprise users at the ONS doing with SDN?
The panelists on the ONS’s Thursday morning keynote panel focused on what their enterprises had already accomplished with SDN and what they were hoping to accomplish in the short term. One of the panelists was Bryan Larish, Technical Director Enterprise Connectivity & Specialized IT Services at the NSA, which, according to Larish, means that he is the CTO for enterprise networks. Larish said that NSA has already deployed SDN in campus networks and in data centers, and that they soon would in the WAN. He said that centralized control via OpenFlow is key to their implementations of SDN both for enhancing security, as well as to enable them to better support mission-critical workloads. Larish added that his organization is attempting to be ruthless in leveraging SDN to simplify as many activities as they can and to implement new functionality, such as traffic engineering, which either would have been very difficult or impossible without SDN.
Since Larish is a CTO, one might expect that his presentation focused primarily on all of the advanced technologies that NSA has implemented. It didn’t. Larish talked in depth about the time and energy he has spent fighting the bureaucratic and cultural barriers. As Larish said, “Technology is the easy part. The tough part is changing the culture.” And don’t make the mistake of believing that the concerns that Larish raised only apply to large governmental bureaucracies and not to the private sector — at one time I worked for NSA’s IT organization, then later in my career I worked in the IT organization of two Fortune 500 companies, and I found more similarities in those organizations than I found differences.
Vesko Pehlivanov, VP, Technology Services & Strategy Team, Credit Suisse, was also on the panel. While emphasizing that his presentation would highlight his thoughts about SDN, and not necessarily the official position of his employer, Pehlivanov said that the main question he faces from a networking perspective is how to build networks that both support cloud computing and integrate with their legacy infrastructure. He said that he often hears comments like “Facebook runs their entire network with 10 people, what’s wrong with you?” In part because of comments like that he stated that his organization’s need to automate was not in question, while adding, “As we move forward with automation, we cannot just automate our current processes. That approach tells us nothing about how a change will impact the network.”
Pehlivanov said that unlike Microsoft and Google, his organization doesn’t have network programmers and he sees little reason for them to have them. He also said that Credit Suisse realizes that they have to adopt public cloud services, and that the company was in discussion with regulators on the topic of how to build in acceptable governance into their use of public cloud. He added that Credit Suisse does not intend to compete with public cloud providers on efficiency, and he closed by saying that Credit Suisse currently has more capacity than they need, so adopting public cloud services will not enable them to cut costs in the short term.
Another panelist was Richard Kaufman, VP of the Infrastructure Group at Samsung SDS, who runs a research group focused on new technologies. In contrast to what Pehlivanov said was the case within Credit Suisse, Kaufman said that enterprise IT organizations are under significant pressure to get their prices “Within a stone’s throw of public cloud prices” and to implement the capability to create and destroy networks with no human intervention and with no errors. Kaufman believes that SDN can help IT organizations achieve those goals but he also identified a number of barriers to broad SDN deployment, including the requirement to:
• Add little if anything to the per hour cost of a virtual machine;
• Demonstrate that SDN security is as good as VLAN security;
• Avoid or minimize vendor lock-in;
• Have a single throat to choke;
• Incur no performance penalties.
One piece of good news coming out of the ONS is that it appears to be getting easier than it was a year ago to find mainstream enterprise organizations that have implemented SDN. It’s also positive that the factors which organizations named as being the drivers of SDN deployment in the enterprise are the same ones that were talked about a year ago. I say that is positive because it shows a maturing of how people think about SDN.
While I can’t call it good news, it is certainly understandable that as mainstream SDN deployment becomes closer to a reality, the conversation expands beyond technology. As highlighted by Larish and Pehlivanov, the conversation about SDN is expanding to include the need to change the organization’s culture and processes. While understandable, that is concerning because I think it is easier to implement the biggest and baddest technology than it is to make a significant change to an organization’s culture and processes.