The Software-Defined Networking market is by all accounts still in its nascent stages – its scale and scope has shifted drastically as everything in the datacenter races to become “software-defined”. As we ramp up 2014, its time to step out on a limb to make some predictions about what we’ll see over the course of the year.
1. Accelerating Application Deployment Will Be the Key SDN Use Case
I had the opportunity to get involved in SDN early in its development and worked with the open source community to promote an SDN controller as a programmable platform. Our team created what seemed at the time to be a compelling vision of moving the network control plane away from the data plane and into a generic x86 server where it could be presented as a generic programming environment.
After quite a bit of sweat teaching folks how to program a network controller, I learned only a couple of PhD students actually wanted to do it themselves. It was far too complex and error-prone, and use-cases often boiled down to rebuilding solutions that major vendors like Cisco were already providing.
As I discovered through countless conversations with customers and operators, it turns out that we, the vendors, were not really addressing the most pressing problem: accelerating the deployment of end user applications securely and at scale. Rather than disassemble applications into VLANs, subnets, and ACLs, application policies must be expressed in simple, abstract terms and remain separate from the IP forwarding fabric itself.
With its launch of Application Centric Infrastructure, Cisco has led the way in redefining SDN to focus on accelerating application deployment throughout IT infrastructure using radically simpler application-centric policies. It’s a major change in focus for the SDN community but one that we believe captures the key use case we’ve seen in the market.
Over the course of 2014, expect to see the concepts of application network policies appear in other places like OpenStack and Open Daylight, where subgroups are already forming to design new APIs. Also expect to see other networking vendors pick up on this as well and start working on this approach as well. So far, our competitors at Arista have misunderstood the ACI approach as per-application “tuning” rather than accelerating applications through radically simpler policies but as we open source our models and APIs over the coming months, we expect they will catch on as well.
2. Network Overlays Create Huge Problems in Visibility and Telemetry
Network overlays were among the first solutions to hit the market offering SDN capabilities. The idea is to separate logical and physical network topology using a number of encapsulation technologies. The solution deployed on existing network hardware and on the surface seemed to mimic what IT teams were already doing with hypervisors and servers today.
Unfortunately, the true operational picture is a bit more complicated. Imagine this scenario: You lose network connectivity between two virtual machines in different racks in your datacenter connected via a logical network. How would you debug this? Check the server, hypervisor and vswitch to make sure they are functioning correctly. Log into each switch on the packet path to see if they are configured and functioning correctly. Then check each L4-7 service you are using (assuming they support your chosen encapsulation!) to make sure they have the correct settings as well. You end up with a multi-step process spanning administrative domains.
Over the course of 2014, expect to see a well-documented set of war stories about the challenges of operating network overlays due to the lack of visibility and telemetry. At Cisco, we designed our ACI fabric to integrate virtual and physical environments to provide a uniform view across the network and we expect customers and our competitors customers will come to appreciate why we did so.
3. L4-7 Service Chaining for Both Physical and Virtual Devices Becomes a Killer App
Anyone that has built out a self-service cloud environment understands that in addition to automating virtual machine provisioning and L2/L3 networking, one must also be able to offer network services like firewalls and ADCs in a self-service manner. These services are often essential to the correct function or security of an application so they must be automated as part of any deployment. Also, while virtual machine based services may increase in popularity, some of these services (like SSL offload) will continue to be delivered in hardware.
Over the next year, we expect more customers to require that an SDN solution deliver service automation capabilities by offering dynamic network service chaining. Moreover, this capability must span physical and virtual devices to support performance requirements and preserve existing investments.
With our ACI solution, we’ve already made a major investment in service chaining, offering the first and only open device API that allows the ACI fabric to integrate with the existing APIs or CLIs of any network service. We expect the world to be watching us closely here and a number of other players in the SDN space are hard at work tackling the same problem.
In Conclusion
Well, there you have it – some SDN predictions for 2014. We’re obviously excited about our recent launch of the Nexus 9000 and Application Centric Infrastructure and we’re looking forward to working with our partners and our customers to deliver them application agility, visibility and telemetry, L4-7 service chaining, and physical and virtual integration we expect they’ll need.
Great Post
Rachit Gupta
CCIE29824