Hello, 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 most in their day to day. I'm Darren Fulwell, your host for today's recording. And today, I'm talking to someone that I'm sure many in the community will be familiar with. Ethan, do you wanna introduce yourself? Yeah.

So hi, Darren. My name's Ethan, and I'm a core network engineer at Zen Internet in the UK. That sounded almost like an Alcoholics Anonymous, kind of kind of intro there. Obviously, we we've known each other for a little while, mate, and, it's it's always good to speak to you. So, thanks for thanks for joining me with this.

No. Anytime. It's an absolute pleasure. Always good to catch up with you. Yeah.

Good. Had a long time. You know? Well yeah. Yeah.

It's been a little while, and you've been you've been doing some stuff in between. Right? You've you've this isn't your first podcast recording in recent weeks, is it? No. It's not.

If you can see the video, you can see that got the exact same jacket on that I was wearing, you know, of network engineering. Right. Cool. So you've been speaking to AJ and and Andy and the guys? Yeah.

Yeah. We, jumped on a call a couple of weeks ago. Did did another little podcast recording. So, yeah, we got good fun apart from just staying up really early in the morning. But, yeah, I like the way you just put another little podcast recording.

Yeah. That's, that's says a lot for you on how your life has changed, my friend? 100%. It's just been on the up. I think it's how how many years now?

4, 5 years that we've we've just been chatting. So So something like that. Yeah. Yeah. But so so, Gordon, what we wanted to do really today with our little chat was to, I suppose, compare experiences with how things are as as a network engineer in the world as as it is now, and how it was when when I was finding my way, I suppose.

And and doing I mean, we talk about this sort of nonsense all the time. Right? But it's but it's interesting to to do these comparisons, I suppose, and and see how much better things are or worse that they are now and and where where the industry is going and whether we think it's, you know, that's that's taken us in the right direction. And I kinda wanted to dig into that a little bit. So so let's start with the beginning.

Seems like a good place to start. Oh, that sounds like a song. How did you get started in this nonsense? What what was it that you attracted you to networking, and on on what was it? How did you end up here?

So I'll be completely honest. When I was in school, I didn't really do great. I ended up actually leaving school at 16 with a single GCSE, in IT. I didn't really know what I wanted to do, to be completely honest. Right.

I actually wanted to be a chef when I was leaving school. Nice. But I but I didn't want to travel 2 hours to the closest, like, hospitality college. So I was kinda given the option either to go out, get a job, or just just go to college. So I started off at Burnley College just doing a level 1 IT, just generic computers, showing that you can use, Outlook, Word, Excel spreadsheets, that sort of stuff.

And then it was more sort of the 2nd year where things, like, kinda really kicked off for me. So when you went into year 2, it was either you start off on software or you had networking as well. Right. So I actually started out on software, and you had like a little bit of a grace period where if you didn't like one you can move to the other. Right.

And the first project that I actually had when I was doing the software was to build a bank ATM using c plus plus, I think it was. So So you were your your programming project was to to write an ATM? Yes. Using c plus plus. Amazing.

And after about a week, I just kinda got to the point where I was just pulling my hair out, and I was like, I can't do this, and I don't want to do it. And I moved onto the because people would use chat GPT for that now. Right? Yeah. A 100%.

I think so. It's so easy now. So yeah. So then I went on to the the the networking course. And, essentially, I I remember on my I think it was one of 1 of the first few days, It was essentially just getting 2 PCs and plugged them into a switch, and it was literally just pinged across.

And I saw them big exclamation marks, and I pinged across, and it was like a a a brain stroke moment for me. Like, what how is that working? And literally from that exact moment, I've just been being hooked. So that's kind of a a short version of my getting to IT. Honestly, that's that's really interesting because, so so for back when when I started this crazy stuff, Networking wasn't really a thing in the in offices generally.

It was it was getting there, and people knew about it. But there there was a real it was a real mystique around it. No one really understood it. You know, so very the the education wasn't quite there. The the, you know, people people didn't know what they wanted to use it for.

Yeah. So so so my background, very similar in a way that it's that it was much more general IT, that it was, I mean, my my education was always as general as possible until it needed to be specialized, and and my teachers kept advising me, don't do IT. Don't do IT just because you might choose not to want to do it in the end. And and with me, it was all was never gonna be anything. But but I've reached a point when I first started working, where I was working in application and desktop support.

Right? I was literally teaching people to use WordPerfect. But that's but it's the same thing because then you get to a point where you go, yeah, but with word perfect, I want people to be able to save files on a file server or a central file store or and use centralized printers. And it's that whole hooking things together and having the, you know, the light bulb moment. Yeah.

We go, how does that work? What does that do? You know, how does it how does this happen? And all of a sudden, you're away. Right?

100%. Yeah. Yeah. It's so so once you'd got got that initial hook, there's there's then a learning process you gotta go through, I suppose, to start to understand why and how and and and what that looks like. What does that what does that look like for you guys?

I mean, what what what was that? What what did you have to go through? I mean, you're at college anyway, right, studying this stuff. But Yeah. So, on the level 2, it was pretty much just going through the NetAcad course and for the old CCR and T, for your So it's the Cisco sorry.

The Cisco NetAcad, Syllabus. Right? Yeah. So you'd you'd work on that as well, but, obviously, you have certain modules that that you have to complete outside of the actual, outside of the NetAcad course. So that that is kinda where the foundation started to be laid.

Sure. Getting your your lab set up on on Packet Tracer, going through all the specific modules, kinda doing your own crimping cables, that sort of stuff. I was gonna say I was gonna say, so it's good to still be doing the physical stuff and understanding how all that stuff hangs together. Right? Because, you know, there there's I was starting to get a little bit worried there for a second.

You'd gone straight onto onto ping and and not not understood how things hang together. So that's good. Yeah. So, I think it was just because I kinda started a little bit late, and they they kind of already gone through, you know, the r j forty fives, your cables, the MDX, all all that sort of stuff. So I I kinda came in a bit later with, like, starting just a week after.

But, yeah, I mean, you go through you're crimping your cables, which I really disliked. I still can't do it to this day very neatly. Yeah. And then so so I finished my level 2, and then for my level 3, it was either potentially having a look at an apprenticeship, going out to a business, getting hands on, learning more about how things work, or I could have stayed and done, a level 3, which again is is a lot more theory. Right.

And the and the and the best way that I learn is is being hands on. Practice. Yeah. Yeah. Yeah.

Yeah. 100%. So rather than just all theory based tasks have to get in hands on doing something, working with different people, working with all various different departments, pretty much. I don't like being kind of sat around, I like to be go go go 100%. And and, yeah, that's sort of where my full trajectory started.

Sure. He's he's on the apprenticeship working with all the different people working with Yeah. I was gonna say, so so there, you're you're basically building on other people's experiences. Right? And you you're you're learning as you go based on how they do things now and then start to form up your own opinions, I suppose, as to how that can be done going forward.

Right? Yeah. A 100%. And, I mean, the so obviously, my I I started going, on my trajectory upwards, and, one of the engineers who I started on the apprenticeship, on the apprenticeship with, so he was a a tier 2 engineer at the time. Right.

Fast forward 6 years, we're now working on the same team together. There you go. So There you go. So we'll we'll talk more about how you got to that stage in in a bit. But but I think I think this is this is an important point.

Right? The the I guess what you've got here is the support of of almost mentors. Right? And and people who are prepared to to put the time and energy into making sure that they bring other people on with them and, and and upscale them so that there's someone to to fill the gap once they move on and and do whatever they're doing. Right?

So, you know, that that side of things is is always super important. And I think I think that's that's, again, a theme, right, in in IT more generally. But but certainly something that I can relate to as well. You know, when when I was at that those early stages, working with people who were able to give me the benefit of their experience was really, really important. I guess there is a difference now, which we didn't have then, which is which is the the the way the community can can contribute to that.

Because at the moment well, we'll talk about that in a second, but the community is everything. Right? And and I think when and at the time when I was doing this, certainly, your community was a lot smaller. It was the people you worked with and and, potentially, you know, occasional meetings outside of that, but but very rare. So you had to almost build your your, community based on on choosing the right place to work in order to to to develop yourself.

But, of course, now that's that's, a lot easier, right, with the way we do things in the community. Now what what are your experiences of on the community side of things? Obviously, people know you as as, Ethernet, right, on on Twitter. So, so yeah. So I mean, the the community is a great place.

I mean, you you can pretty much go to anybody within the networking community. Everybody will be happy to help. I I think you really hit the nail on the headline when you compare it to potentially when you first started networking, it it didn't really have things like Twitter or LinkedIn or things like Slack or Discord to actually be able to actually have a chat and to discuss things, it had to kinda be in person. Yeah. I think and learning from books and stuff like that was was much more the the way you had to do things because you had no choice.

Right? Right? There wasn't anything else. That's why I've got all these books behind me. Most of these most of these are, you know, ancient books from from those sorts of times.

But but that's it. You know, it was all about that. And and it was slow, and it was it was tough. And and you had to have a a kind of academic inclination, I think, a little bit in order to to really get to the bottom of things. And I think that's that's immeasurably different now with with the community.

I think it's a much more open, environment as a result because we can get people who aren't academically inclined or people who have much more creative, much more, I don't know, able to to sustain, relationships with real people. You know, you know, that kind of thing, which which was difficult for the for for us oldies. But I think, you you know, the world is a different place. Yeah. 100%.

I mean, the thing is sort of, like, just going off in a little bit of a tangent so that the As we as we always do, mate. As we always do. So the the the fundamentals of networking are are always gonna essentially be the same. So it was like when when you first start Lee started probably studying for your CCIE, the Geoff Doyle CCPR people, it's it's one of the the main books. So you've got up there on your shelf, and I think that came out the year that I was born.

Oh, I don't do. Wow. But it's like e even though the foundations of networking have changed in, it's just how can we evolve networking into better practices Yeah. And and kinda what what can we do to make it easier on the person? I like it.

I like your thinking there because it's that that's exactly where we are, I think, is that the and there's, I don't know if you've ever read, RFC 1925. Right? It's a bit of a classic read that that people should all all look at. The, the networking truths RFC. And there's there's, rule 11, is that that, there's, basically, there are no new ideas in networking and and everything is, has always already been invented, and we're just repackaging the same ideas over and over.

That's exactly the the the case. I mean, we know that. We know that that, you know, SD WAM, when it was introduced, was just tunnels. And we used to do tunnels all the time back in the day. You know, whatever it is, there's there's always that that repeating, because the fundamentals don't change as you rightly point out.

I think the what tends to happen is we we slap these abstraction layers on, and it hides away some of the detail that perhaps we don't need to understand in as much, you know, to to the same level as we as we used to. But, ultimately, there there's a reason for that. And what we're trying to do is exactly as you say, trying to make it more consumable, more, agile, more stable, more available, and look at that as a service rather than as a technology that we're trying to implement. I think that that's where we're trying to get to. Right?

Yeah. Definitely. Yeah. That's a really, really good point. I think that's that's kind of driven, certainly, a lot of what I've done over the last, I don't know, 5, 6 years or whatever with through the design work that I did and everything was as much about, yes, the technologies are important, and putting those technologies together to deliver service is more important because it needs to be answering a business requirement, but also it needs to be supportable, and it needs to be maintainable, and it needs to be these other soft things that actually are as relevant to what the technology should deploy as.

Can I tweak this thing to to do that? You know? It's Yeah. It's really, really, really important. So, yeah, really good fundamental point there, mate.

And I completely derailed the conversation there with that. So, yeah. Yeah. Well, I I was gonna say, I mean, on on top of what what you've just said there exactly, there are some sort of caveats in in regards to actually getting to the final destination. Right.

You could say which kind of leads into the next thing that we could potentially maybe jump into. So you've got to have certain steps in place to obviously get you to where you need to be. Right. So got a certain thing that you want to do. So if you've got a task that's very repetitive, so what what can we do to stop this being repetitive on the person, stop this being a manual job?

But then it kinda leads us back to the place where it's not very often that you get brand new greenfield networks that come about today and say, like, 9 95% are more than likely gonna be brownfield deployments. Yeah. You know why? Because that's because because my generation put in the the greenfield and, and you guys are fixing all the problems that we we put in the first place. Yeah.

Definitely not. So, yes, obviously, if you got all these brownfield networks that are obviously still coming in, you can't just use automation as an example just willy nilly. It's exactly as we said. We need to have a foundation built that we can build upon to get you from the start of the journey to your end end destination. The when it there's obviously requirements that that have to be met.

Yeah. There's obviously certain things that they have to potentially work around. Do you have the staff to maintain it? How do you know who's going to actually do the implementing? Have you got people who know how to actually do what you want?

It's an interesting point. I think because because, basically I mean, I the way I tried to design networks before I really got involved in the automation was to make them support. Right? To to, you know, it was it was you you walk into an environment, go, I've got all these technologies to choose from. How am I gonna do this?

What am I gonna piece together? And you could look at the bleeding edge stuff and go, I could deploy this and do this and do this, but then it's super complex for someone who's never seen it before to come in and learn how to do it. Right? Yeah. And and so so what I always tended to do was to start with those those requirements.

So you you just said there. Right? Pull pulling the almost the the the nonfunctional requirements out and go, actually, before I even start any of this, someone's gotta support this. Someone's gotta learn the technologies that I deploy if if I'm introducing new ones before they can even support it in the first place. How is it gonna get maintained?

What happens if the people what happens if I leave and I take all the knowledge of these new tech this new tech with me? What what does that leave people with afterwards? And and so you start to look at it from that perspective of how it's gonna be used and consumed rather than what functionality does it have. And it flips the whole thing on its head, and it it's exactly like you say with them when you start to look at automation and layering that on top. Again, you've got the same problem.

We're being taught all these these cool things about programming and and answerable and and all the tooling and all the rest of it. But it's still a minority of people who understand those things. You deploy those things and not have without the support around them, without the people who've learned you know, been trained to use it or whatever. And those things are just gonna die as soon as someone walks away because you you've not able to continue, The development. Continue development.

Exactly that. Exactly that. So, yeah, I I'm with you completely on that. I think that makes a bunch of sense. Yeah.

In interesting that we find ourselves at this place because, really, it's just an extension of of what we were doing before. It's just like you say, rather than worrying about what technologies we're deploying, we're now getting to the to the good bit, which is worrying about how to actually operate these things better. Yeah. And as you say, I mean, there there's gonna be certain scenarios where, like you say, you've got the complex networks, which is gonna be harder to to bring in and to start help lay the foundation again. Whereas in in network terms, I mean, I've I've heard it throughout my my career, the the simpler the network, the better.

But it's now how can you piece together all these different parts of the network to make it more consumable Yeah. More efficient, better for the business. Obviously, I did these pros and cons, and, I mean, the list could literally go on forever in a day, to be honest, couldn't. And so but then it's not just certain functions that you've got. So, obviously, you could potentially use your Ansible.

You could use your Python scripts, But then it's not just that that you have to worry about. You then potentially what do you want to do for for validation? CICD pipelines, GitHub is your DevOps. It's a case of intertwining those into the full build. Yeah.

So it's not just one thing that you're looking at. You've kinda got to picture all these different applications that can work together. This is this is what what I was thinking, that the the complexity that we've got. So so so, again, looking at, the the design of the network and the technologies and and the build, the complexity in that is isn't necessarily that you're using a technology that's hard to understand. If you simplify and you said about the keep it simple principle and all the rest of it, that's all good stuff.

But if you but you're still gonna have a a number of moving parts. Right? You're still gonna have Yeah. Different domains in the network, potentially different vendors or whatever. And you have to understand, really, the complexity then comes in the way these things work together.

Right? So it's Yeah. How how much, interaction there is between those different parts of the network and how deep those interactions are. And, again, I refer to, to Russ White as I always do with these things, who's who's kind of the master at explaining these things. But he always talks about that complexity as being those those the the breadth of the interaction and the depth of the interaction as being what what adds to to network complexity.

But that is that's true not just in the networking technologies, but also in the tooling that you're using from an operational standpoint. So you just you just touched on this. And it's a really good point that you can have a dozen tools to look after all these things, and that's super tough because you don't you've got to then work out. Right? How does the end tool interact with this one to give an output and whatever else?

So, again, that that managing that tool sprawl is something that that's super important. Now back in my day here we go. Here's here's a history lesson again. There weren't that many tools. Right?

You know, you you literally had to to make them up as you went went along, to a lot to a great extent. But their networks were simpler. You know, back back in in the the nineties, before the world wide web, networks were literally contained within a building. You'd have servers would be just doing file services and print services. That's it.

You know, there there would be no real complexity in in what you were trying to deliver over the network because it was all about sharing resource. But, really, once the worldwide web hit, everyone realized, oh, man. The brains were exploded because you could now distribute applications worldwide if you wanted to. Yeah. And and that really is what started the ball rolling, the the the dependency on on networking, the, the ideas and the innovation around the delivery of applications really stem from that time.

There were obviously other other factors as well. But, and I think that's where why what we're dealing with now is so much more complex than what we were dealing with then. But but we also need the operational paradigms to to work with that. And I know I mean, this is something we we're definitely gonna have follow this up with another conversation, mate, because because, digging into that that automation piece a bit more. You're currently working your course for a service provider.

Right? Yes. You've got a very, very interesting perspective on the automation piece. That probably is is perhaps a bit more advanced or a bit more, a bit deeper than than your average, enterprise network engineer. But, just give us a flavor of what that automation looks like fit for you at the moment.

Yeah. So, I mean, it's a case of running running Python scripts, Ansible playbooks, Ginger templates. It's a case of of of, like I said, using other applications. So we've got things like Azure DevOps. We've got things like GitHub as well to be able to actually validate the configuration changes, make sure it's alright before actually pushing it.

So so this is this is basically all workflow, that's that's effectively predefined. Is that fair by by the tooling folk to to deliver standardization across across the the service provider. Right? Yeah. So especially when when you're talking about, our core devices, the the configurations are are pretty much templated.

So if we want to make any actual changes, we end up having to actually update the specific templates. So it's like one thing that that we've put that that I've done recently is, we've just had a a bit of a bug with, some syslog files on Juniper's. So what what I've had to do is update the Jinja templates. We, pushed that out to our live devices, made sure that it was all up and working. And then it was then obviously, once we've validated it and made sure that it was okay, we've checked the lab device, we've made sure that we can obviously see the config on that device after doing the push, then we roll it out to production.

But then when it's actually rolled out to production, is rather than it just doing the whole estate, essentially, we'll just push it to a singular device. And then what we'll then do is we'll then but we we will manually validate it just, obviously, because you still need to have that manual intervention. Even though it's all automated and it's all templated, there needs to be a manual intervention to make sure that you are seeing exactly what you expect. And then once it's manually validated, then you can start pushing out to the rest of the estate Right. For the the specific change.

So that template will be what in a version controlled repo and, you know, this is, of course, what we're learning as as through our through our normal education that that this is, you know, and get somewhere and and, and version control and everything. But then you have these pipelines around that that repo that are delivering these changes into, first, your lab environment, then as a one off to to one device in your production environment. And then when that's been validated, you can you can open that change up to to everywhere. Right? Yeah.

Yeah. Exactly that. So so and, when we were talking earlier, obviously, you know, this this I'm assuming this pipeline is built and and tested and and whatever by a development team. There there'll be people look after that stuff, that they'll take input from from the network folk to really fully understand that. But this is this is, you know, formally developed as a as a software solution for for you guys.

But you mentioned that you are doing your own ad hoc typescripts and and stuff. Now what what would that be for if that's not for pushing config? So with regards to sort of, like, the ad hoc, Python scripts, it could potentially be something like if if I'm looking to do, an IP audit. So we've got we've got store so many prefixes that we need to check through. We're not gonna check through each device.

So so what we will do is basically run an m up on on run an n map on the specific prefixes. We'll see which are responsive. Then what we can do is then we can essentially put all of the horse into, like, a horse file. And then we can essentially just create our own Python scripts, run this against the host file, with the, device names in. Yeah.

And it'll basically come back and say if it's responsive, if it's not, what the IP range is. So those are are sort of like other little side tasks rather than working with the main. But I suppose these are key operational tasks. Right? That that what you're basically doing is making more efficient.

Because once upon a time, I would have sat down with a with an Excel spreadsheet and been SSHing into every one of those things to try and find what what those you know, what that information was. And I've I've recorded it in a spreadsheet. And I guess that's the other thing that that you'll you'll be doing now, right, is using, more appropriate tooling, I suppose, for actually storing this stuff. Yeah. So, I mean, essentially, when our script is run I mean, I I use VSC, so I'll just put them into a file in VSC, and then we we use, like Jira just to keep on top of task update.

So Sure. Potentially just to upload a file into the, into the Jira task Yeah. With all the information in there rather than on a spreadsheet. And for the for the network itself and the devices in the network, you're gonna need a source of truth. Right?

So what what kind of are you we're using NetBox? Or Yeah. Yes. I'm sorry. We we use NetBox.

There we go. So, so I guess, again, you've got that ability to script against that as well. Right? API driven. So you can you can do checks against the the source of truth from the network and and bring be able to pull all that information together.

Yeah. I see what IPs are in there, go off specific device names. You can potentially start deep diving it more with with more information like IPs and VLANs if you really wanted to. But just even based off this conversation, just like it it's genuinely mind blowing how fast technology has moved forward. I mean, it's been mind blowing for me, and I've I've been in the sort of networking industry for about 8 years now.

Right. So, I mean, I bet from when you started, it's literally been like a full full life cycle. Don't don't even start. And and it's and, you know, I mean, I I always joke about being the the the network old dog, you know, trying to trying to learn new tricks and stuff. And and it's that's the point here.

Right? As and and I find this with networking folk generally. Right? Is that we are very, a, open to to to looking at new approaches and new ways of doing things. And, b, we're so obsessed with the technology and learning it and staying on top of it.

And, you were used the word earlier, actually, when we were talking before we started this. Giddy. Right? That that's Yeah. We get.

We just get giddy with it. And do you know what? That is that is how we are. Right? Yeah.

I I just don't think there's any other way to describe it. We just we we get obsessed. Yeah. I mean, it's it it's just obviously you start on one thing, but then it's just like, oh, but this is coming out. So so I I just let me look into that.

And then literally maybe a couple of hours later, oh, I've just seen that. And then you kinda come to realization. You're like, I haven't got enough time to look at all these certain things. What am I gonna do? And it's just like yeah.

I mean, just just being able to work on on the automation side of things because when I first started, it's only recently in my current position at the moment that I'm kinda getting into all all the automation side of things. So, like you say, applications, things like that. And it's just, like, being able to see your your script running it, pull back all the information that you're requesting it to. Yeah. It it's like it's like the dark art as you could call it.

So so is that is that your future then, do you think? Do you think that's where you see see this being going forward? Maybe. Maybe not. I mean, I'll I'll be I'll be completely honest with you and say, I'm a networker kinda through and through.

Yeah. I feel like it's kinda my bread and butter. I mean, luckily still, like, I've still got fire in my belly. I still love learning about all the new technologies. I mean, at the minute, studying from a JNCRPSP, it is like I've just started looking into multi multicast, but I'm kind of I'm kind of at the point where I'm like, I don't know whether I need to be excited or kinda scared because it's such a huge topic to look into.

I think the 2 in equal measure, is a is a good good approach. As it does sound like you've been scarred by the c plus plus experience still, mate. I'm I've gotta tell you. Yeah. I mean, I I I I I overdid it for a week as well, so I I don't I won't like to think if I stayed any longer.

But a 100%, I mean, as soon as I've got my my IPSP, I mean, I want to start looking into this more. I mean, I I follow certain people in the community who who are doing a lot with, like, Ansible. So I think it's IPV 6 Sean, Sean Kavanagh. I understand. Yeah.

Yeah. He's doing a lot with Ansible. He's he's putting that up on Twitter. But just being able to to see, like, the benefits that it can bring. And I mean, you see it nowadays with with how many net DevOps engineers that that are being hired and and brought in to obviously make the network and make the business more efficient.

But yeah, I don't know. May I'm I'm I am gonna start delving more into automation. But yeah. I think it's I think that's a healthy attitude. I think when it boils down to it, what you're, being a networker, you want to give the best network service you can to to people who pay the bills, basically, because because without that, you know, you won't have a role to play anyway.

So so that becomes an important part of it that that this isn't you wanna make your life easier and better for yourself, for your colleagues, but you also wanna make sure that the business is getting the the service it it needs. And and I think that that balance means that, a, you you can't avoid but get involved in the automation space. But Yeah. Think of it as a tool, and think of it as as, you know, how do I how do I use it to get where get what what I need it to be? Unless you, you know, unless you wanna go down the path of becoming a software developer, and then it's a whole different a whole different ballgame.

And I think there's there's a lot of people are still treading that line, trying to work out, you know, what which way am I gonna go? Because you do see people get get completely consumed by the whole dev net thing and whatever, which is fantastic for them because that means that they've clearly decided that's that's a path. And the more developers we have with network experience, the better, you know, in in the sense of developing tooling. But, yeah, I think it's I think it's opened up a lot of doors. I think if if I think if I had been looking at it now, I'd still probably have says done much as you.

So I was kept to the networking side of things, but but always kept our mind open. Yeah. A 100%. I mean no. I think I think you said it.

You you sort of hit the nail on the head again. I mean, but, obviously, you've got your networking, but then you've you've got your your software as well. Yeah. But it's how can they be combined for for to to make better results Yeah. Essentially.

Which is what we're all because they work they work. Exactly. They they work hand in hand. Yeah. So And and I think that the the network tooling has always been difficult to get right.

I think, certainly, over the days I've been using using all of the tools. No. There's never anything been exactly right. You know? There's always been things that we could do better, things that we could apply different logic to, or whatever it was in order to to sort of get it closer to what we needed it to be.

Now we're in a position where we can be much more flexible about that to apply proper real logic to, to that tooling. It's opened a lot of doors. But we still need the support and the love of our development colleagues to to help us, deliver that service. I'm conscious that I'm burning through your time, Meehanay, so I I don't wanna keep you too much longer. Have you got anything that you would like to leave us with?

No. I I mean, based off this conversation, I I would like to think that there will be another episode where we can actually start Yeah. Absolutely will. Deep deep dive in more so rather than because he's just kind of scratching the surface, but no. Thank you very much for having me.

That's an excellent question. Yeah. Always good to talk. But, yeah, we will definitely, line up, line up another recording session to to dig a bit into that service provider automation because that's, an area that, that's still, yeah, clouded in mystery, I think, for a lot. Yeah.

So I think it is. Awesome. Alright. Well, thank you for your time, my friend. We will speak again soon.

Definitely. Thanks, mate. Cheers.