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?
Please note I’m talking about service provisioning. Having a GUI-based service-focused monitoring and troubleshooting system instead of today’s device-focused single pane of glass is a major step in the right direction, and some vendors are getting there.
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.