Embracing APIs and Network Automation at Interop ITX 2017

Chris Wahl · Posted on

Not too long ago, Ethan Banks and I recorded an episode of Datanauts entitled The Current State Of Network Automation & Telemetry with special guest Ryan Booth. If you haven’t heard this show (gasp!) I basically get the rundown on how challenging it is to programmatically control most currently deployed network gear. After all, as a long time virtualization administrator, I’ve had the “abstract, pool, automate” mantra drilled into my head repeatedly for years. In a nutshell – things aren’t that fun, RESTful APIs are no where to be found, and most folks are reduced to screen scraping terminal windows to interact with a network device. Sad panda.

No blog post does a better job at capturing the “facepalm” nature of network operations than Ivan Pepelnjak’s post entitled Let’s Drop Some Random Commands, Shall We? In it, he describes the pain of sending commands over SSH in which the target device simply ignores (drops) various lines of configuration code. Note that this occurs even when using a reliable protocol such as TCP.

https://www.instagram.com/p/BUHz5apjaE8/

This – and much more – were topics of discussion at this year’s The Future of Networking Summit held at InteropITX. Hosted by the Packet Pushers, Ethan Banks and Greg Ferro, I sat in many segments of this two day network knowledge overdose to learn more about the world of network operations, SD-WAN, pipeline automation, and more. Here are a few takeaways that I’ve gleamed from different speakers.

Network Skills Pay the API Bills

According to Matt Oswalt (@Mierdin) – who had a cheeky session on the inevitable movement of everyone’s cheese – there is a light at the end of the tunnel. Much of the blame, he laments, comes from the vendors themselves who seem to have no idea how to properly construct an API architecture for their product.

Additionally, some tasty snark was served on a silver platter concerning faulty testing scenarios. Chief among them was the story of how the use of “ping.exe” is often the most widely used application for testing performance, connectivity, and so forth. Oswalt makes the joke that “We all know that ping is the most widely used application in a hospital” to carve straight to the heart of the matter – test all the (real) things!

As a final helping hand to networking engineers looking to up-level their skills, or to fend off the caustic advice of “becoming a developer,” Matt makes it clear that having spent years or decades designing, troubleshooting, and configuring networks has a huge amount of value. There are many startups and legacy vendors who would benefit enormously from this talent pool. A form of DevOps, if you will: take developer knowledge around pipelines, automation, APIs, and so forth and blend it judiciously with concrete networking know-how.

Bravo! I’ve said the same thing to IT professionals in the server / virtualization space. It’s good to hear it repeated from someone who has put his feet down into the software development and network engineer worlds.

Our Meat Spatulas are Faulty

Another gumball machine of wisdom was my co-host Ethan Banks. In his session, he mocked up a virtual whiteboard and took the audience on a journey through his thoughts on network design as it pertains to programmability and automation. Most of his points came across as arguments to start down the path automation – consistency, reliability, and a general awareness that “people make mistakes” in spectacular ways.

This begs the question as to who designed the network in the first place? In many cases, automation is not the best initial step to take because the network itself is in a sorry state. Perhaps it would be best to come up with a plan to remediate the major issues and craft a new design (that leverages all of the fun automation bits) and work to migrate over, rather than trying to automate yourself out of a deep, dark hole. Plus, Banks feels that commoditized, dis-aggregated networks are best.

Agree or disagree?

Recording the Room

The final “wow” moment was when the networking gurus themselves took the stage with podcasting gear in hand to record a live episode of the Packet Pushers Show. Many superb questions came from the audience with Greg urging participants to “shut up and ask your question.” I sort of liked that because many people seem to twist questions into inappropriately long stories about themselves.

https://www.instagram.com/p/BUIRMpQjABM/

I won’t spoil the episode since it will be published soon, but suffice to say, there was a lot of concern over the fate of networked architectures since they are incredibly crucial for global business. A few notable questions:

  • How do you test, measure, and certify engineers and architects that are working on such important devices without having to lean on vendor specific training and certifications?
  • What role does the network engineer play over the next decade?
  • Is there a certain size that is “too small” to be worth investing in automation?

Thoughts

As usual, I’ve enjoyed another spectacular time at Interop listening to industry folks deliver their thoughts, ideas, stories, and war wounds. The show continues to draw an amazing crowd of speakers that get my creative juices flowing with a focus on the future. Sadly, if you didn’t get a chance to participate in this show there were no recordings. Hopefully the presenters publish their decks / thoughts on their respective blogs, or in the case of the Packet Pushers, check out their upcoming episode from Interop’s Future of Networking Summit.