I am Soni Jiandani, SVP of Marketing for Cisco’s Insieme Business Unit. Together with a team of veteran leaders and engineers, we continue to disrupt markets to drive industry transformation. Our latest disruption is focused on leapfrogging Software Defined Networks (SDN) with a holistic approach to the future of networking: Application Centric Infrastructure, or ACI for short.
My blog is timed with announcing the shipment of ACI – namely the Application Policy Infrastructure Controller (APIC) with ACI mode for the Nexus 9000. But this is not a corporate sales blog. My intent is to foster an open discussion about the future of the networking industry.
ACI: A key enabler to driving fast IT
We have spent the past few years to gather the best and the brightest engineering minds focused on one simple goal: to design an infrastructure for our customers that meets the needs of applications today and in the future. These applications require dynamic, agile, fast, secure, scalable, reliable infrastructure that is automated as a native, baseline requirement.
Our whole approach to Software-Defined Networking (SDN) is very different from other models. By looking at the problem holistically, we’ve taken into account the variety of needs from a wide range of customers. We designed an infrastructure with the intent for co-existence of both physical and virtual networking worlds.
By focusing on the delivery of the application, we built a network based on its business requirements, including security and user experience services (L4-7). We did this with an open approach, allowing our customers to pick and choose the best of breed virtual or physical appliances to meet their needs.
Simplicity is a core part of ACI. The simplicity comes through the use of a common policy framework that empowers teams across the IT environment with the ability to more rapidly and cost-effectively deploy applications. ACI automates across network, security and application teams driving consistency of policies, and at the core – as there should be – scale, security and support for multi-tenancy. This means a single network can run workloads for multiple purposes: existing and emerging cloud applications, development lifecycles spanning enterprise, service provider and cloud provider customers.
Unlike approaches that focus solely on the virtual machine, we looked at where the network is today and where it needs to go. Today’s data center has workloads that are 70% virtualized, not 100%, and servers are only about one third virtualized. With new high growth applications being bare metal in nature such as Big Data and the emerging Linux containers disrupting virtual machines, in 5-7 years, it will be less virtual in the traditional sense.
The networks of the future will be an elaboration of the mixed workloads of today. Virtual machines will be used for specific workloads, bare-metal for others, and Linux containers like Docker for another set.
We took an approach that normalizes each of these, allowing them to be used where required and without the need for separate network tools.
Protect existing investment while realizing instant benefits
We’ve received positive customer feedback from those who have tested the Nexus 9000 and ACI over the past few months. We created a model to give our customers the ability to move their network into the next decade at their own pace. With the inherent flexibility of deploying ACI, our customers have the ability to gracefully transition to the required 10G, 40G and 100G speeds without the need for any rip-and-replace of existing networks and cabling plants.
A great example of this is NetApp. They chose Cisco’s ACI in its global development lab for this very reason, and are able to utilize the benefits today to create test scenarios, creating a DevOps methodology-driven private cloud. This allows them to speed up the time to market for their own products and customers.
Symantec IT found that with ACI, they are able to move to a more modern agile environment today. By having an ACI-automated IT infrastructure, they are able to significantly accelerate the detection and remediation of security issues with business critical applications.
Cisco’s IT Elastic Infrastructure Services (CITEIS), one of the largest data center environments in the world, has fully deployed ACI. As John Manville, SVP IT, Global Infrastructure Services, states:
“In Cisco IT we have deployed ACI in production, and we are continuously giving feedback to our engineering teams. We are receiving significant benefits, while also seeing the competitive advantage due to the network policies and policy-based automation it brings. The ACI technology represents potentially huge savings in IT operational costs.”
We look at ACI the way Wayne Gretzky looked at hockey: “A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.” ACI is not a good architecture; it’s a great architecture. We’ve designed a solution that takes customers where they need to be, with an on-ramp for where they are.
I want to hear what you think about our holistic approach to networking. And please share your own thoughts about the demands on your IT infrastructure in the coming decade. I promise a lively discussion.
For greenfield deployments or deployments with existing Nexus line devices, users can use leverage ACI.
But what about deployments with legacy devices (spanning across L2-L7) from cross vendors. When such an infrastructure is plugged alongside leaf and spine with ACI, how can APIC push down policies to those legacy devices which dont speak openflex or any variant of openflow.
How can we prevent them to turn out as blind spots in the network from APIC management perspective ?
Thanks for your question Dibakar.
Many customers have been concerned about integration issues with their existing networking equipment as they migrate to ACI. ACI does not require a greenfield environment. There are multiple ways of integrating with and migrating to ACI from any kind of existing network topology (ex: core/aggregation/access, vPC, VxLAN, etc).
In those mature production environments requiring additional capacity, new ACI pods are capable of being seamlessly interconnected with existing networks either by extending layer 2 VLAN’s or by interconnecting at layer 3 using standard route peering. Networks that require more granular segmentation and automation for layer 4-7 services can leverage an ACI as a data center policy engine connected to the existing networks. For those environments wanting to add full ACI policy capabilities without replacing the existing network, remote physical and virtual leaf switches can be added in an incremental fashion at the edge of the current network. For more information on types of integration, you can refer to this white paper.
As for Layer 4-7 devices, there are a number of open APIs that can be leveraged. OpFlex offers an API through which policy can be directly exchanged with an agent running on an L4-7 device. This allows the tightest level of integration with APIC. If OpFlex is not yet available on a device, there is also a device package API that leverages the existing APIs on L4-7 devices so they can be used in an unmodified manner with ACI. And of course, in the worst case, there is always the option of integrating directly with multiple management platforms to provide the proper networking within your environment. These may include automation and orchestration tools that take out the manual element of administration.
Many datacenters are migrating their DC networks to next generation switching and routing evolutions every 4-6 years on average. So while you may not be able to fully transition to an ACI design overnight, you may still head in that direction by integrating Nexus 9000 series switches into your current network design evolving to 10G, 40G and 100G while future proofing and making migration to ACI simpler later on.
If you would like more information on how to do this within your specific environment, please contact your Cisco Sales Engineer to figure out a design that will work best for you.
You said “My intent is to foster an open discussion about the future of the networking industry.” Okay, then let’s begin with some forward-thinking visions of progressive DevOps scenarios.
Within an Application Centric Infrastructure, can we envision a time and place where mundane policies become self-sufficient?
Do you see a future where networking automation of policies mean more than creating alarms or alerts that then require human intervention — in order to take action based upon that trigger event?
As you know, there’s an increasing expectation that CIOs and other IT leaders will evolve their roles (further up up the value chain), thereby devoting more time and effort to addressing the CEO’s desired strategic business outcomes — enabled by technology.
But as enterprise networks continue to grow in scale and traditional VM-based optimization approaches tend to plateau over time, the whole process of effectively managing very large deployments is still labor intensive.
I can foresee a more desirable future where lower-level tasks are routinely resolved by automated actions within an SDN operational model that incorporates robotic intelligence which goes beyond merely creating alarms or other alerts.
Can software defined networking software achieve this goal? Will software automation become more agile and actionable, just like the business processes that are intended to help humans harness its inherent capabilities?
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 http://www.cisco.com/go/aci.
Soni, thank you for your thoughtful and insightful response to my questions. You make a strong case for the ACI approach, and I’m now beginning to appreciate the benefits of what you refer to as a “fundamental change of transforming IT to *intent* rather than process-driven.”
The potential for applications that tap into these open APIs seems to be a powerful combination that every network engineer and architect should explore. In fact, I’m eager to learn more about how this approach will evolve over time. Very enlightening, indeed.
For greenfield deployments or deployments with existing Nexus line devices, users can use leverage ACI.