Elevator Operators Wanted

Recently I had the great joy to be invited to a special Tech Field Day (disclaimer below) event — the Data Field Day Roundtable 1! My first Tech Field Day event, and the very first Data Field Day, so basically very cool stuff! If you have some time, check out the videos on YouTube or Vimeo, it was really fascinating stuff! This event was focused on telemetry, configuration management, and the embrace of open source tools. Really though, the main theme wasn’t about how Netflix does their telemetry (although very cool), or how Google wants to help move along OpenConfig (again, also seems pretty cool), it all really boiled down to building a better mousetrap.

So, given that I’ve got a very network-centric viewpoint of the world, what did this event really mean to me? How does it play into the future of networking/networkers? Well, I think its safe to say that network folks will have to learn new skills — else be doomed to being the elevator operator (my friend Mark Snow’s favorite analogy when discussing this!). There is of course no scenario at all, assuming a desire to stay relevant, where network engineers can just stop learning — period. Technology is of course not standing still, so even if you’re just learning new syntax or a new routing protocol, you’re not off the hook.

Okay, great, we have to learn new stuff — why does how Netflix and Google interact with and/or configure their networks matter to me? Glad you asked!

I think the bottom line is it’s not about programming, it’s not about being an open-source tool wizards — its just about configuring and managing devices in a way that sucks less than the way we do it now. If you listen PacketPushers Podcast, you’ve undoubtedly heard Greg Ferro and his fantastic hatred of SNMP. He is so on the money with that hate it’s not even funny. SNMP is of course not the only, or even primary, method for configuring devices — that has been and still is the CLI. Well the jury is in and the CLI has got to go at some point — it will be a long slow death because it has evolved out of necessity to be what we rely on daily, but it just can’t remain. But why the hell are we still using these tools, and what else could we replace them with? Well, like I said earlier, I don’t know that the outcome matters, but we certainly can’t continue dealing with SNMP and MIBs and blah — thats painful… and the next time you want to make a simple config change across 100s, or even just 10s of devices, you’ll recall why the CLI isn’t that great.

Why does this have anything to do with DFDR1 (Data Field Day Roundtable 1 if you were wondering, a bit long don’t you think)? Even though I feel like DFDR1 was way over my head in a lot of ways - Linux/Program-y/Dev stuff — the central theme was pretty apparent; we need better ways to mine data from devices, we need better ways to configure devices, and we need it now. Not when we can finally figure out what the hell to replace the CLI with. So some really smart folks have said screw it and just forged ahead. Like i’ve said several times now — I don’t care what choices they’re making to do this, the platforms and tools they select may stick around forever or they may be gone next week… still doesn’t matter. If five wizard level people at Netflix can handle all of their monitoring and logging on millions and millions of points of data, we can do better than SNMP and platform/device/vendor specific CLIs. Lets not be the elevator operator.

Disclaimer: Not that this post was about any one vendor or anything in particular anyway, but wanted to point out that the lovely folks at Tech Field Day did indeed fly me down to and put me up in San Jose for the DFDR1 event. There was also drinking involved. It was great. Vendors I’m sure paid for my drinks and flights in some way or another, they did not ask me to write about stuff, and this is not that anyway.