SDN and Innovation Base Camps
SDN and Innovation Base Camps
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
SDN is almost universally associated with disruption, the general consensus being that it is a significant departure from the way networking has been handled for decades. Insofar as SDN marks a major architectural shift, it absolutely should be considered a disruption. But how does disruption relate to innovation in general? And how do customers navigate an environment that is subject to disruption?
It certainly is not the case that all innovation is disruptive. In the general case, an existing architecture serves as the starting point for innovation. From that starting point, the products and even the architecture itself goes through fairly incremental development. New features are added, primarily to address needs that can only be known after a solution has been deployed. No one can predict with certainty or with precision how exactly a technology will be used. And even if they could, it is impractical to wait until everything necessary is in place before allowing users to start working with it.
The challenge here is that this incremental development leads to a linear growth in product capabilities. Every subsequent revision is a derivative of the previous. The intent is to hone the solution, so this actually makes a lot of sense. Both vendors and customers need to observe a solution in context and then iterate on it to make it better.
Over time, this ends up looking like what we have today: a set of technologies, protocols, and policies that all work together to make the architecture useful.
But technology needs are not bound to the products but rather the context that surrounds those products. Network requirements are not a function of the network so much as all the things that surround the network. If those things mature at exactly the same pace (or slightly slower), then an incremental approach makes sense. But if the context around the solution changes faster than the solution itself, this creates a widening gap between requirements and capabilities.
This is where disruption comes in.
Taking the current networking climate as an example, so long as compute, storage, and applications were evolving at a relatively slow pace, the network was fine to take incremental steps. With virtualization, end point explosion, and an increasing focus on the application experience instead of mere availability, the networking space became ripe for disruptive technologies.
And so it seems certain that SDN (and it’s cousins NFV and network virtualization) will emerge.
But then what?
Some companies will mistake this moment in time as indicating that disruption is an always-on thing. They will look for the next disruption, and the next, and the next. But customers who deploy SDN and its relatives will actually press for more incremental development. They will require operational capabilities useful for monitoring, troubleshooting, auditing, and security.
In essence, what SDN represents is a base camp.
Imagine that you are off to climb Mount Everest. You don’t take one linear path from the airports in Nepal all the way to the summit. You establish a base camp, and you work your way from there. The base camp gives you a chance to orient and acclimate, making the necessary adjustments for the rest of your climb. But even then, you don’t just have one camp from which to work the rest of the ascent. You move forward, establish a new camp, and adjust.
So it is with technology. We establish innovation base camps – specific architectures or frameworks from which we can learn and adjust. Then we iterate on our solutions, never quite perfecting them but certainly advancing. And then some other disruption comes along, which serves as the next base camp in the journey.
This means that as we look at SDN, we should expect a calming period. Vendors need to iterate on their products, and the industry at large has to absorb the change. Deployments need to go out, customers need to learn, vendors need to modify, and everyone needs to adjust accordingly.
That’s not to say that anyone should stop planning ahead. In climbing Everest, you might settle in for a few days or even weeks, but you have an eye on where your next base camp is. Knowing where the next stop is helps you understand what you will need to do from your current camp. It allows you to make adjustments with a purpose. As SDN matures, this means that customers ought to already be looking at what the next innovation base camps are. There seem to be several areas that are emerging, and not surprisingly, they align with the major ascents that lie ahead.
Operationalizing all the different things that SDN enables requires an increased focus on automation. The most obvious innovation base camp that is already fairly well defined is DevOps. Customers looking to evolve their networks need to be planning their SDN architectural choices with the knowledge that DevOps will likely be the next stop in the climb. Vendors lacking a compelling DevOps story will leave customers stranded at the SDN base camp.
Beyond that, the growth in network traffic (especially in the data center) is accelerating. Cisco’s Cloud Growth Index suggests that datacenter traffic will triply by 2017. There will need to be a disruptive force in networking to address this. Simply making devices cheaper allows us to extend the horizon for our current architectures, but the primary source of cost is operational, not capital.
The next innovation base camp is likely to be photonic switching, leveraging advances in silicon photonics to bring the manufacturing costs down to a level that makes optics more consumable in other parts of the network. The number of optically-oriented companies is already increasing, which lends some credence to the prediction. But customers will want to plan their Everest ascent with this base camp in mind.
Another long-term trend is the software-defined datacenter. Beyond the buzzword, what this really means is a more highly integrated IT infrastructure inclusive of more than just the network. Compute, storage, and applications will ultimately need to collaborate with the network. But how? Another innovation base cap is going to need to address this integration.
There will be additional innovation base camps beyond these, no doubt. To navigate between these camps, network architects will need to do a couple of things:
- First, to plot a course, you have to know where you are going. CTOs, CIOs, and architects will need to look well past SDN, because long-term success means choosing an architecture from which you can make the next transition more easily.
- Second, during the SDN evaluation phase, network designers need to be including long-term vision as part of the selection criteria. While not a primary purchase driver, it could be a reasonable tiebreaker where competing solutions are largely equivalent.
- And finally, companies will need to be able to differentiate disruption that serves the vendor (being disruptive is a means of differentiation) vs. that which serves the customer. This seems obvious, but it can be difficult to see when you get lost in the details (see Nortel’s PBB as an example)
[Today’s fun fact: Shakespeare invented the word "assassination" and "bump.” Sometimes the fun facts stand on their own, but it does make me feel more literary referring to baby bumps now.]
Published at DZone with permission of Mike Bushong , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.