Software-defined networking (SDN) is the current "next big thing" being put through the hype-mill by the analyst community and vendors alike.
Software-defined networking (SDN) is the current "next big thing" being put through the hype-mill by the analyst community and vendors alike. Although the concept of SDN emerged a few years ago in response to the challenges of the rigidity of physical networks and manual operations, its adoption remains gradual. Early adopters of SDN in the Middle East are currently investigating a wide range of applications and use cases. These include network virtualisation, large-scale data centre infrastructure management, traffic engineering, and WAN flow management.
A lot has been written about SDN, and the one thing everyone does seem to agree on is it will change the dynamics of the Middle East networking market. Like many technology trends however, everyone also seems to have their own view of what SDN is, what it will ultimately look like in a 'standard' deployment, and just when the hype will be replaced by measurable results. It is perhaps due to this lack of clarity that the global market for SDN still remains relatively small. IDC reports that it currently accounts for around $360 million in annual business in a USD 30 billion networking industry.
SDN is actually a fairly simple philosophy if you will, but the preparation to be able to deploy SDN needs to start now. To start with one of the big questions that few seem brave enough to ask: will Software-defined networking really herald an era when we can say goodbye to the network complexity that has come to dog both customers and the industry for the past decade, so we can access new applications on-demand rather than "on-deployment of some new networking kit"?
The good news is the answer is a resounding "yes". SDN is a way of approaching the management and utilization of the network differently, enabling customers to fully utilize the power of virtualization of hardware and software effectively across the infrastructure. However, it is not, despite the hype, a replacement of the physical infrastructure, and unfortunately if your physical infrastructure is still a three-tier, legacy affair, with redundancy and resilience issues, any investment is SDN will reap you little real reward. And this is where fact and fiction on SDN must divide if we are to deliver SDN the way the solution is designed to be deployed.
Unraveling the Data center Networking Conundrum
Data centers have grown to comprise of a huge number of physical devices to create a network. When organizations need to support faster connections, more connections, bigger data sets, or more applications, the traditional approach has been to add more devices. Over time this turned out to be a very ineffective methodology once those networks reached a certain size, with low utilization per device, high-redundancy, complex work-arounds to navigate the north-south nature of traditional network designs, and growing complexity requiring more resource. 'More' has just added up to 'less'; less efficient, less cost-effective, less reliable.
Virtualization has emerged as a way of managing devices better and this is a technology that has progressed beyond the hype into the actual deployment phase. According to Biswajeet Mahapatra, research director, at analyst firm Gartner, "Most companies today are virtualising 20-30% of their hardware". By dividing physical devices into multiple virtual "units" that can be assigned to certain tasks across the infrastructure - not just those related to the tasks assigned to the physical unit, enterprises can use their full capacity and compute power.
But now the issue is how to manage and track a huge number of virtual devices, and unlike the physical units those virtual devices really could be just about anywhere on the network. At the same time the virtual devices still have to be moved around making the management of something supposed to ease complexity, well - rather complex. A clear example in fact of how a fantastic solution to infrastructure inefficacy still relies on the right network environment to work.
Defining SDN: The key is in the "N" (because the network still matters)
Software-defined networking takes virtualization to the next level. By separating the control plane (the part that holds the instruction manual if you will) and the data plane (where the data sits) within a device, SDN enables the control element to move with a virtual device around the network. This means that a virtual device automatically knows how to deal with an application or service request regardless of where it is within the infrastructure. It doesn't need re-programming every time it gets moved; the compute power and the intelligence reside and move around the network together, making virtual machines much more powerful, track-able, easy to move, and easy to manage. SDN provides the framework to deliver this process, so management of the network becomes more about software commands and application enablement, less about where certain physical devices sit or what they are plugged into.
This is where some have taken a leap of imagination and jumped from network to software, inferring that hardware will become redundant as software takes over. Which is a nice idea were it not for two questions that anyone looking at SDN should really ask: what exactly is that software going to run on and be accessed by, and, what exactly do they think the "defined" in SDN stands for?
The reality is that the not quite as trendy network piece is still going to be vital. Just as virtualization did not bring an end to investment in storage or IP infrastructure, SDN is about better utilization and increasing the agility of the underlying infrastructure, not about replacing it. And if that infrastructure is not able to deliver a flat, fully resilient, auto-healing, auto-forming network that supports east-west traffic (i.e. directly between servers), SDN will suffer the same challenges at deployment that virtualization has.
To put in another way, if SDN is a top of the range sports car it will still perform badly if you use it on a road that is full of portholes, dead-ends, broken bridges, and unnecessary loops, to be beaten by the average family saloon travelling on a new straight, flat, road that goes direct to its destination. Worse still if you find your SDN sports car is non-compliant with the proprietary road surface you have just spent a fortune on and you now can't come off at the next junction.
So to go back to the question: can SDN really herald an era when we can say goodbye to network complexity and access new applications on-demand? The answer is still emphatically "yes". However, there remain three things that need to be addressed to realize SDN's potential.
Firstly SDN must be recognized as an approach not a product, with all vendors developing and optimizing their product portfolios to support SDN right across the data center. It's already been widely acknowledged that multi-vendor environments provide the best solutions overall to customers - ensuring this continues brings us onto point two. SDN requires open standards (such as OpenFlow) to prevent the very silo's and bottlenecks it is designed to address, and to be cost-effective at deployment. Last, but definitely not least, SDN can only be effective when deployed on fabric networks. Fabrics resolve all the issues of the legacy, three-tier architecture, to provide the road your super-charged SDN solution needs to operate at optimal levels. Without this SDN will still "work", but it will take longer, cost more, create additional levels of complexity and won't deliver the business benefits you hoped for.
Understanding these three points is critical to making the right SDN investments for your business. Defining SDN is simple; it's all in the name. To deploy and benefit from it just bear in mind what the "N" stands for, and why it remains the critical foundation to your technology plans and business performance.
Sufian Dweik has a breadth of experience with over 19 years' IT industry experience, 13 of are in the Middle East. Before heading the MEMA team at Brocade he spent six years at Cisco leading the vendor's Abu Dhabi Public Sector team.
© Zawya 2013
