ACI

There’s been a lot of talk in the market around Software defined networks with VMware and Cisco leading the way with NSX and ACI respectively. But with the introduction of a new technology comes a new wave of terms, buzzwords and abbreviations and despite Cisco’s ACI being launched back in January 2014 there’s still a lack of understanding of what ACI is, where it fits and what the benefits of a Software Defined Network is. With a focus on terms like contracts, policies and end point groups, which although important when digging deeper into the technology, there has been more confusion created leading to people dismissing the technology due to a perceived level of complexity.

Some of the key questions we’re hearing around ACI are:

Where does it fit? Is it an enterprise offering suitable for only the largest of Data Centers with specialist teams? Is it only suitable for Service providers with multi tenanted environments? What benefit would ACI offer me? Do the benefits outweigh the challenge of incorporating and learning a new architecture or methodology of networking? The aim of this article is to try and simplify the concept of ACI and answer those questions while also demonstrating that although ACI can be a complex beast when digging deeper the overall concept and user experience is essentially simple.

So what is ACI? As mentioned earlier there are policies and contracts and the use of end point groups but in it’s simplest form and to explain the biggest benefit of ACI the easiest way to think of ACI is that it gives you a central point to manage and configure your Data Center fabric from. With the introduction of an Application Policy Infrastructure Controller (APIC) which sits outside of the fabric and gives you a central point to carry out configuration which is then pushed out across the fabric. When you look at your traditional way of configuring a network going hop by hop configuring through the command line on each device this creates a simplistic way to create configurations with less chance of human error. Where does ACI fit? With the release of ACI there was a definite view that ACI was aimed at the enterprise and large scale fabrics but as the technology has matured there’s been a shift in the view of who can benefit and what size of fabric work best within ACI. It’s very much a case now of being use case dependant rather than size dependant with more and more small ACI pods being deployed where people can benefit from centralised management of the fabric and increased levels of telemetry offered through ACI as well as some of the more complex functionality of ACI in terms of traffic shaping and micro segmentation. Another area of concern within the market for ACI has been the shift in physical design topology with a shift from your traditional tiered architecture with Core, Distribution and Access layers to a spine and leaf architecture. The concern hasn’t been around any form of technical concerns with the shift in topology but more a case of engineers sticking to what they know and being reluctant to move from an architecture that they have relied on and implemented for years. Of course as I’ve alluded to earlier ACI is complex and see’s a shift from our traditional design concepts and there is a lot to learn with few reference points back to old forms of networking and the OSI model but there is definitely enough benefits and reason to shift to an ACI fabric to warrant the time invested in learning the technology. For this reason we’re currently running ACI demo sessions within our lab environment to demonstrate ACI in real world use cases and show that it really isn’t as complex as first thought.