For disaster recovery, political, and organizational reasons, enterprises like to have multiple datacenters, and now they are going hybrid with public cloud capacity adding in the mix. Having networks scattered across the globe brings operational challenges, from being able to easily migrate and manage workloads across the multiple sites and increased complexity around networks, security to adopting emerging datacenter technologies like containers.
As the world becomes more cloud-centric, organizations are looking for ways to gain greater visibility and scalability across their environments, automate as many processes as possible and manage all these sites as a single entity.
Cisco Systems is putting new features into the latest release of its Application Centric Infrastructure (ACI) software that they say can address many of those problems, including more easily managing multiple ACI network fabrics in different geographical locations and integrating Kubernetes for better container management.
ACI 3.0 is the latest version of the software that drives Cisco’s software-defined networking (SDN) strategy. The networking giant unveiled ACI in late 2013 as an answer to the growing network virtualization trend that was being driven by the likes of VMware (with its NSX technology inherited when it bought Nicira), smaller startups, and open source projects. The idea was to create a network architecture that responded to the demands of applications, ensuring the necessary resources were available. The response has been good. The company has more than 4,000 ACI customers, and in Cisco’s fiscal fourth quarter, ACI revenue grew 38 percent year-over-year.
In addition, earlier this year, Cisco unveiled an initiative called Network Intuitive, which is designed to drive the development of intent-based networks that are intelligent enough through machine learning and advanced analytics to anticipate needed actions, offer predictive network analysis, address security threats before they become a problem and essentially evolve by learning over time. Intent-based networks are a key part of Cisco’s larger efforts to address customer needs in an increasingly multi-cloud world, CEO Chuck Robbins said during a conference call in August to discuss the quarterly numbers.
“We are helping our customers take full advantage of a multi-cloud world that has become the norm in managing their applications and hybrid cloud solutions,” Robbins explained, noting the combination of ACI with the company’s Unified Compute Systems (UCS) as well as the new intent-based network. “Our goal is to deliver the best multi-cloud platform built on an intelligent Intuitive Network enabling faster automated and highly secured delivery of applications in the cloud.”
ACI 3.0 is the latest step in that direction. A key new feature is Multi-Site Management, which enables ACI customers to more seamlessly connect and manage multiple ACI fabrics, whether they’re scattered across multiple datacenter or private cloud sites or within the same on-premises environment but running on multiple clusters. Much of the work, from connectivity to policy management, can be automated, according to Srini Kotamraju, director of product management for Cisco datacenter networking. Using traditional datacenter interconnect technologies in such distributed environments is difficult, complex and expensive.
Cisco on Thursday announced updates to its software-defined networking (SDN) offering, Application Centric Infrastructure (ACI), with the intent of simplifying network management for the growing number of customers adopting complex, multi-cloud strategies.
The latest release (ACI 3.0) offers improved security and simplified management for any combination of workloads in containers, virtual machines, and bare metal for private clouds and on-premise data centers.
"By automating basic IT operations with a central policy across multiple data centers and geographies, ACI's new multi-site management capability helps network operators more easily move and manage workloads with a single pane of glass - a significant step in delivering on Cisco's vision for enabling ACI Anywhere," Ish Limkakeng, SVP for data center networking at Cisco, said in a statement.
I can’t believe it has been a year since I wrote the blog series (part-I, part-II, part-III and part-IV – last one with help from Vincent Esposito) to share some ideas about how to bring theory to practice when it comes to ACI and Micro Segmentation.
In the last 12 months we have added quite a lot of new functionality to ACI and in this post I begin another small series to share the latest about APIC related to Micro Segmentation. Now we are getting to the point where the architectural advantages of ACI and APIC will begin to show and shine compared to alternatives.
To begin with, the APIC declarative approach to network and policy allows it to interact with different data plane implementations. APIC does not need to have low-level information of the data plane specifics, since each data plane will be programmed in its own particular way via a local OpFlex agent. This approach has advantages scaling, but in addition, it allows us to adapt to changing environments and potentially work with third party data plane elements. As an example, APIC can program L2, L3 and stateful security policies to Open vSwitch instances. We use that approach as part of our OpenStack KVM integration as well as on the APIC CNI-plugin integration with Kubernetes.
A consequence of this architectural advantage of APIC is that it does not depend 100% on the virtual switch. In other vendor SDN implementations, you have to install (and license) the vendor’s virtual switch and in absence of it, you get nothing. Not the case with APIC.
For instance, in the case of the VMware native VDS we cannot program policies on it, but we can program it using open northbound APIs with simple features in order steer all traffic to the ACI leaf, where we can apply policies. In a way, we program the VDS to act like a FEX: all traffic goes to the leaf where we can do more intelligent things. So sometimes we apply policy on an ACI leaf, sometimes we apply policy on a virtual switch, and sometimes we will do it in other data planes.
The other architectural advantage is that our model expresses policy intent, and policy is not just restricted to security. For example, QoS settings can be part of policy. I will elaborate this a bit more in upcoming parts of this series.