Remember in 2001 when you heard about VMware GSX? It sounded like pure magic and seemed to do the impossible: it allowed you to run multiple instances of any real server operating system on a single hardware server. The operating system thought is was running on a hardware box, and yet it was just a slice of that box. Over the next few years, the buzz turned to a roar and quickly encouraged most commercial organizations to try a ‘pilot’. During those pilots, they realized that certain applications (like web servers) were a great fit for virtualized servers and these organizations set their buying sights on a new generation of big beefy servers which were needed to take full advantage of virtualization. Virtualization delivered just what it promised, and then some!
It turns out there are several technical ways to virtualize, so VMware found competitors like Citrix and Microsoft also jumped in and over the next few years the single-host/multiple-guest computing model came of age. Intel and AMD even changed their CPU chip architectures to directly support this type of virtualization innovation at the core. Software providers changed their licensing models to account for virtualized servers directly too. From a timeline standpoint, virtualization was imagined, tested, tweaked and then adopted “en masse” over a period of a dozen years. According to Gartner, server virtualization accounted for 16% of all workloads in 2009, accounts for more than 50% of all server workloads today and will rise above 80% within the next 3 years. This is an adoption curve we expect with game changing technology.
That brings me to the area of Software Defined Networking. Although programmable networking can be traced all the way back to 1995 with efforts at AT&T and SUN, the modern-day use of the term SDN is connected to the period around 2011 when the Open Networking Foundation (ONF) was formed to further the creation and use of the openflow networking standard protocol. The idea of today’s SDN is simple: Rather than each vendor continuing to ship proprietary networking gear with each device carrying all of its transport intelligence in every device, why not separate the control plane from the forwarding plane? Decompose the problem into two distinct areas that can each individually be focused upon. By making this separation distinct, each device can be aggressively optimized, and if that separation is done using industry standard protocols, then in theory multiple vendors will be able to be combined into a single network based upon the value.
Today we are just a handful of years into this SDN journey, like where virtualization was circa 2006. SDN is all the buzz today, but is still just scratching the surface in adoption. Many corporations are trying SDN pilots and investments are being made by the VCs, vendors and end-users alike. A few huge deployments have happened (like Google), which goes a long way to demonstrate the scale and commercial value of SDN. Startups have formed for nearly every aspect of SDN. Some create high density hardware (“Forwarding Plane” or Switches), some create high intelligence controllers (“Control Plane” or Operating System), some even create value-added Applications (like traffic management and analytics). The biggest old-line networking vendors have released overlays to their existing products to allow “participation” in SDN networks. (This participation is at best a defensive/transitional approach, since the old devices will still carry all their heavy baggage, but it may allow some level of migration for large installed bases until they get to REAL SDN). Given the huge potential and the original premise of SDN, that transitional approach will be short-lived and I would expect to see a significant number of new generation hardware and software suppliers that are built from the ground up to be SDN components, adopting SDN protocols as their main communication scheme.
We are also seeing the SDN revolution underscore the need to think about application-level business values and set expectations accordingly. The staff required to manage SDN networks is vastly different that that of the older CLI-based “box by box” approaches network administrators have practiced for years. With SDN, if you can “think” it, the network can be programmed to support it. Most importantly, you “think” networking in an SDN world at the business level and delivered service, not at the box or protocol level. And in the same vein, the performance of applications can be measured against those business needs and could (in theory) self-adjust the network performance to meet their precise contracted needs. While SDN protocols have certain built-in performance values being collected all the time, this next generation of tuning capabilities will come from software developers that orchestrate the performance data being collected at the application level and communicate changes needed directly to the control plane itself.
Time will tell where and when adoption will occur. OpenFlow has been an earlier leader in the technical approaches used by many vendors in the SDN community, and yet there are a handful of other competing approaches to SDN on the table today. The stakes are high, so startups that focus on delivering the highest value will likely be poised to enjoy their unfair share of the burgeoning SDN market. And just like Virtualization, we will likely find ourselves with several competing approaches to SDN. But that said, by 2020, we’ll all be connected by SDN….