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.

Cisco ACI comprises two major components, one the Application Policy Infrastructure controller (APIC) and the other the Cisco Nexus 9000 series Datacenter class switches. APIC helps application developers, and network and security operations to work together and separate the connectivity and security policies related to application deployment from the underlying network. For the first time, we see an opportunity to unify Development and Operations while preserving the ability to prescriptively apply policies dynamically. The Policies encoded in an Application Network Profile (ANP) can be created on the APIC tool and instantly pushed to the underlying Nexus 9000 based network for implementation. For your comparison, the ANP, is conceptually similar to the Service profile concept in Cisco UCS. Just like Cisco UCS service profiles implement stateless computing, intelligently re-purposing UCS servers to run and teardown applications on demand, the ANP likewise creates network connectivity and L4-L7 services for Applications, based on policies to push down on stateless network infrastructure. When the application moves from a Dev to Test to production phase, it is just a matter of applying the same or a different profile, and the application communication policies across web, app and Database tiers are executed per the profile. This solution automates the entire application deployment process and makes the network application centric.  The Nexus 9000 is inherently secure, connections must be allowed by an ANP in contrast with traditional networks where anything can connect to anything unless blocked by an ACL.  My security ops example above would not have been an issue if we had had ACI.

There are two other ACI innovations I want to briefly touch upon. The first one is the hardware based VXLAN implementation in Cisco Nexus 9000 Series switching platform. VXLAN is fast gaining industry adoption and acceptance, and is designed to address the scale limitations and L2 extension related pain-points of VLAN.  What is unique and an industry-first with Cisco Nexus 9000 VXLAN support is consistent line-rate hardware performance whether it is bridging VXLAN and VLAN segments, or routing across VXLANs in different IP networks.

Figure-2: Bridging VXLAN and VLAN into one single domain with Cisco Nexus 9000

Routing VXLANs in Cisco Nexus 9000 switches deserve special mention. Cisco Nexus 9000 ASICs optimize routing, and avoid burning up front panel ports. Routing across VXLANs is handled seamlessly from ingress port to the egress without any additional complexity. Competitors use inefficient techniques like burning up front panel ports, and go out of the host switch to an external vxlan router/gateway, with manual cabling across the front panel ports.

I will conclude with one last feature. It is not because, I have a bias based on my programming background, but Programmability and Open NX-API in Nexus 9000 switches impresses me most for the great benefits it brings to Data Center operations. Five years ago, Open APIs, programmability and automation were prevalent only in server domains. In recent times, we are seeing the need for increased agility and automation across data centers. Networking and Storage infrastructures are now equipped with similar capabilities.  Cisco Nexus 9000 switches with its purpose-built NX-OS provides broad support for Programmability. I speak from my experience as a one-time programmer, in this instance. Support for web server interfaces with Cisco Nexus 9000 can help Application developers to build powerful tools, to interact with the switch via XML and JSON, and Python, popular languages among programmers today. In addition, NX-OS also supports Python scripting that enables users to perform sophisticated POAP (power-on-auto-provisioning) and replace manually repetitive/error-prone configuration tasks with automation. Figure-3, depicts programmatic access to Cisco Nexus 9000 switch

Figure-3: Programmatic access to Nexus 9000

There are several other use-cases where the SDN programmability features can be discussed in detail. I will reserve these for a future Blog. Programmability and Automation alone do not suffice to bring datacenter transformation. We need to leapfrog, and make the network infrastructure application centric. For that, a network platform that can decouple connectivity and security policies to make application deployment flexible is mandatory. Cisco ACI and the Cisco Nexus 9000 platform provides a comprehensive solution to take you on this journey towards unprecedented agility and automation.  In conclusion, I want to provide you access to our ACI resources and web links. Please check them out to learn more.

Related Links

www.cisco.com/go/aci

www.cisco.com/go/nexus9000

www.cisco.com/go/ucs