Lately, two acronyms have been making the rounds: SDN (Software Defined Networking) and ACI (Application Centric Infrastructure - promoted by Cisco). Both have things in common which equate to great marketing: a delightful vision and being difficult to pin down in terms of a crisp definition. Let me try to clarify as best I can with the disclaimer that this is purely my perspective representing Arista, as we celebrate the deployment of our second million ports of cloud networking.
The common view is that SDN is a controller or a set of network management products based on Virtualization Technologies or OpenFlow. At Arista we have a more pragmatic view. To us, SDN is a programmatic suite of open interfaces that allows applications to drive networking actions. Unlike the misconception that SDN is just a controller, I believe SDN is about scaling the control, management and data plane with programmatic and open interfaces. This means customizing the network with high-level scripting and programmatic languages, structured and machine-readable APIs, and standards-based protocols as well as interoperability with controller-friendly networks.
As we enter 2014, we are witnessing the deployment of SDN via Arista EOS and associated programmable network applications such as Advanced Telemetry, OpenWorkload and Smart System Upgrade (SSU). The benefit of these applications is a dramatic savings in OPEX and improved agility. The hype is indeed settling down to a few meaningful use cases and the reality is that SDN can become a $2B market in 3-5 years. The realization has hit that SDN cannot be deployed in isolation and that it must be built in hybrid configurations, co-existing with open IP fabrics.
Vendor-Specific versus Customer Need?
The latest marketing comes from Cisco’s October 2013 announcement of its yet-to-be-delivered “ACI.” ACI appears to be clearly dependent on the types of applications that are used to tune, to track and to specify network flows and connectivity. It feels so wonderful in vision and claims to innovate via a proprietary ASIC and hardware, but once reality sets in, it creates more questions than answers and is built around the concept of “Hardware Defined Networking” (HDN), rather than the software approach of SDN.
Much of the industry is trying to determine if ACI is simply a vendor specific lock-in or if it manages to uniquely satisfy real customer needs. As Arista deploys in major web, public and private cloud networks exceeding two million ports over the past five years, our customers seem to be demanding the five “P’s;” Price, Performance, low Power, high Port density and Programmability. Customers demand an open standards-based approach, which offers them the assurance of choice in their network deployments. I have not heard them ask for a “6th P,” which could be stated as “Please give me a proprietary single vendor network!”
On the contrary, what I keep hearing consistently from customers is the need for a universal cloud (leaf-spine or spline) network in which one can automate and orchestrate any cloud application. Representing a change from the legacy methods of tuning on a per application basis (aka mainframe and client-server model), our customers expect to be able to facilitate a rapid and agile deployment of modern cloud applications. Enterprises are looking to take advantage of the public, private or hybrid cloud. Applications must be agnostic (not centric) to the network for appropriate telemetry and monitoring as required, alleviating the cumbersome and costly traditional approach. I am reminded of the feverish marketing of FCoE (Fibre Channel over Ethernet) or AON (Application-Oriented Networking) in the 2005-2010 era at Cisco - neither ever lived up to its market hype. Customers instead built higher speed SANs using iSCSI or Ethernet-based Network Attached Storage, thus validating universal cloud networks. In fact, if history is any indicator, then it will simply be a matter of time until these acronyms become yet another obscure chapter in the Networking and history books.
The table below shows a stark contrast in approach.
|Application Centric Infrastructure||Universal Cloud Networks|
|ACI Concept||Proprietary Header Limited to Nexus 9K||Open Standard L2/3/4|
|L4-L7 Support||Service Chaining Vendor-Specific Controller||Align with Best-of-Breed: F5, A10, PAN, Riverbed|
|Network Virtualization||Proprietary vSwitch and Controller/Overlay||Integrate with Best-of-Breed Controllers|
|Programmability||Old Enterprise OS (Re-packaged)||Programmable Foundation (AEM, eAPI, SYSDB) Physical to Virtual Telemetry|
“Cloudify” with Network Programmability
At Arista, we are maniacally driven to innovate based on real customer needs for cloud and SDN. The universal cloud network deployment requires programmability at every level. It is not just a mantra for us but the foundation of the Arista network OS. It is not just adding a few APIs and Python scripts or declaring a new acronym. One has to innovate with a ground-up design delivering overlays and underlays across virtual and physical multivendor networks including:
- Programmatic interfaces (eAPIs) for integration using leading orchestration and provisioning tools with best-of-breed partners such as F5, PAN, Aruba, SAP and Splunk, using Python, Perl and other scripting options for the appropriate overlay model
- Network Virtualization support for VMware and Microsoft with VXLAN and NVGRE-based underlays
- Advanced telemetry and monitoring options for network and application interaction such as LANZ, DANZ and Network Tracers for Big Data and Virtualization
- New Quantum OVS plug-in and native OpenStack provisioning capability that connects the Quantum OVS plug-in to EOS via eAPI
- New DirectFlow mode that enables protocol-based topology construction with advanced per-flow forwarding policies as enhancements to OpenFlow
I wish my Arista readers and well-wishers a happy 2014 as we continue to strive to demystify the buzz words and marketing from real products and real use-cases in Software Defined Cloud Networking. As always I welcome your comments at firstname.lastname@example.org.