It’s been almost a year since Cisco publicly unveiled its Application Centric Infrastructure (ACI). As we’ve noted in the past, ACI had to overcome a number of preconceived notions about Software Defined Networking (SDN), and without some detailed explanation, it was hard to get your head around how ACI worked and how it related to SDN. As we continue to clarify the message, there are still a number of ACI myths running around out there that we have to spend a good amount of time dispelling, so I thought I’d summarize them here. (Like Centralized Policy Management, Centralized Myth Handling can lead to greater efficiency and increased compliance. :-)).
1. MYTH: Cisco has limited software expertise and can’t deliver a true SDN solution because ACI requires Cisco switches (hardware) as well as the APIC controller (software).
REALITY: Cisco believes data centers require a solution that combines the flexibility of software with the performance and scalability of hardware. ACI is the first data center and cloud solution to offer full visibility and integrated management of both physical and virtual networked IT resources, all built around the policy requirements of the application. ACI delivers SDN, but goes well beyond it to also deliver policy-based automation.
2. MYTH: ACI requires an expensive “forklift upgrade”– Cisco customers must replace their existing Nexus switches with new ACI-capable switches.
REALITY: ACI is actually quite affordable due to the licensing model we use and because customers can extend ACI policy management to their entire data center by implementing a “pod” with a cost-effective ACI starter kit. On July 29, Cisco announced four ACI starter kits which are cost effective bundles that are ideal for proof-of-concept and lab deployments, and to create an ACI central policy “appliance” for existing Cisco Nexus 2000-7000 infrastructure to scale out private clouds using ACI. Customers who compare ACI to SDN software-only solutions discover that operational costs, roughly 75 percent of overall IT costs, are substantially lower with ACI — so the total cost of ownership is compelling. Along with the fact that the existing network infrastructure can still be leveraged.
3. MYTH: The ACI solution is not open; Cisco doesn’t do enough with the open community.
REALITY: Openness is a core tenet in ACI design. 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 to provide tightly integrated solutions engineered to work together out of the box.
ACI is designed to operate in heterogeneous data center environments with multiple vendors and multiple hypervisors. ACI supports an open ecosystem covering a broad range of Layer 4-7 services, orchestration platforms, and automation tools. 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 with our Group-Based Policy model, we are offering a fully open source policy API available to any OpenStack user. Cisco is also working with open source Linux vendors like Red Hat and Canonical to distribute an ACI Opflex agent for OVS, and contributing the Group-based Policy model to Open Daylight.
4. MYTH: Customers want SDN solutions for their data center networks, but ACI is not an SDN solution.
REALITY: We believe that SDN or even software defined data centers are not the sole results customers are looking for – it is the policy-based management and automation provided by ACI that delivers tremendous benefits to application deployment and troubleshooting– and provides a compelling TCO by cutting operational costs. Channel partners agree with us: a recent study by Baird Equity Research surveyed 60 channel solution providers and found that they would recommend the Nexus 9000 portfolio and ACI to their customers.
5. MYTH: Cisco can’t compete against cheap commodity “white box” switches – they are the future of data center networks.
REALITY: The truth is that only a handful of companies can effectively deploy white boxes because they require a great deal of operational management and troubleshooting, which is more expensive than the upfront costs of non-commodity hardware. Deutsche Bank published a report last year titled “Whitebox Switches Are Not Exactly a Bargain” which explains how the total cost equation changes when you take into account operational costs. In addition, white boxes don’t include the rich features and capabilities that most companies want. Channel solution providers know this very well. The same Baird Equity Research study of 60 channel solution providers cited above indicated that only 2% would recommend NSX running on white-box or non-Cisco networking gear.
In the data center, “one size does not fit all”, so Cisco offers a variety of switch configurations to match customer needs. For example, customers can start with merchant silicon-based line cards and migrate to an ACI environment with ACI-capable line cards and APIC, if and when they wish.
BOTTOM LINE: We believe that Cisco will continue to win with our partners in the data center by delivering innovation through a highly secure and application centric infrastructure. Through training, support, and new certifications, we are empowering over two million networking engineers and thousands of channel partners worldwide to succeed with ACI in the data center and cloud.
Tags: ACI, APIC, Application Centric Networking, Nexus 9000, Open Daylight, OpenStack, OpFlex, SDN
[Note: This is the last installment of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not. Part 1 | Part 2 | Part 3]
As noted earlier in this series, modern DevOps applications such as Puppet, Chef, and CFEngine have already moved toward the declarative model of IT automation, so there is already some obvious synergy between DevOps and the Cisco ACI policy model. DevOps automation products are also optimizing application delivery processes and are designed to automate critical IT tasks to make the organization more agile and efficient.
In an early 2014 blog post, Andi Mann, vice president of strategic solutions at CA Technologies, wrote about the evolution to DevOps and the synergy with the Cisco ACI policy model:
Though the DevOps approach of today—with its notable improvements to culture, process, and tools—certainly delivers many efficiencies, automation and orchestration of hardware infrastructure has still been limited by traditional data center devices, such as servers, network switches and storage devices. Adding a virtualization layer to server, network, and storage, IT was able to divide some of these infrastructure devices, and enable a bit more fluidity in compute resourcing, but this still comes with manual steps or custom scripting to prepare the end-to-end application infrastructure and its networking needs used in a DevOps approach.
The drag created by these traditional application infrastructures has been somewhat reduced by giving that problem to cloud providers, but in reality this drag never really went away until Cisco innovated application-centric programmability with Cisco ACI. This innovative new solution is now poised to greatly benefit the whole application economy, especially management of the DevOps application environment…
Read More »
Tags: CA Technologies, CFEngine, Chef, Cisco ACI, devops, OpenFlow, OpFlex, ovsdb, Puppet Labs, SDN
[Note: This is the second of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not. Part 1 | Part 3 | Part 4]
Following on from the first part of our series, this blog post takes a closer look at some of these architectural components of Cisco ACI and the VMware NSX software overlay solution to quantify the advantages of Cisco’s application-centric policies and demonstrate how the architecture supports greater scale and more robust IT automation.
As called for in the requirements listed in the previous section, Cisco ACI is an open architecture that includes the policy controller and policy repository (Cisco APIC), infrastructure nodes (network devices, virtual switches, network services, etc.) under Cisco APIC control, and a protocol communication between Cisco APIC and the infrastructure. For Cisco ACI, that protocol is OpFlex.
OpFlex was designed with the Cisco ACI policy model and cloud automation objectives in mind, including important features that other SDN protocols could not deliver. OpFlex supports the Cisco ACI approach of separating the application policy from the network and infrastructure, but not the control plane itself. This approach provides the desired centralization of policy management, allowing automation of the entire infrastructure without limiting scalability through a centralized control point or creating a single point of catastrophic failure. Through Cisco ACI and OpFlex, the control engines are distributed, essentially staying with the infrastructure nodes that enforce the policies.
Read More »
Tags: APIC, Application Centric, Application policy, Cisco ACI, OpenFlow, OpFlex, ovsdb, SDN
[Note: This is the first of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not. Part 2 | Part 3 | Part 4]
IT departments and lines of business are looking at cloud automation tools and software-defined networking (SDN) architectures to accelerate application delivery, reduce operating costs, and increase business agility. The success of an IT or cloud automation solution depends largely on the business policies that can be carried out by the infrastructure through the SDN architecture.
Through a detailed comparison of critical architectural components, this blog series shows how the Cisco Application Centric Infrastructure (ACI) architecture supports a more business-relevant application policy language, greater scalability through a distributed enforcement system rather than centralized control, and greater network visibility than alternative software overlay solutions or traditional SDN designs.
Historically, IT departments have sought out greater automation as device proliferation has accelerated to overcome the challenges of applying manual processes for critical tasks. About 20 years ago the automation of desktop and PC management was an imperative, and about 10 years ago server automation became important as applications migrated to larger numbers of modular x86 and RISC-based systems. Today, with the consolidation of data centers, IT must address not only application and data proliferation, but also the emergence of large scale application virtualization and cloud deployments, requiring IT to focus on cloud and network automation.
The emergence of SDN promised a new era of centrally managed, software-based automation tools that could accelerate network management, optimization, and remediation. Gartner has defined SDN as “a new approach to designing, building and operating networks that focuses on delivering business agility while lowering capital and operational costs.” (Source: “Ending the Confusion About Software-Defined Networking: A Taxonomy”, Gartner, March 2013)
Furthermore, Gartner, in an early 2014 report (“Mainstream Organizations Should Prepare for SDN Now”, Gartner, March 2014), notes that “SDN is a radical new way of networking and requires senior infrastructure leaders to rethink traditional networking practices and paradigms.” In this same report, Gartner makes an initial comparison of mainstream SDN solutions that are emerging, including VMware NSX, and Cisco ACI. There has been some discussion whether Cisco ACI is an SDN solution or something more, but most agree that, in a broad sense, the IT automation objectives of SDN and Cisco ACI are basically the same, and some of the baseline architectural features, including a central policy controller, programmable devices, and use of overlay networks, lead to a useful comparison.
This blog series focuses on the way that Cisco ACI expands traditional SDN methodology with a new application-centric policy model. It specifically compares critical protocols and components in Cisco ACI with VMware NSX to show the advantages of Cisco ACI over software overlay networks and the advantages of the ACI application policy model over what has been offered by prior SDN solutions. It also discusses what the Cisco solution means for customers, the industry, and the larger SDN community.
Read More »
Tags: APIC, Application Centric, Application policy, Cisco ACI, OpenFlow, OpFlex, ovsdb, SDN
The Cisco-Citrix partnership has expanded significantly in recent years from UCS-XenDesktop based Desktop virtualization solutions to span Mobility, Desktop as A Service (DaaS) and most recently ACI-NetScaler joint solutions. I have been fortunate enough to be part of this momentum. And it’s been fun. In this blog, I want to announce another significant milestone on the Cisco ACI-Citrix eco-system front. The Citrix NetScaler Device Package for Cisco ACI is now FCS. You may recall earlier in August, we started shipping Cisco APIC worldwide. Read Blog
Citrix NetScaler needs no introduction and powers some of the world’s largest clouds providing capabilities that smartly and affordably scale application and service delivery infrastructures without additional complexity. Cisco ACI delivers a centralized fabric control and automation framework capable of managing application policies. This framework allows resources to be dynamically provisioned and configured based on application requirements. Citrix NetScaler provides core network services such as load balancing, SSL, SSL-VPN, and firewalls that can be used by applications in an automated, programmatic and simple fashion.
Now let us segue to the Citrix NetScaler Device package integration with Cisco APIC. Citrix NetScaler integrates with Cisco Application Policy Infrastructure Controller (APIC) through open APIs and provides per-app, per-tenant L4-L7 policy configuration and dynamic service chaining and insertion. In addition, the integrated solution also allows exchange of intelligent telemetry information between NetScaler and APIC for application and tenant visibility.
The diagram below illustrates the integration architecture.
The Citrix NetScaler Device Package for Cisco ACI comprises a device Model and a device Script. The device Model defines the functions provided by NetScaler SDX/VPX/MPX such as load-balancing, content switching etc., The device Script provides the adapter functions required for NetScaler to communicate with APIC.
The Citrix NetScaler device package is now available for download
The advantages of deploying Cisco ACI + Citrix NetScaler solution is multi-fold. First and foremost it accelerates application deployment with reliability, security and multi-tenancy on existing NetScaler physical and virtual appliances. All of this without disrupting services operational best practices. Second, NetScaler’s built-in Autoscale feature proactively signals Cisco APIC when to add or drop application capacity. This capability allows customers to efficiently and seamlessly utilize their resources without any added downtime.
The delivery of NetScaler device package is just the beginning of the Cisco ACI and Citrix NetScaler journey. Together, Cisco and Citrix are also focusing on driving standard protocols and open initiatives. Our engineering teams are in the process of defining within IETF standards body, the Network Service Header protocol (NSH) which defines service insertion specifications for application- and service-aware infrastructures. We are also co-authoring the OpFlex, an extensible policy protocol that abstracts service policies independently from device-specific configurations and contribute to Open Daylight.
Tags: ACI eco-system, Cisco ACI, Cisco APIC, Citrix NetScaler, L4-L7 services, NetScaler Device Package for Cisco ACI, OpFlex