This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

At the end of my vNIC 2018 keynote speech I made a statement along these lines:

The moment you start using GUI with an SDN product you’re back to square one.

That claim confused a few people – Mark left this comment on my blog:

My question is what is the alternative to a GUI which I interpret in an SDN world as a central authority that has oversight and controls all aspects of 10’s, 100’s or potentially 1000’s of devices/sites?

Before I dive into the details, let’s put some context around my statement (because I know that not everyone will go and watch the presentation to understand it): it was made in an SDDC presentation assuming the users of a particular SDDC product (NSX) plan to deploy more than one application stack in their data center.

Ready? Let’s go.

Someone could decide to use an orchestration system, or an SDN controller, or an intent-based product (keep in mind these things do pretty much the same thing but use different names because $marketing) for a variety of reasons, including:

• You want to get rid of those pesky networking engineers;
• You want to do things that nobody in their right mind should be doing, and the $vendor promised they are really easy to do with their recently-launched machine-learning-based unicorn dust;
• Your $vendor told you it makes sense to deploy things that nobody knows how to configure correctly (a bunch of four-letter-acronyms comes to mind), and their SDN product supposedly does that (good luck figuring out what it did when it breaks);
• You want to give people who don’t understand how stuff works tools to get stuff done.

These are all valid reasons and there’s nothing wrong with them… but if you answered YES to any of the above, please consider outsourcing your infrastructure by moving into a public cloud (see also: three paths of enterprise IT).

Still here? How about:

• You want to increase speed of deployment;
• You want consistent deployments;
• You want to make deployments reliable and repeatable.

If you want to reach any of these goals, you should remove the human element from the deployment process. An operator clicking on an SDN GUI will be no more reliable than an operator typing reload in the wrong SSH session. The only exception might be an orchestration system that is abstracted enough to take only a few input parameters (example: edge ports and service type) from the operator. SDN products like Cisco ACI are lightyears away from that simplicity (see also: why do we need an Ansible playbook to collect ACI configuration parameters).

Furthermore, if you want to make complex deployments repeatable, you have to use infrastructure-as-code principles and rely on machine-readable deployment recipes. Expecting a human to consistently follow pages of instructions is insanity.

To recap: Even though an SDN product can control 1000s of devices, using a GUI to configure those devices (or services on them) is plain wrong as soon as the operator has to enter more than a few tightly-controlled and validated parameters to deploy the service, and will not give you any substantial benefits… or as I’m always saying: technology is not a solution, it’s just an enabler that allows you to optimize your processes.

Corollary: If you’re running an SDN or next-generation-whatever proof-of-concept without asking the $vendor engineer demoing the product to configure everything through an API you’re doing it wrong… and if you don’t know which automation or infrastructure-as-code tool you’ll use to deploy services on top of that platform, you haven’t done your homework.

If You Need More Information

• With Standard ipSpace.net subscription you get access to more than a dozen SDN and network automation webinars;
• Expert subscription gives you access to all those webinars plus an online course – choose Building Network Automation Solutions course to go with your expert subscription.