Posted: June 30th, 2014
Authors: Chad Hintz and Cesar Obediente
Understanding ACI
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
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 traditional 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!
Bonus Material
Here is our interview with Mike Dvorkin, Co-founder/Chief
Scientist at Insieme Networks and Distinguished Engineer at Cisco.
Topics include:
·
Changes in how conceptually we interact with the
Network Infrastructure
·
What will Role be for Applications and
Infrastructure engineers in the future of Data Centers
·
ACI and Promise Theory Clarification
·
Where do you see things going in 6-12 months
