Hedge 200: Automation with Ethan Banks
We’ve been on a long streak of discussions about automation, why it works, why it isn’t working, and what the networking industry can do about it. For this episode, we’re joined by the indubitable Ethan Banks. If you don’t think there’s anything left to say, you’ve not yet listened to Ethan!
The “Wardley Map” sounds compelling, but I’ve never been able to really make it work, either.
Wardley makes is look easy, but I have yet to make one work. https://www.youtube.com/watch?v=-jCFVhnf2HE
By the way, “There is no industry standard way to build a network” is problematic not just for automation, but also for getting AI to work well for networks as well. David Meyer wriote a great article about this in 2017. He says we are missing the *theory* of networking. https://www.sdxcentral.com/articles/news/machine-learning-hard-apply-networking/2017/01/
I think we are seeing some standardization in overlay networks like SDN and small networks, but once you get beyond trivial scale it gets nearly impossible to template.
We do have “theories of networking,” but not a unified “theory of networking …” There are two problems, though. First, we are stuck in an “application first” world where theory is generally considered “useless.” For instance, how many times have we all heard “certifications are garbage because they are just book learning, and book learning isn’t useful.” I don’t agree with this mindset (obviously) but … we’re so deep in this mindset it’s going take some serious work to create a better balance between theory and application.
Second, I don’t know you can get to a “universal theory of networking,” other than saying something like “here is where all the tradeoffs are.” I would really like to be wrong on this, but … 🙂
You and I may be disagreeing on what “theory” means. When I say it, I’m thinking of the rigorous network heirarchies created by the Bellheads in Ye Olde Days, with strictly designed capacity measures, queuing theory, and mathematical models that made extremely good predictions. In This Modern Era, the “Network” is heavily overloaded with non-transparent services, from NAT to firewall to opaque tunneling and all other manner of “bumps in the wire” that make any kind of rigorous analysis and prediction near impossible except in tightly constrained areas. This leads to the “vendor specific” architectures that you and your guests lament.
The good/bad news is that the Moore’s-Law driven bandwidth ascendance has allowed us to detly paper over these extraodrinay inefficeincies, so we only really experience them when out video calls hiccup and out games lag. We have been able to get away with slipshod designs because it’s all “good enough.”
Well designed applications know better than to trust the network.
Ultimately, the automation problem you discuss is a multidimensional one, which includes the plurality of configuration and monitoring interfaces; the difficulty of ascetaining states and state changes across a dsitrubuted set of interdependent targets; the profound ability to screw the pooch when a change or sequence of changes disconnects the node and triggers a truck roll to resolve the resultant outage; and, of course, the difficulty in illustrated the ROI of automation to the decision makers, who end up being driven my many other non-technical factors in decision making.
I heard a great quote from Robert Lucky, legendary Bellhead: “Larry Lessig has pointed out [that] regulation is achieved through four means: law, norms, market, and architecture. We engineers usually control only one of these, and that’s something we should always keep in mind.” I find that “regulation” can be replaced with “design.” Engineering architecture often ends up being a smaller part of any decision making than we might like.