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.
Last week was a memorable one for me in more ways than one. First, the unveiling of Cisco’s Application Centric Infrastructure (ACI) specifics by John Chambers and his Executive Management team via a public webcast on Nov 6. The announcement was a big success and received broad endorsement and support from a big eco-system of Partners, customers, Press and Analysts.
Second, personally it is special to me, as I became part of the ACI Marketing team two weeks ago, to join life in fast lane. In this blog I want to share my excitement with you, and focus on nuances of ACI that do not overlap with blogs already posted by Shashi Kiran and Harry Petty.
The excitement started with an ACI boot-camp, I attended last week. In 2 days, I got a good overview on the architectural advantages of Cisco ACI and the Datacenter pain-points it addresses. By now, many of you would have learnt that ACI is all about Datacenter agility and automation. Sounds easy, but you may be wondering how to attain this goal. I will give examples from my career as a software engineer in the 90’s, when I worked for Sun Microsystems. Those days, I wrote code for 2 –tier and three-tier enterprise software applications that required global deployment and access by users on the company-wide WAN.
My problem started as I went from the Application Development phase to Test/QA phase. I had to run from pillar to post coordinating my application deployment needs with security, network and database/storage admins to identify the best rollout strategy. There was no collaboration between Dev and Ops teams. The alpha and beta test phases required testing on multiple subnets, across geographies, via multiple protocols like to establish proper SLA/functioning of the application. If my application had to open say, a firewall port to allow a particular traffic type (non http) it was next to impossible to get security ops to agree. Opening non-http ports were considered a security risk. In addition, tight coupling of network constructs like subnets, VLAN, security, network services, IP addresses etc with one another, further impacted the network flexibility and application deployment process. (Refer to Figure-1 below for details)
With ACI architecture, tight coupling between network constructs can be eliminated. Figure-1 above, illustrates this approach via Abstraction.
If you have been following the news, I’m sure you saw that Cisco just introduced Application Centric Infrastructure (ACI). Combine ACI with Cisco UCS Director and you can provision and deliver application-centric infrastructure automatically.
Over the past 11 months, I have discussed how Cisco UCS Director reduces data center complexity with unified automation and management of multi-vendor converged and integrated infrastructure systems. But the provisioning of compute, storage and network resources is just the start. IT needs to deliver infrastructure that is tailor-made for the specific applications their users need. Together with ACI, Cisco UCS Director has key capabilities to make this happen.
What ACI has done is backed off from all the network complexity in trying to build more and more intelligence directly in the fabric. Building the network to be externally automated can centralize the intelligence and control, while simplifying the design and operations of the fabric greatly (also a goal of SDN, by the way). But what’s really new about ACI is that the programmability and orchestration of the infrastructure (how it takes the orders) is now done in a business-relevant policy language/model.
In a pre-launch post, I looked at why application policies were an ideal model to build infrastructure automation around, and how application policies are better suited to mirror business objectives and requirements than traditional IT infrastructure policies. The fact is that applications are the brains of the business and best reflect the activity and dynamic requirements of the business. Application policies are inherently business-relevant. The key benefits for customers end up being vastly greater degrees of automation, process improvement and business agility. [Note: It will be left as an exercise for the reader to prove that OpenFlow, e.g., is not a business-oriented policy language.]
After countless brainstorming sessions, code reviews, lab trials, scores of NDAs and nearly two years of intense speculation from media, analysts and the internet community – it is finally here! Today, Cisco is pulling back the curtains to reveal details of the vision of Application Centric Infrastructure (ACI) announced in June 2013. With shipping products as part of the announcement today, Cisco is also taking the first steps in making this vision a concrete reality. In the process, Insieme networks also returns to become a wholly owned subsidiary of Cisco.
For those tuning into the press conference and webcast today , you will see John Chambers, Rob Lloyd and Insieme executives get into the specifics of ACI, with the event being hosted out of the historical Waldorf Astoria in New York. You will also see Cisco’s partners and customers share both the stage as well as a common vision.
So, after months of silence, there will be quite a bit of information sharing, perhaps Information overload even. This is an announcement with innovation at multiple levels, and even for the tech savvy it will take time to fully understand and appreciate the architecture and the benefits it brings.
I wanted to share a few key concepts, innovations, and highlights of the announcement today. We will delve into additional details and dissect these pieces over the next few weeks on this blogging platform as well the public www.cisco.com/go/aci website, which will host a lot of the structured content.
1. The concept of Application Centric Infrastructure
We put together a short video to distill the concepts of ACI. It encompasses a lot of what existing networks today, as well as emerging SDN concepts (regardless of what the definition of SDN is), and goes quite beyond what anyone else is offering out there today. You will see some critical differentiators here:
De-coupling of application and policy from IP infrastructure
Ability to define application network profiles and apply them
Integration of physical and virtual infrastructure elements with end-to-end visibility
The Application Policy Infrastructure Controller (APIC) is a new appliance that will be the heart of the ACI fabric. While the actual product will ship around Q2 of next calendar year. An APIC simulator will also be made available on a controlled basis for customers and partners to get familiar and additional information will continue to be made available. Unlike most software-only controllers in the market today that have little ability to exploit the capabilities of hardware, APIC provides a holistic system level view and an ability to tap into the capabilities of the underlying infrastructure. While it will initially be paired with the Nexus 9000, the APIC will be expanded to support other parts of the portfolio as well as other infrastructure building blocks.
The APIC utilizes a centralized policy-model with an application network profile and open architecture that allows for the application needs to be defined and mapped to infrastructure, to make it application-aware.
3. Nexus 9000 – Expanding the Nexus switching family
We’re expanding the highly successful Nexus family with the next “big bad boy” -- the Nexus 9000. This will initially come in two models – the Nexus 9500 and the Nexus 9300, with the former shipping now. It has a variety of innovations for all of the “5 Ps” – (i) an extremely attractive Price point , optimized for 1G to 1/10G in the access, and for 10G to 40G migration in the aggregation layer. In addition (ii) It brings in Industry leading Performance with 1.92Tbps per line card and is 100G ready. (iii) Has significantly higher non-blocking Port-density (iv) Flexible programmability with JSON/XML API with a Linux container for customer apps and (v) Power efficiency – with an innovative design that has no mid-plane/backplane resulting in 15% greater power and cooling efficiency.
The kaon shows the “see-through” design of the Nexus 9500 without the traditional mid-plane design. To see the 3D design of the Nexus 9500 click here
The Nexus 9000 is designed from ground-up to be ACI ready with a combination of merchant silicon and Cisco custom ASICs to deliver the “5 Ps”.
As customers migrate to 10/40G over the next few years, the cost of laying new fiber and overhauling the optics is a tremendous drag and raises barriers for 40G adoption. I wrote about multi-layered innovations – this is one of them at a component level. The 40G BiDi lets customers preserve their existing 10G cables, resulting in tremendous time savings, cost savings (labor and fiber) as well as improved time to market for the upgrade. Bandwidth upgrades is one of the top reasons that drive network refreshes, and this innovation (a Cisco exclusive) produces remarkable results
5. The Partner Ecosystem
It is not possible for one company to address all the challenges manifesting in the data center on its own, no matter how revolutionary the architecture is or how radical the innovations are. This is where a rich ecosystem of partners have stepped in(see the technology leaders rally here), each of them market and innovation leaders respective domains, to make the vision of ACI all the more real and consumable.
Their vision and commitment is reflective both of the shared vision and commitment to transform the data center infrastructure, as well as reflective of the open architecture of the ACI approach in general, building on the principles of the Cisco Open Network Environment (Cisco ONE), but also taking it to other aspects of the infrastructure. You may expect to see a lot of the demos as the APIC becomes generally available next year, even as services offerings around ACI become much richer, as evidenced by Scott’s blog link below.
Please stay tuned to this blog space and the www.cisco.com/go/aciwebsite for additional information over coming weeks and months. As always we would like your comments and constructive criticism as we together help redefine the power of IT.
(*) Click on the Infographic to enlarge or download it