Wishing you all a very Happy New Year and thanks to you all for considering ACI as your SDN solution to simplify your data center operation and automation. This is a follow on to my last blog to provide details on how we have delivered a true disruption in networking and opened the gate for agility of your applications where-ever they are.
The ACI’s policy model allows a consistent way of managing your infrastructure. For people new to ACI, let me step back and describe what I mean by policy model.
With traditional networks, application teams put in requirements for their infrastructure teams who then translate it into networking constructs like VLANs, subnets, ports, and routes often times using spreadsheets. The following picture depicts a very simple case for a three tier application. As you can see, the workflow for how application requirements get translated which can be slow, labor intensive, and vulnerable to manual errors.
Now imagine adding security, load balancing for the web tier, and any other L4-L7 services into this diagram. The problem quickly gets out-of-hand and this explains why it takes days to weeks to deploy a new application. Now that you appreciate the complexity of configuration, but what about day to day operational challenges such as:
- What happens if subnet allocated to the tier runs out of IP addresses?
- What if I want to spin up a new webserver but I just ran out of compute capacity, can I place it wherever capacity exists in the infrastructure?
- What if I want to make a change in application, do I need to wait for days?
- What if I have to split off the application because it serves an environment with new regulations, or a part of the company that will be sold?
- And many more
ACI Policy Model
This brings in the context the ACI policy model. You indicate the intended state of your application to the APIC controller as follows:
The application owner specifies tiers, security constraints between these tiers, how web-server connects to outside world, and as needed firewall, load balancer, and any other L4-L7 services. The APIC takes these inputs and provisions the entire application automatically. All the questions cited above for traditional networks are no longer a constraint with the ACI architecture.
Under the covers, APIC handles all the complexity of diverse network infrastructure and mapping to the physical or virtual elements. Since APIC already knows the relation of an Application’s Policy Model to the real infrastructure elements, it automatically correlates infrastructure events and failures to each tenant and application.
Just to give you a sense of visibility and troubleshooting, let’s imagine today’s situation with a network link failure. For most customers, an event/failure is logged in some management system. The network administrator may, at best, know the server and/or set of servers affected. The application owner has no clue of what happened, perhaps can only see degraded performance. In APIC, as soon as the link is down, the impact will be reflected on the health score of the application as shown in example below:
What we delivered so far under the ACI Model
Based on ACI’s unique and flexible architecture, we first shipped ACI with support for bare metal and for ESX through integration with vCenter. But soon we extended it to shipping the following combinations today. Note the customers still operate using the same high level Application Policy Model with the choice of workload type – Bare-metal, VMware ESX, Microsoft Hyper-V, KVM, Xen, containers, and L4-L7 services. The result is:
- Consistent Network connectivity across Bare Metal, ESX, Hyper-V, KVM, Xen, and Containers
- Consistent Security enforcement across Bare Metal, ESX, Hyper-V, KVM, Xen, and Containers
- Consistent Multi-Vendor L4-L7 services across Bare Metal, ESX, Hyper-V, KVM, Xen, and Containers
- Consistent Visibility, Troubleshooting across Bare Metal, ESX, Hyper-V, KVM, Xen, and Containers
The Sky’s the Limit with the ACI Policy model
Now that we are on the same page with the ACI policy model. Let’s stretch our imagination to provide the same consistent policy model for your entire infrastructure. Here are some of the thoughts we have and customers requested:
- What if you are able to provide a trait stating whether an application is active/active or active/standby across sites and multi-site deployment happens?
- What if you are able to say extend this application to branch?
- What if you are able to extend your on-prem applications to hybrid cloud with same ACI consistent policy model and troubleshooting?
- What if you are able to share the same consistent policies across compute, network, and storage?
- What if you have visibility to derive these decision based on real time application latency and telemetry for all of your applications?
Conclusion
With ACI, I am humming my favorite song by R. Kelly, 1998:
If I can see it, then I can do it
If I just believe it, there’s nothing to it
I believe I can fly
I believe I can touch the sky
For More Information:
- Executing on Our Vision and Strategy: The Future of Networking for an Application Centric World
- ACI Overview Video
- ACI Virtualization Integration with vCenter, vRealize, SCVMM, Azure Pack
- Benefits of Cisco Application Centric Infrastructure and OpenStack
- Contiv Networking for Containers
- ACI Ecosystem
- Pulsant Delivers Agile and Cost-Effective Hybrid Cloud Services with Cisco ACI
- Symantec Delivering on Its Strategic Vision with Next-Generation Secure Datacenter Powered by Cisco ACI
Is EPG grouping by DNS record GA?
Yes Marc this is in list as well to deliver.
Can ACI enable application to choose say cloud provider A vs provider B via performance (storage, network) policy based decisions? That could be a big use case -enabling cloud vendor agnostic apps and inter cloud app mobility.
Shaloo, that’s the direction we are headed with future hybrid cloud capabilities along with telemetry based on latency for example. And most importantly, focus would also be ability to operationalize and troubleshoot the applications wherever they resides.