How Open is Cisco s ACI?

Transcription

1 Lippis Report 220: How Open is Cisco s ACI? By Nicholas John Lippis III President, Lippis Consulting March, 2014

2 Cisco s acquisition of Insieme Networks enables the next generation of data center automation led by Application Centric Infrastructure (ACI) and the Nexus 9000 family of switches, which is comprised of the Nexus 9300 series fixed switches and the Nexus 9500 series modular switches. In addition to offering rich programmability features, industry-leading layer 2 and layer 3 forwarding, and advanced behaviors, such as VxLAN routing, the Nexus 9000 switches run in a fabric mode commonly referred to as ACI. ACI is an architecture that enables the automated deployment of applications across the network using Application Network Profiles. These profiles use a common declarative policy language that automates network configuration. The policy creates an application dependency map that spans applications, compute, storage and networking across data center, campus and WAN to enable cross functional application troubleshooting and performance optimization. Critical to expanding ACI is the new Opflex protocol that enables an open source community to leverage ACI for policy-based automation for all data center devices (more on this below). ACI delivers the complete ability to provision, manage and monitor applications in a fully automated workload creation world. This is the Holy Grail of IT as it enables business resiliency and lowers OpEx. But the two big questions that many have been asking are: How open is ACI, and can I trust it? Applications and Networks Don t Talk to Each Other As the requirements for IT agility increase, administrators are constantly pressed to increase the speed with which they can deploy, manage and troubleshoot applications across compute, storage and networking domains. In the network space, a number of software-based overlay technologies were developed to approach this problem. These tools created issues in performance, integration with physical devices and management across overlay and underlay domains. Most critically, though, they focused on virtualizing the network as it is today rather than refocusing on the needs and requirements of applications. For instance, they are of little help in building a dependency map for an application across firewalls, IPS, load balancers, switches, virtual switches, virtual machines, bare metal servers, routers, WAN links, storage, VLAN, etc., that s required to deliver and service applications. They also hinder visibility by separating underlay and overlay environments. With no map of these dependencies and limited visibility, how are IT professionals to conduct change management, troubleshooting, monitoring, performance optimization etc.? How is application behavior assurance realized when various application responsibility dependencies are shared across administrative domains of compute, network, storage, devops, etc.? To create an application dependence map today, NetOPs has only a manual sniffer in its tool chest. What s really needed is a self-documenting policy, which is what ACI offers. ACI: Policy-Driven Application and Network Connection Cisco s ACI was purpose built to address these issues. The solution, built around the Application Policy Infrastructure Controller (APIC) and Nexus 9000, offers a combined overlay and underlay that provides line rate performance at scale with full real-time visibility across physical and virtual domains. Also, unlike traditional network overlay solutions, ACI is based around an innovative, declarative policy model that allows users to naturally describe application requirements and automate their deployment across the network. This Declarative Policy approach is a key differentiator for the ACI solution. It uses an abstract policy model to describe a future state of the infrastructure and relies on a set of intelligent devices capable of rendering this policy into specific device capabilities. By distributing complexity to the edges of the infrastructure, this approach promises excellent scale characteristics. Additionally, its use of abstract policy allows broad interoperability across devices without limiting a vendor s ability to expose a differentiated feature set. Abstract policies also give application administrators a self-

3 documenting, portable way of capturing their infrastructure requirements. Finally, Cisco s ACI solution was designed around open APIs. The APIC exposes a comprehensive REST API based on its policy model that supports integration with automation, enterprise monitoring and orchestration frameworks plus hypervisor and systems management. Each REST API call can directly configure multi-tenant policies, which the APIC communicates to network and service infrastructure via southbound APIs. Network and service infrastructure may include physical and virtual switches, as well as firewalls, load balancers, IPS, etc. Clients of the REST API include Puppet, Chef, CFEngine and Python for automation; OpenStack, CloudStack, VMware, Cloupia for orchestration; KVM, Xen, VMware, Oracle OVM and Hyper-V hypervisors, and system management tools, such as IBM, CA, HP, BMC; and enterprise monitoring tools, such as Splunk, NetScout, CA and NetQoS. ACI Architecture For ACI to deliver on its promise, it needs to be in-between management/automation/monitoring/orchestratio n and network/service infrastructure. ACI is based upon a set of open standards and initiatives. The most obvious one is REST for northbound communications. For ACI to enable applications requesting network services governed through policy, it needs to connect to any network/service infrastructure, not just the new Nexus 9300 and 9500 switches with custom ASICs. Between ACI and network/service infrastructure on the southbound, Cisco is proposing a new protocol called Opflex, which they plan to submit to the IETF for standardization. Opflex Opflex is designed as a generic, extensible policy resolution protocol. It was designed to function in a Declarative Control system, such as ACI, where a Policy Authority (PA) interacts with a number of distributed Policy Elements (PEs), such as physical or virtual switches, firewalls, ADCs, etc. In a Declarative Control system, the PA represents a logically centralized location where policies are specified while PEs instrument and enforce these policies across a control fabric. Policies are passed over an Opflex channel as managed objectives that can be interpreted by both the PA and PEs. A concept called Promise Theory, which provides the logical foundation for Opflex, is commonly employed in policy driven control systems. In a Promise Theory Hive, individual PEs make promises to a PA, agreeing to autonomously enforce policies that are in scope without detailed instruction from a PA. Scope in this case is defined by operational circumstances and end-points upon whose behalf policies are enforced. Opflex natively supports bidirectional communication, which is necessary for declarative policy resolution. To support a wide range of network/service infrastructure PEs, abstract policies rather than device-specific configuration is supported. Opflex enables flexible, extensible definitions of policy using XML/JSON, and through an Opflex agent, Cisco states that it can support any device vswitch, physical switch, network services, servers, etc. An Opflex agent would sit on a firewall, vswich, ADC, switches, routers, etc. The APIC or other Opflex-enabled controller communicates directly with devices equipped with Opflex agents as it distributes configuration instructions requested from applications, monitoring systems, systems/hypervisor management, orchestration systems and custom automation scripts. Polices may be directives, such as which servers can connect directly, or stating that web servers can connect to application servers. These policies are then translated into network/service configuration changes. Opflex is fundamental to ACI. It s in Cisco s best interest that a wide range of networking and hypervisor firms support it. Opflex is currently an IETF informational RFC, and Cisco intends to open source an Opflex agent that can be used by any hypervisor switch, physical switch or L4-7 device and even extend its use to the campus and WAN environments.

4 In addition to Opflex, Cisco has developed a scripting API for layer 4-7 devices based upon Python/CLI and XML. The scripting API, a first in the SDN ecosystem, is designed to support network service insertion and chaining of L4-7 devices to application flow without requiring any changes to network devices. There is a Device Specification that is an object model for a L4-7 device, and a Device Script that s an integration script using a L4-7 device s existing APIs. Device packages for most major vendors, such as F5, Citrix, etc., will be released as open source code on github.com website. Object Exposed REST Northbound APIs The northbound API is REST and based upon an open ACI object model, which is the foundation for integration with open source and third-party tools. JSON/XML over HTTP is the language plus transport and data store tools used for northbound communications. The northbound API promises to offer a wide range of service integration into ACI and is, thus, the most complex. Expect northbound vendor and open source package support to roll out over time. This is an ecosystem in development, and as such, Cisco has published its object model and documentation. It will make available a simulator environment, open source a Python SDK, Neutron Plugin for OpenStack and cookbooks for DevOps tools, such as Puppet and Chef. Cisco is also working with the community to build a unified view of policy across a number of open source projects. The goal here is to ensure that application policy can be portable across a wide array of technologies and implementations, and utilized even without the APIC and Nexus For example, Open Daylight has recently created a Group Policy project intended to build a policy abstraction API. It is supported by a number of companies, including Cisco, Plexxi, Midokura and IBM. Additionally, Cisco is engaged with the OpenStack Neutron community to expose a similar policy API. Cisco has also committed to work closely with the Open vswitch ecosystem to support compatible policy primitives. ACI offers a solution to today s uncontrolled growth of network operational cost. It s fundamental to establish the link between applications and networks without NetOps manual intervention. If it s able to deliver on its promise, then it will offer IT executives a powerful tool to offer on-demand service creation and deletion a requirement that s shared across the global 2000 and below. ACI: Trust and Openness For Cisco to realize ACI s promise, it will have to demonstrate that ACI is open and interoperable with non-cisco switches, routers, load balancers, firewalls, etc. On this front, it has done well in announcing support from partners, including Microsoft, Red Hat, Canonical and Citrix as hypervisors, as well as services products from Citrix F5, Embrane and others to be announced. Opflex could be an industry and/or de-facto standard if this momentum across the industry continues. Furthermore, its commitment to open source an Opflex agent with a liberal license much like Apache 2.0 and plans to submit Opflex to IETF for standardization; all of which are positive signals. However, the southbound API is where Cisco has to work hard for industry adoption. That s where it will have to answer the key questions of openness and trust. ACI is at the epicenter of IT infrastructure, which requires great trust of the technology that it will work securely to configure network and service infrastructure on behalf of applications. In Cisco s favor is the fact that it has a long track record of supporting a technology for the long haul. It has the economic resources to create the programs necessary and product engineering to navigate ACI through to success. But with ACI at the epicenter, some feel that there is a strong potential for a Cisco lock-in, as ACI will be controlling how applications use network infrastructure. Cisco s commitment to building ACI via open standards will be critical to its success. If ACI can support a wide range of network vendors equipment via Opflex, northbound systems and interoperable interpolicy management that allow true plug-and-play without lock-in, then ACI will be highly successful and Cisco, justly rewarded.

5 About Nick Lippis Nicholas J. Lippis III is a world-renowned authority on advanced IP networks, communications and their benefits to business objectives. He is the publisher of the Lippis Report, a resource for network and IT business decision makers to which over 35,000 executive IT business leaders subscribe. Its Lippis Report podcasts have been downloaded over 200,000 times; ITunes reports that listeners also download the Wall Street Journal s Money Matters, Business Week s Climbing the Ladder, The Economist and The Harvard Business Review s IdeaCast. He is also the co-founder and conference chair of the Open Networking User Group, which sponsors a bi-annual meeting of over 200 IT business leaders of large enterprises. Mr. Lippis is currently working with clients to design their private and public virtualized data center cloud computing network architectures with open networking technologies to reap maximum business value and outcome. He has advised numerous Global 2000 firms on network architecture, design, implementation, vendor selection and budgeting, with clients including Barclays Bank, Eastman Kodak Company, Federal Deposit Insurance Corporation (FDIC), Hughes Aerospace, Liberty Mutual, Schering-Plough, Camp Dresser McKee, the state of Alaska, Microsoft, Kaiser Permanente, Sprint, Worldcom, Cisco Systems, Hewlett Packet, IBM, Avaya and many others. He works exclusively with CIOs and their direct reports. Mr. Lippis possesses a unique perspective of market forces and trends occurring within the computer networking industry derived from his experience with both supply- and demand-side clients. Mr. Lippis received the prestigious Boston University College of Engineering Alumni award for advancing the profession. He has been named one of the top 40 most powerful and influential people in the networking industry by Network World. TechTarget, an industry on-line publication, has named him a network design guru while Network Computing Magazine has called him a star IT guru. Mr. Lippis founded Strategic Networks Consulting, Inc., a well-respected and influential computer networking industry-consulting concern, which was purchased by Softbank/Ziff-Davis in He is a frequent keynote speaker at industry events and is widely quoted in the business and industry press. He serves on the Dean of Boston University s College of Engineering Board of Advisors as well as many start-up venture firms advisory boards. He delivered the commencement speech to Boston University College of Engineering graduates in Mr. Lippis received his Bachelor of Science in Electrical Engineering and his Master of Science in Systems Engineering from Boston University. His Masters thesis work included selected technical courses and advisors from Massachusetts Institute of Technology on optical communications and computing.