The Data Center Network Evolution

Editor's Notes

• #16: This scripted slide is part of the Simplified IT - core ACI “Easy” message. If seen by itself, the script might not make sense. Animated Slide: YES To deploy applications, we need to deal with two different set of languages. Those of the application people and those of the network/infrastructure people. The key to remember is that the business needs information/data which is delivered by applications. The applications themselves depend amongst other things on network infrastructure, but the business doesn’t need or care about the network infrastructure itself. When applications need to be deployed they talk about certain aspects of the application – they use their own jargon/terminology. They talk in tiers, in availability, in compliance and in availability. The infrastructure language is very different. To deploy the application, the network team needs to know about VLAN’s, subnets, ACL’s, firewall rules, loadbalancing rules. There is a massive mismatch, and it is solved by human translation. The network infrastructures teams hopefully translate the requirements correctly… if not, there will be a second and third round of discussions, re-configuration until the translation is done in a way the application can run. Fun fact you could mention: Did you know that the network infrastructure teams have lots of ways to say “NO” without actually using that word? We ask questions that the application teams don’t know how to answer with the end-result being the application teams end up with actions and the network teams don’t have to do things yet (“which VLAN’s would you like”, why do you need 3 VLANs? Do you need me to enable ACL port 443 or port 80? ETC). If we don’t want to be stuck with an action, just ask a question  Taking away this human translation problem is one of the things we are trying to solve. Getting to a new way of describing connectivity that is driven from the right of this slide, not the left. Not via CLI, not only Software Defined, but Policy Driven and Application Centric Note: These are the term used in the last slide. Nice to mention them here and to recap in the last slide
• #17: This scripted slide is part of the Simplified IT - core ACI “Easy” message. If seen by itself, the script might not make sense. Animated Slide: NO Cisco introduced Application Centric Infrastructure (ACI) publicly in November 2013 and we started shipping ACI to customers in August 2014. There are a number of key characteristics that form the foundation of ACI that I would like to introduce you too now. Apps + Infra: ACI is focused on an Applications infrastructure needs, not just about forwarding packets. For the first time a network understands that the packets it is forwarding belong to applications and for the first time a network can provide application relevant information about the applications infrastructure behavior/needs. We have built ACI around the infrastructure needs of applications. Physical and Virtual: The new DC networks (or fabrics as we started calling them) have changed in that while there are now much more virtual workloads that need to be supported the actual number of physical servers still large and is not projected to go down in numbers. Also the new way of developing applications (DevOps, Agile, distributed) has changed the communication needs from mainly north-south to mainly east-west (more on that later). That impacts the physical requirements of a new DC network or fabric, but more on that later. They key message here is that physical systems play a critical role in most customers business environments (and don’t forget, VM’s run on hypervisors which run on physical servers). ACI delivers network infrastructure connectivity to both virtual and physical workloads EQUALLY. Secure: ACI is built from the ground up with security and multi-tenancy in mind. Todays DC network has a default policy that allows end points (workloads) to communicate unless there is a specific configuration that forbids it. It is open from a security perspective. ACI fundamentally changes the security level as the default policy is to deny communication between end points (workloads) unless there is a specific policy that allows it. (Note: I’m specifically not mentioning more about security at this stage, there is specific Security slide coming later). Open: Open is top of mind in many of our customers conversations with us. Open protocols, open source, open programing interfaces etc… ACI is designed to be open. Open with regards to a single API that can be used to talk to ACI. Open with regards to the protocols used inside the ACI fabric, Open with regards to the eco-system and the protocol used to distribute policy (Note: I’m specifically not mentioning OpFlex at this stage yet, just want to set the scene for open, to have a more detailed follow-up conversation later in the presentation) OnPrem and Cloud: (note: Of the 4 points this is the least tangible for now, decide if you want to cover this or not) ACI can be deployed on premises by enterprises and services providers. It is multi-tenant and secure by design. We see ACI as the fabric foundation for cloud offerings, both private On-Prem as well as Cloud. Cisco has introduced the Cisco Global Intercloud, an initiative to build the worlds largest cloud of clouds, together with our service provider partners. The foundation that the Global Intercloud is build upon is ACI. OnPrem and Cloud: A significant portion of customers have moved to Converged Stacks, and in the most recent Gartner Magic Quadrant, Cisco is represented in the leaders quadrant twice, with the Vblock and FlexPod offerings. Both of these converged stacks have announced support for ACI enabled Converged Stacks.
• #21: One of the core design principles behind ACI was to provide complete visibility into the infrastructure – physical and virtual. Cisco APIC is designed to provide application and tenant health at a system level by using real-time metrics, latency details, atomic counters, and detailed resource consumption statistics If you application is experiencing performance issues, you can drill down easily into the lowest possible granularity – be it at a switch level, line card level, port level. We have atomic counters – That essentially enable you to get consistent view of your counters anywhere within the fabric. The holistic approach to correlate virtual and physical and tie that intelligence at an application or tenant level ensures that troubleshooting becomes extremely simple across your infrastructure, through a single pane of glass