My focus at CiscoLive 2014 included one thing: attending any session that discussed Cisco Application Centric Infrastructure (ACI). Cisco ACI is a comprehensive program that offers an incredibly exciting solution for the deployment and management of applications. It’s all about the application, and how the network infrastructure can be automatically configured to meet the policies specified. For example, instead of configuring access control lists (ACLs) on individual switches, you can configure one policy for the application and ACI will take care of ensuring that it is realized by the entire network. So ACI drastically speeds the deployment of the application while also providing a specification that can be deployed or replicated anywhere. What UCS did with service profiles (which enabled the mobility of physical machines), Cisco Application Performance Infrastructure (or APIC – see below for description) does with application network profiles. It provides similar functions with respect to the ability to deploy and move applications, because all the network specifications are defined as part of the application.
According to Cisco, ACI consists of the following:
- Cisco Nexus 9000 series of switches – Provides a new fabric that ACI is built on and focuses on large DataCenter deployments. ACI fabric can scale to a million endpoints, 200K 10GB ports and 64K tenants. The fabric supports multiple hypervisors by normalizing NVGRE, VXLAN and VLAN networks. The fabric is based on a spine–leaf concept, where the spines only connect to the leaves, and all of the leaves connect to all of the spines. This is similar to Cisco FabricPath, but a Cisco Live speaker indicated that Cisco Nexus 9000 did not leverage FabricPath.
- Cisco Application Policy Infrastructure (APIC) – APIC is the brains of the solution; it translates the application-level policies into actual instructions that the network layer equipment can understand. It’s the APIC that abstracts all the network complexity and automatically provisions all of the network components to meet the policies specified. Note that this is also referred to as APIC-DC (APIC DataCenter).
- Cisco Application Virtual Switch (AVS) – AVS is built on the Nexus 1000V, where the APIC replaces the VSM. Policy is pushed to AVS from APIC, effectively extending the ACI fabric to the hypervisor. Support for all leading hypervisors is provided.
- Software and hardware innovations – This appears to refer to Cisco ASICs used on 9000s, along with the APIC software.
- Integrated physical and virtual infrastructure – This is important since it provides full support for physical servers and physical Layer 4-7 devices, as well as for virtual servers and virtualized Layer 4-7 devices. This is definitely an advantage over VMWare’s NSX software-based overlay approach, which is optimized for a virtual infrastructure rather than physical.
- An open ecosystem of network, storage, management, and orchestration vendors – Cisco has really focused on open APIs in the last year or two, and this makes it easier to integrate with other vendors’ products. With respect to ACI, the key to this integration is via APIs defined on APIC. The APIC has two Southbound APIs to allow support for third-party products. OpFlex and Device Packages provide a mechanism to push polices to third-party devices while a northbound REST API provides full integration support with Management and Orchestration systems.
Beyond Cisco’s advertised features, I thought it was worth mentioning some of the other initiatives around ACI that I learned during the CiscoLive 2014 sessions.
- APIC-EM – This is a completely separate product from APIC-DC. APIC-EM is based on the OpenDaylight project, while APIC-DC comes from the Insieme acquisition. At CiscoLive, it was stated that APIC-DC and APIC-EM would have “a common policy intent framework” as well as “a common northbound API” (ONE DevKit). Southbound APIs include OpenFlow, onePK, and CLI.
- UCS-Director –UCS-Director is an orchestration and management tool for UCS that currently supports non-ACI infrastructures. In Release 5.0, which was just announced, UC-Director will also support ACI infrastructures.
- OpenStack – Cisco released a plug-in for OpenStack that allows it to leverage APIC to provision the ACI fabric.
- Microsoft System Center – APIC integrates with System Center so that System Center instantiates the VMs and then instructs APIC to instantiate the network.
- InterCloud – Cisco’s global network of clouds hosted by Cisco and partners’ data centers; will leverage ACI.
As you can see, Cisco is serious about ACI, and I believe that their strategy is spot on. They have taken the whole SDN argument to another level with ACI. That is, the APIC may be an SDN controller, but it is also a whole lot more. Though ACI may take some time to mature, I predict that eventually Cisco will get it right; it’s only a question of how long it will take. This is a large undertaking with a lot of moving parts and a lot of third parties involved. However, Cisco has an advantage here: its size and its breadth of products. If anyone can pull this off, Cisco has my vote.
