Demystifying ACI Application Centric "Mode" Through the Lens of an Engineer

For anyone familiar with ACI, the concept of Network Centric "mode" and Application Centric "mode" are not new. They are usually one of the first topics discussed during proof-of-concept, technology comparison or design sessions.

Network Centric is simple and straightforward — VLAN, endpoint groups (EPG) and bridge domains (BDs) are mapped in a 1-to-1 relationship, hence the most popular choice to start an ACI journey.

On the contrary, Application Centric isn't as popular, and there are misconceptions of what it means, the benefits, the challenges and the methodology to deploy. However, we quite often leverage the characteristics of both in the field. The bottom line is that we should be utilizing ACI features to meet business requirements, regardless of mode.

Misconception #1: Application Centric "mode"

You might have already heard this before, but there isn't a "mode" or a "switch" that we simply flip to change between Network Centric (NC) and Application Centric (AC). AC is a design concept, an approach to deploy and a way to leverage ACI's capability to achieve network policy alignment with applications. 

Though NC is the most common design, occasionally, aligning network policies with applications made more sense than simple VLAN to EPG mapping. It does not mean that we deployed any specific mode, but we applied ACI features to fit specific scenarios.

NC and AC designs are not mutually exclusive. Especially during transitions from NC to AC, both structures will co-exist until completion. From this point on, we'll use the word design or approach instead of 'mode.'

Misconception #2: Application Centric design requires greenfield

It is believed that AC design requires greenfield applications or re-IP. Well, not exactly. Greenfield application with new subnets certainly is a plus and makes life easier for an AC design, but is not required.

If you started deploying ACI in brownfield, NC is more approachable and resembles a legacy data center design, but you will not enjoy the full benefits of ACI. However, you want to ensure that the initial NC design is flexible enough to allow a smooth transition towards AC down the road with minimal impacts and efforts.

There are two primary reasons for most customers not being able to leverage ACI to its fullest potential, or they are stuck with an NC fabric:

• The team or the culture is not ready to embrace software-defined infrastructure in general. It is such an enormous paradigm shift that the learning curve is too steep to overcome.
• The initial NC design lacks flexibility, which made transitioning towards AC felt like another whole new project.

Brownfield AC design will require more planning, designs considerations and much more profound knowledge of ACI to be successful though.

Misconception #3: Application Centric means ADM and segmentation

This is probably one of the most common misconceptions of AC. There are actually two phases, at a high level, with the second phase being more complicated and requiring more effort.

The first phase is to design and build an AC fabric (non-secured). The second phase is to perform segmentation.

To demystify this part, we'll break it down step-by-step.

Step 1 – Identify an application

If we think about a simple process of how we purchase an item on Amazon:

1. Go to amazon.com (HTTP request, Webpage loaded).
2. Login to your account (Authentication).
3. Search for an item by approximate name (search engine).
4. Results returned from inventory based on best match, top reviews, etc. (request processing, DB query).
5. Add item to cart.
6. Place order, process payment and display order summary.

The above is certainly a simplified version of what may be happening behind the scenes, but it's what a web application is generally comprised of:

• HTTP Web UI for user interaction (Web Function).
• Authenticate the user to login (AAA Function).
• Process user input (search engine in this case, App Function).
• Back-end data processing (search inventory database and return results, DB Function).
• Update user carts with new items (Checkout Function).
• Process payments (Amazon API request sent to bank for payment processing, Payment Function).

Each function listed above is responsible for a specific area. You can consider Web/App/DB/Checkout as part of one application which provides an amazon.com shopper with the full experience.

The AAA and Payment are applications on their own, as they are useful not just for amazon.com, but maybe AWS, vendor services, WholeFoods services, etc.

At this point, we've identified three different applications: amazon web, AAA and Payment.

Step 2 – Translate application concepts and tiers to ACI Application Profiles

In ACI, there is the concept of "Application Profiles" (AP or ANP), which is somewhat equivalent to the concept of an application as described in step 1. As a result of step 1, we have the following as an example:

However, do not get boxed in by the concept of AP. There will be cases where you can't, or it doesn't make sense to match application names to the ACI application profile. Depending on the design, you can name AP with "Dev/Prod" environments, "DC1/DC2" data centers or even "NetworkTeam." APs are no more than a folder that hosts endpoint groups (EPG) and does not provide any segmentation capabilities.

ADM software can be helpful if you cannot clearly identify the functional tiers during this step. Most of the time, you should be able to identify the core tiers of an application manually.

Step 3 – Perform segmentation between functional tiers, or not?

This is probably the most challenging step because security and flow discovery are involved. Understanding detailed flows, communications and developing security postures takes time, not to mention expensive flow discovery process, tools and software.

However, if we are only building an AC fabric during the first phase, security and segmentations are not needed.

So what benefits do you get by stopping after the AC design phase?

• Application Centric automation. One of the main goals of AC is to provide application-level awareness top-down by aligning network policies with application tiers. Start with understanding the components of an application, then build network policies based on application tiers and finally, deploy holistic configurations for an application via automation.
• Application Centric operation. You might be familiar with Application Performance Monitoring (APM) software like AppDynamics, NewRelic, Dynatrace, etc., all of which can help catch application issues before user experience starts degrading. However, the shortcoming is they lack visibility at the network layer, which becomes a gap in holistic monitoring solutions. Aligning network and application monitoring will allow teams to identify application issues caused by the network much quicker.
• Application Centric software development in a private cloud. Developers usually do not care about how the underlying infrastructure is deployed, as long as it's deployed quickly and holistically (think of XaaS). With ACI's private cloud capabilities, you can develop in-house self-service solutions with the network deployed as part of the overall application/system initialization process.
• Application Centric security. Set your fabric up for future AC segmentation. Security and segmentation are not a destination, rather a journey. Because cyber threats will never stop and will continue to evolve, so will security.

Therefore, I encourage every ACI customer to try, at least, AC designs without segmentation. The key is to understand that AC design is a stepping stone towards segmentation and security. This doesn't mean that security should not be considered at all during the AC design phase. Rather, don't mix them together into a single effort.

ADM can help complete the full picture of AC design but is not required, especially for small to medium-sized environments. However, flow discovery (usually via ADM) is necessary for security and segmentation. ADM comes in two parts: manual discovery (interviews) and software-based discovery.

It's not about Network Centric, nor Application Centric

Imagine that we just completely ignore the concept of Application Centric and Network Centric for a moment and only consider the essential features ACI provides. We end up unlocking endless possibilities with ACI, such as shared infrastructure design, hybrid designs, L2 segmentation designs, swimming lane design, etc.

The term Application Centric design is overused and has been tagged with too many overly complex concepts. Fundamentally, if we consider how multiple EPGs associate to BDs in an N-to-1 relationship, we can already start building an AC design, which requires zero software. 

In building an AC design, we also need to familiarize ourselves with the concept of decoupling VLAN from subnets. Logical designs such as EPGs naming, VLAN design, domain attachment, and object sharing will be the key to a successful AC design.

While we spend little time on EPGs during an NC design, we spend most of the time on EPG in an AC design. Eventually, we'll be able to steadily shift towards security, segmentation, automation and operationalization in AC design.

It's not really about selecting either design. Again, NC and AC are not mutually exclusive. Instead, focus on leveraging ACI's native capabilities to meet your technical and business requirements.

What about security, segmentation and ADM?

As mentioned earlier, segmentation can be the second phase after the initial implementation of an Application Centric design.

Security, segmentation and ADM are essential to any organization, with or without ACI. During the journey towards a secured infrastructure, you will need tools, process, governance, standardizations and a cross-functional team to help drive it. For most environments, the challenges lie within visibility; you can't secure what you can't see.

Therefore, understanding traffic flow is critical to the success of segmentation. Security governance provides clarity for policy definitions. Standardization and process help streamline the deployment, control and maintaining the security posture. Lastly, a cross-functional team breaks down silos and will help deliver the solution holistically and accurately.

Hopefully, this article helps provide clarity to engineers, architects and customers who are struggling to pick between NC and AC designs. Lastly, I hope every ACI customer can give AC a try and not be bound by technical terms.