Hi, and welcome to another episode of the Community Fabric podcast, where we bring the networking community to the table to talk about the things that matter to them the most in their day to day. I'm Darren Forelleld, your host for today's recording, where we're gonna dig into a topic that's very familiar and keeps giving and giving and giving. I'm joined by someone who's coming to many people's consciousness recently as a member of the awesome Art of Network Engineering team. AJ, would you like to introduce yourself? Yes.

I am AJ Murray at noblinkyblinky, and I am the creator and cohost of the Art of Network Engineering podcast. Thank you so much, Darren, for having me. This is really exciting. It's an absolute pleasure, my friend. I've been dying to talk to you for ages, so, you're looking forward to this conversation.

Now we were talking the other day about a topic for today's conversation, and it struck us that while there are loads of places to find out more about that legendary topic of network automation, there's not that many places where we're really looking at the bigger picture. Understanding how the impact disposal that's having on on people's day to day, and whether or not we're doing it, and why we're doing it, and all those kinds of good things. Right? So I thought that we could start digging around in that a little bit if you've, if you're up for that. Absolutely.

Awesome. So, I mean, you're in a really interesting position where you're having conversations with dozens of of network engineers day in, day out. What do you feel is the general feeling, I suppose, amongst them about network automation, in their day to day? Yeah. Certainly.

So if anybody, you know, isn't aware, I am a post sales senior network engineer for a a large, partner. And so I I take the solution that a presales architect has designed and spec out with the customer, and I do the implementation. And so you're right. I talk to network engineers all the time. And one of my favorite things to ask them is where are they in their network automation journey?

And and so I I think that my view or perspective of this might be a little bit skewed. Right? Because the customers are hiring us to come in and augment their staff, help them out with a project, and, you know, we're we're filling a skills gap that they may or may not have. Right? So I I think that most people or most organizations in that position aren't doing network engineer or, aren't doing network automation.

At least that's that's what I'm seeing. Right? Like and and I get a whole gambit of excuses. I don't have time to learn that. We're not that big.

You know, and then the list goes on and on and on. And so I I think there's this common misconception, right, that only large organizations are doing network automation. I mean, network automation is is for any size network. It's not always about scale. It's about, you know, dependently, confidently, applying those configuration changes every single time.

And I guess, complexity is the is the thing that that where it really comes into its own. Right? I'm trying to manage and control that that complexity. Because you're not just it's it's not just I need to make I need to push some config to a thing, but it is about saying, oh, actually, I've got a whole bunch of things that I need to do in order to deliver a capability. And so it's it's it's there where it really starts to pay off, I guess.

You're adding a new service or or whatever, and you gotta touch the firewall, the switches, the core, this, that, the other thing all at the same time. Yeah. Right. Right. I mean, we're getting you you start to get into the realms of workflow and and orchestration then, I guess.

But and this is, I guess, the point I was I was trying well, one of the points I was trying to get to here was that the what we you know, we we were all being educated to to to to look at network automation. But the the things that we've looked at so far have been very much one dimensional. It's been a case of, oh, I need to change a VLAN on a a load of switches, or I need to push a particular NTP configuration to a bunch of routers. And it's and it's a very like I say, it's one task really just done over and over and over again consistently, templated, whatever. But, you you know, we we try to do a lot more than that, I guess.

Yeah. That that that's been a lot of the the examples. Right? Like, anybody who's learning is gonna see the example of adding a VLAN to a switch or pushing out configuration. And then, honestly, like, how many times are you adding a VLAN?

I mean Exactly. How many times do you need to change your NTP server? Just that's it's not it's it's a great it's a great demo. It's not a great, you know, use case. And I and I guess that's that's the problem right there, isn't it?

It's then saying, well, actually, what is it that you do as a network engineer a 1000 times? And how do you get that consistency and whatever built into that that process? And I guess so so as a consultant then working into other other organizations, as part of the delivery that you do and or or that that your teams do, do do you use automation yourselves in in that process? Yes. So I have a number of tools that I have, you know, developed and used that my myself.

They're simple Python scripts to do testing so I don't have to sit there and keep typing traceroute IP, traceroute IP. You know? So I can give, you know, the little script, a list of IP addresses that the customer has provided to me of, you know, endpoints in their network, and then I could just let it do the testing, and it works great. Right? It's it's simple.

It's consistent. It's it's easy to do. It's and and it takes away the work that I have to sit there. I just have to watch the results come in rather than type the same commands over and over and over again. And then, of course, there's a whole bunch of tools that Presidio uses.

I I won't give that away. That's kind of Presidio information. But but then also, I I I like to use Ansible myself. So if I'm doing a large deployment for a a customer, I'll work with them, and we'll create a standardized, you know, gold template. Right?

The standard template that we're gonna use. And I turn that into a Jinja template, and then I can insert the variables for the building, the IDF closet, whatever the case is. And then I can consistently create these new switch configurations and then apply them to the switches as we're doing the deployment. So that's an interesting so you're basically giving people, the the scoop, I suppose, on on how you do it, so that they can maintain and continue to do it themselves once you've deployed and walked away. Absolutely.

And I I've had those conversations with customers, like, you know, here's what I'm doing. If you're interested, I can show you how to do that. You know, I I have a demo that I do using Ansible, and I I really like Ansible because it has a low barrier to entry. Right? Like, it's free.

You don't need to know coding to understand it. If you're a network engineer and you know your configuration commands, you can get started pretty easily. So, and it's just full of these these helpful tools and things. So I I have a bunch of different demos that I do with, like, switches and routers just to kinda show them the power behind network automation. Like, well, I've seen a little bit on it, but I don't know if there's something in there for me.

Like, well, let me show you. That's cool. So so as part of your day to day, you're using it to to demonstrate the capability of it so that you people again, it's an education piece then, right, of of trying to get people to see the value. Exactly. Exactly.

And and hopefully, you know, definitely in in some cases, customers have asked, like, well, where can I go to learn more? You know, and, I I can point them in in various directions depending on what their their real interest is in. Right? So, I I've seen a lot of customers use out of the box tools, which is great. Yep.

But sometimes that's only good for, you know, fulfilling 1 or 2 different things for them. And then, you know, sometimes they they set it up to check the box. Right? Like, I did that thing, so I'm compliant. They're not really That's it.

Or or or I can put it on my CV then. Yeah. Yeah. Exactly. They're they're not really using the tool to, like, its fullest extent or what it was actually meant to do.

So this is an interesting point. So you're if you're having those conversations and you're helping them understand more about about it, how what do you talk about in terms of the value of automation? What what does it bring the network engineer in their day to day, do you think? For for me, it's that consistency. Right?

The the dependent repeatability, I don't it's the it kind of takes out the human error. That being said, if there's error in your scripts, that human error is gonna be applied all over the place. So test test test test. But, you know, like making any sort of network modification, if you've gotta do it to a bunch of of network devices, you can do it consistently. And, I I think that's really when management is talking about network automation, they're not talking about network automation to replace network engineers.

It's that dependability. You know, when we push out a change, we wanna make sure we're pushing out the right change. We're eliminating the human error, and we're not gonna cause additional work for the team by making this one one change. Right? That's interesting.

So you've talked there about, obviously, the network engineer themselves, and then the the the the management at the layer above, I suppose, to say, you know, we can trust that we're getting an outcome that's delivered and tested. As you said, test test test. Right? Automate the testing as well as the the actual process of making the change, I guess, in order to to be sure that you've got that consistency. Now one of the problems that when I'm talking to people about is then how you educate the layer above, that in order to get the resource that you might need or the the, you know, the the the tooling or whatever it takes.

The the the time, right, to to for people to go and learn this stuff. Do you have any thoughts on on that at all? Or That that is, I think, probably one of the biggest barriers that I have seen talking to to my customers, right, is, like, that I do find the case where I see the value. I wanna learn it, but I'm not given the time. I have too much other things going on.

You know, literally, like, it's just the the the higher up you go, the less they, you know, are informed about it and don't give the time to the people that need to have it. And, yeah, the the the time is the killer, isn't it? That's that's the one. Because as as I guess and one of the problems I've always found is is that as a as a network engineer, I spend way too much of my own time, learning and whatever. I've always done that.

You can see the the Cisco press books behind me on the on the, the bookshelf here. It's just an example of of those things that you've always done. So now automation has come along. People are doing the same. Right?

They're using their own time, their own energy to do that. Whereas, I think you're right. I think I think there's there's enough of an operational benefit when it's when it's well understood that we should be using our time as part of the day to day in order to develop those skills, but also then to look at how those skills can be deployed into the into the operational ecosystem that we're we're operating, I suppose, with within our organisation. And one of the areas that that I've seen a lot of take up on is is not just in the actual automation of the process of the things that we talked about by making change or whatever, but being able then to take information about the network and use it in other places. Right?

Being able to, I don't know, things like ServiceNow or things like, monitoring systems or whatever, taking that data. Have you seen any any interesting use cases around that sort of stuff or or those sorts of processes? I I mean, I've seen interesting automation around, you know, like, detection of a potential issue using these analytics and then some automatic remediation because of a a a common known problem. Like, well, that interface is starting to act up, so we can just, you know, shut no. Shut it, and things will hopefully be happy again.

Right. So so using tooling, I suppose, and interacting with the actual devices themselves in order to to to, yeah, create a a more interesting and useful workflow than just pushing a VLAN over a 100 switches. Yeah. Yeah. Yeah.

That makes a makes a great deal of sense. And so I guess, I mean, what this is leading to then is ultimately a completely different way of operating our networks. Yeah. Yeah. Absolutely.

I mean, the network's not going away. I I know everybody's, you know, talking about cloud and, you know, there's still a network, and we still gotta get there. And and so, yeah, it the network's not gonna wait, but it's it's definitely changing, and how we manage it and operate it is it has to change with it. Yeah. Well and and you you mentioned cloud, of course.

The the cloud cloud, I guess, in some ways has has started all this, right, for us because without the consumption of of cloud over API, We probably could have done a bit long gone a bit longer without, without automating stuff. Right? Right. Right. Thank you, Cloud.

Yeah. Yeah. Yeah. It's gotta be good for something, I guess. But, Yeah.

I mean, it's obviously inevitably gonna be a part of of everything we do going forward. And and but it's interesting to see how how much is coming back from cloud and and going back to an on prem kind of scenario. Right? And I so I suppose that's why then we need to make our on prem infrastructure look more cloud like by automating. Yeah.

Yeah. The the more the more the on prem mimics the cloud, the easier it is to shift workloads back and forth. So so here's here's another question, I suppose. From from that cloud perspective, I suppose cloud is it's inevitable that that cloud is gonna be more part of our existence, than it than it has been, but but not completely replacing everything. Do you see that take up of cloud and that understanding of cloud in in network folk more generally?

Oh. That's a good question. That that is a fantastic question, and and I would say that from my audience of people that I I work with, the the customers that I work with, usually, if the organization is adopting cloud, it's somebody else's problem or task. Right? I I work with the network engineers.

They are the network engineers. There's there's a cloud architect or a cloud engineer in the organization, and and the network engineer maybe is only aware of the handoff between the 2. Which is which is an interesting problem in itself, isn't it? I suppose that ultimately, you ultimately, you know, as you say, the interaction with what's going on on prem becomes really important to understand. I I guess what I'm getting at here is that we we always used to have this problem, and I'm I'm a I'm a network old guy.

What can I say? We always had this this problem when when people started first creating data centers instead of we used to call them server rooms back in the day, but everything got upgraded and and was much more fancy. When that started happening, we ended up with specialists. We had people who would specialize in the data center environments and whatever, And and you'd start to get disconnects between the people who looked after campus or the people who looked after WAN and the people who looked after data center. And it feels like they've that that kind of silo mentality has almost been another adopted again for cloud.

And so you have gaps, don't you, between them? And and whether that's knowledge or skills gaps or just general understanding, I suppose. So I suppose something like automation with workflows and stuff gives us an opportunity to start at least papering over those cracks, if you like, bringing bringing some of that information together or spreading the knowledge. I think that's one of the things I see, and and you'll see this a lot, I'm sure, with the audience of the from the podcast of of the people who are doing cloud search and whatever to try and understand more of, those kinds of environments. I I think that is kind of a normal, like, evolution of of that position.

Right? Like, you know, a long time ago, it was just the IT guy, right, or the IT girl or who whoever. Right? And so now now we have, like, an IT infrastructure person, an IT applications person, and then a network engineer. So we're still in the early days of cloud.

So now we just have the cloud architect or the cloud engineer, and eventually, I think we're gonna see a cloud infrastructure or some more server focused type person, and then we'll have a cloud network engineer as well. So I I think we'll start to see that. I think, I find it fascinating. I mean, I I worked my previous role, I was working for a reseller in the UK who progressed through the whole Cisco Gold Partner and all the rest of it eventually to to looking after cloud migration. And it's and you're in a situation there where you're taking what was once upon a time someone's shiny data center and trying to move all the services to the cloud and be able to manage and maintain that.

And the biggest problem that we found at the time was the connectivity. It was people understanding what the connectivity requirements were between moving things to the cloud, and then being able to bring that that that connectivity back home into the on prem environment in order to break create what we're now calling hybrids. Right? Hybrid cloud. But I suppose things like the Aviatrixes of this world and the and and SD WAN environments and stuff are gonna kind of again, more cracks that need to be papered over, but but it's, you know, how how do you fix the problem?

Just build tunnels. Right? AJ, listen. Really appreciate your insight, in this conversation. Clearly something that's top of mind in in many of our, many of the people we speak to day to day.

Certainly, I do, and I'm sure you as well, much needed that that people know where to go, I guess, to to to sort of find out more and and have these conversations. Do you wanna just share your contacts and and and everything with people so that they can, they can find you? Yeah. Absolutely. I'm on Twitter at noblinkyblinky.

My blog is blog.noblinkyblinky.com, and the podcast is the Art of Network Engineering. You can find us on Twitter at art of neteng and on our website art of network art of network engineering dot com and wherever you get your favorite podcast like this one. I was I was just gonna say you're probably one of the easiest persons to find people to find on, in the space anyway because, you know, you're you're you're everywhere. But, no. Listen, I really appreciate you spending the time with me today.

Thank you very much for for joining the call, and thank you thanks to everyone else who's listening. Tune in next month for another community fabric episode.