IP Fabric for the journey. Hi. Hi, everybody. Welcome to, episode 1 of For the Journey. This is gonna be a podcast recorded in front of an audience, kind of, in a weird way, where I'll be joined generally by network automation practitioners and thought leaders to discuss that real world journey towards the nirvana of the self driving network.

Now For The Journey is an IP Fabric podcast, the automated network assurance platform. And the plan is for most of our guests to come from the IP Fabric family of customers and partners, all of whom will bring their unique perspective. My guests this episode are Gilbert Moisio from NXO Digital, one of our French consulting partners, and Peter Spregardo, who's the VP for product management for Mytent Shop. Hi, gents. Great to have you with us.

Thank you. Thank you. Starting with Gilbert. Great to see you again, my friend. Would you mind sharing a little of your background for our listeners?

Wow. Today, I'm network and methodologies senior consultant. But, a long time ago, I studied mathematics and expert system, you know, the the ancestor of artificial intelligence. Right. One third of my career has been, as a system engineer, one third as a system developer, and he also served as a network engineer.

And currently, I'm doing, a lot of research on blockchain and web, free. Tool, and artificial intelligence. Interesting topics. Maybe we'll touch on those a little bit later. That'd be interesting.

Thank you, That's that's great. Peter, I know you're relatively new, in your role with Itential, but you've got a real pedigree in the network automation space too. Would you like to introduce yourself? Sure. Absolutely.

So, yeah. So currently, you know, currently, I've recently joined, Itential, as you said VP of Product Management where I'm kind of overlooking overall product developments and strategic direction. But as it relates just to network automation, I've been doing this I kind of been living this world for almost 10 years now. I can actually date myself all the way back to about 2012 is when I really started on this network automation journey. And back then, it was really starting this journey more from the kind of the vendor side.

And having left that world, I went into the software world and had the distinct pleasure to join an early stage startup called Ansible and really kind of drove them into the network automation space and spent a long time there, really kind of cultivating network automation and specifically what Ansible did you know, in in that field. And so, yeah, I've had the distinct opportunity to really kind of watch this whole, automation network automation concept really kind of play out for the last 10 years and and be a key part of it. Awesome. Well, it's good to have you with us, my friend. And hopefully, you can bring some of that insight, the both of you to, to what we're talking about today.

So as you know, IP Fabric is associated with the idea of intent based networking. In particular, obviously, it's supplying that network assurance capability to the, to to really provide the checks and balances, I suppose, to ensure the network is doing what it should be doing. So today, I wanted to talk about fulfillment, which is in a in a intent based network, that's the bit where we're talking about the configuration, the automation, the orchestration aspects. The kinds of things, I guess, that that everyone's talking about from a network automation standpoint these days and and very familiar to network engineers. Now we're seeing and hearing so much about network automation, particularly in the the social media channels and and all the things that are named squarely at network people right now.

But it's always focused on programmability. Is that the right place to start, do we think? Gilbert, what do you think? Oh, you know my way of thinking about network automation. Network automation is nothing new to me.

As far as I can remember, I have always used network automation. The the the difference is that now there are some of the DaaS protocols and data formats. But if we limit ourselves only on this world, it's to sound slight buzzword. I prefer to speak about NetDevOps And, perhaps, Anton Bus Networking is a way standard standardized way to implement NetDevOps. But NetDevOps is something that include tools, organization, methodologies, and new people profiles.

So it's I prefer to speak about NetDevOps, not just network automation because all network engineers such as me, always used network network automation. But without the the the the standards that we have today, of course, it was nothing, but it's nothing new for us. I I must have yeah. It's something that's that's familiar. Peter, I suppose, specifically, you know, thinking about from an Ansible aspect and everything, things that get taught to network engineers quite frequently.

Right? But that doesn't it doesn't stop there, does it? No. Absolutely not. You know, I think that, you know, in in you know, the grand way that we always tend to do things, when this whole journey started, you kind of get that pendulum swift, and we go very hard to the extreme, Right?

And that extreme became, you know, that that network engineer suddenly had to become developers and programmers and write code, and and and those aren't necessarily I mean those are good skills to have, but they're only a piece to the puzzle here. And I think that when we think about network automation and where we need to kind of bring that back towards center now is this idea that network automation really needs to become more of an act of doing something, I'm sorry, it needs to be more ingrained into the way that people think about solving as opposed to an act of doing something, right? We kind of swayed so far to this idea that automation, as I've talked about in other forms, it has become a verb, right? It's something I do. And that's not what network automation is really all about.

It needs to be more about a state of mind, a way to approach solving problems. And it needs to be done, and applied really as much as possible. It doesn't necessarily have to be for big complex problems. You know, you can use these mindsets and these skills to solve little things. And I think that's really where it needs to where it needs to go.

It's it's interesting, isn't it? Because there are of course, there's there's different ways of approaching it as well. I mean, you've there's different tooling. We can talk about the programmability. You can talk about, the answerables of this world.

You can talk about SDN. I mean, in terms of having a controller is is is an automated way of pushing config to devices. Right? You can even talk about policy engines for for, you know, retrieving, pulling configuration, if you like, into devices in an automated fashion. There's so many different aspects, I guess.

And and and, of course, there's there's there's, elements where you're not actually touching the configuration at all. You're just you're you're giving almost an intent or or or kicking off a workflow to make stuff happen. So, I mean, there's there's lots of different approaches to this. Right? I mean, I Oh, without question.

Yeah. I mean, I mean, I guess and I guess that's something that you're seeing, from from your work at the moment with iTentia is that that that coming together of lots of different work streams to achieve an outcome in in different ways, right, multiple different ways brought together. I I think that oh, go ahead, please. No. Go go your way.

I I I think that we have to to speak about the the objective because, the goal of the network is to be able to to scale at the same speed that the system and the applications. That's why we are trying to to do today. And when we speak about network automation, it's not just to to configure the first time the product. It's it's not just for that. We we we we use the the this way of thinking a lot of years ago.

But today, we have to build the networks that is able to scale really at at very high speed. And a network project does not stop after its deployment. It will continue to leave, thanks to the Internet DevOps Organization. Yeah. I think, and and I guess, yeah, it's that business outcome, isn't it, that you're trying to achieve?

And that's not gonna involve just, I don't know, pushing a VLAN across a a bunch of switches, is it? It's about bringing together multiple streams, I guess, of of configuration and automation. Peter, you were gonna say? Yeah. You know, I think that that this touches on a really good point, and and this kind of, you know, just exemplifies what I was I was mentioning earlier around automation.

And that is, you know, automation, when it becomes a mindset, a way of doing things, you start to realize that automation is more than just laying configuration down on a network device. Right? There are all kinds of opportunities to embrace automation well beyond just simply configuring the device that gets into some of the day 2 operational natures of how we run infrastructure. Right? Everything to to thinking about, you know, how you do things like like using automation to to triage network issues, to, you being able to use automation to create self document networks, to there's just a whole plethora of use cases here you know, that we can start to explore, you know, when we really embrace this idea around, automation and and to kinda take it to to a whole another level here.

Sure. I mean, that's and that's something that we see a lot with with our customers is that that because we we go ahead and and gather a load of data, that data is not just useful for for configuration or or even for testing that that that changes have been delivered properly. But there's a whole load of other places where that data is useful. So why not embed that into your operational ecosystem and push data out so that you're not just automating the network itself, but the operations of that network as well, Right? To to get a visibility, to get an understanding of what's happening, and to get that broader view.

And I think that that is a really key point, here. I I guess, you know, the the the automation in itself, though, is you know, it needs a whole load of other things to function, not to wrap around it. Right? So so you've mentioned the the fact that it's not a stand alone thing, and and, Gilbert, you mentioned the the the ideas of of DevOps. I guess what you've got here, you've got to think about process.

Right? You've got to think about about, you know, all of those sorts of operational aspects as well. Any more thoughts on on that side of things? Yeah. In fact, if you, if you want to implement NetDevOps, you have to think about, the organization of the service, the network service.

The the people that you are using. Peter said, to, for a network engineer today, you are you are not too obliged to to be a a developer. Yeah. Of course. But you need to have a lot of knowledge about development system and network.

It's a new profile. We need, network specialized. High level of network specialized are always necessary because you have to troubleshoot the network. You have to be a very high level network engineer to troubleshoot the network. But it's it's not those people that you are using in the NetDevOps team.

In the NetDevOps team, you have to, to know system development and network. Even if you are not a network specialized, it's not it's not, necessary. Just some knowledge to, to understand what you are programming. And and you have to organize the the new way of thinking, the new way of of walking into the into the the service. Because when you begin with network automation, sometimes later, you take into account the firewall, the servers, the routers, and so on.

And in fact, you are you are doing a lot of automation on all the IT parts of of the of the enterprise. Yeah. I guess, Peter, that's an an important part of it. And I guess this comes back to the idea of orchestration as much as automation. Right?

This this thing of of bringing together lots of different elements and and building workflows. Right? Yeah. The interesting thing that often gets overlooked in this conversation, in this journey, is that when you start down this and I think it's absolutely true that this permeates the entire organization. No question about it, right?

This isn't just something that is confined to the networking teams. But I think that what makes this what gets forgotten is the fact that we've got all kinds of systems out there that need to get brought into this in order to successfully automate network infrastructure. Right? You know, we don't you know, we as an industry, right, we don't just simply put config on devices. We gotta get we gotta get the information to build that config from a plethora of systems that are out there, whether it's your DNS, whether it's your management, whether it's your IBM, whether it's your inventory system wherever that data lives, we've got to be able to go out and get it, collate it, organize it, make sense of it and ultimately be able to generate configuration.

I think this is where, right, that development skill set comes into play. Whether or not you actually are sitting down and writing code is kind of immaterial to the conversation. What is key though is that network engineers and folks in the networking industry that are embracing automation, the ones that are very successful at it, understand that there is a methodology behind how you do this. And you start thinking in terms of broad systems as opposed to discrete elements, right, that that compose the the infrastructure. Yeah.

So this is the idea of of saying, look, there's there's data that you need in order to to do this thing. You've gotta gather that data. You've gotta have it's gotta be good quality data. It's gotta be looked after. You act on it, but then you also have to come out the other side of that and say, has it had the result that I was expecting?

Do all the testing. And and and basically have a feedback, right, to to bring that back and say, actually, it isn't what I expected. So we go again until we get to the point where we've got something something worked out. And it's a full ecosystem. It's not just one thing.

Right? It's I guess is what you're saying. Yeah. In fact, you touched on something there, and I keyed that in one word. And I think that it's really this is this is where I I think that that, you know, as we continue on this evolution and Arm's journey, it's an area you'll see more emphasis placed on and that is around this idea of testing.

And it was fantastic that we've been on this journey to create tooling and to create processes to help automate laying down the configuration. But what we also need to do is we also need to think about how do we validate that what we're doing makes sense. And I'm not talking about validation in terms of the network do we want, but in terms of how are we using and turning into automation to be able to build our test infrastructure, our test harnesses to go out and test those devices to make sure that they're doing and achieving the intended effect. And these are all elements that can be turned over to automation when you embrace it in such a way that you can reap the rewards from it as an organization. It also frees up your engineers and your engineering and operations teams to focus on really the high value tasks as opposed to, you know, simply iterating through a list of test cases, right, to to see if if a network is performing properly.

That's a good that's a good point. I know, Gilbert, we've talked before about about the DevOps cycle being including CICD and all those sorts of good things. Right? And this is all these principles we're talking about, isn't it? Yeah.

Peter was speaking about what in fact we we call acceptance test in the application world. In fact, when when we want to implement intent based networking, we have to build the source of truth, and we take the source of truth with some script and programs to apply configuration to devices. So the purpose is not to look at the devices to see if the configuration is applied. Yes. It's applied.

We know it's a computer that did it. But the the the the issue is that if the behavior of the network is the one we wanted before. And this is the closed loop automation. So we have to to to do some acceptance test. We can say that.

To look at the network behavior and to see if the network is doing what we what it is built for. Is the intention is applied, but is it realized? So it's measuring the outcome rather than the rather than the configuration matching what you what it what you someone thinks it should be. Yeah. You know, the configuration is good.

If your source of truth is, is good and your program is, is working, the configuration is applied. So it's of course. But even if your source of truth is right, even if your program is working as expected, is your network, working as expected? It's not not it's another question. It's not the same question.

That's a good point. And I guess the other thing, once you've built that that capability to to to do that is how you then can trigger those those events to occur. I suppose what you're then saying is, giving people the opportunity to decide what they want the network to do in a simpler way or in in a way that that that kind of abstracts all the network complexity away and perhaps presents, I don't know, a self-service port or something like that where people can say, I want the network to give me this thing. Point, click, go, and then you can all all of this process is built underneath that, the orchestration to deliver it, the testing to ensure it's delivered the way you expect, any feedback loop, in order to make it happen, I suppose. Is that what we're what we're driving towards?

It's an it's an infinite loop, such as we are speaking about in a methodology. So we have to, you you have to, to build an infrastructure as code with the source of tools with the program, and you have to get feedback from the network. It can be, metrology. It can be telemetry, some test, acceptance test. All of this is able to, to answer to the question, is the network doing what we expected?

No. That's that's that's understood. And I think, hey. Shameless plug. This is where, I guess, IP fabric comes in because it it has this ability to thank thank you for that, Gilbert.

To to to to do some of this this intent measurement for you. Right? If you if you ask the questions in the right way. And then, of course, you've got a nice API to extract the answers. So you can then use that, I guess, Peter, in in the workflow itself.

Right? It's another data source that you're using in order to, to build that process out. I mean, that's exactly right. And and, you know, that's that's the key to it is, you know, how do we tap into all of these, you know, various pieces of data or data sources and bring all of this together, under a single umbrella, through a single workflow? I think that there is a lot of noise in the industry right now around this idea of source of truth.

And and I think there's there is, you know, like anything, there's there's a lot of opinions and a lot of different ways of approaching it. You know, certainly, from from my opinion and and based on my practical experience, you know, I think that that people become overly consumed around this idea that I've got to go through this big data normalization exercise to ever benefit from automation. And I think nothing could be further from the truth than that. I think that as organizations start on this journey and start on looking at embracing automation, it can be done with very solving very simple things. One of the challenges one of the big challenges I see is organizations and when I talk with individuals, when I talk with companies, etcetera, they get very frightened is the best word I can come up with right now by by this this amount of terminology coming at them, right, you know, sources of truth and and testing and automation and CICD pipelines and development and programmability and APIs and etcetera.

And and the reality is is that, yes, there are big complex problems to go solve, but it doesn't always have to be about solving the big complex problem. It could be about solving something very small and very minor. And and and, you know, I think that it's really key that that individuals and organizations don't lose sight of that, that you can benefit from automation just simply by doing one task and automating it and then build on it. You know, add a little bit more, add a little bit more, tap into another data source, You know, do something else, and that's how you ultimately start to to really reap the benefits of of automation. So now I I find this one quite interesting because, often often when we you have the conversation, the question comes up, you know, who benefits from from the actual automation process?

Because if you turn around and say, well, actually, I'm gonna do all this automation. But, you know, from a network engineer standpoint, it's obvious because you're saving yourself loads of work and time and effort and energy. But then there's the business aspect of it, because, obviously, they need to invest. Right? And they need to to give you the time and the opportunity to develop an automation solution.

But then you need to show a business benefit to actually achieving that automation. And I suppose this is this is the balancing act here, isn't it? Because you mentioned doing the small tasks, but there is no not necessarily any large business benefit to be seen by that. And so it's it's a case of balancing these things out and saying how much effort do I can I put in without incurring a cost so that I can develop a a way of automating and then and then gradually, I suppose, tipping the balance so that you can see business benefit and get an investment into the process? Tricky one.

Yeah. When you speak about software that are running on system, you speak about time to market. But software and servers today are running on network. If the network is unable to, to scale at the same speed as the software and the system. You you cannot be in time to market with the software.

So in fact, network is part of the process and network is able to go as quickly as the rest of the IT. It was not the case until today. That's a good point. And and I think in terms of actually taking that that process apologies. In terms of taking the process on and and and and scaling it up, I guess, this explains why people opt for those those, open source solutions, initially perhaps, and then grow into commercial solutions going forward.

Is that a fair, a fair assessment? Yeah. Yeah. I think it's a fair assessment. I think, you know, early in the early days in the nascent stages of network automation, the only thing you really kinda could do was you you really only had 2 choices.

You had you had the great big behemoth frameworks out there that were 1,000,000 of dollars to implement, or you had open source tools and there was nothing in between. Right? You know, I think that over time, we've learned, you know, we've grown, we've we've developed technology and it no longer is beneficial to the business to invest in building everything from scratch. You know, it's just there's no value there. I mean, every company doesn't need to write the same thing to access a router.

Right? I mean, there's only so many ways it can be done. So so, you know, I think that we're starting to see a number of tools that are starting to show up and a number of products that are starting to show up in the market that really give customers the opportunity to jump start their network automation journey and be able to bring these different tools and platforms together to ultimately do it. I think one of the keys to making this happen is kind of this movement away from trying to do everything in one platform and one box and in one software application and really kind of starting to look at this as I need to pick and choose the right pieces and parts and put them together to ultimately achieve what it is I'm trying to what my goals are here. And I kind of love to talk with organizations about this idea and it's this concept that we're starting to morph away from this idea that I take a tool or I take a software application or I take a platform and I figure out how to build my operational model around it.

That's no longer the case today. Now we are starting to define operational models and then go select the right pieces and parts to actually achieve, those desired goals. Which which are gonna you're gonna assemble into an ecosystem to deliver the the That's right. Ultimate solution. Right?

Yeah. Yeah. And and I think that That that's right. That's something that that we we see a lot of is that, obviously, people already have tooling to do automation of that they may have an an SD WAN controller to look after their SD WAN. They may have a controller to look after their data center but not have anything for their campus, and they need to automate that.

What you're needing to do then is bring those elements together in order to to make sure that they can work in in unison, I guess, but then also have the ability to perhaps orchestrate them into into a single workflow so that when you want to achieve a business outcome, it might make a change to your SD WAN, make a change in your access network, make a change to your to your data center or your cloud infrastructure, and then test the whole thing as a as a as an atomic change rather than try and manage all the individual little bits, I guess. Yeah. Yeah. Of course. We are developing a lot of software, for customers that take into account all the part of the infrastructure, not only the the network.

It begin the conversation begin with the network, but, we we we have to take into account all the other parts of the network or the infrastructure part. Right. Because it's about delivering a a service, which is fundamentally the network is there to support all of the other IT services that sit on top of it. Right? So availability of the network has to be has to be as maximized because, otherwise, all of your everything is gonna fail in your IT.

Right? So Yes. And and this the virtual simulator that we use to, to do some tests before, pushing the configuration into, the running network. It's mandatory today to to work with simulators. That makes a lot of sense.

Chaps, I'm I'm conscious of of time. I don't wanna keep you too long. But I did have also one last question that I wanted to just think about is in terms of what you your organizations do, it'd be interesting to see how that everything we've talked about, how how they how you feed into that. So so, Gilbert, we'll start with you. You know, the work that you're doing day in and day out is helping people adopt these kinds of solutions.

Right? Could you could you summarize that for us? Wow. A lot of years ago, I begin to I began to to try to speak about network automation and all the the the process around the network automation. But people were not ready to, to hear about, this way of, doing the network, practices.

But today, since the beginning of the of the year, all the customers are asking to have network automation and intern bus networking into their organization. And, in France, the companies are not ready to understand to this, to this, custom to those customers. So, in my company, I work with, some guys in a team. We are training together, to, be sure to, to know all the the last technologies. And we, we answer to those customers in all around France.

And as far as I know, we probably are the first one company to, to, do, NetDevOps on the market in France. Excellent. Thank you, Gilbert. And and, Peter, obviously, I tend to, have a particular, particular approach and a particular way of of delivering, to customers. Can you help us with that a little?

It looks like we may have lost Peter. Yeah. I'll just give him a chance to come online again. No. We've lost Peter by the look of it, so apologies.

In that case, Gilbert, is other do you have any closing thoughts? Any anything that, you'd like to say, or is there any any way that people can get hold of you and, and and continue the conversation? Well, if we if we want, we can continue the conversation on the other session or using LinkedIn or or, Discord and so on. No problem about that. There there are a lot of things to to say about, network automation, NetDevOps, and Internet BaaS networking.

And as I said, before, I'm working on some new technologies. I'm sure that these those new technologies will change the way we will do network, tomorrow. No. That's that's, that's a very valid point. And, and I think something will probably pick up again on, on another time if we may.

All I'll do now is, wrap up, I think. Thank you very much, Gilbert, for for joining us, and thank you, Peter, if you can hear us wherever you are. Yeah. Thank you. There we go.

Balance there. I tell you what, I'm I'm just gonna rewind a little then and and go back to my to my previous question, which was which was really, from from an ITential perspective, how would you help with this journey that we've been talking about today? Yeah. Yeah. You know, I think what what we're doing at I Tenshil is we're really trying to focus on, you know, delivering to the customer a network automation platform, right?

And it's something that they can really coalesce around. And that's really the idea. Network automation, to be effective in any organization, any size organization and to be successful is only achievable if we bring automation to the masses. It cannot be 1 or 2 individuals that are carrying the torch in every organization. So we're really focusing on building a platform that delivers network automation for anyone in the organization who wants to do it, whether you're a hardcore developer or you don't want to ever learn how to write hello world, we're trying to do that.

And then the other element and from a technology standpoint is we're really focused on as I've talked about a lot through some of this is that, we really are focusing on how do we help organizations bring all these disparate systems together under one platform so that every organization out there isn't having to write an integration to this framework and that framework and that framework and that framework. And that's really what what the goals are for our attention. That's awesome. And and is there do you have any other closing thoughts, or or, where can people sort of speak to you to to continue your conversation? Yeah.

Absolutely. You know, I I I love talking with with anyone about anything in in this industry. I've been doing it a long time. The conversations are always fantastic. Anyone is welcome to reach out to me.

Easiest ways are probably via Twitter at private IP is my tweeting handle and feel free to reach out to me and let's engage in a conversation about anything network automation related. I'd love to hear stories about what people are doing and how they're going about doing it because, you know, collectively, we do a whole lot better, you know, when we work together and share experiences than everyone trying to do it, you know, by themselves. No. That's a really, really good point. I know that's that's some somewhere I I tend to spend way too much time is is on on the Twitters and the LinkedIns, you know, with the community, just hearing the stories because that's where, you know, like like you say, learning from from from combined experience is always a winner.

Right? Definitely. That's right. Well, thanks very much, gentlemen. With that, we are going to wrap up this time.

Please, look out for this and other episodes coming to a Podcatcher near you. And thank you very much for listening, and thank you very much, Peter and Gilbert. Thanks for having me. Thanks, guys. Appreciate your time.