Computerworld

Digital Spotlight: SDN – a disruption waiting to happen

SDN, which traces its origins to work done at UC Berkeley and Stanford University, currently looks eerily like cloud technologies did in the early stages, in that it has multiple definitions and people working on it from different angles creating user confusion

Disruptive technologies do just what their name implies. They shake up existing markets and values and replace it with new markets. Such disruption can be painful, wrenching and traumatic, even though they play out over decades and, more often, come out for the better at the other end.

Many would argue that software-defined networking (SDN), within the sphere of a software-defined enterprise, is just such a technology.

SDN, which traces its origins to work done at UC Berkeley and Stanford University, currently looks eerily like cloud technologies did in the early stages, in that it has multiple definitions and people working on it from different angles creating user confusion.

“The premise of SDN is that the control plane is separated from the data plane and provides for a management interface that can be used to orchestrate and automate the deployment of applications, services and their related network infrastructure requirements,” says Arron Patterson, CTO at EMC NZ.

“SDN will ensure that new services can be brought on line quicker and will be able to adapt more readily to meet the changing demands of data centre environments,” says Scott Penno, APAC regional marketing manager for Christchurch-based Allied Telesis.

“The SDN proposition leads to enhanced speed to serve capabilities. Having the ability to software-define a configuration end-to-end and have that configuration be applied through soft patch type capabilities in data centres means you can start to spool up networks like you would a new server.

“In terms of the WAN environments, having the capability to assign rules to the types of traffic that are moving through the network provides for fast optimisation of traffic profile flows," says Steve Lloyd, Gen-I’s head of network solutions.

"In addition, third party support capabilities like F5 or Riverbed and network security boxes can now be applied as an API software device, removing the need for hard boxes in the network. This supports the application of a rules-based environment managing the types of traffic profiles to achieve the best network performance," he adds.

“Software-defined networking as a concept can be confusing for clients, with hundreds of definitions [that are] often contradictory. So we have distilled it down to two core concepts: One, SDN enables the move of some networking functions to the software domain, and two, providing a programmatic interface that allows the network to become a programmable entity,” says Richard Fitch, network integration and performance optimisation solutions specialist at Dimension Data NZ.

The state of the user

Early stages of any disruptive technology can be difficult for end-users, whether large or small. The decision maker often has to struggle with conflicting information and continue to consider whether it is the right time to take the leap or not.

With SDN, vendors state that there might be some pre-requisites that need to exist before the end-user need consider it seriously.

“If you have a data centre capability and or need then SDN can bring both technical and financial advantages today. If you are a campus or enterprise then you need to look a little more clearly around the benefits to you and your customers.

“If you run a hybrid type cloud and infrastructure on-premise model then SDN is a proposition that can also be advantageous from day one in terms of financial return and speed to capability,” says Gen-I’s Lloyd.

For many organisations, SDN may not be relevant and will deliver no benefit at all – despite requiring hardware, software and skills to deploy and manage

Allied Telesis’ Penno states that the firm is yet to see a compelling reason for the majority of small to medium, and even most large enterprise organisations to adopt SDN.

“For many organisations, SDN may not be relevant and will deliver no benefit at all – despite requiring hardware, software and skills to deploy and manage. Organisations need to engage with their vendors to understand the costs associated with deploying SDN or similar technologies and also to understand the benefits that may be delivered," adds Penno.

"They then need to determine if they have a problem that can be solved by SDN or similar technologies and if the benefits delivered will exceed the cost of deployment and management over time," he says.

“Every organisation with large data centres and network pressures would benefit from researching SDN and the developments in the industry. Networking has held back agility and speed of delivering, modifying and decommissioning applications for too long. Data centre networking investments should be evaluated as well,” says Patterson.

The road ahead

While user cases remain rare, vendors are encouraging all large enterprises to consider SDN when evaluating an infrastructure refresh, and to start developing a plan that ties in with the business case of the business.

However, this is not possible without a key understanding of what SDN means and how it can benefit the business.

The most important thing to comprehend is that SDN is an architecture, not a technology. It is a way of systematically designing networks from the ground up based on the key concept of centralised control over forwarding elements.

“The main key challenge today to a successful SDN deployment is in building an understanding of how it can drive success for an organisation,” says Jim Fagan, president of managed services at Pacnet.

“Many organisations have become interested in software-defined networking, but don’t have a clear understanding of what comprises an SDN architecture or why the architecture is the way it is. The challenge is that the market’s attention on individual technologies such as OpenFlow and overlay networking has limited the conversation – to fully understand SDN, you need to examine the architecture as a whole.

“The most important thing to comprehend is that SDN is an architecture, not a technology. It is a way of systematically designing networks from the ground up based on the key concept of centralised control over forwarding elements,” states Matt Miller, senior manager of field system engineering for A/NZ at F5 Networks.

Besides understanding what SDN can do for an organisations’s specific use case, there is also the issue of finding the right skill sets to make it work.

The organisation needs to build a capability in its people to evolve and grow with the SDN capability

“The key challenges our clients are facing is getting access to appropriate skills, reliable information, and developing a plan,” states DiData’s Fitch.

“The biggest challenge is that the networking industry has been pretty much the same for so long that people have built careers on doing things the same way. It is very similar to the mind-set change required when moving from CLI-based management to API automation [from command line to driving things programmatically]. This is where most network engineers struggle to make the transition,” says Patterson.

“If an organisation is locked down in the rigour of traditional network design and deployment and apply that methodology to an SDN environment then you won’t be successful. You are essentially changing from a router or switch based mind-set to a flow based. The bulk of network engineers are somewhat conditioned to the traditional methodology and will struggle to adapt," adds Lloyd.

"The converse is the virtualized software engineer doesn’t usually have the underlying architecture knowledge of a fixed network (you will still need one) and as such will struggle with the constraints this applies to flow design.

"So the organisation needs to build a capability in its people to evolve and grow with the SDN capability,” he says.

This is still early stages for the technology and use cases are rare. However, there's no dount that the path ahead is one of growth, change and increased adoption, as definitions and standards fall into place over time.

“SDN technology will develop along a similar path to server virtualization, with fundamental ‘hypervisor-like’ capability being enhanced with automation, orchestration and self-service to deliver the same high speed operational model for network and security as that of a VM,” says Patterson.

“A lot of vendors have an SDN strategy. Unfortunately, our customers tell us that these strategies tend to vary in coherency. SDN does have a place but there is a danger of it becoming a solution in search of a problem. Consequently, starting an SDN conversation with the business case first can highlight whether the investment now, as an early adopter, is worth the risk,” says Miller.

Echoing Miller, Allied Telesis’ Penno concludes, “The real challenge for most organisations is that today, there are relatively few applications for SDN in the enterprise – for the enterprise, it’s very much a solution waiting for a problem. But we believe like many technologies, applications will arise over time and so organisations need an understanding of what SDN for when the time arises.”

Walk the talk

While definitions abound, there is no doubt that vendors are scrambling to invest in what could potentially be a deal-changer in the networking industry. Global firms like VMWare are spending billions of dollars in ongoing investment to support development of SDN.

The likes of Dimension Data are also investing in the technology, having recognised it as disruptive and wanting to take a leadership position in the same.

“We have established a multi-vendor SDN lab in Johannesburg which allows us to demonstrate the various technologies – from traditional partners and market challengers alike – to our staff and clients," says Fitch.

“We have also established a Global Working Group, involving technical and specialist sales resources from all countries, which allows us to quickly share experiences and evaluate industry developments.

“This group has been instrumental in the development of our Software-defined Networking Development Model (SDNDM) which we are launching globally on the May 27. This model is a comprehensive consulting engagement that provides a focused starting point for client organisations interested in learning more about SDN, about the impact SDN will have on ICT operations, and where to start with SDN,” he says.

Local companies are not far behind in trying to capitalise on SDN.

“Today Gen-i is working with its supplier and partner network to consolidate the functionality and capability end to end of their products in relation to the existing Gen-i infrastructure. Gen-i is investing in training its network engineering and design teams, implementation and operate teams as well as it sales teams to ensure that we are able to articulate the Gen-I SDN proposition,” says Lloyd.

“Allied Telesis has its premiere research and development facility located in Christchurch, New Zealand where the development of our switching and routing products takes place. Support for OpenFlow is a module within our industry-leading AlliedWare Plus operating system. At the time of writing we have approximately 70 staff involved in the development and testing of modules like OpenFlow for use across the Allied Telesis switching portfolio," says Penno.

“We are currently negotiating a program with a New Zealand tertiary institution around furthering the research and development of OpenFlow support within our products but this has yet to be finalised,” he says.

“Our recently launched PEN is a platform that provides flexible and scalable bandwidth provisioning to customers. What we offer customers is akin to a “network on a plug,” much like we offer power from an electricity outlet. We can do that now because the physical cabling no longer restricts how the network is configured. With SDN, the network is virtualized, programmable, and boundless,” says Pacnet's Fagan.

For now though, SDN remains a distruption waiting to happen, in NZ and elsewhere.