State of the Union of ACI — Have we reached “peak” ACI?

Woohoo click bait title!! This post is actually a good long while overdue, but work and my other passion (car projects!) have been consuming a goodly amount of my time and attention.

So what exactly is “peak” ACI and why do I think we’ve reached it? Also… is that a good thing or a bad thing? I suppose I should start by adding a bit of back story to this to set the stage. ACI is I suppose the first product/solution that I’ve had as a central  focus, and not just that, but had as a central focus really since the commercial inception (FCS if you want to use Cisco wordy-words (first customer ship for my non-Cisco sales-y friends)). Previously in my career I’ve of course been involved with let’s say the Nexus 7000 line since the early days of that product line, but I was also doing things on Cat6ks, ASRs, ISRs, different firewalls, and a menagerie of different switches from other vendors too. So this journey with ACI has been a unique one for me.

Despite ACI being so much of a focus for me, I’m not actually associated with the product in any way (i.e. I don’t work for Cisco/INSBU) other than designing/installing it, and occasionally teaching a class on it. This gives me an interesting perspective on it. Now before I go any further, I should mention a few things:

1) (Obligatory) This post does not represent any viewpoints of my employer, or Cisco, or anyone other than myself

2) I am absolutely an ACI fan boy, not because of the logo on the box, but because I’ve worked on a lot of different products and I happen to think this is a good one. I’m happy to have a discussion about my thoughts on this at any time, feel free to tweet/comment away.

3) Just because I am a fan boy doesn’t mean I don’t have critical opinions (as you’ll see in this post)

With all that out-of-the-way — what is “peak” ACI? In short, I think the product has achieved its desired goals, and everything from this point on is simply bloatware being added in to appease large customers and their giant POs. Awfully cynical eh? Let’s dissect that a bit more.

The very early days of ACI were, shall we say… interesting. It is my strong opinion that the folks who created ACI (and other “SDN” products for that matter) looked deep into their crystal balls and saw the future, or at least their hope for the future. They saw APIs – and with it the death of the CLI, containers and micro-services more generically, and the synergy of hardware and software (buzzworddddd binggoooooo!); in short, they had a vision. If you look back to the 1.x versions of ACI, and dispel the punditry and bemoaning that ran rampant on Twitter/blogs, you’ll see that the product itself was executed quite well — IF, and only if you too believed in the aforementioned vision of how the data center should look. There was kind of a CLI, but not really. There was a GUI, but it was much loathed — yet the API gave you 100% clear programmatic control of the fabric. There were oddities (to “normal” network folk), things like not supporting routing “through” ACI. None of these shortcomings would matter in the least though if you too bought into the vision.

Frankly all this talk about “visions” is total supposition on my part. Though I do believe there is compelling reason to believe my version of this recent history. Ultimately I’m neither agreeing with nor diverging from the original vision of ACI, however the “market” (channel partners, end customers, bloggers, tweeters, etc.) clearly did not agree. Cisco to their credit (though it seems no-one wants to acknowledge this) reacted relatively quickly. By the 1.2 code release major changes to the GUI were implemented — improving if nothing else the aesthetics. A very familiar “NX-OS style” CLI was implemented — ultimately doing nothing more than masking the very same API calls the creators of the product hoped you would use. Transit routing was quickly added into the mix as well. It is entirely possible that these additions were on the roadmap anyway though given my thoughts on the “vision” of the product I would find that to be a dubious assumption at best.

In any case, features have been of course added since the initial release of the product — things like multicast support, IPv6 support, additional nerd knobs on routing protocols, and many more (in my opinion) necessary features. With the relatively recent release of the 2.0 train — codenamed “Congo” — I, and many other folks I speak with, feel that ACI has reached “mature” status. That’s not a knock that it wasn’t stable before this (there were bugs to be sure, but there are bugs in EVERYTHING — there were bugs in my first “Hello World” script so you know…), just that ACI has moved from minimal viable product for a commercial release to a fully featured, mature, data center platform.

This however does bring us back to my theory regarding “peak” ACI. We now have literally more features in ACI than I can keep up with — and recall that ACI has been my central/primary focus! Yet even so, the features keep pouring in. Now certainly there will always been feature adds as hardware/software improves — the new FX blades/switches are an excellent example of this; they add MACSEC encryption all over the place, this was just not possible on previous hardware version — but we are getting more and more features that don’t have an obvious use for 99% of customers that I see. As with every other product in the history of products, money talks, so of course if large customers have demand for feature XYZ and money to back it then feature XYZ it is! The problem with this is that for the 99% these features add confusion, and a larger code base, which of course means a larger surface area for our friends the bugs to latch on to!

My principal complaint about the feature bloat isn’t even the expanded code base and potential for bugs (thus far with ACI at least bugs have been very isolated to particular features so hopefully that trend continues), but instead the confusion that this brings to the field. I feel at this point I should also make it clear that this is of course not an ACI specific problem. Regardless, the problem persists. I’ve been on many a call with partners and/or Cisco folks who are not actual practitioners/hands-on users of ACI and yet they insist on pushing new features — eking out every last bit of (perceived?)”value” so that they can make the sell to customers. Don’t get me wrong — new features will absolutely solve needs customers have, but my primary concern is that the real value of ACI is overlooked, under-sold, or completely ignored, perhaps in the face “progress,” or more likely in the face of sales targets for newer products.

Hence we have arrived at peak ACI. I don’t mean this in the stupid Gartner way. I mean to say that we have collectively moved on to a point where the core benefits of ACI are ignored, pushed aside, or otherwise looked over in favor of the up-sell. This post has turned into a bit of a call to action to remember that keeping it simple works. Always. All the time. I am, and will likely remain, an ACI fan boy; however I now am looking at new features with a cynical eye. I’ll still advocate ACI, however I will absolutely continue telling people to stick to the “KISS” (Keep It Simple Stupid!) principles.

Advertisements

5 thoughts on “State of the Union of ACI — Have we reached “peak” ACI?

  1. How do you see or have you experienced any companies initially moving from 3 tier design to aci network centric mode and then begin rolling new services (post-migration) out using application mode?

    Also, do you have any tips or words of wisdom moving SVIs from legacy environment to aci environment?

    • I always always always advocate getting into ACI before trying to do anything cutsie. Migrating any DC infrastructure is already a huge undertaking, then learning a new thing (be it ACI, or going to JuneOS or Arista or whatever) is another huge undertaking on top of that. So in short, move what you have into ACI, then start going to do the fancy stuff once you’re in ACI and have a level of comfort with it (it isn’t terribly difficult but it does take a bit of time to get familiar like anything else).

      Words of wisdom would be basically that. Keep it simple stupid. Just because you can’t doesn’t mean you should… and other cliches like that apply. Lastly, “application mode” is allllllll marketing. Do what makes sense for your environment. If you can build ACI in a more “app-centric” fashion thats cool, if not who cares.

      Hope that helps!
      Carl

  2. Hi Carl,

    Firsting, thanks for producing an excellent blog. I have a question relating to the NX-OS style CLI, and how well on integrates into ACI. I can see that using this method for configuration omits a number of fabric access policy options, and when configuration is run generically named objects as opposed to used defined (as you would get using Advanced GUI/Rest) are created.

    I am curious as to whether opting for using NX-OS style cli for configuring the enviroment will limit features/availible functionality of the fabric? And your thought’s on how feasible using this as a princible configuration method for the fabric is (using pexpect like scripting)?

    Many Thanks

    Jon

    • Hi Jon,

      The NX-OS CLI is not fully featured as far as I know. I would strongly advise that you don’t waste your time with it. Use the API, and certainly don’t bother with expect. You can use the utility I wrote: https://github.com/carlniger/acitool to do many common tasks. All that said, you *could* do it with NX-OS CLI but I can’t think of one reason why you would want to 🙂

      Carl

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s