Network or Application Centric? The latest questions on ACI answered.

In the ‘ACI demystified’ white paper I described some of the fundamental concepts of ACI, including a look at multi-pod concepts and features. (If you’d like to read this white paper, please register to download here .)This follow on blog is intended to answer a question I get asked a lot – “What’s the difference between network-centric ACI and application-centric ACI?”.

As you already know ACI stands for Application Centric Infrastructure, but why is it referred to as either network or application centric from a design and deployment perspective?

Network-Centric ACI

In this ACI deployment model, the ACI fabric is deployed to function similarly to a traditional data centre, but with some key advantages. ACI is not a security tool in its own right, but it has features that are a big improvement when compared against legacy DC fabric designs. One standout capability is the level of granularity available in terms of micros-segmentation, when compared to a traditional data centre. Most of the desirable functionality however, is provided by the policy plane in the form of contracts between EPGs.

As we learned in the white paper its usual to have a 1:1 relationship between BD’s and subnets. In this approach where we have multiple subnets and BD’s we can make ACI very similar to a traditional network and leverage the advantages that ACI holds over a traditional network. In this approach, we basically take the existing VLANs and VRFs and map them into ACI. We can now control traffic between EPGs (and if required within EPGs) using ACI’s policy plane. This method is usually the first point of migration, when first deploying an ACI fabric. The disadvantage is that it’s a bit more involved to automate, and you must take a lot of legacy logical components with you into the ACI fabric, some of which may not be optimal. The advantage on the other hand is that it is relatively easy for traditional network engineers (who might not have had lots of exposure to ACI) to understand how ACI functions.

Deploying network-centric ACI is often seen as the first step towards application-centric ACI.

Application-Centric ACI

In this ACI deployment model the expectation is that everything is automated, and that it’s desirable from an automation perspective to have the underlying ACI infrastructure as simple as possible. How simple? One subnet, one BD, one VRF simple, this way you can spin up new servers and the associated EPGs in a single workflow, without having to worry about automating route leaking between subnets or VRFs as part of the workflow. Using Application-centric ACI it’s very easy to map a 3-tiered application into three EPGs, one for front end, one for middleware, and finally one for DB backend. As EPGs use a zero-trust model, the automation workflow can create the contracts to include exclusive communication between the application tiers. Multi-destination flooding is also controlled so that MD traffic is either dropped or flooding in its original encapsulation, rather than flooded (which is the default).

This deployment model for ACI lends itself to multitenancy and cloud provisions, where the expectation is that the fabric facilitates the application traffic, and that some access to the public internet will be required. The deployment of a high-level orchestration engine such as Cisco Cloud Connect to manage, define and deploy the various automation elements that make up a workflow is expected.