5 Questions Cisco Doesn’t Want You to Ask About ACI
Nov 14, 2013
Last week, Cisco launched their Application Centric Infrastructure (ACI). Much of the discussion centered on business transitions, technology evolution, and how to capitalize on the next big trend, which they call the “Internet of Things.” And while it may sound good at face value, it’s important to look under the hood and evaluate if ACI can actually deliver on the promises that Cisco has outlined.
As you’re taking a closer look at the details surrounding this new infrastructure, here are five questions to ask about Cisco ACI:
1. Is Cisco’s open the same as your idea of open?
Openness must translate to conforming to industry standards, and supporting broadly used protocols to ensure interoperability, so that customers avoid getting locked-in by a specific vendor. In the past Cisco has implemented proprietary protocols well in advance of industry ratification and, at first glance, ACI looks notoriously headed in the same direction. During the launch, Cisco stated that ACI would provide open APIs, and work with a host of partners in the data center ecosystem, but what they didn’t mention was interoperability. For instance, Cisco’s proposed technology to interconnect data center/cloud locations is based on proprietary protocols like OTV and LISP on the Nexus 7k switches. Furthermore, Cisco uses a proprietary NSH header for their specific implementation of service stitching. They also use proprietary optics on their devices like the QSFP-40G-SR-BD optic that only works in their new Nexus 9000 switches but not any other switch in the industry, including Cisco’s currently shipping Nexus switches. Make sure to ask Cisco how ACI will interoperate with other vendors’ equipment. You should be wary of “open-washing,” and instead focus on the key attributes of interoperability (Will what I buy work with my current or future technology from other vendors?), multi-vendor support, and flexibility (Can I continue to evolve my network solution to adapt to future open standards without another change?) so that you can build your networks to solve your problems.
2. How will ACI work with my current data center management systems?
Your organization is probably not starting from scratch. You have some infrastructure in place, including servers, storage and networking devices. More than likely, you have data center management systems in place for provisioning, configuration, monitoring, health management and troubleshooting. Cisco didn’t announce support for vCenter for VMware environments, so with Cisco, you will still need vCenter and also APIC. What you really need is a single pane of glass across platforms and not a swivel chair method that’s prone to errors. Although they showed some other vendors’ logos on their slides, Cisco didn’t say whether ACI would work with existing versions of their management tools or if you will need a new version. So ask Cisco how ACI will integrate with management/orchestration systems that you already have in place that were supported by Cisco in the past. The last thing your organization needs is to implement a brand new management system that does not integrate well with your existing management systems, which requires additional cycles for training and increases the potential for mis-configuration.
3. How long will Cisco support ACI fabric?
Cisco hopped on the fabric bandwagon a bit late, and over the past three years, they have come out with a number of solutions they call fabrics: Fabric Extender (FEX), FabricPath and Dynamic Fabric Automation (DFA), to serve different parts of their portfolio. With this announcement, there’s yet another fabric to add to the list and it’s not compatible with the others. The ACI fabric is based on a new approach using a VXLAN-based foundation. The obvious question is: What does this mean for FEX, FabricPath, DFA? Does Cisco expect your company to support multiple fabric architectures? Cisco has not stated if there is any migration path for those customers who have invested in current fabric architectures or if the switches used on those architectures will work in an ACI fabric and vice versa. Even if the benefits of ACI sound compelling, it’s worth asking about the longevity of the fabric architecture (both the one you already purchased and the one you are considering to buy), since it’s such a large investment in equipment, deployment and administration that you are making.
4. Will I have to rip and replace?
Cisco supported the Catalyst 6500 for over 15 years, but the Nexus 7000 is being made redundant by the Nexus 9000 after just a few years. As before, the new device does not have the same feature set as the one it is replacing. It seems that Cisco expects you to choose between features on the 7000 and density on the 9000, or that they expect you to buy two switches to do the job of one. What about their SDN architecture? You can’t use just one. You will have to run two SDN systems. The APIC controller works with the Nexus 9000s but the onePK toolkit works with the Nexus 7000s. Ask Cisco when the features promised by their SDN controller will be available and if (ever) there will be feature parity between OnePK and APIC. The announcement said it will be mid-2014 before the APIC is released. In the meantime, the Nexus 9000 is a middling stand alone switch as it depends on the APIC for the advanced features. The last thing you need is to get stuck at the mercy of a vendor and their product portfolio transitions, only to find yourself locked-in.
5. How easily can I swap a component in or out of the ACI architecture?
At first glance, the value of the all-in-one data center stack seems attractive, like an all-in-one home theater system. For a single price, you can get everything you need to enjoy surround sound, play movies on DVD, and enjoy games. But what happens when you want to integrate the latest Blu-ray player? The point is that you need to maintain flexibility, so that when you need a new service which requires a new component, you can add it without being forced to go through a painful process of replacing the entire system. Similarly, in the data center, there are many components from various vendors. Some are networking devices and some are management, automation and orchestration tools. As the technology evolves around the network, you will need to add and remove components. Cisco has not said if you will be able to add components (other SDN controllers, other switches for their SDN controller) into their ACI service model seamlessly. Cisco needs to let you know if you can use common interfaces and cabling and not have to replace everything at once. Ask them if they will interoperate with other components, such as network management tools, and services appliances, in the ACI architecture without issues.
These are just a few questions we had after examining Cisco ACI, but I’m sure there are more out there – feel free to share any you may have in the comments below.
Update on 11/21: updated to correct the QSFP-40G-SR-BD optics to standards-based and interoperable with other Cisco platforms