In reply to David H Deans.

David, thanks for your questions.

I definitely see a future where we have true network automation - not just alarms or triggers for human interaction. In fact, I believe we’re there now, especially with ACI and the Nexus 9000 series switches.

First, the Nexus 9000 series switches have open APIs on which everything is built. So there is nothing you can do using the command line or GUI that you can’t do using the API. This includes scripting via Python, DevOps tools like Chef or Puppet, open source orchestration tools such as OpenStack, or even turnkey solutions like UCS Director that automate anything within the switches and ACI in general.

This brings us to ACI - Application Centric Infrastructure. This is not a virtual machine-based orchestration tool or just an SDN tool. ACI uses the same management tools to deliver network virtualization as well as hardware abstraction. ACI works on both virtualized environments and physical environments, and allows you to assign policies to both in the same way.

Now any IT team member can have visibility into how applications and hardware are running. ACI offers health scores and alerts that can be used by custom and integrated orchestration tools to carry out tasks without human interaction. An example of this might be evacuating VMs off a host or physical machines to another rack (in a cluster setup) because of a physical or virtual network event.

With ACI, we separated policy from the underlying infrastructure layer as well, allowing you to build repeatable processes that offer maximum flexibility to administrators and engineers. With our OpFlex API, we’ve even created an agent framework to automatically distribute this policy to the points where it’s needed, allowing devices to automatically configure. While engineers may start with low-hanging fruit, the ease of use that comes along with ACI - especially when combined with something like Cisco UCS Director - will make it simple for engineers to continue on their automation journey.

Notice I’ve been using the term “application” a lot. That’s because we want ACI to truly help in responding to business drivers within a company, not just a new technology to be implemented. ACI introduces an intent-driven policy model designed to break down the language barrier between application/executive teams and networking teams. It allows application teams to directly describe their requirements in a language they understand while networking people focus on delivering applications, performance, and security in an agile and flexible way that will meet customer needs, whether that customer is internal or external to the company.

We believe this fundamental change of transforming IT to intent rather than process-driven is necessary to permit the evolution of automation from a framework for simple repetition of common processes to become a dynamic system. The goal of distributed processing networks - which dynamically adjust network behavior based on empirical observations without pre-programming - becomes possible with ACI.

For more information on ACI, you can refer to www.cisco.com/go/aci.