Learn more about Cisco OpFlex and what it means for the company’s software-defined networking (SDN) strategy. Here you’ll learn about OpFlex’s development, use cases, and other helpful insight on Cisco OpFlex.
When the Cisco Application Policy Infrastructure Controller (APIC) began shipping this summer, it marked the final milestone in the rollout of Cisco’s long-anticipated Application Centric Infrastructure (ACI), the company’s take on software-defined networking (SDN). Cisco ACI forms the core of Cisco’s SDN offerings, but its underlying structure presents an evolutionary leap from the origins of SDN.
SDNCentral recently sat down with industry leader Soni Jiandani, senior vice president of marketing for Cisco’s Insieme Networks business unit, which has been responsible for developing the Nexus 9000 switch, the Cisco ACI architectural approach, and the APIC. We had a long talk about what sets ACI apart, what it means for the company’s existing SDN products, and how Cisco sees its SDN strategy evolving in the future.
Left: Soni Jiandani – SVP, Marketing, Insieme Business Unit at Cisco
Right: Shashi Kiran – Sr. Director, Products and Solutions Marketing, DC and Cloud at Cisco
SDNCentral: It has been more than ten months since Cisco announced its ACI approach. What has been the response so far?
Jiandani: The response and uptake from our customers and partners have been overwhelmingly positive. In the past nine months we had close to 600 customers on the Nexus 9K/ACI and won more than 60 customers within the first 30 days of shipping the APIC. Our technology partner ecosystem continues to grow, with 33 partners in various stages of engineering integration and joint solutions.
ACI appears to migrate Cisco’s positioning from network programmability to a focus on policy. What’s driving this shift?
Jiandani: Policy always has been central to Cisco’s vision of network programmability, SDN, and much more. ACI is the policy-driven systems approach to automation we take for the entire end-to-end network. It’s very similar to what we did with our Unified Computing System (UCS), which allowed us to transform the server market.
ACI allows us to design simpler architectures that are scalable and secure with an open, extensible policy model that allows the entire infrastructure to be application-centric. We believe this will help solve some of customers’ biggest operational challenges by automating their workloads at scale with visibility across physical and virtual deployments. This is a unique value proposition in the industry.
If you look across the infrastructure landscape, you’ll see a shift toward policy management, particularly toward declarative models like ACI’s that describe desired state without explicitly defining the configuration steps needed to achieve this state. This approach already has taken root in the DevOps world with tools like Puppet and CFEngine. We’re carrying some of those same concepts forward with ACI.
Are customers indicating that they want a policy-based model instead of flow-based programming like OpenFlow and other forms of SDN?
Jiandani: To be honest, our customers are just asking us to solve the problems they have today — challenges like network service automation and speed of application deployment. They are not dictating specific technologies so much as explaining their pain points and asking us for solutions.
By using a common policy model supported over a scalable physical and virtual network, we’re able to meet their needs while enabling them to embrace the cloud — both on-premises private and hybrid. Being able to extend it beyond the data center into campus and WAN is a bonus.
The APIC at the heart of the Cisco ACI ecosystem forms the crux of Cisco’s controller strategy. How do APIC’s design and implementation compare with other controller approaches?
Jiandani: We took a different, very open approach with APIC compared with classic SDN controllers on the market today. APIC is based on open APIs and open standards that enable our customers to leverage their existing tools and infrastructure, such as existing Layer 4-7 services.
APIC also is rooted in the declarative management model that focuses on distributed intelligence, scale, security, and a higher degree of resiliency. Traditional controller mechanisms follow an imperative system that compromise on scale, simplicity, and resiliency.
When we built APIC, we focused on managing physical and virtual components through a single point of management. We drive scale and security with our controller working closely across the network to drive policy across intelligent endpoints.
Kiran: The focus is on looking at ACI as a single “system” and not as siloed hardware and software. APIC fosters better collaboration across various IT teams because it provides a single point of provisioning, monitoring, and troubleshooting. It enables different teams to come together and have visibility into the network infrastructure, which drives application agility across and time to market.
How does APIC implementation provide resilience and ensure there is no single point of failure?
Jiandani: Cisco APIC is built as a cluster of multiple compute nodes, each capable of taking on any request for the entire fabric. Any node in the cluster is able to service any user for any operation.
The primary function of the APIC is to provide policy authority and resolution mechanisms for Cisco ACI and managed devices. As the centralized point for policy definition, APIC pushes policy to the ACI fabric, where policy gets enforced.
By centralizing policy definition but distributing control, networks can become much more scalable, resilient, and interoperable. Even if the APIC were to completely fail, the fabric will still continue to forward traffic.
What types of benefits can customers expect from ACI in a mixed-vendor environment? Is Cisco ACI really open?
Jiandani: Openness has been one of the core tenets around which we designed ACI. We see openness in three dimensions: open source, open standards, and open APIs. This naturally fosters an open ecosystem as well. Several partners like F5 and Citrix already are shipping device packs for joint deployments. Customers experience tremendous benefits when vendors come together and provide tightly integrated solutions engineered to work together out of the box.
ACI is unique in providing a multivendor, multihypervisor solution that offers flexibility with deployment models. It’s designed to operate in heterogeneous data center environments with open interfaces, open source, and open standards.
ACI supports an open ecosystem that includes a broad range of Layer 4-7 services, orchestration platforms, and automation tools. This reflects real-world data center deployments. One of the key drivers behind this ecosystem is OpFlex, an open standards initiative that helps customers achieve an intelligent, multivendor, policy-enabled infrastructure. Additionally, through contributions to OpenStack Neutron in our Group Policy initiative, we are offering a fully open source policy API available to any OpenStack user.
Kiran: We’ve exposed every aspect of our system via a REST API so it can be tied seamlessly into any other infrastructure component. This has enabled us to build a rich multivendor ecosystem around our ACI APIs. We’ve really made a huge investment with these initiatives to create an open platform.
For example, ACI supports third-party Layer 4-7 appliances from a broad range of ecosystem partners including Citrix, F5, and Cisco ASA. For virtualization, ACI supports multivendor hypervisor environments including VMware (ESX/vCenter/vShield), Microsoft (Hyper-V/SCVMM/Azure Pack), and Red Hat Enterprise Linux OS (KVM OVS/OpenStack).
In terms of orchestration, ACI supports multivendor orchestration tools such as OpenStack, Microsoft System Center, BMC Cloud Life Cycle Management, IBM Tivoli, and Smart Cloud Orchestrator, and Cisco UCS Director. We are planning to support VMware vCloud Automation Center in the future.
Finally, ACI also supports automation tools including Puppet and Chef, and it will support CFEngine in the future.
We expect ACI to simplify processes across traditional silos, drive operational efficiency, and accelerate the time to application deployment. For example, Cisco IT expects ACI to drastically drop application rollout from weeks to minutes. The division anticipates cost savings north of 41 percent with the bulk of cost savings coming from operational expenses. Customers like Symantec, Acxiom, UOL, and other companies going down this path project similar benefits.
Is it reasonable to expect that an umbrella policy framework across all elements of the infrastructure is possible or even desired? Can we expect Cisco’s competitors to participate in this?
Jiandani: We’ve had quite a bit of success in building multivendor ecosystems. In OpenStack Neutron, we’ve teamed up with Big Switch Networks, IBM, Juniper, Midokura, Nuage, One Convergence, and Red Hat to drive forward a policy API for networking. In OpenDaylight, Cisco is collaborating with HP, IBM, Intel, Midokura, One Convergence, Plexxi, and Red Hat to drive group policy.
So it’s wrong to look at this as a competitive situation where one vendor dominates the landscape. In each of the dimensions of policy, we have to work together as a community in partnership with the operators who are deploying the technology we build. This is where we are focused.
How can customers begin using SDN with Cisco? What is the starting point with ACI?
Jiandani: Cisco is educating our sales teams and customers about ACI and how to get them from where they are now to fully realizing the benefits of this evolutionary architecture across both greenfield and brownfield deployments — all the while keeping an eye on investment protection.
For customers testing the SDN waters, we’re making it easy for them to adopt ACI through attractively priced ACI starter kit bundles starting at about $175,000 (U.S. list price). These starter kits contain everything customers need to start an “ACI pod,” including a resilient cluster of APICs, fixed and modular spine switches, 40-Gb/s optics, and leaf switches.
We’re also introducing lab bundles starting at $115,000 (U.S list price) for customers to run in lab environments and get familiar with the ACI architecture. These can be upgraded to full-fledged production deployments.
We are taking investment protection quite seriously. For our Nexus 7000 series customers, we’re introducing bundles with the Nexus 9300 remote ToRs that can evolve into ACI-ready 40-Gb/s leaf-spine architectures. Because the ACI approach allows for seamless transition by extending the policy model to existing Nexus infrastructure, it protects existing investments in IP networks, hypervisors running virtual networks, Layer 4-7 services, automation, and existing systems and cloud management tools.
Trying to unify a set of network policies across all areas of an enterprise network must be a huge, expensive effort. What are the costs of implementing Cisco ACI?
Jiandani: The capital acquisition costs for ACI allow customers to achieve a lower capex while providing investment protection for existing IT assets. The operational costs, which usually form 75 to 80 percent of costs, are substantially lower, making total cost of ownership very compelling.
Most IT organizations and CIOs welcome unifying network policies, as they’re already using various forms of policy in their IT environments today. Now, ACI allows them the opportunity to do it in the context of networking and Layer 4-7 infrastructure at scale across multiple vendors while allowing IT teams to collaborate more efficiently. This is huge.
We’re extending this to compute and storage over time. We have a number of tools and migration strategies available that allow a gradual transition to state where you take full advantage of the policy model. From talking to many of our customers, they see huge operational benefits in using it as a means of documenting their current environment as well as maintaining an accurate view of infrastructure policy.
As Shashi mentioned earlier, Cisco IT expects cost savings with ACI to exceed 40 percent as a result of simplified provisioning, operations, and automation. CIOs love these kinds of savings. More important, it gives them significant agility and increased velocity to serve the needs of their business.
Let’s switch topics for a moment to white boxes. What’s your opinion on white-box switching? Do you think switching could go the way of the x86 server market?
Jiandani: If switching does continue to go down the way of the x86 market, Cisco’s strategy continues to win. Five years ago, with UCS, we out-innovated a commoditized x86 market. Today we’re still growing in double digits getting to No. 1 or No. 2 in various markets worldwide, while other server vendors are faltering with new innovations continuing to roll in, as announced earlier this month. Ultimately, customers care about innovation, TCO, and the value these innovations bring.
White boxes represent a do-it-yourself mentality and represent the lowest common denominator in terms of functionality and value. There are only a handful of customers that have the IT wherewithal to explore networks with white boxes.
The ACI approach focuses more on business needs and less on white box issues. It is all about delivering value.
Kiran: Deutsche Bank put out a report last year titled “Whitebox Switches Are Not Exactly a Bargain.” It’s interesting to see the equation altering dramatically once TCO and operational savings come into play with ACI.
Looking ahead to the next 12 to 18 months, what developments do you expect to see with ACI?
Jiandani: In the short term, you can expect customer deployments across several segments. Now that APIC is shipping and we have the ACI starter kits and lab kit licenses, more customers are getting exposed to the benefits of ACI and how they can bring it into existing deployments.
We’re seeing positive traction for Nexus 9000 and support for ACI across our entire customer base. With innovations like the BiDi Optics, we see customers making a shift to 40 Gb/s while protecting 10-Gb/s cabling plan designs, saving millions of dollars during the transition. You also will see our partner ecosystem broaden as we engage in joint go-to-market projects with our partners to get customers ready for ACI.
The new applications of today are imposing real demands on the infrastructure. The aspirational goals we had when we were architecting ACI were simplification, simplification, simplification – at the infrastructure layer, the system layer, and the management layer. We expect the market will see that an application-centric paradigm shift will actually enable them to drive a much simpler way of solving their problems. It will be an exciting journey.
Kiran: We will continue to share customer success stories and information on new innovations at www.cisco.com/go/aci. Be sure to keep a lookout.