Layers of Single-Pane-of-Glass Abstractions Won’t Solve Your Problems
This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.
We’ve been told for years how we’re over-complicating networking, and how the software-defined or intent-based whatever will remove all that complexity and remove the need for networking engineers.
What never ceases to amaze me is how all these software-defined systems are demonstrated: each one has a fancy GUI that looks great in PowerPoint and might even work in practice assuming you’re doing exactly what they demonstrated… trying to be creative could result in interesting disasters.
But is a GUI on top of an abstraction layer really what we need? I always thought that the problem we were trying to solve was to deliver services faster through self-service portals, or to deploy applications faster and more consistently.
Now take a closer look at the GUI layer offered by the SDN platforms like Cisco ACI or VMware NSX, or most intent-based systems. Is it really aimed at the end-users provisioning their own service, or is it suited for network administrators configuring the network with mouse instead of keyboard? If so, what have we gained?
How about faster and more consistent application provisioning? Will we really provision them more consistently if we handcraft environment for individual applications using mouse instead of keyboard? What we really need is an automated deployment process that takes a deployment recipe and executes a series of API calls to consistently provision the exact same environment every time it’s executed.
Long story short: whenever you’re evaluating new technologies or architectures, try to figure out what business (not technology) problem you’re really trying to solve, and whether the new shiny thing solves it or introduces another distracting layer of abstraction.
Unfortunately the networking engineers often don’t think in these terms – that’s why I included Collecting the Requirements section in Building Next-Generation Data Center online course and Putting It All Together section in Building Network Automation Solutions online course.
The one important thing that I got out of that podcast was the word "consistency" (which was mentioned several times during the podcast). It doesn't matter what system you have to work with, if you can check-in/check-out your infrastructure configuration with a text file - you are heading in the right direction. Now I wonder if these crazy new platforms that offer GUI only configuration approaches and a non existent API.. where could we possibly turn to?.. well, browser based automation could be a nightmare - but let's not hope we should ever rely on something like the Selenium Webdriver.
At a bare minimum, we should determine the who, what and why of a device configuration change.
Who - Use of RADIUS/ACS/LDAP, no use of a single user - difficult to audit.
What/When - Use of centralized logging, consistent time configuration and correlation
Why - Was there a business need behind the change, is there an open ticket, or was this an untested/accidental change? - This would most likely at least please your friendly auditor.
Then work on getting a configuration management tool in place that would enforce proper and consistent device configurations, no matter what adhoc changes were made on the fly from unknown "AdminX". - This would most likely save you time and heartache in the long run.
Mario
If they provided an API only, customers would complain they had to do some integration work to set up the platform.
So, in a way the UI can be seen as both a way of using the mouse to configure the network but also (and more importantly) a demonstration of what is possible if you use the API.
You just have to do the integration with your own customer portal.
You can do everything programmatically if you want to.
Of course you can do your own integration, but it would be nice to have a simple "configuration file"-like approach (infrastructure-as-code anyone). Cisco ACI has something along those lines, but I've been told it's not exactly useful, and I haven't found anything for NSX.
There are also a few plugins for major provisioning tools. VMware has Terraform plugin... but only for NSX-T, and there's a third-party Terraform provider for Cisco ACI.
However (coming back to the blog post) - that's not how these solutions are demonstrated and sold, and usually not how they're evaluated in PoCs.