Excellent overview of ACI.
Posted: June 30th, 2014
Authors: Chad Hintz and Cesar Obediente
Authors: Chad Hintz and Cesar Obediente
Understanding ACI
In this blog we wanted to take some time to give you a basic understanding of a system called Application Centric Infrastructure. The goal will be to give you an understanding of what ACI system is and isn’t through the rest of this blog and a bonus material we have a very special guest for a quick interview at the end of this post.
Before we start talking about ACI and how ACI is going to help IT companies achieves their goals, we need to realize one of the major gaps that we faced in today’s industry, is the separation or “the silo syndrome” between groups in the IT environment.
As it is represented in the below picture where every component in the Data Center is usually segmented and typically don’t collaborate with each other. But more importantly since the Applications are the most important component in the Data Center because that’s what runs the business, normally this group has direct access to the CTO office. Quite often in today’s environments the application requirements get lost during the translation to the infrastructure teams. This is where a new approach is needed to overcome this obstacle.
First we need to look at traditional infrastructure and how it is consumed. Networking in particular has usually had a control plane and data plane on a per device basis, as show in the picture below.
Because of this, we traditionally have consumed infrastructure on a device-by-device basis as well as from how we manage and monitor them on an individual basis. Over the years as we have added services such as security, Quality of service, load balancing it has become extremely complicated. To that point network engineers have become what we refer to as “masters of complexity”. As the industry has seen this problem emerge, a new shift to how networking is being consumed needed to be created. In response to this problem in the industry created Software Defined Networking (SDN).
What is Software Defined Networking?
Lets take a look of what SDN means to many people through this below illustration.
Well as you can see this can mean many things to many people based on what they are interested in looking at. At the heart of what Software Defined Networking is to fix the individual device-by-device consumption, management and monitoring.To solve this they decided to shift the traditional control plane and data plane to a centralized control plane model.
The above image show how the many flavors of SDN have decided to solve the traditional infrastructure consumption model problem by removing the control plane for management, monitoring and ease of integration into automation and applications. Since there is one place to do this it makes the network more open to spin up and spin down and a central point of integration to upstream applications and tools. One application that leverages this model of the separation of control and data plane is “Openflow”. Openflow is a protocol interaction between the controller (centralized control plane) and the data plane devices. One of the main applications that it is leveraging Openflow in today’s world is what we called a “Matrix Switch”. Where flows are created to redirect traffic to monitor devices.
What is old is new again!
In technology we often realize that in a lot of cases what is old becomes new again by applying an older concept to solve a problem. SDN is no different.
When it comes SDN approach, wireless networking had a similar model change many years back with the introduction of a wireless controller and “dumb” access points to solve the management problems of a bunch of autonomous access points spread through the network.
But something changed in the wireless model that we should take note of, as the years progressed and implementations broadened it was noted that not everything from a control plane or feature set was best implemented in a centralized manner. What this really means is that certain features and functions are better utilized at the edge and centralizing them to a controller first introduces a single point of failure (ways around this) but if I lose this central control plane I also lose my ability to implement these features and functions.
Has this solved our original problem?
Even though we can now manage the infrastructure centrally and have opened up API for data center to speak to a controller it still hasn’t solved our translation problem. Network and Application speak are still 2 different languages with no translation, the only way to do this is through human translation, which we know has not worked to date.
So what is ACI?
Application Centric Infrastructure at its core is a different way to consume infrastructure based on policy and any applications ability to consume any infrastructure in this manner. Why applications? The reason we build data centers is to house applications and the data to support them, so we should build a model that allows the applications to consume infrastructure in the easiest and efficient manner!
With traditional SDN we solved a portion of our original problem it also has introduce many other new problems to be solved. While ACI goal is to solve a similar problem it is not doing it with the SDN approach, therefor it is NOT SDN. Application Centric Infrastructure is “Policy Defined Networking” (or policy based infrastructure consumption in general terms). What this means is no longer do I manage each individual infrastructure component or centralize its control plane, instead a create policy of how I would like an application (in all its tiers and interactions) to consume an infrastructure.
This is known as a declarative policy model, where we tell a system (which ACI is, a group of machines acting as a system) what we want to see happen and allow the system to figure out how to implement it. Below you can see a system, which is a fabric or grouping of network devices. Above them is a declarative policy of what we would like the system to do and a device that is able to send the policy to the system, which is the application policy infrastructure controller (APIC).
Well how does this change networking from consumption, management and monitoring perspective? First it changes the management of the network into a policy that allows each device to have its own control and data plane but put together with other it will act as a system. The system then receives a declarative policy based on how the application would like to see the infrastructure act and puts it into a run time state.
Second, this greatly simplifies how infrastructure is consumed, and integrated to support applications. Since we have a policy that defines how we would like to have the infrastructure act, we can easily create the policy with high level intent based knowledge or use automation tools to specify these to the APIC.
Last but not least, since each policy is defined to support the entire application’s intent on the infrastructure (including tiers and interactions between the tiers) we can then definitively know how the system is implementing this intent and provide details back of health of the applications intent on the infrastructure using a scoring system.
Closing
This is a basic introduction into what ACI is and isn’t, we will have further blogs to break down each part of the system and policy model in future. As you can see by allowing abstraction of what we want into a policy changes we way the industry can consume, manage and monitor their infrastructure and only ACI can deliver this!