We've been getting a lot of great questions about ACI since our launch as people try and better understand the value of an application-oriented approach. I got the following questions on my blog post about the Application Virtual Switch that probed on some of the thinking behind an application-aware architecture, and why now was the right time to release it (after all, John Chambers called it the most disruptive Cisco innovation in a decade!). Anyway, on to the Q&A:

I'd like to know more about the path that Cisco pursued to evolve towards an "application aware" architecture. This back-story (how Cisco arrived at this juncture) would be very helpful to industry analysts, customers and institutional investors. Here's some of the key questions on my mind.

-What were the primary roadblocks that inhibited the adoption of this innovative approach in the past?

I would say that the Application Centric Infrastructure (ACI) was a combination of a Eureka! moment, that people just never thought of it before, and that it was also an insightful evolution from early SDN technology. So, it might be fair to say that SDN had to come along, and then we realized, here might be a better way to program the network (with an application-oriented model, rather than a network-centric model).

That might be another way of saying that the lack of SDN as a precursor to ACI was a roadblock. But I think of it as networks were just built on hardware that were optimized to pass packets and other very specific tasks. And the limitations of historical networking protocols and traditional network designs, coupled with very limited ways in which you could manage a network and tell it what to do, all served as roadblocks to implementing anything like ACI. So the roadblocks that had to be cleared included the ability to program switches through software interfaces, and to centrally manage the software applications or controllers to orchestrate the broader network, not an individual device. Those are some of the things SDN brought along.

If you read my earlier blogs about ACI, particularly this one and this one, I discussed why an application-centric model is really a much more business-relevant approach to telling your network what to do. Recall the tweet I provided that implied that networking vendors had run into a brick wall trying to cram more intelligence into the network. Everything was getting too complicated and brittle, which was inhibiting cloud migration and scale. So ACI is really about taking complexity out of the network, building a network that can take arbitrary orders, and being able to do so in a business-relevant language. The last part is the really disruptive part of ACI.

All this network programmability and simplification is really about better ways of optimizing the network, setting up new applications, and remediating problems, automatically, in real-time, in response to BUSINESS REQUIREMENTS. If you can't easily translate your business requirements into a language that your infrastructure understands, things are going to be more difficult. Since applications run the business, they are the best reflection of business policies and requirements.

-A purpose-built hardware solution seems to be the road less traveled, because it requires a greater R&D investment. Why did Cisco take this approach, and decide against using one of the alternatives?

This is a great question, and it would be easy to say that it's the road less traveled because only Cisco has the resources, scale and experience to invest in doing it from the ground up, at least as quickly as we did it. But it also gets back to my earlier point that traditional networks and network devices really needed to be redesigned for this new ACI model. To optimize the Nexus 9000 for 40Gb and beyond, with all devices understanding the ACI application policy model and "accept the orders" from the APIC controller, really required purpose-built hardware. We were able to accelerate time to market with the combination of merchant silicon with our own purpose built hardware. Overall, it does require greater R&D, but we believe the ROI will be worth it.

Other vendors took the approach that network complexity had to be eliminated, and settled for a pure software overlay approach on top of existing physical networks. This may be the cheaper (less R&D) way to go, but we know it has tradeoffs, which we mentioned repeatedly. You are only masking limitations that are still there, you lose visibility to the physical network contraints, you end up with silos managing both a physical network and a virtual overlay, etc. This all led us back to the fact that purpose-built ASICs and hardware were the only way to go.

-What legacy design challenges did Cisco have to overcome, before it could attain the advantages of the ACI fabric orchestration model?

As I mentioned earlier, once programmable networks came along (e.g., SDN), the biggest design challenge was to shift the programming model from a network and flow-oriented model, to an application-centric, business-relevant programming language. This was done by creating features in the Nexus 9000 devices to support the object-oriented language that understands the application centric concepts and could take orders in the business-relevant language.

Also, we realized that a true application-aware approach had to address not just the network devices, but really all the application network services, security devices, and more that applications need. My previous blog does a good job of walking through the complexity of orchestrating and provisioning all these components, and an example of the types of commands the APIC controller gives to the devices. Eventually we will add server and storage infrastructures under this same programming model, which will allow for the mythical single-pane of glass for automating the entire infrastructure, and removing the silos between network, security, server, storage and application teams.

-My follow-on question is about the status of the "Cisco One" initiative - How is the developer ecosystem evolving since the announcement, and how many of the planned APIs are actually available?

Just for clarification, Cisco ONE is really a broader initiative that includes all forms of network programmability from Cisco. It will encompass the APIC controller and the ACI business-relevant programming model. I'm assuming you mean the earlier network programmability models we announced last year, and the resulting ecosystem around our onePK API, and our XNC controller.

XNC is already benefitting from being an "Open" design, since it is the first commercial version of OpenDayLight open source controller. That will allow XNC to generally benefit from all the applications that will be written for the multi-vendor OpenDaylight system. Open API's and an open source controller are helping to grow the ecosystem for us and everyone. XNC comes with ready to use applications such as Monitor Manager, Topology Independent Forwarding, and Network Slicing that already help customers to build and  implement SDN in a low risk way.

Developers can write apps using the OpenDayLight open source controller which can call the northbound REST APIs supported on XNC and extend the controller capabilities via the Open Services Gateway Initiative (OSGi) Framework.  All of the interfaces we announced to the switching platforms, namely onePK and OpenFlow 1.0 are available and have been released on some of the Nexus portfolio. More details can be found here and here.

I would appreciate it if you could share these details in a follow-on blog post. It would help to fully understand why Cisco specifically chose a solution deployment methodology that's somewhat different from competitors. Thanking you in advance for your consideration.

I hope that was useful and the information you were looking for. We are always open to follow-on questions and I know we cranked out a lot of material to wade through for folks to figure out what ACI is really all about. (Long list of all Cisco assets, as well as great stuff from our partner ecosystem is here). With plenty more to come, no doubt.