Folks, good morning, afternoon, evening. Welcome wherever you are. We're you're here for the, IP fabrics community fabric webinar where we're talking today. Well, the title is what has network automation ever done for us? Now some of you are gonna get that reference.

Chances are you may well have a a British influence if you do. And guess what? Our panel has a very British influence today. We've got, a number of people gathered from the the the great and the good, in, network automation. And I'll I'll whisk quickly around everyone, but you'll you'll get to know them all, no doubt, over the next, the next half an hour, hopefully.

We have Charles, Greenaway, who is, a customer CTO with BT. Charlie, is that fair? Yeah. That's right. Yeah.

Hi. Excellent. Hi, Ray. Thank you. Stuart Clark and the reason I'm pointing like this is this is where you appear on my screen above me.

So Stuart, who, of course we all know and love from, Cisco DevNet. Thank you very much. Lovely to be here. Not sure if that's a love bit though. Always, mate.

Always. And and, of course, we have, Eloise, from, Eloise, Bloomberg. Right? Working out with them. That's right.

Nice to be here with all of you. Awesome. So, yeah, I talk about a British, influence. Of course, she works in London. We've seen not from these fair- Good enough.

Not quite from these fair aisles just yet. Hey. The guys, as we know, the network engineering community, we've spent, oh, would you believe my phone rings at exactly the wrong moment? Good grief. Get rid of that.

Apologies. There it goes again. I'm just gonna stamp on that. As we know, the network engineering community has spent an awful lot of time over recent times and and Stuart you're you're as as responsible for this as anyone I suppose learning about all these crazy network automation ideas of programming, of DevOps, of Ansible and all this good stuff. But for a lot of people, I guess this is theoretical, right?

What does actual network automation really look like and how has it changed the working lives of those who practice it? And that's why we're here today, guys. We're here to talk through some of the ways in which network automation specifically has changed from what we do from being, you know, CLI jockeys to to really using these these programmability ideas in order to deliver capability into the networks that we support. So what I'm gonna do, if it's okay with you guys, I'm gonna we'll we'll sort of do a rotation. We'll go around the table and we'll look at some of the areas, take one view at a time, look at some of the areas where things have changed for you and we'll just have a bit of a free for all discussion if that's okay.

Yeah. Excellent. Sounds good. Awesome. Awesome.

Alright. Well, Charlie Charlie, let's start with you. I mean, as as a as a customer CTO and BT, I mean, just give us a fill us in a little bit about what that means and then perhaps, if we can sort of take that into when network automation has changed, what that that actually, does day to day. Sure. So I I'm working in the area which is where, say say you got a customer who's, you know, they own their assets, they own their their infrastructure, but they want BT to manage it.

That that's the area that I work in. So they've offloaded the risk of the moves, ads, changes, and runs, of that environment. So so that's the area that I work in. Whereas as you'd imagine, BT has other areas like the global network, which has got a high degree of automation in it. I don't work in that bit, so I'm working more more on the the the customer driven side of it.

So, network automations come in about really about managing risk, you know, doing things fast and and and managing the risk of that. So, there's loads of examples I could give, but, for example, with, you know, a complex change. I was doing a change for a customer that that does some stuff for national infrastructure, and, the change windows that you get are very tight. You might get 2 hours on a Sunday morning at 2 o'clock in the morning or something like that. And if you screw it up, then, it affects people in the morning.

You know? It becomes a news item. Right? So that's that's something where there's there's risk. So, if if you're gonna do a change or or especially if it's a a sweeping change, it's like, how do you do that change consistently, and how do you check that the changes work?

So how do you do your your pre and post checks rapidly so that you can you can remediate fast as well? But in those environments, you're going into it with a lot of planning. You've got all your decisions made in advance. You you know, if this happens, what do you do? And you try and anticipate as much as you can.

And where the automation kicks in is that you can you can test for those different things. You know, it's like, if this has this happened? Has that happened? Has that happened? And figure out what has happened where so that you can respond.

And, hopefully, no one knows that you've been there. You know, no one's seen the change, and it's it's seen on the It's not just it's not just about pushing stuff out, but then validating that the right fit or or that the right outcome has come from pushing stuff out. Okay. Absolutely. Is what you say.

Alright. Okay. Absolutely. So so you know that the service was good when you started, and it's good when you finish. Yeah.

Yep. Which is always the thing, isn't it? Everyone wants to walk away from one of those change windows without, without having to to sort of work the crazy hours to try and fix everything, which I guess we've probably all done at various various times. But Yeah. I can certainly imagine that, yeah, automation changes that game completely.

Right? And and I suppose in terms of actually operating the, operating the service itself and providing a way of of giving that feedback to to customers, I suppose, that that shift is shifts as well. Right? Yeah. That's right.

So, one of my colleagues, he's, you know, he he he wrote the tool that, looks for changes in a customer's environment and and runs that every day. You know? So, where you've got environments, especially now with with APIs being more exposed, you you expose more of the change down to the customer, so you empower them. Right? You you empower them to to run their own things, but you gotta do that in a in a particular way.

So that's managed through protection and identity. So, you know, we we can't have someone you know, kind of a customer making a change, breaking something, and then we compensate them because they made a change that broke their network for for for a new contract. So so there's an element there of of making sure that, you know, we sweep the estate. Like, with ACI, for example, the the code they wrote sweeps, the fabrics to see, has there been any changes either made by a person or by another automation system? You know, like someone's done something on VMware or Right.

Firewall said block this or some security events happened. So so we see that, and we have visibility of that. Now there's other systems that do that kind of thing, you know, that that meant to be tracking change, but this is absolutely checking that that nothing's been missed. And and if something has happened, we've got a very quick view of of, oh, this happened at this time by this this actor, and then, and then bring that bring that to the fore if there's an incident that we need to manage. Yeah.

And I guess I guess, as well, that's that's gonna be very much tailored to what the customer requires of the service. So, really, it's all about making sure that the that that you're delivering the optimal service to that customer at that point in time. Yeah. Yeah. That's right.

And and I guess there's there's another aspect to that. If if a customer doesn't care about that config at that gory detailed level, you can kind of abstract some of this stuff away as well, right? And start looking at self-service and workflows and blah blah blah. Do you get to to play with that side of things very much? Oh, yeah.

Yeah. For sure. So, being able to take as much complexity out is is really important because, what what that what that does is it actually opens up the user base. It means that you can move away from just having, you know, really smart network engineers driving a project, and you can devolve stuff down to say you know, let let's say you got 10 engineers, but you got 200 project managers. Right?

If you can empower them to self serve, by limiting the choices, you know, give them, like, an a la carte menu, so to speak, and productize stuff in in that environment, then then it empowers them. It it does 2 things. It drives volume for for, consumption of the service, which is which is good for the provider, but it means that the customer's getting getting their job done. Right? They're they're they're moving faster, and and speed is is better than efficiency in a lot of in a lot of things.

Yeah. And I guess I guess that that it comes back to almost what what the part of the reason why we deliver networks anyway is is to make sure that we're we're giving them the maximum opportunity to deliver the application traffic when they expect it, maximize the availability of the IT systems. Right? And and that that I guess is is a way of of of, like I say, creating that that uptime basically for for for them to to be able to to make the changes they need to make, but but not have to be concerned with, the the the gory details of how it how it goes, how they're implemented. Yeah.

I mean, if you can separate running the infrastructure from the user experience and improve the user experience, then people are gonna use it more. Right? Yeah. So if you've got trust and confidence in it, maybe Yep. But the thing the thing you gotta remember is that, you know, with great power comes great responsibility and all that.

You know? But, you know, videos yeah. We we with with automation, you can you can mess things up pretty quick. Right? So Yeah.

So you're gonna make sure that if you're introducing speed and and repetition, that you're also introducing risk controls as well. You know? So how do you how do you achieve that value without introducing more risk? So your testing program becomes really important there. Yeah.

And I think that's a lot of the reason why, you know, especially within the enterprise environment, a lot of companies and organizations were very slow to adopt this. Certainly, some of the early experiences I had with automations within Teams was that we didn't want to adopt this because too many times automation had run. And it's to your point, Shadi, is that, you know, you can take a network down quite easily when we talk about network automation. Just, you know, simple one line command. You know, it's happened to every engineer whether it's spanning tree or not putting the AdWord on switch port VLAN, you know, that that thing or, you know, something worse for BGP.

And then, but with automation, you know, you're pushing out as such a of a, you know, a wider scale. You know, you're automatically connecting to a lot more devices, so it's a lot easier to, you know, to bring down, a a network in that sense. And some of the, you know, some of the earlier pieces that, you know, certainly, I saw in my crew was doing, you know, certainly automation at scale. The the the first few times when this was run, there was, you know, a number of things where services went offline for periods, and we were still doing rolling out automation at sort of, like, 2 in the morning at a quiet period because, you know, we tested in prod. It went straight into the into into the prod, you know, things.

And it was just simple things like automating things like load balancers, shifting things around from devices for devices for or or pools, things for capacity and things. Things were really laborious changes, in moving off single slash 32 IP addresses from different pools to different files and redirecting traffic globally around. You know, those mistakes kind of happened even, you know, even though we were doing some kind of checking, there was some unpredictability within that. And our our business unit really shied away from it Mhmm. To start with.

And this is why, you know, when we went into back into automation, we had to go in and we had to go into the company and the, you know, the decision makers to say, this is our plan, and our plan had to be a 100% kind of rock solid here because we couldn't afford customer downtime, you know Yeah. At all in in that circumstance. Oh, Eloise is, on mute. I'm sorry. Go on.

I think, that's a good point because with network automation comes big responsibility. Right? And I think for me, coming from a NOC environment, that's my first that was my first desire to automate because you are, you know, looking at 100, if not thousands of circuits or, you know, interfaces and links that you're looking at. And to troubleshoot very similar protocols, you know, over and over again. I was like, there there has to be a better way to do this.

You know? And it kind of was this major shift in, like, thinking, well, this is what a network engineer was and what a network engineer needs to be now because of just the scale and the complexity of of the systems that we're working with at the moment. I think I think you've you've introduced another magic word there, complexity. Because for me, it's as much about the fact that you're not doing the same thing to thousands of devices that are all the same. You're doing you're doing that, but then you're doing other elements that all need to tie together.

So so you've got this this this, you know, this this combination, if you like, of different network domains that are built together and interact with each other in order to deliver a service, you wanna make sure that you if you if you make a config change here, it doesn't just, you know, make it doesn't impact stuff what's going on here. Mhmm. But what about all the other network domains as well? The interactions have to be right as well. Right?

So this is where you're talking about the testing stuff that that Charlie mentioned before and about that understanding, isn't it, of of of the end to end? Yeah. For sure. And that's that's sorry. Go ahead.

No. I was just thinking that, you know, that's that's why, like, now we understand the use of APIs within, network automation. You know, we can use different programs and different capabilities of different systems to achieve something much greater. Whereas before, I think, we, you know, with the network engineering, certainly, there wasn't that understanding how we had this problem, but how do we solve it? You know?

And that's why I really love, like, the Cisco DevNet, you know, kind of, you know, world is because they are educating, you know, the global network engineering community how we can solve problems. And that's ultimately what we wanna be doing as network engineers, right, is is solve problems for our customers. Yeah. I'm sorry. Charlie Yeah.

I was not I I was just gonna say that when when I first got into networking, it was, it was it was actually more about directed graphs. So it's all about those kind of systems about how things in interlink and interoperate. And I don't know if you remember HP OpenView, you know, a couple years ago, like a a very early network monitoring tool, like, 20 years ago. Well, I I I yeah. When I was when I was doing my degree, I I I rewrote, a a network auto discovery tool.

Yeah. And the idea was, how do how do you, understand the system as a whole? So rather than managing individual nodes, there's context. It's like, how do you get that context? And then with context comes a greater understanding of the system.

And then, and now as things have moved on with, you know, you may have heard of the term digital twin, for example. Yeah. How do you get a a view of the system as a whole and how one thing interacts with another? Being able to ask questions of that, I think, is gonna be increasingly important. Yeah.

Because you can ask the question of what's happening now, what do you observe now, But, really, the the future's gonna be in if I'm looking at code and all the interactions, you know, what should it be or what could it be, and do they line up? And and do they line up? Yeah. I mean and, Charlie, I I do apologize. I know I didn't said I wasn't gonna mention any product, but, you've you've kind of hit on part of the reason why IP Fabric actually exists, right, from a network assurance perspective.

So at that point, I'm going to let that go, and and we'll move on. But, but but you're you're you're absolutely right, of course. And I would say that. But I suppose I mean, Eloise, you mentioned, DevNet, and obviously, we've all got, a lot to that we've learned from from from the DevNet process and everything. Stuart, you can't have even begun to imagine that it would change your life the way it has.

Right? No. No. It it it hasn't. I just can't you know, thinking you think back and the, you know, the parts and the process, like, you know, and how I joined DevNet as well was just kind of very, very strange in that I I became aware of DevNet through social media, and I tried to learn automation through brute force.

Like, I've we all do. We try to learn think about brute force and unfortunately I wasn't smart enough to to learn it through brute force. You know, like so many people do, you know, a lot of people, you know, just refer to documents and away they go. And for me, it had to be more of a structured learning process. I found that's the best way for me to learn, you know, and, you've seen me back on consistency, consistency, you know, consistency, and that's something which I really do stick to.

And so not just, you know, learning coding or different things. It's in every section of my life. And, yeah, I came across DevNet, and it's, you know, thought this is just great, you know, from an outside perspective and then started talking with the team internally, to the to the leadership and the people on the team, you know. Because because you were at Cisco already. Right?

Say again? You were you were at Cisco already. I was. Yeah. I'd already been with Cisco sort of 5 years at that stage, and we started automating, you know, 2 of Cisco's biggest global networks, and that was really great.

But what I found was is that, I needed to learn deeper a deeper understanding of, you know, out of automation, all things like Python and the tooling because, like I said, I just kinda brute forced it. And that gets you so far. But having a greater understanding of how and why you're doing something rather than I'm tick typing this just because Joe told me this is the way to do it kind of thing. Joe being a fictional character, by the way. And so so I I spent a year kind of before I joined DevNet just going through, you know, DevNet's materials and running labs and the pieces before June, and, you know, joining DevNet and then, you know, join DevNet.

And I mean, you know, that was such a great opportunity for me to then start creating content for DevNet and speaking for DevNet. And then the momentum started picking up and, you know, when we went in when we started working on the DevNet certifications, it it I mean, DevNet was big, and then we started doing the certifications and it just exploded. Yeah. I just went like a it went like a rocket ship, which was just so such great honor to be a part of, you know, that entire process as well. Yeah.

That's interesting because before DevNet launched this big 2020 kind of campaign, right, get your certification, you've got 1 year, and then you get a special badge, and who knows what else. I was there was already a course on, the learning network that was called dev ASC. Mhmm. I think it was that was like the and I tried to get access to to study it, but I was kind of still busy doing, like, foundational network training kind of. So and when DevNet came out, I thought, wow.

Like, the this is like when the CCIE kind of came out and everybody was like, Cisco is so great. You can earn so much money if you have a Cisco certification. This is that time in history where you can get on the bandwagon, right, of something that's still in its infancy, and you can grow with it. And I think what's so cool about automation, not just, I mean, from the Cisco perspective, but with automation is that it's something cool that an engineer can do. Right?

We all wanna work on exciting, interesting projects. If you have the skills, it opens up opportunities to work on more exciting projects. But it's also you know, what I've seen is this there it's been a shift in people who want to get on that wagon and people who don't, people who thinking, like, we are here to we wanna learn automation to take their jobs. You know? We're not gonna work on the CLI anymore.

There's but what the more I work and the deeper I get into automation, the more I realize that it's it's honestly, and Cisco has coined this, but it's it's an extra 2 in your toolkit. And for the next gen next gen engineer, you're gonna have to have these skills. Right? But just to just to kind of show showcase kind of what learning automation skills, and I'm still a beginner, basically. I mean, I got my cert last this year.

So I'm still learning, but already, just because of understanding and knowing this the fundamental topics, you know, I've been able to move into a really cool team, a really cool job. And at the moment, like, stuff that I'm working on is resilient. And and earlier, I think Charlie was talking about testing our systems, you know, with the the growth and how how how systems are becoming more complex, we testing our network in a lab is not good enough anymore because we test and we we bring it into prod, but we always somehow, there's real world scenarios that we can never ever plan for. And that's really where this, like, resilience experimentation or chaos experimentation really comes into, that we can learn about our system because we're now injecting failure in a very controlled way. It's not in a chaotic way.

Injecting failure into our system with certain ideas, like saying, okay. If link a we we've got 20 links. So our our application should be completely redundant. Right? The if one link goes down, it should be fine.

Let's test how, you know, redundant how resilient our system is. Let's take out 5 links. Let's see what happens. Because a lot of time, we have application issues, and people blame the network team. And we're like, no.

It's not the network team. It's a huge not that work. Martin. No. Dennis.

Yeah. It's always Dennis. Exactly. So but how can we prove this? Right?

And how can we do this in, in a way that, you know, the business will actually approve of? Because you can imagine, you you can't you don't wanna bring the system down. Right? So you you don't wanna lose your job. So that's another kind of thing.

And I just want to kind of highlight to people who are listening is that there's so many new avenues of work that automation opens up for people. You know, don't think like one track, you know, just automating whatever on the network. There's so many other opportunities. No. That's a that's a really interesting point because because because there is that sort of classic network automation equals configuration template in push, policy push, whatever Yep.

Mindset, and yet there is so much more to it though, isn't it? Because, I mean, I I I think of of coming from from a network design background and have it and being about building networks to be to be managed and operated to to maximize availability, you then said, well, actually that network data is great in the network, but also why not integrate it with other things and and have messaging and chat chat ops and and and all this sort of good stuff that you can you can basically change the way that you operate a network altogether. You still need and as you rightly point point out, Eloise, you still need that that networking knowledge because without it, you'll never get to the bottom and understand exactly why things are doing the things they're doing. But to have to then be able to use the the capabilities that are brought from a from a programmability perspective changes the game completely. And I think what's the opportunity here is that you you are able to get a seat at the table with these skills.

So I'm not a CCIE, but now I'm working with people that are CCIE level. So I it's it's a win win for me. You know? I'm learning from them. You know, and I'm also gaining experience.

So if somebody wanted to Well, I I was just gonna say that the the dynamic of the network and where the network is is is changing as well. And there there are bits that are opaque and bits that are provided by services and service providers, bit that, you know, provided by cloud providers or sub, you know, 3rd party contractors and all that kind of thing. So, as these systems are growing, you know, we're getting organizations that are investing in buying in capability to do something, to to get speed, you know, to get that value faster. But then, you know, how do you then check that it's deployed as required? You know?

So if you're designing an application to say the application is resilient between 22 locations, then you find that someone's nailed up an IP address in one site and the thing doesn't fail over, you know, that that kind of con continual verification Yeah. Is is important. Otherwise, you find out, and the first person that tells you is a customer. Yeah. And that's that's awesome.

That's the worst place to be, isn't it? In front of a customer trying to explain why all those cool things that you put in place to to save their service have collapsed because of one little part somewhere deep in the, in the automation and it's gone fair shape. So I guess, I guess, Eloise, that was what, you know, when you talk about your resilience engineering, that's that's it, isn't it? It's all about understanding those those relationships, those interdependencies and and then being able highlight where where they can go wrong. Exactly.

You know? And and the ability to kind of be able to identify root cause quicker because you understand those dependencies. Yeah. That's that's cool stuff. Stuart, I'm conscious I mean, we we we talk about we talk about the programmability stuff and all the rest of it, but there is, you know, there is a whole lot more to it.

Right? So Mhmm. So I know, there's been, a lot of focus recently and definitely on things like NSO and orchestration capability. What you know, has that had any impact in on on what you're doing at the moment and what on what people you you're seeing and what people are asking? Yeah.

It's funny because, you know, we were talking about this a little bit early before we went live. You know, automation isn't isn't exactly new. You know, people have been writing back scripts and scripting for a very long time. You know, I was, speaking at Lowna, a while ago. We haven't done any personal events for a while.

And I was speaking at Lownap, and I was there. And, you know, there's a a gentleman talking. He was, saying, yeah. Well, you know, yeah, during the late eighties. And I'm thinking, late eighties?

You know? And he's talking about this. I mean, expert in the field, you know, been doing this for for many, many years, and I've, you know, we'll have all have seen people writing bash scripts, expect scripts for a number of years. And these are great. And I used to work with some really talented engineers who would be able to instead of, you know, we're talking about logging into multiple devices, they just use a script and do it.

To Charles' point, they couldn't roll that back. There was a lot of times that couldn't get rolled back, so they had to get it right first time, you know, or there'd be, again, manual intervention. There was pretty much no checking going into this either. So once you went out into the big wide world and it was deployed, you know, it was a kind of a done deal. So you had to be really, really good at at at at at doing that.

And writing individual scripts to perform, tasks is great. It's time saving. As we know, it can be a lot it can be a lot more accurate. But then we start to look at something a lot wider, which is, to your point, is orchestration. How do we build this into complete pipelines?

You know, how do we put a lot of these things into here? So we think about this. So when we start talking about building, say, consistency across a set of vendor neutral data models across everything that we're doing, you know, within our, in our in our network and our back end and everything, like this. So, you know, we're implementing the entire service end to end, and we're standardizing everything that we're doing, and it's repeatable. You know, we're not just creating these kind of, the the snowflake.

Oh, we can we can do this. We can do this. We need to have that entire change model in place and that governance across the place. And this is where we, you know, start seeing a lot more use cases with, you know, SDN controllers, once you know, networks get to a certain size. And SDN controllers, I think for me, that was always the interesting bit when I started my automation journey writing scripts, and I was using, you know, Python and Ansible to to do this.

And we're using, like, a a back end like NetBox, CMDB to the store of devices. But what will Control is gonna do for us? You know? So we're talking about what has no location ever done for us. You know, you could say that.

And then in in the true spirit of the life of Brian, I could go, SDN controllers? You know when you ask that kind of question, and this is where, you know, we start to see, you know, the SDN controller like NSO, you know, SD WAN, Crosswork, DNA Center, you know, there's a whole a whole bunch of, you know, great controllers out there which can do tons more for the network. You know? So this when you look at the modern controllers, you take something like Crosswork, how Crosswork is evolving now. You know, we're talking about having machine learning and artificial intelligence built into this.

So it's very much thing and the way that I like to think about this is, you know, how we're kind of mapping the weather, and we're we're doing predictability models on the weather, whether it's gonna rain, how much sunshine we have, you know, whether it's gonna snow. We're looking about that from, you know, at the network now. How the changes are gonna affect our network? What's taking place within the network? And a really funny story when I used to work ISP level was, you know, we all remember the sadly, the the death of Michael Jackson, and that had a tremendous effect on the Internet.

You know, we see this. If you're working in any service provider, c c n CBN or providing Internet services, major sporting events, new funny cat photos, you know, go online, bandwidth starts to soar, you know, especially when they're streaming things like the Olympics. You know, we've seen this bandwidth just, you know, starts to be consumed across your Internet links and things. And I remember telling a customer once, and he was saying, oh, you know, we can't get to these sites. And I actually said to him, you know, we've seen a dramatic slowdown because and I'm reading about it on our, the sort of, like, you know, the the, what they used to be called, IRC channels?

Reading on them on these channels about saying, oh, yeah. Links are saturated. My you know, death of Michael Jackson, blah blah Jackson, blah blah blah. Had a huge surge in Internet. And I said to this customer, we've seen a huge surge in Internet traffic due to the death death of Michael Jackson.

And he started laughing at me and caught me up, you know, sending me that to me as fabricating stories for, you know, our ISP services being terrible. And I was like, no. The, you know, these events happen, but this is the kind of the predictability that we're looking at, you know, with AI and machine learning. And so if we are seeing huge say we're seeing huge capacity transit through, you know, start to transit to links. We need to add and bundle more links into that service, you know.

In the same way that SRE does this, when they start to see more capacity, they start to add more VMs in there. They have to do this, you know, and with their hybrid cloud inside. But, yeah, the elasticity. Exactly. They start to run into their Cloud instance, and they start to, you know, move traffic around.

And that's how we're also viewing the network. Now, this is when we're looking at sort of, you know, Cloud Native Network Engineering as well, and and building out this capacity. As we start to see things changing, and it's not kind of like, you know, 10 engineers piling all into this trying to go, yeah, I'm adding links here. I'm adding this here. I'm adding this here.

Our SDN controllers are now taking care of this. They're seeing the change, and they're putting more capacity and shifting traffic where we need it. And we see this with, you know, again, products like Crossroads doing things like, rooted optical networking as well, shifting capacity as we need this. So, you know, network engineers like me can sit back, drink more coffee, you know, and look at more cat photos. Winner.

It's interesting. I always think here about how, if you think about routing protocols and whatever that we've used traditionally to manage these kinds of things, it was always very much a distributed control plane effectively. Everything looked after its own immediate sort of view of the network, but everything was centered around the device. What you're describing there is is kind of lifting up a lot of that intelligence and having it from a central point where there's a a view across the entire network and understanding, right. Okay.

Oh, now I need to go do something over here because because I've I've I've hit a bottleneck or or an, I can scale things down over here because it's traffic's quietened down and and whatever. So it it it's a whole different world. Right? Because because we're so used to thinking, well, you know, OSPF will look after that or BGP will look after this and having to construct these kind of labyrinths of tunnels over everything in order to make, make stuff work. And now what we're saying is, well, if you, if you, you're augmenting that with this completely new layer of visibility across the the entire network to to to help then, I suppose, a layer underneath to automate and and make the changes that need to be made in order to facilitate.

It it brings with it a new a new set of problems that need to be solved as well. Yes. Right? So so when when you when you bring, okay. I'm gonna say some bad words now, but, you know, people frown upon the use of SNMP.

Right? But if you just look at, you know, look beyond the protocol as a distributed system. Right? You you're you are spreading the load across every device. Mhmm.

And then as soon as you move to a controller architecture, you're you're bringing all that data up to a controller. And and the question there is is is it just another server or an instance that's hosting that, and you're hammering it for, I don't know, 5,000 nodes worth of telemetry? Or is it is it, you know, a scale out platform behind it? You know, this is where Meraki is a good example. You know, I can you pull data back in linear time?

You know? So regardless of the size of the managed estate, can you pull that data back in linear time, or is it gonna get progressively slower as you add more nodes? Because they're saying yeah. Yeah. Yeah.

Mhmm. So so there's there's been so much focus, especially in, you know, you you know, VXLAN, you know, which covers most software defined networks. But there's been so much focus on getting the features working, getting traffic moving that for me, I'm looking at the in life operations, the day 2 operations. Can I get the data out fast enough? Can I can I if I've got a 15 minute window to respond, you know, to get an action plan underway, Am I waiting 20 minutes to actually just pull the data back?

You know? So we we've we've gotta we've gotta progress the automation story to make sure that we can actually automate getting the data out, turn it into information, and make real decisions. And and I guess this is where, again, that that sort of idea of cloud scale helps, right? Because if you deliver that capability in the same way you would a cloud native application, then you've got that ability to scale it out. You've also got all of the tools that can sit behind it, like the, the AI and the ML intelligence that you need to to deal with the data and manage it and handle it.

Sounds to me like we're you know, network engineers are gonna start turning into, I don't know, data scientists and stuff, you know, because I think that Well, they're not there, doesn't it? Definitely. Yeah. Oh, with Yeah. I think one of the sorry, Kyle.

One of the notes that I sorry. One of the notes that I actually made was, for today was the point of data extraction, data analysis. Because now with the system and with services being, like, spread out over such such a large, you know, infrastructure or architecture, you know, that your understanding of where things are, where services are at any specific given point in time, how how are services impacted, you know, when it it might not be that the application completely dies, you know, but you might see latency or some functionalities that aren't working for your customer that should be working. You know? And and that's the whole point, I think.

I know I'm coming back to the, like, resilience stuff, but I do think in all the time that I've been working with it, which isn't such a long time, but there's not really a lot of it going on in the network space. You know? There's a lot of application, stuff that's been written. But are we really do we really understand how what our network is doing? Because in the past, we had a topology diagram.

You know, we had a a Visio diagram, and we knew we could say, oh, yeah. This links to that. And we know exactly what's going on. And these are the protocols. And but even then it was difficult to troubleshoot.

Now, everything is everywhere. So, yeah. Go on, Charlie. You were gonna say? Well, I I was I was just gonna say with, you know, AI and machine learning, for me, I've I've not I've not done anything with AI.

Right? I've been looking with looking at machine learning because, you know, like, with NetFlow, for example, it's it became increasingly sampled, you know, because you couldn't keep up. And the the thing which got me looking into machine learning was that I could look at every data point. Mhmm. You know?

So I could say, right, I need to ask this question of of a 100000 data points. It's the same question. You know? Go go find out. And it was that kind of thing being able to train a model and then have the model work with with, you know, in a in a far more efficient way, but but cover all the data set rather than just sampling bits.

Which I suppose covers exactly the point that that Eloise was making before. Right? It's about how you how you can make sense of all that data in some shape or form, I guess, with, with ML, which obviously we we're talking very, very strictly defined cases, right, that that that you've, asking the ML to to work on. But it's just, it's almost like automation again, right? It's that this time you're automating an analysis rather than an actual configure piece of configuration or or retrieval of information.

So, gosh. Right. Layers and layers on automation. Oh, no. You you my head's starting Yeah.

You need automate I mean, you can't sift through data, like, for days. You know? The first time you do it, you're gonna have to kind of do it manually, but you're gonna have to start finding ways of automating. You know? So it I think, yeah, this the the roles of the feature is certainly gonna be super weird and hybrid.

That's that's that's very, very true. But of course, there'll always be that need for the for the network expert. Right? The people who I I'll hope so. Those those people who could get to the bottom of things.

Folk, I'm I'm just thinking we we're 3 quarters of an hour in. I'm just wondering whether you've got any other points you wanted to make before we start thinking about wrapping up. Stuart, you've been quiet for 5 minutes. Yeah. That was taken on board.

It's it's always great to, you know, to to listen, you know, to, you know, to the other experts, and I am I am told that I do talk too much. No. No. Never. Never, my friend.

Neither. Never. My wife says, do do you ever shut up? No. No.

I think, you know, all the points you're making here, hugely valid. I think you said, you know, as much as, you know, network engineering and all the, you know, the automation coming into this has changed in, you know, the last, you know, number of years. It doesn't show really any signs of of slowing down at all, you know. If if anything, it's gaining more pace and we're certainly seeing this within our, you know, communities. People are exploring into different other tools, and we're talking about, you know, not just doing, you know, CLI things with automation.

Now doing whole different things with automation. Loads of different great projects coming out. We see these, you know, from, you know, the definite community, certainly, the people that are contributing into, you know, code exchange and sharing things at, you know, some of some of our events is is just, you know, phenomenal what what people are doing. And, you know, I encourage everybody to get involved with those community projects and and start talking to other people, contributing into, you know, open source projects as well, putting in pull requests, issues, things like that, because we can you know, the you know, 22 heads are better than 1 Yeah. You know, contribute into those kind of projects.

Well, I think I think you've you've got some examples here of how how people can can learn from from their immediate peers. Right? So it's it's important to share, as much as we can. Charlie, any particular thoughts you'd like to leave people with or? I just wanna second the community aspect because all all the all all the work that I've been able to do and some of the ideas are are really building on the shoulders of giants.

Right? You know, people have come up with other ideas. I mean, there's there's loads of people out there, but, you know, notably, you got folks like, you know, John Caffobianco or Jeremy Schumann. Yeah. And the work that they've been doing.

I mean, you just look at their Twitter feed from the last 24 hours, and you'll see, wow. I've just done this. And I'm thinking, oh my goodness. Oh, god. I've gotta try that out.

You can't get back with the guy. He's a he's No. He can't. He's a machine. Yeah.

He's absolutely a machine. Also, you know, Jeremy Shulman, so, you know, stuff that he's been doing, which is Yeah. Yeah. And I've I've borrowed some of his slides to actually get a business case over the line in internally and, you know, you know, Chuck Black and David Bombal, you know, the the the stuff that they've been putting out and, you know, really giving out of our YouTube and on the community and the live streams and stuff is that that's the that's the kind of thing, worked examples that I can then build on. Yeah.

That's been really helpful for me. I guess, Eloise, you're you're just following that in that as well because, you know, you obviously do do work in the community yourself as well. So Yeah. I think what I what I would like to say is, you know, I when I joined when I started my blog and I kind of joined Instagram and I was on the whole DevNet Bandberg. And I think meeting so many people who are so enthusiastic about the same things that I am enthusiastic about.

It inspires you. It pushes you when things when when it's hard. Right? Because it's not easy to learn a new skill when you haven't done computer science in university. You know, it's not easy, but it is achievable.

And I think one thing that Stuart said that was great, you know, people put in pull requests and and all that kind of thing. I think for me, at the beginning, initially, you know, it was so hard because I had all these ideas because I was working as a network engineer in real time. But I felt so kind of out of I had the book knowledge about, okay, I can automate this, but you sometimes need a helping hand. You know? And I and I want to say to people, don't be afraid to reach out thinking that somebody might not even answer you on LinkedIn or, because that's how we met, Darren.

You know? Yeah. Sure. Sure. Put my bright hat on and, like, hey.

I I need help. You know? So ask for help. Don't you know? And that's the way you learn, you know, is by someone maybe showing you.

But don't let your good ideas go to waste. You know? Ask for help and see how your cool network idea could be integrated. You never know. Cisco might use it one day.

You know? You never know. True enough. Actually, it's it's interesting because because I was just thinking that the not the exact opposite, but but the the fact from from those who who are in a position who who have learned these things and who who are on, on the path. There's an awful lot of people who aren't.

And, and I think, you know, just, just something I see in, in our day to day is that that there are people who are yet to start on that journey. And I think all I'd say there is, you know, for for for those of us who are lucky enough to have started, bring those bring bring everyone else with us. Right? So that we're we're working together to to move the whole thing along. I think it'd be really it'd be a miss if we didn't and and let let other people learn from from the experiences of people like your good selves, and and the rest of the community generally, I think is is really, really important.

So community, a little interesting because community, community, community, and all that would be community then. So I think there's some bit of a theme. Yeah. There is. And I I I I see, Anas has commented on the Yeah.

Thanks for commenting on that. And and Ernest will testify, and I didn't realize I said this until I didn't realize I said this as much until he pointed out to me, and he said, this is Stuart always says we are all in this together. And I I truly do believe that. I really do believe that. And I know I think, you know, speaking to people, having their experiences has been the greatest lesson for me throughout, you know, my, you know, not just automation, but my entire career and stuff.

And it's one of the, you know, the great things, and and I am honored when people reach out to me, you know, at at DeafBlend, they say, hey. We're doing this and stuff. And it's great just listening to people, what they're doing, why they're getting stuck, the common use cases, what they're looking to learn, what's blocking them, and all of these things. And just hearing those stories, those real world stories, and then, you know, often, you know, if it's something I can help with, then we can take that to Cisco. And we can say, you know, hey.

You know, this is what we're seeing. You know, what's the what's the plan here? You know, are we looking to remediate this, you know, and then we can feed that information back and build this kind of collective loop to to all of this. The the beauty of it is as well, there's always people who have a certain type of brain will will be able to attack things in a certain way. Others will have others.

By collaborating, it means that you've got access to to all of that knowledge and that that experience and that and that way of thinking, I guess, which which is is a key to the whole thing. Right? What we're trying to do here, I suppose, is move networking along full stop. Right? We're not we we don't want it to sit still because, you know, it's it's been a certain way for a certain period of time, but we we need to to change, to adapt, to do all of the things we've talked about today.

I mean, these things could not have been done without having automation the way way we envisage it now. We wouldn't be able to to build the levels of availability and resilience engineering and all that sort of good stuff if we if we didn't take this stuff into account. So I think it's, you know, it's really, really important that that by working together, by taking people with us on on our journeys, then then, you know, we we all, as as Charlie said, you know, stand on the shoulders of giants. Right? That's that's the way to to progress things.

Yeah. Awesome. Listen. I'm gonna wind it up there because I think that's a really nice, really nice point to stop. Folks, your your I see all of your Twitter handles on the screen in front of us here.

I take it if you'll accept anyone to come and approach you. And I guess LinkedIn is the other place where people can get you just general general nods. Cool. Well, listen, I'm gonna leave it there. Thank you so much for your time.

It's been very cool. And we'll probably go on gassing anyway after the stream stops even hours, but now it's been really, really good to see you all. And if I well, I certainly won't be the first, but I'm sure I won't be the last either to wish you all, season's greetings, and, hope to see you all in real life very, very soon.