Six non-hype network automation lessons from IT pros

Critical Conversations on Critical Infrastructure Ep. 1: “Where’s the automation ‘Promised Land’?”

There’s a false notion in IT that the network automation train has already left the station. That, if you’re not on it, you and your network are on the brink of obsolescence. It’s a toxic narrative that probably scares more people away from trying their hand at automation than it helps.

In the spirit of challenging the hype, pros from across the IT industry gathered last week to discern what’s truly helpful when it comes to the automation conversation.

Moderator: Andrew Wertkin [LinkedIn | Twitter], Chief Strategy Officer, BlueCat and host of Network Disrupted podcast

Panelist: Phoebe Goh [LinkedIn | Twitter], Principal Architect Worldwide Technical Team Enablement, NetApp, and host of Go Your Way podcast

Panelist: Jon Macy [LinkedIn], Director and Principal Engineer, Cerner Corporation

Panelist: John Capobianco [LinkedIn | Twitter], Senior IT Planner, Parliament of Canada, and author of Automate Your Network

Panelist: Ethan Banks [LinkedIn | Twitter], Co-Founder, Packet Pushers

Below is a list of the most important, helpful messages to come out of BlueCat’s first Critical Conversation on Critical Infrastructure. To continue the conversation, follow up with panelists, and see what others have said about the roundtable, join Network VIP – our Slack Community where pros in IT connect and share their expertise on all things networking.

Lesson #1: Network automation is actually a really simple thing.

“A lot of the automation conversations go from zero to 1,000 miles an hour very quickly,” cautioned Ethan Banks during the conversation. It overwhelms people, and makes folks at all levels think that they have to come out of the gate with automation as a perfectly orchestrated set of processes. Members of the Network VIP community agreed, voting during the panel that the perceived automation learning curve is a primary roadblock to testing out the waters.

Orchestration is its own domain, explained Jon Macy. There’s a difference between automation—which starts as the elimination of a singular manual task—and orchestration.

Lesson #2: Take small steps.

“Eventually you want to be automating your network as a system, but you don’t start there,” Banks reminded the audience. “That’s too big of a thing. So find the thing that you do over and over and over again that takes a lot of time out of your day, and figure out how to automate that thing.”

Good places to start, according to the panel:

• Something you’re doing in a spreadsheet
• Something you’re doing by handwriting it
• Information gathering
• A playbook against a single device
• Things you do really often

To this point, John Capobianco shared a lesson about what can happen—in the best of cases —if you don’t start small. He said, “I thought, ‘Look, I can’t give operations 500 change files to go switch by switch and do this manually. That’s not the right approach. So let’s try this as our first automation exercise. Five hundred routers, and let’s make the big change, right?’

“Oddly enough, I found success. But this was day and night of toiling, my weekends were gone, my lunch hours were gone. Any spare minute I had went into my little Frankenstein I was building. I can laugh at myself now looking back at that approach. And I would not suggest that approach to anyone.”

“It starts with actually understanding what you do,” noted Phoebe Goh. “Before you even try to automate anything. And it’s kind of going, ‘What are the tasks that I need to do?’”

Lesson #3: Build any automation to accommodate change.

If you’re building automation, you’re probably strapped for time. However, Macy reminded the group of the importance of building things so that they can accommodate change. “Take a couple of extra steps to build in those things that are going to support you in making changes. If you make it a very brittle, rigid construct, you’re going to become dissatisfied with it when a change comes in and you can’t service that change.”

Supporting that, Capobianco recounts of his experience, “I was lucky and fortunate that the director of software development actually approached me. Which was odd, because I work in the technical infrastructure space.

“But, he said, ‘Look, it sounds like you’re doing some great stuff. You need to get into a Git repository. You need to hook up with some of our developers. They’ll show you the ropes, get this stuff under version and source control. No more working _version3_new.testfiles.’

“And that opened the door to VS Code which opened the door to extensions, which opened up the door to YAML and Jinja, right? It snowballs. So, anyone intimidated by the field, it snowballs very quickly. Doors open other doors which open other doors. And soon enough, three months later you’re doing things entirely different with an entirely different toolkit.”

Lesson #4: Version control doesn’t need to be a nightmare.

“Before anybody gets overly intimidated, using a tool like version control, there’s three or four different ones out there,” explains Macy. “I started off with Subversion. It was pretty easy to learn. And you don’t have to go through the rigorous developer process, necessarily, when you’re starting off.

“All you’re looking to do is keep track of your changes, and to make sure that you’re always working on the current stuff. Or, you can flip back to a previous version when you go off on some wild tangent that breaks something in a significant way. You can always go back. When you’re dealing with Notepad, a lot of times that’s not really realistic to have that expectation. So, use that. From an editor, from a tooling standpoint, I like VS Code for a lot of the things that I do. They’ve taken that tool and really blown it up in terms of capabilities and interactions.”

Version control is also helpful for showing others what you’ve done.

“It just becomes so, so useful to go, ‘Well, this is what I got up to. And it got this far, can you help? Maybe you can think of better ideas of how I could do it’,” added Goh. “And you can show those incremental steps.”

“I think it makes us all better technical citizens because you can’t just go, ‘Oh, it’s just kind of magic and works.’ You have to understand what it does so you can explain it to somebody else. So you do become a smarter person.”

Lesson #5: You don’t need to start as—or become—a developer.

Banks noted, “There’s been a whole implication here that network engineers need to become coders and developers. I don’t know that I agree with that.”

“We’re talking about digging into Swagger documentation, and looking at APIs, and all the rest. Yeah, if you’re engineering-minded you can do that and begin to take it in. But is that what a network engineer role is ultimately going to be—transitioning into an infrastructure as code developer? If you have a tool that can do a lot of the work for you, you’re less likely to be so overwhelmed.”

Capobianco, who has written a book about network automation, also added, “I’ve memorized my nine Git commands. Don’t mistake me for saying I’m a Git developer. I know my nine Git commands, and if I get into trouble, I blow away the folder, and I call in the repo again, and I start over. I mean, I still do that today. I did that an hour ago. I blew away a folder and got cloned to start again. So, don’t be intimidated.”

Lesson #6: Don’t get precious about the tools.

“You’ve got to keep reminding yourself to keep it simple, and be flexible,” said Goh. “It’s going to change. You’re going to use a different tool next week, or next month, or next year, and be okay with that.”

“Tongue in cheek, Ansible is the skies part, the sun shines, and I found my Lord and savior,” Capobianco added. “I feel lucky that I bet on that horse three years ago. And that was the tool that I found such a low barrier for entry and success.

“But it might not be the end goal. This might be a flash in the pan. This might be a three-year tool, where Nornir or Python comes along when I have more experience in coding, and I just take that power over myself. Write my own Python at that, almost, C level, right? Go further than a framework provided to me by a vendor, and do it myself entirely, right? I’m not there yet.”

That’s all, folks. This has been the first of a series of Critical Conversations about Critical Infrastructure that was so rich with helpful insight. Coming up on October 27, the Network VIP community will be exploring the question, “Should you DIY your DDI?” Tune in and participate in the thoughtful discussion on Slack.