Merging DevOps and NetOps with Network to Code’s Jason Edelman

This is Textron tv. Hey guys, thanks for the throw. We're here with Jason Edelman, who's CTO for Network to Code, and we're talking about, well, it's been a long held ambition, but maybe we're not making enough progress, but the unification of NetOps and DevOps, it's coming.

It's just happening slower than we possibly thought. Jason, welcome to the show. Thanks for having me on.

Really appreciate it. Where are we on this journey? And, and it feels like it's a natural extension, and yet there's a different set of tools for, for provisioning networks and the DevOps folks have infrastructure in, at least in the cloud.

These things seem to be coming together, but where are we on this journey and why aren't we seeing more of it? Yeah, it's a great question, and I was just saying we're, we're 10 years into it at Network dku, and, and I would've thought 10 years ago we would've been further along to, to where we are now in 2024. I would say there's a variety of reasons, and I'd probably maybe point out, point out two or three of 'em just to, just to recognize why we aren't further along.

One, one is culture, right? Two is skills, and three is the concept around data. What data means to, to network automation and at DevOps.

Those are sort of like my, you know, my top three reasons why I'm more than happy to kind of dive into them. Uh, should you want to, Well, let's jump into it. Let's start with the culture stuff in this, uh, it seems to me we have a whole lot of, everything is different, as they say, or the old joke is, you know, the French have a different word for everything, right?

Seems like in networking is similar, there's just different words for different concepts, and we can never normalize the nomenclature. So how do we work on the cultural side of this thing? Yeah, I think the biggest thing is being open, open to change.

You know, I think the network industry, you know, going back 25, 30 years, you know, from some of the larger manufacturers that, that exist, right? There is one defacto way to, to really interact with the network via the commandment interface, the CLI, and then other major manufacturers followed suit. Uh, then there became certifications really to kind of like promote the manual operational operational model.

And that kind of became, that was stagnant for, you know, for, for decades. And then it was sort of structured designs around campus networks and win networks and so forth. And everything was, was a bit more, I would say, structured cookie cutter, so to speak, but very static in terms of the operational model.

And then if we look at the DevOps, the DevOps space over the last 15 years, what we learned, you know, it's, it's really kind of jumping into the deep ends from where we've been in networking now for 25, 30 years and there's just, you know, acronym soup, right? There's just so, so many, so many things to consider. I would say technically, let alone like what it means to all the processes that were created maybe 20 years ago, even 10 years ago, that, you know, that haven't changed of what it means to, to make a change on the network and all the things that go along with that from opening tickets pre and push changes.

And, you know, a lot of that is, is still done manual. So I think it's really the openness, the openness to change and to recognize that it's a journey. You know, I think I've had so many conversations over the years where there's still a perception that a, it's quick or a tool's gonna help just do the automation versus like really investing in the team and the people and their skills.

Because a, the payoff is really twofold. The payoff then becomes, uh, to that individual in their career. And then it really, looking at it across an organization, across the team, it just helps drastically improve like the business, right?

The agility, predictability, reliability, and uh, and so forth. And this comes to the rub. I mean, sometimes I think about the only thing that the network people and the DevOps team agree on is that there should be ACL I.

But, um, when we get involved with the speed, right? The whole point of DevOps was to accelerate the building and deployment of applications. But you can't do that without provisioning networking services.

So sometimes I feel like we rush to get the application together and then we wait on the networking services just 'cause it's not part of the same workflow. So, um, can I integrate these things and how Yeah, absolutely. Well, well two things there.

One is, I, I always remind people that the network is greater than the data center or, or the cloud these days when we're bringing up applications because we have things like local area networks and branches and retail stores, corporate campuses, university networks. So there's so many networks out there, and I think they can be integrated. I remember again, even 10 years ago was involved in writing some of the first Ansible integrations to, to Cisco and a few other networking vendors.

And that was the start of being able to integrate and understand earlier what that means in terms of if you do have one continuous workflow or pipeline to be able to deploy an application. It, it is, it is no doubt possible to be able to, to do that on the network side. But, you know, there is a little bit more caring feeding because sometimes using the same tooling that's being used and the, the quote unquote DevOps space, it is still fairly new, right?

For those in the networking domain. And then even in terms of how that's adopted with ensuring the device is in the proper state, ensuring, again, you're gonna automate some of the, the pre-checks and the post checks, right? So it's like, for us, I would say it's technically possible to automate like the configuration of deployment of a given device.

But I would say realistically, you know, going back to some of those things that are holding us back, it's where, where is that data coming from required to actually deploy that change, right? And sort of like this IAC and EZ code and DevOps space, you know, there's this, the, the database or the CMVB is always kind of, you know, forgotten about too around where, you know, where is that data stored. Not uncommon to have, you know, thousands of YAML files or data files to be able to define things as code in the networking space, right?

We're seeing similar patterns emerge, but at some point, you know, sort of users, users try to, you know, figure out better ways and you kind of look at networking databases and sources of truth to be able to define that state. I would say once the data is curated and managed, then the automation of that last mile to be able to do that really does get simplified. You mentioned Ansible.

Is that playing a key role in kind of normalizing the data and the workflows? Because it seems like, you know, we've seen it become more of a defacto standard in the networking community and of course it's widely used in the DevOps community. So has this become the place that we can maybe agree to at least disagree?

Yeah, I, I think Ansible, Ansible is still part of almost every conversation, right? I think it's, it's, it's sort of the defacto tool that's a part of the conversation and those that have, that started five years ago or, or no doubt using it, I would say for those that are starting today, right, you're kind of looking at other platforms and tools to see what makes sense for an organization. Personally, I always like bringing up Ansible because it actually helps those that are, that are new to this space because A, you can get it installed fairly, fairly quickly and to be able to use Ansible, it kind of takes you down the skills, that skills conversation, right?

How do you get it installed? Do you, are you, are you then using Linux? Are you then storing things in gi, are you building things like jja templates and understanding YAML and JS O?

And so ans always does a really good job to kind of, it, it's almost like a good foundation to look at all the things that, that I believe are the primitives, right? For the next generation network engineer that even those that aren't going to be yeah, neck deep in code in the future. There are these primitives that at the end of the day, I think IT professionals have to be aware of as we go forward.

Again, going back to Linux and get and test and so forth. Right. Do you think AI might help streamline some of this for us?

Because we can start thinking about summarizations of things we can start thinking more about, uh, maybe executing playbooks through some level of simplified orchestration. I mean, what's your take here? Yeah, no, no doubt.

Yeah. Like I think, uh, the intersection of, I would say AI networking and therefore AI network automation is, is new, but I, I would say, yeah, the way, the way I think about it every day is leveraging AI to, well, for one network automation was built to be able to automate the network. I look at AI as how do we then automate you automation?

And so I do think if we're thinking about these examples, if it's constructing a YAML file, constructing a template, constructing a Python script or a playbook for that matter, based on what we've seen to date already, AI can have an enormous, uh, impact to be able to accelerate the building of those artifacts, right? So you don't have to be as skilled maybe to build them on the starting point. Then I think the challenge then becomes, you know, how do we, you know, how do we, uh, as an industry then build even better tests, more guardrails, right?

To be able to just to realize that it's coming, that we're gonna have more, more automations, more code built from AI over the next five or 10 years, and to figure out how do we, how do we embrace it? How do we promote it by therefore building these guardrails that make that safe? Where will security fit in this conversation?

I asked the question. 'cause on the dev side, we see DevSecOps and on the network side we see more, um, security controls and even policies being implemented and managed by the NetOps team. So is security kind of the, an opportunity to bring all this stuff together in a way that's a little more cohesive because we have a, shall we say, a pressing problem?

Yeah, no, it, it's a good one. I think there's so many, there's so many ways to talk about security. I know what's top of mind for me is always the, the infra structure part of it.

Yeah. Going from applications to the network and we look at, you know, what I would call the layer four to layer seven services across the infrastructure that drive things like proxies and load balancers and firewalls and, and VPNs and all of these things. Yeah, I think it's same, right?

It's all the same, I think to be able to automate those types of things, right? With, with and without ai. I, I think it comes back to data, right?

Being able to understand where that data is, is sourced. And I would say if I were to look out into the future, yeah, you know, it could be two, three years against organizations sooner or some later, but it's to be able to define, right? I think policy as code is still, uh, an up and coming sort of, um, paradigm shift to be able to define, to be able to define abstract policy in that business context, to be able to define security in one location and have that be translated into the different environments that need those policies Today, if we look at it both in the networking space and application space, there's probably numerous tools that have the same policies to a certain extent being configured and deployed, but they're not mandated essentially in one location, right?

Even even taking easy examples like border routers and firewalls and campus switches and, uh, north, south, east, west traffic in the cloud, typically the security policy, security groups, you just manage totally independently to think about the po, the the abstract policies, the governance that should drive those same policies that exist to really have that, that data first approach, right? To sort of net DevOps and network automation. I think a lot of folks would settle for just some simple visibility and observability to start, and I bring up the question because we spend a lot of time on the DevOps side, you know, trying to test applications for performance, and then we deploy them and they're distributed and they're on these end points and there's all this internet stuff in the middle and nobody knows is what the heck's going on.

And latency is variable and the experience can be, shall we say, spiky. So, um, how do we kind of just get some insight into what's actually happening on that wire that's impacting our applications? Yeah.

Starting with where we wanna end up and which, which isn't the, the simplistic part is this closed loop automation in the sense you're gonna continuously observe and monitor, um, learn, learn from that, and then to be able to configure and remediate right in this closed loop. It's a long way, right? I think in general to be closed loop industry-wide, but that first phase to learn to learn about the network, you know, clearly I, I think, you know, we're seeing the evolution of your traditional monitoring tools that have been built, you know, 20, 30 years ago, and, you know, we have to embrace them, right?

I think getting, having some visibility is better than no visibility. But where we're going with being able to get the real time alerts from the devices streaming telemetry and being able to define, just to understand what normal, what normal is, is, uh, it's paramount, right? I think it's paramount to understand what the intended state of the network, uh, should be and having the tooling, uh, deployed makes sense.

I, I'll couple that, I'll couple that and segue also back into the growth and skills and network automation, because there should be observability tooling deployed on the network to get that understanding. But at the same time, I would say it's actually a good gradual ramp to dip your toes into network automation A by understanding how to deploy those tools. But two, it could be through read only automation, right?

Hypothetically, if there's a lack of budget to be able to purchase a tool, deploy a tool, or have the time or the skills to deploy open source tooling, there could be the, the gradual step to be able to interface with a series of devices, a series of nodes or controllers, uh, perform read only, you know, gets to the network, re you know, get that data back and, you know, create documentation, right? Read only documentation as a first step, you know, kind of borders that observability, you know, state. But you know, there's still so many enterprises that are, uh, flying blind, so to speak.

And just, you know, kind of combining both of those worlds, you know, is still hugely valuable as a starting point. So what's your best advice to kinda get to that end state? Because should I just take everybody and lock 'em in a room till reason prevails?

Or is there some small steps that could be taken that might be a little less, uh, shall we say drastic? Yeah, I, I would say two th two, well, two or three things. I was mentioning data, I was mentioning data earlier.

I think it's, it's critical to understand data in an organization. You know, we've seen large enterprises literally have dozens of data sources that are used manually to get all the data that would be needed to make a change on the network or to do a deployment. So I would say documenting data sources is key.

Uh, same for workflows. Yeah, networking folks. I always, I always joke, there's usually a four or five phrase sentence or worded sentence that I'm gonna balance a switchboard or do a deployment.

Then it makes it sound so easy. And so, you know, documenting and understanding those workflows is, you know, is critical. Those two are great 'cause they're non-technical and you can, anybody can kind of start and dive in.

I would say technically, yeah, just, yeah, for me, it's just getting started, right? I think we're in this new age and we're gonna see new roles emerge, and we already are from network automation engineers and developers and architects for automation. And so we start thinking about Linux and GI and tests and pipelines.

I think it's really important to understand how these things go together because look, there, there is a misunderstanding too, even mentioning those things. Uh, I'm, I'm referring to things that are, that are broadly applicable. So even if a, uh, an organization is buying commercial tools, almost, almost every tool that is downloaded to plug the open source or, or is purchased, has some integrations that would require version control and testing and, you know, managing software artifacts.

But I think understanding, again, how to use GI understanding Linux and understanding the value of, even if it's a config file, what building a test like that looks like. So I think just trying to, just starting and, and jumping in, you know, makes, uh, you know, makes sense. And yeah, I would say simplistically, I, I wouldn't, I wouldn't overthink it, right?

Just starting somewhere is better than, than, uh, not starting at all. All right, well, there's an old joke that says, uh, what's the one thing that an application developer and an IT admin can agree on? Well, the answer is it's the network guy's fault.

Fortunately, that joke is still funny. Hey, Jason, who's the networker genius? Hey, Jason, thanks for being on the show.

Thanks, Mike. All right, and back to you guys in the studio.