The only thing people seem to agree on when it comes to the direction SDN will take networking, is that no one agrees. So the headlines read, at least. One (perhaps the) core tenant however is clear to most equipment vendors, service providers, and enterprises – amongst other things, SDN will bring more programmability to the network. Given that this driver alone could result in a drastic shift in how networks work years from now, the opinions vary when painting what that picture will look like. In the mean time, network needs of today are not waiting for the jury to return. In other words, what will that programmability look like in the short term?
In parallel to wrapping their heads around the technology shift, network operators and administers would be happy to hear how they can benefit today. And how is that? In a recent poll conducted by Enterasys, just over 20% of respondents said that network customization is the greatest benefit of SDN – but over 50% were looking for it to bring simplicity, automation, and faster deployment of new applications. This supports the notion that the real value will be found in partners that can provide a level of programmability, but at the same time ensure a net decrease in the effort spent establishing services (with the ultimate goal of end-to-end orchestration).
While a majority of the market place has focused on OpenFlow at the expensive of the bigger picture, there is one established networking vendor besides Enterasys who has had more of a focus on programmability. Juniper has been on a roll in the past years, at least in terms of repositioning and planning to add product after product to their list of data center platforms, and SDN as an opportunity for yet another. This time, they put a focus on providing a variety of programming language interfaces so you can re-program your network.
OK, so who’s ready to program! Oh… wasn’t Python covered in your network certification course?
Opening up an API into your networking solution such as Enterasys OneFabric Connect is a critical step and will prove useful to many parties, but is everyone ready to code tools themselves? In addition to the equipment and software vendors and system integrators, there are networks out there with an admin staff big enough to be hungry to do also take on more programming skills to better sculpt their networking processes. But what about those network admins taking care of an entire network with only a small team, or only themselves alone? They’re looking for more support than someone just pointing to an online programming course.
We at Enterasys are hearing the call for more support – for SDN to make their lives easier, not harder. Not only does this help solve the practical problems of today, but we believe this is the essential tenant that should lead the technological shift as it evolves over time too. We’ve started by doing two things in addition to opening up the OneFabric Connect API:
- Guided integration – Enterasys network administrators are now able to plug in their tools of choice, either with our help or without it, but we’re helping them along the way by also leveraging the integrations we’ve built so far, including virtual hypervisors, firewalls, web filters, third party networking infrastructure, unified communications equipment, mobile device management or MDM, etc.
- A supported community of developers – For those who are building their own integrations or customizing those that exist, they’re not on their own. We’ve used LinkedIn – where so many professionals are already connected – to create a portal for truly anyone to collaborate. The site just launched recently and we’re already collecting input from customers and providing guidance and code to solve those problems.
I think intelligent hardware will always provide critical value to networks, but we are long past the days of solving the bigger picture with just a box. We need to think outside of that thing – symbolically and physically. Increasingly more pervasive and easily integrated software will be one ingredient in doing so, but adding the open collaborative element makes the difference between being stuck with a command prompt and actually solving a problem.