Now that we've announced the Cisco Application Centric Infrastructure (ACI), everyone is trying to come up to speed quickly on this new fabric architecture and the power that this revolutionary application-centric model will bring to data center and cloud automation. One of the best insights to ACI I have seen comes in the form of a 140 char tweet from Insieme TME Joe Onisick (he also blogs at definethecloud.net) who says, "Building intelligent networks is a fool's errand. Build a network to take orders, then teach it to do so in a business relevant language." If you truly understand that, you'll easily grock ACI. The rest are implementation details.

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.]

Let's look deeper into one example of the difficulty in deploying and managing applications and the level of complexity that must be overcome to truly automate application-oriented tasks: application-specific network services and security policies.

Let's take, for example, a fairly complex web server application deployment. Once we've installed the application on a server and connected the server to the network, there is still a great deal of complexity and policy management that is required before the application can go live. Each of the red blocks below represents a layer 4-7 application or security service that has to be configured to support the application, including application delivery controllers, WAN optimization, network monitoring applications, perhaps multiple stages of firewalls and IPS, including firewalls between app tiers, and even configuring the network devices to deliver the appropriate quality of service, access controls, etc.

Each of these services represents a significant policy configuration and management effort in its own right, as well as various ways of routing traffic to and/or through the required devices, depending where they are located in the data center, if they are virtual or physical, and if they are in-line with the traffic flow or require some other protocol to be configured. For example, IT administrators would configure an application delivery controller across a rack of servers using Secure/Source/Stateful Network Address Translation (SNAT), insert firewalls/IPS devices into the traffic flow with VLAN stitching, and configure virtual firewalls between app tiers like the Cisco Virtual Security Gateway (VSG) using vPath service insertion technology in the Nexus 1000V virtual switch.

Once these devices were properly configured into the network, the actual packet flow from the client to our newly deployed application could take a circuitous and complex path as shown below. Assuming it was all done correctly on day one, the resulting application network would be challenging to modify as policy requirements changed, and our resulting policy would spread out over many devices with incompatible management stations, languages and protocols. Wouldn't a single, centralized policy model across this whole system be much more advantageous? Hmmm...

The vision of ACI may be best illustrated in how it tackles this problem and greatly improves over our traditional deployment models. As I described in my earlier ACI post, ACI consists of a centralized, infrastructure-wide policy model that assumes many of these diverse application service policies. The policy model describes, among other things, the application requirements for application delivery controllers, firewall services, network analysis and monitoring, etc. Having a single, centralized policy language and model makes the ongoing management and modification of policies across many applications, and potentially many hundreds of devices, easy and intuitive, and vastly more scalable.

Another feature of the ACI-enabled infrastructure is the technology for managing the traffic flow to the proper devices as they are configured and provisioned into the network. An example of service path routing is the Cisco vPath technology in the Nexus 1000V for virtual service nodes. Similarly, ACI will enable application policies to be enforced consistently, independently of the location of the workload or service nodes, and whether the workload is physical or virtual.

The centralized application policy, over all compliant ecosystem partners supporting the model, can now support a great deal more automation in terms of updating the security or QoS policies on-demand, based on externally monitored events, or programmatically through orchestration systems. This is one of the reasons why we say that ACI unifies the networking, security, application and server teams for the first time, as we have a single policy model across all those infrastructures, based on a business-oriented, application-centric view of the infrastructure.

If we look at a simple ACI example, in the diagram at right we have a simple three-tier web application with virtual firewalls separating each of the web tiers. ACI allows an Application Network Profile (ANP) to define how new instances of this virtual application deployment are set-up and provisioned, with the right firewall policies configured, and the right firewalls inserted between the right application tiers.

Without going into much detail about the ACI policy language, we can provide a brief pseudo-code example below that might describe the above configuration. Connectivity between devices and app tiers, and which firewall policies are enforced at which location can be easily described and managed. Changes to this centralized policy could be replicated immediately across all devices and across all implementations of this particular application whether it was running locally in an on-premise data center, or a cloud-based version. Ongoing management as well as compliance audits would be greatly simplified. As we have discussed with ACI, this policy model is based on an open, extensible XML/JSON (JavaScript Object Notation) language.

As we have seen, layer 4-7 application services and security may be the greatest obstacle to truly automating application deployments and automating policy updates across vendors and device types on-demand. The application centric view of ACI is really a generational leap forward in this regard as, for the first time, we are unifying not only a wide range of security and application services under a single policy model, but unifying that with the network policy, and eventually across servers and storage. The single resulting policy model will allow for greater degrees of automation and much more sophisticated, business-oriented policies.

At the ACI launch on Nov. 6, we were supported by a number of technology partners representing layer 4-7 application services or security offerings, such as F5, Citrix, Symantec, et al. In my next blog post I'll summarize the ecosystem support for the ACI Application Network Profiles and how they are incorporated into the ACI architecture. Stay tuned...