To learn more about Application Centric Infrastructure,
join us for a special webcast with John Chambers and Soni Jiandani
on November 6th at 10:30 am EST/7:30 pm PST/15:30 GMT.
Register here
I want to address some questions about VMware’s NSX virtual networking announcement that have been asked of us by the media and social Web commentators in the past few days. Specifically, they have asked why Cisco did not announce support for NSX and whether the announcement changes the long-standing strategic relationship between our two companies.
First, let me be clear: VMware is an important partner to Cisco, and we expect to continue our close collaboration around private cloud and desktop virtualization. As we outlined yesterday in a joint news release about Cisco and VMware’s mutual customers, thousands of organizations rely on our combined innovation in their businesses each and every day and I look forward to continued success in this area.
While we share a common vision for private cloud and desktop virtualization, there are significant differences in our visions over the future of networking.
Network virtualization is important. We both agree on that. In fact, over the past several years, we have delivered game-changing innovations in this area particularly with the Nexus 1000v and more recently with NFV solutions, both of which are key elements of the Cisco ONE portfolio. Today, more than 6,000 Nexus 1000v customers benefit from the flexibility delivered by our virtual networking technology.
However, a software-only approach to network virtualization places significant constraints on customers. It doesn’t scale, and it fails to provide full real-time visibility of both physical and virtual infrastructure. In addition this approach does not provide key capabilities such as multi-hypervisor support, integrated security, systems point-of-view or end-to-end telemetry for application placement and troubleshooting. This loosely-coupled approach forces the user to tie multiple 3rd party components together adding cost and complexity in day-to-day operations as well as throughout the network lifecycle. Users are forced to address multiple management points and maintain version control for each of the independent components. Software network virtualization treats physical and virtual infrastructure as separate entities, and denies customers a common policy framework and common operational model for management, orchestration and monitoring.
Cisco has a different strategy and that is embodied in the Application Centric Infrastructure. Application Centric Infrastructure (ACI) is an innovative secure architecture that delivers centralized application-driven policy automation, management and visibility of physical and virtual networks. It’s built upon a fabric foundation that delivers best-in-class infrastructure by combining hardware, software and ASIC innovations into an integrated system.
The architecture provides a common management framework for network, application, security and virtualization teams — making IT more agile while reducing application deployment time. It’s built for multi-tenancy ensuring proper isolation and detailed telemetry of SLAs across different consumers of the infrastructure while also providing a consistent security policy across both physical and virtual applications. ACI allows IT teams to offer a public cloud experience and economics to their customers while maintaining the associated SLAs and performance requirements for the most demanding business applications. It’s an open programmable architecture with a comprehensive set of APIs that enables the broadest ecosystem of datacenter management and L4-7 services. Finally, ACI enables comprehensive investment protection by leveraging existing IT teams’ skillset and infrastructure to lower overall TCO.
I recently wrote a blog post about how Network Virtualization is a Different to Server Virtualization as we think about the next chapter of networking. It’s key to remember that underutilized compute resources created the opportunity for server virtualization. Underutilization is not a problem in the network. In fact, server virtualization is pushing the limits of today’s network utilization and driving demand for higher port counts, application and policy-driven automation, and unified management of physical, virtual and cloud infrastructures in a single system. Businesses today are looking for more from their investments as they turn on new services and applications more quickly, in a way that is easier to manage and that can scale with applications needs.
We believe that delivering those benefits requires the flexibility of software coupled tightly with the performance and scalability of hardware and ASICs. That’s what we’re delivering with our Application-Centric Infrastructure vision and throughout the entire Unified Data Center portfolio.
Stay tuned for some exciting news from us in this area in the next few months.
Dear Ms. Warrior
Thanks a lot! Great wrap up and makes loads of sense. Being a network engineer, what I fundamentally never understood is how on earth would a software-only approach work in the first place?! Your typically lucid commentary addresses the same. Application centric Infrastructure indeed makes sense from a point of view of scalability and as an answer to “what is required as infrastructure to support my apps and scalability?”
As virtualization keeps evolving in different flavours, questions about Application Centric management of Cloud services are also being asked, especially as related to managing complex applications and workloads in the clouds which require automation of timely infrastructure reconfiguration. Do you envisage Cisco’s vision of ACI to also include addressing of similar scenarios please?
Thank you!
Best Regards
santanu
“what is required as infrastructure to support my apps and scalability?”–It is a great ACI question. Hope Ms. Warrior an help.
Another great question would be: How RJ’s 10G-HDPP–(High Density Patch Panel)can help the ACI?
For Ms Warrior, it may involve with “The Controllbility of the Coupled System”. For HDPP, it is an integration of the ACI.
Why Cisco not try?
I read this at 2:00 AM and wanted to re-read it before I posted a comment. I’m not completely sold on VMware NSX for network virtualization as it is yet to be even released. However, I’d like to hear some clarity around your statement that software based network virtualization doesn’t support multiple hypervisors and doesn’t scale.
As I understand it PayPal (48th most visited site on the Internet) uses Nicira v3.0 which tells me that it scales and they have over a combined 60,000 cores of ESXi and KVM running on their, I’m assuming virtualized network. I see this as a discrepancy between Cisco and the Software Defined industry (VMware/Nicira). As one of those bloggers that have been questioning the strength of VMware/Cisco relationship, I’d like to see specifics around these claims.
During the VMworld keynote, CITI, eBay and GE attested to their deployments of Nicira and its capabilities – scale being one of several discussed. This appears to conflict with your statement “It doesn’t scale” among others. Can you offer some context and clarify what you meant here and why it’s scaled so well with these very large customer deployments?
“During the VMworld keynote, CITI, eBay and GE attested to their deployments of Nicira and its capabilities – scale being one of several discussed” – No they did not. I attended the keynote. They talked about VMware in general, not Nicira. They use ESX heavily, but not yet Nicira (I asked).
In any case, the future is public cloud, not on-prem components like Nicira. Witness AWS’s remarkable growth. VMware has taken the right step by now investing in vCHS. That is the right bet for the future, not Nicira.
John, I as at Scott Carlson’s OpenStack session on on Paypal’s experience integrating ESXi, KVM on OpenStack over their Nicira based network. He specifically said they were running Nicira v. 3.
Anyway Rackspace is using Nicira 🙂 So yeah I guess it scales … :()
I attended the session as well and all three companies spoke about VMware nothing specific about the VMware NSX. In addition, the message about NSX was not clear define. It seems promising but the question is “Can this be possible today?”
This brings up several issues for me surrounding virtualized network components that I haven’t yet seen addressed. The first being how do software-implemented network functions stackup up against ASIC-implemented network functions in terms of performance? Is a VEM, for example, faster than a linecard? I’m sure in terms of east-west traffic it’s as fast if not faster, but what about traffic exiting and leaving the area served by the VEMS – north/south traffic?
Anyone who has worked with cisco equipment has seen that the biggest advancements in terms of performance often happen when functions are moved from software to custome hardware. So if those are moved back into software, isn’t that a step back in time?
So yes idle compute cycles are an opportunity to virtualize, but the just doesn’t extend logically to the network. Unused bandwidth isn’t an opportunity to virtualize network components.
However, when all you have is a hammer, as the saying goes, everything looks like a nail. Or a cloud in this case. So it seems like what to virtualize and where to leverage hardware is a topic not yet hashed out.
Lest be real, Virtual networks means less jobs for all of us.as Simple as that!
What does it take to deploy a new server with Cisco gear? we need to configure VLANs, we need to modify ACLs, we need to add entries to the firewall, at the same time coordinating with several IT personnel. Oh and on one configuration mistake, could put the entire DC at risk.
What does it take to deploy a new server using NSX on a virtual network? Fill out a template, deploy and your done. Equipment that needs to be modified are modified. The changes are automatically documented and I get an excellent view of my network’s health by using APIs.
Networks are becoming too complex. We are loosing time and money because we are doing 21st century networking using 20th century methods.