Hello, and welcome to another episode of the Community Fabric Podcast, where we're bringing the network community to the table to talk about the things that matter to them most in their day to day. I'm Darren Forwell, your host for today's recording. We're gonna dig into a topic that just keeps giving and giving, and that's network automation, of course. I'm joined by someone who's built a reputation for teaching and leading by example in the network automation space. Rick, would you like to introduce yourself?

Hey, Darren. Thanks. Yep. So I'm Rick Donato. I'm the founder of Packet Coders, which is an online network automation training platform.

And, yeah, it's great to be here. Really looking forward to kind of digging in some of this stuff with you. No. It's great great to have you, with us, Rick. And and, obviously, we've spent a lot of time talking about some of this stuff before.

So, hopefully, we'll we'll be able to bring some insight to the table today. Way to start really, I suppose. I mean, this is always the biggest challenge, I think, when when people sort of talking about network automation projects, isn't it? Do you do you start from the ground up or do you start from the top down? Are you thinking about the what the individual needs to do?

Are you thinking about what your business needs? I guess, I mean, you've had experience of of actually delivering projects and and and working with individuals as well. Let's start there. What what's your sort of thoughts on on where we actually start with when we're talking about network automation? Yeah.

I think for me, I it definitely comes down it all starts with the use case. Like, if you've got a golden use case, you're you're gonna do well. Right? And, I I certainly know this from experience because I've had great use cases and my code has been absolutely terrible, But but the tool succeeded in returning a lot of value because, you know, that that use case has always been really good. But, yeah, I mean, it's always good to start off with that with that use case.

And I think the other thing to to think about is when it when it comes to network automation, it's really easy to kinda get bamboozled with all of the different tools and things that you can do. Right? Because, you know, networks are pretty complicated things. Right? And so, you know, one of the things I always like to kind of divide network automation to 3 pillars.

Right? So we have testing, you have configuration, and you have observability. Right? And so, like, testing is all about obviously testing the network and how it's running or, you know, the configuration before it goes out to the network, you know, tools like Batfish, etcetera. And you've got configuration.

You've got your whole pushing your config out, generating your config, and you got the observability there. You know, getting the information back, asking questions, you know, the telemetry, monitoring, all all of that area. So when you're talking about testing, you're talking about really, what, having the data available to make a reasoned decision about what the the config should be or what what what's or or is it is it the whole picture of once the config has been pushed, being able to test that it's that it's gone out the way you expect it to. Yeah. So, I mean, to be honest, each each of those pillars is its own little ecosystem.

Yeah. Yeah. So with with testing, it's either testing the config before it's even hit the network Right. Like pretesting Yeah. Or post testing, is the network running as expected?

Right. So are we seeing the right amount of prefixes, all of that Yeah. All of that stuff? So you got those. And that I normally frame it and and look at it in that way, and then you can kind of think about, you know, those use cases and those tools, and you can kind of fit them into those different domains.

But, ultimately, like, coming coming back to your question of where to where to start, I would really say a good good place to start is with the with the use case. But a typical way that folks normally go about things is, you know, you you look at that low hanging fruit and also, you know, those easy to deal with use cases, but also read only. Doing read only operations against the network is a really, really good way of of starting out in automation. It's less risky. It's just it's an it's a nice way to be able to kind of go about things without, I suppose thinking about it from a from a suboperation standpoint.

I mean, you know, I've I've done this millions of times. I'm sure you have as well. The whole thing of trawling around the network, trying to gather data for some reporting or or some some audit or or those sorts of sorts of scenarios or even preparation for a change, like you said. There's that's a lot of work. It's grunt.

Right? That that no one needs to to do. The the logging into devices. They're they're capturing a piece of data, then moving on to the next one and doing the same thing and and whatever and try to work out how things are put together. I guess what you're saying there is that that that in itself is a is a useful, way in.

Right? Because it's because it like you say, it doesn't have any impact other than on your time and and energy wasted trolling around the network. Yeah. A 100%. Yeah.

Yeah. No. Definitely definitely is is good way is a good way to go. I mean, the other thing I would say as well is and I'd always suggest this is and I've seen it many times is you get folks really interested about network automation, and they've got this idea for this tool. And they sit and build this tool over, you know, they might be in the company for years years and they've built this tool.

And they have this big kind of monolith or this big kind of coupled system and they they leave and everyone's like, woah, I've got this thing running in my my network, which is doing a lot. And everyone's frightened of this thing sitting in the corner and they're like, don't want to touch it. It runs. And, you know, I've seen, I've I've kind of seen that happen quite a lot where people try to either build these, you know, big systems or, you know, these these big things. And I I I really think it's a good way to go about about automation is is is trying to either build or, you know, a nice small library Yeah.

That is not coupled to anything that could be used in different areas. Yeah. And that is gonna be flexible or adding something to an existing framework. Right. Right.

So, you know you know, adding that task to Nournier or adding a a a good good playbook to whatever the framework might be. Yeah. Yeah. So, basically, bringing together preexisting tools, to and you may not use the full functionality of those tools, I guess. You know, you you may just want a part of that functionality.

But bringing them together, and and I don't wanna use the word pipeline, but but but I suppose that that that fits into the big picture of of DevOps going forward. But but being able to take aspects of those tools, but bring them together to create that that playbook or or whatever that that actually basically puts all the data together from these different tools in order to give you the output you're looking for rather than sit in coding a great big, a great big script or or whatever that someone's not gonna be able to maintain and and and manage once you've opt and left. Right? Yeah. A 100%.

A 100%. And and to be honest so, I mean, I've done this myself to be fair. And so I was like, I had probably all have. Right? When when we're we're trying to get this thing going and and it's there in your head.

Right? Gotta go do this thing. Yeah. No. Definitely.

Like so a good example of this and something that I've done before, I'm like, I wanted to build a tool which done upgrades on, you know, lots of different, words, load balances at the time. And that's all good. And I was like, right. Okay. I wanna build wanna build an API for it.

I wanna build a UI and, you know, you build this system. I rolled up my sleeves, built this thing in Django. But, ultimately, when I left and someone said, actually, I wanna I wanna put a front end onto this to be fast API or, actually, I don't wanna use the Django UI or whatever the all the different bits. And you have this kind of weird coupling, it just makes it difficult for folks. And because they have to take it apart again.

Right? And and almost reverse engineer it in order to, to make any changes or or maintain it. Yeah. Yeah. A 100%.

So, like, I'm probably going off a bit of a tangent, but, you know, you have that use case, start off read only. But when you are when you are building a tool of some sort and, you know, this is probably a little bit outside of maybe kind of playbooks and stuff, but if you if you're building something with a Python, it's just build build that library and then go from there, then get it into Django, then get it into whatever it might be. And and I still I still see it quite a lot. I I it's always good to kinda get that. Get your library on its own completely decoupled, and it's gonna make your life and other people's lives lives a lot easier as you move forward.

That's an interesting point because because yeah. I mean, I suppose I was thinking about that in terms of the the the individual tools. Right? But what you're talking about is once you're once you're into the development side of things, still having that structured approach. So you're breaking it up into, not even into modules and classes.

You're talking about taking it further into creating your own libraries and, and I guess I guess this is this is an interesting point. So this is like prop proper development principles here, isn't it? This is about building individual testable libraries of code that you can, that can stand alone and then be reused by other people, not necessarily trying to achieve the same outcome you are, but potentially still using the logic or whatever that you you've defined in those libraries. Yeah. A 100%.

A 100%. That's a really good point. And I suppose so here's here's a question. Right? So so you've you've talked there about specifically about the the coding principles and and everything.

Is coding something that that that's critical then or understanding the coding approaches, to to network automation more generally, do you think? Do you mean to be able to kind of get benefits from network automation you Right. I mean, I mean, it's it kind of it can't as I say, you can have tools, individual tools that you put together on a on a on a command line that you run and does one thing, and then you chain that into another one that does another thing and so on. And so there's logic behind behind that and and whatever. But if you're using a framework like a or or whatever, bringing that into Python, understanding the the way you structure a Python.

I'm I'm going down a bit of a bit of a rabbit hole here. But but but does does coding in Python become something that's critical? Or is it or is it that you're gonna be able to get better results if you're able to understand and and develop in that way? What do you think? Yeah.

I think, I mean, to to to get the benefits from, you know, automated pipelines and etcetera, etcetera, it's always gonna be and not not necessarily just Python, but any of the the the kind of coding constructs is is gonna be really, really useful. I think as things have become more abstracted, so like, you know, frameworks like Ansible. Mhmm. You could very much will have folks just knowing about, you know, data format. So just knowing.

Yeah. So it does get interesting because, you know, where does that where does that line kind of sit? Because, well, if I'm putting something into YAML, then to be fair, you know, you're gonna be going down the IAC route and you're gonna gonna wanna version control it. So you're probably gonna need to know Git. So Yeah.

There's an element there's an element of that. But it's an interesting question because ultimately, you know, you've got a lot of engineers out there that aren't aren't coders. Right? Yeah. Yeah.

But they they know their networking, right, really, really well. So for them to be able to look at a change request, which has some some data attributes which are laid out in YAML ready to be pushed out to the workflow, that's gonna be really useful. Yeah. They might not need to know the ins and outs of return codes and CI. Yeah.

But but they but they know at least the basics of data formats in terms of arrays, key value pairs. Sure. Sure. So it so it becomes more of a, more of a an understanding of data and data transformation and and those sorts of things rather than and I suppose APIs to a point because, yeah, that data needs to perhaps be fed into APIs and retrieved from APIs, but not necessarily the mechanics of how to do that, from a from a coding standpoint. Yeah.

I'll you know, I love the fact you've you've said that Because a lot of the conversations when you're talking about network automation, it naturally always seems to flow back to data. Yeah. And it is it is all about the data. Right? Totally.

I mean, I've one of my colleagues is gonna love this when he hears this because, he he basically talks about being a a data guy. And when you start him down a path of, getting him to explain what it is that that we do, it's all about building data that's got value, right, based on on unstructured, chaotic, in some cases, information that's out spread across this big distributed system that's the network. And that's that's the key here, isn't it? This is about getting insight and being able to to to which is actionable because by understanding the structure and what it is that that you need to pull from that data. Yeah.

Definitely. And, like, we're talking about data originally that around this point, it was originally around kind of like the the input. Ultimately, now we're getting more and more data out from the network with tools, you know, Backfish or Suzy Q. It's about, well, how do we structure that that query? And, again, that comes back to knowing your network Knowing your networking.

Yeah. Yeah. Say, well, I want this value and this value, and if not that, to to kind of do that exploration. Yeah. Because you you gotta understand how those things relate.

Right? And and and and what it means for them to relate. You know, it's like, well, why is the MTU important here when I'm running OSPF, you know, across this link or etcetera etcetera. It's it's being able to pull those data points and then give meaning to them, in the context of the network that you're working with. Now I think I think this is this is fascinating because it it it gives this it puts this in a completely different, light to me that then it becomes about, okay, I have this data.

What can I do with it? And where where does it take me? Because this isn't now just about pushing config or into devices, is it? This is about being able to help people understand what their network's doing and why it is doing what it's doing and what they can do, you know, beyond that. So building building into the bigger ecosystem.

So it's not you know, this is and again, APIs coming in here. This is you might have an ITSM, a CMDB. You might have, like, you've mentioned observability, and I think these are really interesting, you know, lots of interesting things to be said there. Yeah. Definitely.

Definitely. So all all about the data. Yeah. All about the data. Right?

No. Absolutely. So I'm gonna change tack a little and and and we've talked a little bit about some of the tooling, and everything that that, that certainly that you've come across. Do you have, like, a a particular framework that you like to work with? You know, just you walk walk into a a customer environment for the first time and someone says, right.

We wanna do some we we wanna do some network automation. We don't really know exactly what the use cases are yet. We're working those through. Is there, like, a go to minimum viable product sort of ecosystem that you would have in mind before you even start, or is it very much focused on those use cases? Yeah.

I mean, at the end of the day, a lot of it's gonna be based on, you know, the customer, the Yeah. Client, you know, who because ultimately, my go to is, I would say, like, a non near stack. Yeah. I'm I'm making the hands in comments at the moment. Right?

I realize that no one's gonna see that. Yeah. Quotes are in perfect. And I'll do that because, you know, I say the Nornir stack of, you know, Nornir is the conflict management framework. Yep.

And under that, you've got your napalm, scrapply, or and if if you need to, let let me go. I I love that framework, and I think they it's just great. Really clean, lean. It's really good. But, ultimately, I get that, you know, a lot of folks aren't gonna wanna roll their own Python.

They're gonna need a bit more and or they might even have Ansible already in house. Sure. And so they might wanna use Ansible as a framework. So but my my go to would be Nornir for the conflict management side of things anyway. I think it's a great it's a great tool.

But, yeah, I mean and sports also. It's also great. Right? Yeah. I I so much with it.

I like the way that you you've sort of framed this, like, based on the operationally, I suppose, what you leave behind. Right? Because because, you know, you are not gonna be there for for forever when you're writing the tool or whatever and and putting things together. It has to be able to be managed and supported and operated when you move away. Right?

So so I think that's the probably the key point, almost, isn't it? Yeah. No. Definitely. Definitely.

And I think I mean, that's from the the kind of conflict management side side of things. For testing, I'm a huge fan of Pytest as a framework. And so, like I say, pytest being plug in py pytest being your kind your runtime, and then you plug that into tools like Scrappy or Napalm or whatever whatever tooling you might wanna you might wanna use. But, again, that's a that's a really clean and and so really lean framework. It's really Sure.

It's really good to use, but and that's again and now that's the same for me as what we just spoke about with the Ansible side of things. Right? Because with the Ansible side of things, Ansible versus nowhere near, have you got the experience in house, the support? And the same comes like pytest for me versus, like, the the all batteries included framework of something like PyATS. PyATS.

Yeah. Yeah. Yeah. So, obviously, PyATS gives you the run time, but it gives you all of the other bits as well. But Sure.

You know, you might want that added level of comfort. The fact that it's from Cisco, the fact that there's an online online community you can easily I was gonna say, and all those videos and training materials and all the rest of it. Right? Yeah. Yeah.

Yeah. Yeah. Definitely. And John Capobianco there, on on YouTube, teaching you teaching you the ways of the the ways of John. Yeah.

Yeah. Yeah. A 100%. Love that guy. He's, he's amazing.

He's amazing. So much energy. And, the stuff he's been doing with with chat GPT and stuff lately as well is, absolutely, I mean, hilarious and yet, you know, just opening people's eyes, right, as to to what what you can do when you when you can bring tools together like this. Yeah. Definitely.

And I remember speaking to him once, and I said, you know, how how'd you frame, like, what you're doing out there? And he and the I I always remember this and he said he said to me, well, I just consider myself as, like, I'm just a gardener. I just go out there and I just, I'm just doing my gardening and I'm like, that's a great way of putting it. You're just going out there. You're learning.

You're kind of doing a bit of this. It's and that's what you need to do of all of this stuff. It's just try it out and get your hands on. It's great when you can, when you can have, and that's what I love I love about about about where we are, I suppose. The the fact that community now exists, there are so many people who are just going out there and trying stuff.

Right? And but then sharing the results, and and it gives you almost too much sometimes. Too much too many ideas to go at and and whatever. But certainly, you know that there's support in in whatever you're trying to achieve, which, is interesting. Yeah.

There is there is the quality of tools out there now is is unreal, I I think. I mean, especially if you look at something like scrappy. Like, you install something like scrappy out of the box Yeah. For just kinda do some some SSH handling. I mean, out of the box, it's got no dependencies.

Like, it's such a solid tool. I'm talking about the just the from my view on Python. I'm Sure. Sure. I've not done too much with Go because I know there's there's Go libraries and stuff out there.

But Sure. I mean, yeah, there's so many so many tools, and it kind of now lends itself to well, we've got all the all of the tools. It's how do we put these things together into a good solid workflow? I think I've kinda made things work. And and that's where where it's time to to be creative.

And I suppose comes back to to the use cases again. Right? And and it's like, look, understand what those use cases are, build the the the workflows at a high level to to to see how you then put those tools together. Because if the tools are there, I guess that's the thing, isn't it? Up to up to fairly recently, I suppose people were still, rolling their own very much.

So Yeah. And there's 2 I I kind of always feel this, like, kind of two ends to it because you've got this nirvana state where you've got this big system that just runs by itself. Everything's stitched together. You never have to get involved, and it's just everything's just working really, you know, seamlessly, but that takes a lot of work and also a lot of upkeep. Yeah.

There's nothing wrong with just doing this thing. And I say doing this thing, I e, automating the network and and, you know, just going building out these these scripts, etcetera, but doing it bit by bit, you know, and going you do need to go on the journey because if you're gonna start off at the try to start the Nirvana side, it's gonna be difficult, and it's gonna be hard to get those wins. You wanna kinda do it bit by bit. Yeah. It it's really interesting for me because because I mean, having gone through I mean, I was a, you know, been in networking a long time, was an engineer, was a was a designer, was a consultant architect, and and having worked those through.

The whole point of what I was trying to achieve at the end, as I moved out of you know, moved towards that network architecture side of things was to build a network that was supportable. Right? Because because if it wasn't supportable, then you were never gonna achieve any of the outcomes that you were looking for. So that was always the first thing. And in a way, what you're talking about is is the same thing.

Right? It's it's not not try and build this all encompassing incredible thing because it's gonna be so labyrinthine and really difficult to to sort of understand what's going on under the hood But as soon as you walk away and it comes back to the point again, as soon as you walk away, no one's gonna be able to pick pick up the reins and carry on with it because they don't understand how it's put together, and it has to be, part of of normal operations. Right? So so I guess what you're describing is if you've got a process to do a thing now, take that process and automate it. There still is that process to do that thing, but it now isn't this version of it rather than that version of it.

And then you just go through and gradually all of your processes you you replace with, with or an automated approach, I guess. Yeah. Or just if you've got a process, just automate one step. Mhmm. You can then you know, you don't even need to automate all of the steps.

Yeah. You know, you can then just literally jump into one of those steps, and it's not ideal because it's manually triggered. But, you know, it's just I always think at the moment, I've been doing a lot around, one of the new courses that I'm just about to bring out, which is around pandas. And for me, that's a really good example of this because, you know, you might have a workflow where you've got this spreadsheet, that people are inputting. We don't necessarily need to get rid of the spreadsheet, which is not it's it's a form of it's an input mechanism for folks, especially if you're not tech technical.

But you could then easily convert that into a a data frame, pandas data frame, and then you can automate off of that to to then step through a couple of the steps. Yeah. So Listen, Darwin, that's a really a really good point that that one of the go back go back even 2 years. Right? One of the first steps that everyone would say on the network automation front was, oh, you need a single source of truth.

You've gotta put everything in a in this single source of truth and then automate from that so you know that blah. And I think as we become as we go through this, feels like we're getting a bit more pragmatic and say, no. Actually, single source of truth is great, but in reality, you're gonna have multiples of them. You're gonna have or or if you like systems of record rather than sources of truth and but I need to be able to make sure that I've only got in one place and you have a definitive one. Now that definitive one as you say could be a spreadsheet.

Why would it not be? We've been using them long enough, right, as as part of network operations. So automating off of that is just as good, and, again, I'm using air quotes this time, as as it is automating off of a off of a custom database built for the purpose. Yeah. I suppose it's always gonna be benefits.

Right? If you if you run enough of the database, you know, I certainly don't wanna I don't wanna tout too much. Hey, Rick. It was on the podcast news. You were saying that Excel spreadsheet should be used for network.

No. No. No. No. No.

But A 100%. I saw what you're saying. But this is the pragmatism thing again. Right? Because because the chances are you've already got a spreadsheet with the information you need.

What you sue what you'll soon find out is, do you know what? This would be so much better if it was in a database and then you go to look at actually building up the database side of things. And, obviously, we'd, you know, we're we're both members of the network design partner program, NetBox, or something like that is it would be would, you know, is great for that sort of thing. Right? So, again again, I guess, becomes part of your important tooling, in your in your ecosystem.

So But it's all about, it's just all about to kinda taking those small steps. Right? Because ultimately, you wanna take a small step and then you wanna kind of, stop and you might need to kind of change direction because if it's like, something's gonna happen, you're gonna you're gonna realize that whatever you're doing, people, like, people might have input. You wanna kinda change that or so there might be technicalities. If you go, you know, heading down the path at an a crazy speed, then you're gonna look back and go, actually, maybe I should have done this and that.

So I suppose what I'm trying to say, it's it's good to do it step by step. Kind of just take one part out, automate it. Is that working? Okay. And kind of going at that kind of start in that style, I feel that you can you're gonna build a kind of a workflow that everyone's invested in, I was just gonna say, I mean, that that again, this is this is the pragmatic approach.

Right? This is the the whole kind of don't don't try and do everything all at once. Don't try and build everything that that you think was is gonna be a thing because it's never gonna be what you think it's gonna be. Right? It's because it's always gonna change because there's always gonna be stuff that that that sits outside the scope, that you're gonna have multiple vendors and that's gonna be more difficult and so on and so forth.

So there's always no network is a is a greenfield. So that whole that whole thing. Right? So and and business priorities change as well. And I think this is this is something that gets where it becomes quite interesting.

Because when you start to show when you start to build these things out, what becomes evident, I suppose, once you've got the data, is you can start to do some more interesting things with, providing a business outcome, not just improving the efficiency of what you're doing, at the at the ground level, I suppose. Yeah. Yeah. Definitely. Yeah.

Because there's there's so many different benefits, isn't it, to network automation? A lot of folks just think it's all about typically it's always been about the speed, but you know, you've got human error and, and I know I've said to you as well, but it's the, it's the blood pressure of us. Right? Oh my god. You know, the the there's those weeks where you would you wouldn't see your family because you'd be, you know, firefighting after change that happened at the weekend and blah.

You know, if you can take any of that pain out of out of the the day to day life of a network engineer, then, you're on to a winner for me. Yeah. A 100%. Yeah. A 100%.

So I'm just thinking, right, I mean, with all of this said then, do you if I were to to give give you one sort of parting thought that you want to share with people, on perhaps, I don't know, where where they should, you know, what what they should learn first or whatever. What what do you think? All around you when you say that, you mean around kind of just general network automation? Yeah. Yeah.

Generally. How to how to how to start making your life better and what should you learn for us? That kind of thing. Yeah. Yeah.

Yeah. I think I mean, there's gonna be a few things. Right? And and first of the before you do anything, whether, you know, it's just gonna come to many other fields as well and just general networking is just having a good understanding of Linux. Right.

Right. That's that's that's always gonna serve you. So so many people say this, and and it's it's an interesting one for me because as a network person, I've always felt that I need to know as much about or everything else in the IT ecosystem as I should anyway. And I guess that's not necessarily always the case. And and it's interesting that that we're now getting to the stage where we're saying, well, actually, yes.

It makes sense for us to do this, but it's for a slightly different reason. What what would your what what's your main reasoning with that one, do you think? Just there's with Linux, it kind of there's so many things that it it helps with. Whether you're just if you're just doing general general coding, just, you know, just being able to jump in and out of the system. So, for example, if you're working with tools like, Scrappy or Nornir and you're trying to install them, you know, directly within Windows, I've seen some folks have issues with that.

You know, they they always suggest just go into, you know, WSL. And so that they're then they're built for that. Right? They're they're they're not built for it to be run with with windows. And I guess that's that's part of it.

Yeah. I mean, I don't I've never kind of gone into the full technicalities of it. It's just, it everything seems to work in WSL and Linux on Windows. But so, yeah, Linux is a is a really good thing to to know. And and when you start to do your version control, it's good to know, you know, how to how to kind of navigate, a CLI at the end of the day.

Yeah. I think so what you're saying, I suppose, is is understanding how these things are built and how they work without having to resort to sticking a gooey over the top or whatever. Because, again, you lose the the abstraction, you lose the understanding of what's going on underneath that. Right? And so so really what you're saying is by understanding it, you can use it in its in its native form and, and and get the most from using those tools.

Is that fair? Yeah. Yeah. Definitely. Definitely.

So so, like, a couple of other examples where Linux like, knowing Linux is really, really helpful and something we do on the on the courses, and that's, you know, hitting an API. Yeah. Yeah. You can use Postman, which is good. So it's a GUI Yeah.

For creating APIs, But actually using curl Right. On the Linux command line is pretty good because if you stick a few for both flags on that, you get to see the for all of the headers or all of the guts of what you're doing with the API Right. Request and response. It's a really good it's a really good learning aid. And even to the fact that a lot of the time, it's quite good just to see if you can get an API running within curl before you kind of you move on.

It's just it's quite kind of one one example. So yeah. Makes sense to me. It's, yeah. Because like you say, it's it's just having that that lower level understanding that being able to get into the guts of what's going on.

It should should suit the, the natural, inquisitiveness of a of a network engineer, I would have thought. So makes perfect sense. And also the funny thing is is that, you know, we've spoken about Ansible and it's a good way to go if you're not knowing if you don't know Python and it's, you know, it's got because it's got a low barrier of entry, but, you know, you're gonna be running that from a shell. Right. True.

So, obviously, without all of the goodness of something like AWS or full workflow, but Yeah. Yeah. Yeah. But, again, you know, being able to then switch between the directories, that's gonna massively help. Right?

So Yeah. So, yeah, Linux is is a really good thing to know. And then I think on top of that, understanding your your you know, we spoke about data already, but understanding your data formats Mhmm. In terms of what is JSON, when do I wanna use YAML, and the the key parts of them like, they all look really, really comp you know, I say really, really complex, but Certainly, if you've never seen them before, they they they don't look straightforward, do they? Yeah.

You look at them and you oh, well, I've got these different I've got these different objects within JSON, and I can do this. But ultimately, you know, just knowing about your key value pairs and your raise, it it's gonna serve you well. You know? Yeah. And I say they look complex when you get mat you know, hugely nested pay payloads.

Yeah. You know, it's just kinda knowing how to kind of just work through that in your in your mind. But I think knowing that is gonna serve you well because you're gonna be using that those data formats and and the those concepts throughout all of the different tools that you use. Yeah. Yeah.

Yeah. So I think that that structured data thing and we we you know, just just sort of going back to an earlier point, the idea of of knowing and understanding how how to structure data and what it's gonna what it's gonna give you by having it is probably, probably the key thing, isn't it? Yeah. And it's it's probably just gonna become more and more important as we we go through. Right?

Agreed. Agreed. And more and more things are abstracted. So What? Yeah.

And, gosh, I mean, we could go on for for for weeks talking about this stuff. But, I mean, if you even think about SDN and and controllers and so on, What's coming back from those things when you make API calls into the mixed structured data. Right? And you just need to understand what that means. So even even when you point click through the the UI, that's great.

But as soon as you wanna put that together with other things, you you need to understand structured data even in those environments. So Yeah. No. A 100%. And then, you know, with with that data is is understanding your your APIs, and I think APIs is a great thing to Yeah.

You know, to learn about because and to know. Because to be fair, it's not just about communicating and speaking out to these network devices when it comes to network automation. It's about all of these other systems. Sure. Your Snow, your Jira, your NetBox, what whatever it might be.

Yeah. I'm I'm working with that data between between those different systems or Yeah. Or your IP fabric. I'll just just get that in there. There is there is there is that.

Yeah. I'll give you that. But but, again, you see yeah. That that enrichment that you can get from from having having that structured data, observability, platforms, you know, streaming telemetry, all that good stuff. Right?

It's all in in, in the structured data forms, APIs everywhere in order to ensure that everything's fully integrated and away you go. Right? Yeah. I mean and also with, you know, with APIs, you get that. I would say, what are the the big benefits?

And and that's with, you know, web webhooks. Right. You know, webhooks being able to trigger out and send our API calls based on different events, and you can you can start to stitch things together in an an event based manner Yeah. In a really, really nice way. So, so, yeah, APIs slash with with webhooks, it's, yeah, another great thing to know.

And then on you know, once you've got that, then what, you know, what do you wanna do you wanna start for your testing, your config? And then going back to those 3 pillars, do you wanna do your testing? Okay. What testing frameworks? What tools have we got?

What do you wanna do? Do you wanna do your configuration? You can then kind of go from there. But as those underlying three parts, you know, of your Linux, your data formats, and your APIs, they're gonna serve you well whatever whatever one of those pillars, those network automation pillars you you wanna dive into. So so yeah.

No. No. That's great. Thank you for your time, Rick. I mean, it's it's been great as always to chat.

Is there any way people can get hold of you if you're, if they're interested and got more questions? Yeah. A 100%. So you can reach out to me either on Twitter. So my handle is at Rick j Dunn.

You can find us over there along with our packet coders, handle it, at packet coders. So, yeah, you can hit us up on on Twitter, or you can reach out to us via our website, which is packetcoders dot io. And if you wanna learn more about network automation, we've got a free newsletter that you can sign up to over on our website. So just to let you know, again, that's packetcoders.io, and you can get free tips, tricks delivered to your mailbox every every week and every month. And, so yeah.

Yeah. Just head over to that. That's perfect. Well, thank you ever so much for your time, mate. It's been a blast as always.

Good to talk. Yeah. And you, Darren. Thanks.