SDN is not about Software
(Author’s note: Thanks to Tracy Corbo for contributions to this post!)
I’ve just returned from Interop in New York, and it seemed like every other sentence spoken there included “SDN.” The networking community is abuzz with talk about Software Defined Networks (SDN), but what does this really mean, in terms of what we should expect out this latest, most-hyped term? Current views (and agendas) are fragmented and often too narrowly focused. Many see it as a battle cry for commoditizing network delivery and the end of proprietary network equipment dynasties. Others see it as simply applying the same principals that made server virtualization successful to networking infrastructure and thereby removing the last barrier to the supposed nirvana of the “software defined data center.” In EMA’s view, both of these angles are not only wrong, but are creating a huge set of misconceptions about what SDN really is and is not. The power of SDN has nothing to do with software, the controller, or the data plane – it is about services. A better definition for SDN would be “Service Defined Networks”. EMA believes this is a much better way to describe the true transformative potential of the initiative as a whole. True SDN represents the long–awaited opportunity for networking to be directly connected to the demands of the business, as supported and addressed within the application tier.
EMA has long been an advocate for application awareness within the network management stack, as a means for monitoring and assuring that the network infrastructure plays an essential role in delivering applications and services. With such an approach, any disruptions that occur can be recognized and mitigated in a manner consistent with the priorities and business value of each of the individual applications and services. This concept can and should be extended into the planning and configuration process as well, where business and application priorities are included in the planning process. For example, consider the planning required to support a VoIP or VDI rollout, both of which demand special care and feeding from within the network layer.
But things change, and at an every increasing rate. Connecting the constantly changing world of applications and services to the supporting infrastructure in a way that allows infrastructure operations to be fully in tune and aware of changes in the application layer has been a major roadblock. To date, the vast majority of networking configuration and monitoring changes are made in an ad hoc, manual fashion in response to application moves, adds, and changes. The advent of SDN will require well-defined northbound interfaces to drive end-to-end policy control, representing a means to building automated responses that would enable a proactive exchange between the network and application layers. How this automation is achieved can be done either on the network hardware platform, in the networking software, or some combination thereof, but the end game would finally achieve the delivery of services over an optimized infrastructure driven by application requirements.
So that represents the potential for what SDN if fully realized can be. For now we are caught in a sort of dizzying array of things that claim to be SDN, but are really not. There is more than one way to reach the ideal end point and what we are seeing now are the interim steps to moving in that direction. The path of progress is all about finding ways to make the network architecture more flexible and adaptable and less rigid in design. Let us be clear – networking hardware is not going away, nor is the need for sustained, ongoing innovation within the networking layer. But what is happening is that networking equipment will have to become more application-attuned. If we truly seek to virtualize the network layer, the implementation details within the network layer are less important than what is presented to the rest of the world, which is an automated, service-oriented network delivery service.
We are working towards the concept of northbound APIs into the application layer coupled with consistent, automated policies applied to the networking infrastructure. OpenFlow and general-purpose controllers are all first steps in the direction of realizing SDN, but we are nowhere near the finish line, and much of the story has yet to be written. EMA will be tracking this important revolution closely throughout 2013 and will be publishing our findings along the way. Stay tuned – this is going to get very interesting!