Moving beyond the CLI with Aruba 8400 (Enabling SDN for NetOps)

When I first saw the Aruba 8400 I was awestruck, surprised, actually legitimately excited! I know, I know it’s just a bunch of ports inside of a chassis, but that’s not all it was though. The 8400 brought something to the party which has been forlorn and forgotten in the systemic world of Network Engineering and Administration, and that is they realized the end-users of this product WERE Network Engineers and Administrators. But wait, what do I mean by that?

Moving Beyond the CLI

When any vendor says, “We have a REST API and you can write JSON to us” I immediately dread what comes next, often a convoluted series of ‘help files’ and webpages intending to make every CLI Jockey network admin and tell them “Your job requires you to have 10 years of Python experience, now fetch!” and on the one hand this solution would be no different.
It would be no different if it weren’t for the fact that Aruba recognized, “Our users haven’t changed, so rather than try to get them to reinvent the wheel, let’s enable them in how they do their jobs!” This is made possible by their use of the Swagger interface and understanding of how Network Administrators actually DO their jobs.

I cannot express just how exciting it is to be provided with a REST API interface like this one and instead of just reading code syntax I then have to parse into an external product, having instead the ability to literally just tell it what I want to do, with syntax, strings and parameters right there on screen, which I can just go and ‘execute’ to validate that things WORKED for me the first time.

But it doesn’t stop there! What makes it actually exciting instead of simply “Wow, you moved the REST API to a Browser” is the fact that it then EXPOSES what you just asked it to do into CURL and JSON syntax which takes the majority of the effort out of getting this into a regularly scheduled procedure. What I particularly like is running one set of commands to change ‘one thing’ and then run a separate set of them to generate a second set of information, and I can evaluate it, compare/contrast it and then start to write this code to execute regularly instead of having to always use the Swagger interface.

The biggest testament to this truly has been the recognition that as more and more Network Devices adopt an “SDN” Strategy many of the solution holders assume that every admin is a programmer who learned networking, just waiting for the day for open API’s to exist to manage their environment. And instead the acknowledgement that SDN adoption hasn’t been the strongest because there’s a REASON we’ve been using the CLI for so long and it is our preferred means of managing an environment… It is because it was the best and often ONLY way to do it

No longer do I need to dream for a world where SDN meets NetOps and enables them instead of tries to change them from the outside. Swagger and the Aruba 8400 will change Network Administrators, but it changes them from within. Enabling system management to support their job instead of making them spend hours or days troubleshooting JSON code which isn’t working by default due to a misplaced comma or semi-colon

You tell me if you’re equally excited about this capability to manage your network on your terms instead of having to go to a boot camp just to change a VLAN on an Interface! Or spend hours in in forums trying to troubleshoot “ [unable to parse as json; raw response below]” when trying to execute a ping command.

The bar has officially been set on what the minimum expectation is for bringing SDN and API controlled networking devices to the Campus and Data Center.