Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

9 module online course

Start now!
back to overview

Stop Using GUI to Configure SDN or Intent-Based Products

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:

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.

Just in case you need more information

Please read our Blog Commenting Policy before writing a comment.

No comments:

Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.