November 12, 2013

Putting Cisco’s Application Centric Infrastructure (ACI) into perspective

It’s interesting how the news from Cisco’s ACI announcement last week has fueled renewed discussions around Software Defined Networking (SDN) and application-centric (or application-aware) networks. I guess that is what happens whenever the 800-pound gorilla beats his chest and roars. Thank you, Cisco.

In case you missed it, on Wednesday November 6th, Cisco launched a new architecture of Data Center software and hardware calling it an Application Centric Infrastructure (ACI). The goal is to unify and manage network, storage, hypervisors, security, and applications as a single entity.  Most of the solution came from Cisco’s “spin-in” Insieme.  Cisco acquired the remaining 15% of Insieme Networks it didn’t already own with a maximum price of $863 million, if sales conditions are met.architecture

In a nutshell, ACI consists of three parts that include:

  • Cisco’s Application Policy Infrastructure Controller (APIC)

  • A new Nexus 9000 switch portfolio

  • An enhanced version of Cisco’s NX-OS operating

Cisco positioned ACI as having the features of SDN, but better.  But in my opinion, there are three challenges for Cisco’s customers, especially existing ones.

  1. Pushing a new hardware switch as a precondition for using their new SDN solution. First, even though there is a lot of talk about software, in fact what is new from Cisco (that is available today) is a new hardware switch, the Nexus 9000. Cisco’s ACI is essentially one of Cisco’s recent attempts to offer an SDN solution. But requiring the purchase of a new Hardware switch (Nexus 9000) to enable ACI does not make sense, in my opinion. Why didn’t they offer this software on existing Cisco switches, which many of their customers have invested in? That is what we did with OneFabric Connect SDN, which was launched in May 2013 (when we were Enterasys Networks). The OneFabric Connect SDN works with existing Extreme Networks switches that support the OneFabric architecture – customers don’t need to buy new HW switches to enjoy the benefits of SDN.

  1. The ACI/APIC software is not available for quite a while and the Nexus hardware architecture is really playing catch-up.

The Nexus 9000 comes in two forms:

  • A merchant silicon-based “standalone” hardware model, which is intended to appeal to those opting for an open source software model and more programmability.
  • The second form of Nexus 9000 is based on custom ASIC hardware, which is where ACI fabric features come into play, managed by the APIC controller. The problem is that option #2 is not available until at least Q2 2014, and some say late 2014. Customers that want ACI will have to wait for a while and they will have to buy new switches, as ACI support added to older switches (if any) will be handicapped as they lack the custom ASICs built for the Nexus 9000.

In terms of the Nexus 9000 hardware architecture, this is the first time that Cisco created an “orthogonal” architecture chassis where I/O and fabric modules are directly connected (without an intermediate midplane or backplane), similar to the Extreme Networks BlackDiamond X8 architecture introduced in early 2012. As with the BlackDiamond X8, the Nexus 9000 series is using the Broadcom “HiGig” based flow/hash based architecture.

  1. An emphasis on applications that’s limited to the control plane. Yes, Cisco did a great job explaining the need for application awareness in the whole network – physical, virtual and mixed. Yes, the network needs to be aware of the application and the applications need to be aware of the network – so that network services can be easily provisioned and managed to provide automation, simplicity, agility and reliability. But there is more to becoming application centric than just doing so at the control network – it also needs to be in the data plane.  It is only in the data plane that a detailed, real-time understanding of traffic can be achieved. It is only in the data plane that IT and the business operations can have true visibility and control. But in order to achieve true visibility and control with high granularity and scale, custom flow-based ASICs must be used – for more information on this topic please refer to my colleague’s blog in SDNCentral. The Cisco ACI announcement didn’t get into this discussion and that is probably my biggest surprise. Therefore, I truly believe it is a major miss.

Once again, I thank Cisco for making this announcement and refueling discussions about SDN and both application-centric and application-aware architecture. Extreme Networks OneFabric customers should be pleased because Cisco made the case for many of the features that are already included in the OneFabric Connect SDN solution from Extreme Networks. Cisco made a strong case for the need for centralized automation and policy, Northbound API for application integration, and custom ASIC-based  hardware — we agree — we have been saying this with OneFabric Connect SDN since before its launch in May 2013 (and even longer – 10+_years – in the case of flow-based switching and policy). Essentially ACI is analogous to OneFabric Connect SDN while APIC is analogous to OneFabric Control Center. The differences are:  we don’t expect customers to buy new hardware switches for our SDN solution; and our switches already have custom flow-based ASICs, providing visibility and control in the control and data planes today.

Ali Kafel is the Director of Product Marketing for Enterasys, now Extreme Networks, and an Adjunct Professor at Suffolk University. He is a frequent contributor to the Enterasys Blog site and TMCnet. Please follow him on twitter @akafel for more thoughts on this and other Enterprise Networking topics.

About The Contributor:
Extreme Marketing Team

See My Other Posts

2 thoughts on “Putting Cisco’s Application Centric Infrastructure (ACI) into perspective

Leave a Reply

Your email address will not be published. Required fields are marked *