In The Arena by TechArena - Scott Robohn of Solutional on NetDevOps for AI Networks

Episode Date: August 18, 2026

Scott Robohn, CEO of Solutional, co-founder of the Network Automation Forum, and consulting CTO at Carahsoft, joins Hedgehog founder and CEO Marc Austin to talk about why AI infrastructure raises the stakes on network automation. They cover NetDevOps, the talent gap in network engineering, deterministic scripting versus agentic AI, and where reference architectures fall short at scale.

Hello, I'm Mark Austin, founder and CEO of Hedgehog. This is the AI Hedge where I talk with industry leaders and AI infrastructure about the opportunities and risks of AI and how to hedge them. And on the show with me today, I have Scott Robone. He wears many hats. So I'm going to let him introduce himself before I tag him to any particular hat. Welcome to the show, Scott. Mark, thank you so much. And just for eye rolling and ease of use, it's Scott Robon.

It's like putting a robe on. Oh, yeah. Sorry about that. No, it's okay. I'm pointing to it. Don't ever spell it with a K. There you go. And I've learned that much in corresponding with you, right?

No, look, I'm excited to have this conversation with you today. I've been 37 years in the networking industry. I was an operator with one of the baby bells for a time, moved into the vendor space, largely with Juniper networks, but also some time I Cisco and Nokia. and a disaggregated vendor called Drive Nets. For a very long time, I wanted to go out of my own and start just doing my own individual project work. I started that in early 2023.

That's now done under the brand name of Solutional. That's my consulting company. And there's lots of stuff that fits under this that I'm sure we'll talk about today. Yeah. So one of the things I want to start with is Network Automation Foundation. And part of that is because at Hedgehog,

we're an open networking company. We're members of Linux Foundation, Cloud Native Computing Foundation, Open Compute Project. Tell us about the organization. I think you were one of the founders. You know, what problem were you trying to solve? What's your mission and charter for it? For sure.

Well, back in early 2023, and this actually came about after I pulled the rip cord on my corporate work, started my own consulting work, I actually started having a dialogue with the other co-founder of NAF, a gentleman named Chris Grunnaman. And Chris and I have both been automation practitioners throughout our career. And we started talking about what do we think the problems are with the hesitation

to adopt network automation? Lots of traditional network engineers, trad net-enge, if you will, being worried about taking jobs away and things like that. Yeah. We decided that we were two people with our opinions and perspectives. It would be better to start getting people together to start talking about the issue. That led to AutoCon Zero in November, 23 in Denver, where we said if we got 200 people around the virtual table to talk about this, that would be successful.

We end up getting about 340, 345 people in our very first event, which kind of showed us the topic resonated, right? There are other people that are seeing like, why am I having this trouble driving network automation initiatives? What are other people doing in real networks? How can I share information? How can I get help and how can I help other people? That hallway track became very important as part of our AutoCon events. And it's been a pretty interesting ride so far. Just held our sixth event, AutoCon 5 in Munich, Germany in June, 26. I believe I miss that.

Well, I love Munich. I'm here too. And you're not alone. You're not alone in that. But tell you what, November 26, come join us in Tucson, Arizona for AutoCon 6. We'd love to have you. We'd love to be there.

Cool. So you mentioned Tradnet Eng and 345 people at the different. first show, were they trad net engines on average, or what do the audience look like? So that's mostly the heritage of people. I think people who are going to pay money to show up at a network automation event are self-selected as interested in or actually driving and learning about network automation. And so we're definitely skewed toward people who were network automation literate at some level, right? You know, from beginners to really advanced. I'll use this to make the strong connection with Hedgehog.

Lots of enterprise participants for the most part, some telco, some cloud, but very, very enterprise dominated. I have always been interested in getting more presence from cloud and now AI resource networking to show how important automation is at scale in those environments. And that's a real opportunity for Hedgehog to come in. make us flash for sure. I think you also keyed on another thing, which is, okay, we hear a lot about this right now with AI, right? Okay, AI is just going to automate everybody out of a job, right? And it's kind of an irrational fear because you still need people to do things. It is kind of addressing

that same need early on with the community. Like, I don't want to automate my way out of a network engineering job. Was that part of the charter? So there's some of that. I wouldn't say it's part of a charter per se, but naturally we gravitate toward reality. We really, try to filter out hype that we see with any technology in the market. We're very, very grassroots, community focused, and very interested in what people are actually doing and not marketing messages or inflated perspectives on things. Yeah. Cool. All right, I'm going to shift gears here a little bit. So normally I try to wear a suit so that I'm on brand with my hedgehog lap pin for this end, particularly with really important large customers. But I've heard

tail that if you're a CEO and you wear like a colorful Hawaiian shirt, you're going to sell a lot of autonomous systems to the government. So I wore my Hawaii shirt today on Friday. It's impressive. Yeah, thanks. But look, we work together in your capacity as consulting CTO for Carassoc. Can you tell us, just explain to the audience, what Carasoft is, what kind of that business is, and why network automation is relevant to it. Sure. So Carasoft is one of the largest software distribution partners in the resale space to the U.S. federal government, the public sector, and broadening even more into commercial sales. Started about 20-some years ago by Craig Abod. Really, you have every IT-related technology in the building, virtually speaking. They're based

in Rest in Virginia, and we say in the building for in the portfolio, as it were. I got to know Carasoft as a customer while I was at Nokia federal six, seven years ago. And when I started out on my own as a consultant, I reached back to some of my Carasoft contacts and said, I don't know how I can help you, but there's got to be a way I can help you with my networking expertise. And that very quickly turned into, yeah, we'd love to have you engaged in some of our networking-centric relationships. That's grown into broader data center solutions and actually working with their relationships with some of the foundational model AI providers. We now have about four people from my company engaged with Carasco. But I'm definitely engaged in all things networking and AI networking and really excited to start getting engaged.

You know, it's been a couple months now with you and the Karasov relationship. Yeah. Yeah, I was just with the Karasov sales team right prior to this and just going through the funnel. And there's like there's opportunities are coming in faster than we can even respond to them. So it sounds like the government is building out AI infrastructure at scale. They are. And you're seeing these different RFIs and RFPs. come out, the challenge with the government sales cycle is it tends to be very long. Yeah, you need to know

how to navigate it, which I don't really know, but Carasoft up. And that's, you know, a marriage made in heaven, right? You obviously understand your technology, your product and solutions. Carrisoft understands contract vehicles, Vars that are relevant and so forth. You ask the question is and why is automation important to federal customers. We all want automation. We don't necessarily think of it in those terms, but do we want the toil? Do we want to continue keeping our books on paper, right? Or cutting and pasting mechanically from one spreadsheet to another dock. And there might be some people that want to do that. But in general, markets want to be efficient.

And technology wants to be efficient. But it's even more important with AI networking. And I'm preaching to the converted when I say the following. When I'm dealing with thousands of GPUs that need to be orchestrated like a single organic unit, You can't do that manually. You need tooling that leverages and implements automation to make that look like a fleet of GPUs and a fleet of switches with connections,

not the cattle model, not pets model. And when I deal with thousands or tens of thousands of devices at a time, there's no way human cognitive limits are going to be able to do that fast enough and without error. Yeah. And I think to simplify it, it's like, yeah, we want AI infrastructure that operates at scale, I don't really want to have to think a whole lot about the infrastructure.

I just want to DAI. And we were just talking to DISA yesterday, which is like the IT organization for U.S. Department of Defense, that's arguably the largest enterprise IT organization for the largest corporate entity on the planet. So scale matters. Great. Back to NAF.

You published a primer on Net DevOps. You mentioned Trad Network Engineer a few minutes ago. Can you define for the audience what is Net DevOps, And can you give us just a quick primer on the primer? Sure. The terminology borrows heavily on DevOps from the software development and deployment world. Yeah. Now, you might think initially, like I did years ago, oh, DevOps, that's a software thing.

That doesn't have anything to do with me. You know, I'm a CCI. I'm a JNCI. I know the CLE. And I know how to make the switch dance, right? Yeah. There's a bit of a stickiness. engaged in, if I've invested so much in becoming a guru around Cisco equipment or Juniper

equipment, et cetera, I have real identity bound up in that. And that's a thing. That's a real thing. When I say Trad network engineer. But people like myself, some of us learn faster than others, not me. I'm a slower learner. You know, I came to find over time that so much of what is relevant for net ops and operating networks is now downstream from software tooling. And so there is real value, utility, and logic in I should be using a system for versioning my configs and the automation scripts that I write from my network. Boy, software world knows how to do that with Git, GitHub, GitLab, other instantiations of that.

There's probably great utility in a process for double checking, configs and scripting and having people review things before it gets pushed into production. And I'll tell you what, that's very counter the XXIE mentality of, dude, I know how to do this. I went and earned my leather bomber jacket or I got my JNCI plaque, right? I shouldn't need to have somebody checking my configs. Guess what? If you want to reduce risk and you want to hedge against risk, just like you said earlier here, you want to have the right processes that reduce errors in scripting and configs in your network as much as you can.

And CICD applied to network configurations and scripts makes a whole heck of a lot of sense. That's a very long way of coming around and saying net DevOps is really that smart application of DevOps principles to the networking domain. Yeah, yeah. Look, everybody else who's running code that runs on that network, they have to go through a QA cycle. whole CICD process, like why wouldn't work. Yeah. Yeah. So just back to that DIST's story, because this is just fresh in my mind.

It was yesterday, like we were talking to one of the operators. And they're using AWSGGGGG Cloud with AWS Outposts for a high grid cloud solution. But the operator, what they're doing is using the AWS API to provision virtual private clouds, VPCs, you know, configure the private links that are linking just the data centers to AWS availability zones. And then managing all of that. with infrastructure is code and GitOps, which I was like, that's pretty cool, right?

If they're doing GitOps. But I guess the point I'm trying to make there is that operator is trained on how to operate an AWS network with NetDevops. They're not doing the Trad NetEngh that you were talking about, right? And this is a fairly young, somebody earlier in their career. Is there sort of a demographic difference? And you see there being more Net DevOps engineers now that are sort of entering the job force?

than maybe the XXIEs? So that's an interesting question. I'll answer it this way. I think as a community, we're aging and we look a lot like me, and I'm not saying that as a compliment. And we do have a talent deficit of getting more new and career people in and being interested in net ops and net DevOps. The good news is automation in many forms can help with this problem, right?

Yes. where I can be Tony Stark in the Ironman suit. Sorry if I'm violating any copyright here. I'm still the human in control, but the suit lets me do a lot more, a lot more. And just to connect it back to your world, that's basically a fundamental design principle with Sonic, the open source operating system from Azure

and now spreading like wildfire, really had an automation first mindset. You don't want to configure switches with Sonic by hand. I should be configuring them as fleets of devices, not individual devices. And so I see opportunity here where people like yourself and companies like Hedgehog that have the cloud first mentality of you can't really do anything at scale without automation, come and make an impact and add to that messaging of what we see in network automation forum so that more of the enterprise focused folks and even telco folks that haven't really moved forward. on that front, get a better idea of practical implementation and like automation as a first language, not as a second or a third language.

Yeah. So for somebody entering the workforce now, like I've got kids who are just leaving college, right? So I'm talking to a lot of people at this age level and it's, I don't know, job market's changing rapidly with AI. For sure. What should I go do? So, but clearly the network is like critical control point in all this AI infrastructure. So if people want to sort of get into that domain generally, where do you recommend they really

train and develop their skills? Is it the traditional XXIE? Is it cloud networking certification? Is it just diving in deeper with AI? Where are people going to really train themselves to get the best skill set? Yeah, there isn't one path here. I'll say the really good news is we're in an information-rich environment that no one prior to us has ever experienced. And even if it's just using YouTube videos to go and learn about things. It's a great place to start. But let me box it out into there are a couple domains that are important here. You need to have some basic understanding of networking, right, at the physical layer. What does it mean for an Ethernet connection to connect two switches or a switch in a router, et cetera? That still matters. That can be acquired through a vendor

cert, you know, CCNIA, JNCIA, the ERISA programs and so forth. And you get the practical, hey, I learn how to operate at least one piece of equipment while I'm learning those basic principles. But there's a whole bunch more outside that that is relevant and useful, like things like, okay, what does CICD really mean? Why do I need to learn Python? I actually talk a lot about this in a program I call the next gen network engineer that we work on at Solutional. It kind of shows all the other things around the infrastructure itself that are just as important to know and maybe increasingly important to know. And then cloud networking principles are different because you're abstracted away from the hardware and the different stacks are different. The networking in AWS does

not look like they're networking in Azure in Oracle and Google Cloud, et cetera. But you need to know the principles from at least one of those cloud platforms, right? And then the very special optimizations that are happening in networking for AI are fascinating and another place where you can dig your teeth in. I'm not suggesting that you have to dive into each of these things at the same level of depth, but knowing at least a little bit of each of these areas is really important. I'll throw the capstone on top here of you can use AI to learn about AI. So for any of these topics, make sure you know how to use a couple models to dive deeper and use AI tooling as a patient tutor.

It's never going to say, Scott, you idiot, you've asked the same question five times. it will be patient with me and respond. And I can even say, could you explain it a different way? And so I think that's an essential tool for learning any of these tech domains. Here we're just talking about networking, obviously, much more broadly applicable. Yeah. I want to make sure I come back to that. Okay.

So if you've done all that learning and you sort of get the dream job where you get to work on designing, building, deploying, and operating an AI data set. What do you think of the key risks that you're going to encounter and how do you hedge those risks? Interesting. I think if I take somebody brand new, I would say get in an operations role to start, whether that's in a knock or even you're running the cabling in this next new AI data center buildout. It may not be exactly what you want to start with, but you're going to learn really important things about how it all fits together. But that's a starting point and that doesn't have to last forever, right? To get into an architecture role, you do really need to know how things fit together virtually and physically.

I do know, like in some of the work that I'm doing in terms of networking issues in the neocloud and AI data center space, there is a dearth of network engineering and network architecture personnel. Yeah. So you're already. I was on the question on a panel two days ago here in Seattle Tech Week. What's the biggest gap is a compute, storage, network, talent, and. I'm the one network guy on the panel. Everybody thought I'd say network. And it's like, no, man, it's talent.

Yeah. Yep. I run my own podcast. I do my own consulting engagements. I get to talk to a lot of people in this space. We're doing structured interviews with Neocloud and AI data center providers. And that's a theme that comes up everywhere. We don't have enough talent.

So you're walking into an already fairly de-risk space, which is great. But now we need to help get you the knowledge and the piece parts to put it together and come up and speak quickly. How do you see this? that. Are there other effective things that you've seen for like people coming out? Oh, I think would. Where I see people run into trouble, it's okay, I got some financing. I'm in line to get some GPUs. I've got a power contract. I've signed a lease on space and I've got cooling. GPUs arrive. Oh, yeah, they shipped with some switches that my GPU vendor recommended. Okay, now I got to get all this stuff running. And these are super expensive assets that are just,

burning a hole in your pocket while you're trying to recruit that network architect that's really hard to find. And then you've got to give that network architect design time. And then you've got to have network engineers that go do a bunch of scripting and stuff. So slow time to GPU value, you'd risk. And then once you're up and operating, you mentioned this earlier. Like you need a cluster where all these GPUs work together is really one supercomputer. The network is central to that. Yeah.

And what that means is that you're going to run into a whole bunch of reliability issues. issues in an AI network that you don't have in a traditional data center network. So the incident rate's going to be higher. Your meantime to resolve those incidents needs to be short. Otherwise, you're going to have performance degradation and you're not going to be pumping out tokens the way you need to. Yep. So of course, the solution to that is you start with a reference architecture. That's right.

It's fully automated and boom, stuff gets up running faster and it stays up and running better. So that's a really interesting topic in the whole space right now where, of course, Vividia has their prescribed reference architectures, which I think are super critical and a great starting point. Yeah. But we support those at Hedgehog. Yeah. For sure.

For sure. And like, of course, that makes complete sense for anybody in this business now. We know however much the gorilla weighs, they weigh that much right now, whether it's 800 or 8,000 pounds, it changes. Right. But, you know, what I'm also seeing with some neocloud provider conversations is as they push the limits of multi-tenancy, the reference architectures don't do. everything that they need.

So there's going to be continued evolution there, I think. Yeah, well, I mean, the Spectrum XRA is mostly for the back end GPU network. That's right. You'll need a front end network that gets data in and out of the GPU cluster that gets it in and out of storage clusters. There's a gateway that part of our product. So there's a lot of other pieces to the puzzle around that RDMA network on the back end. You mentioned AI is a key tool in learning and training.

And we talked about automated configuring so that that reference architecture gets implemented quickly. How about the combination of those things? Like, I've heard some people say, hey, look, I can just use AI to go automate the configuration, right? And that's a probabilistic way of going about it. And then there's a deterministic way of going about it, which is if the structure is code and GitOps that we were talking about.

Yep. Yep. Is it appropriate to use AI to go just configure your network? Will it work? And so. And this is one of the questions that's at the forefront, right, that I see through NAF in our Slack conversations and the way content has been rising on agentic AI for net ops. Here's a really interesting design pattern that's emerging. I've seen it on a couple different fronts. You need both. You need determinism where determinism is useful and I need guaranteed outcomes. And I need reasoning where the problem space is fuzzier. And it's very, very, very. cool to see this emergence of hybrid solutions where I can use AI to do some troubleshooting. I can come up with 99% certainty that, okay, it's this issue.

And I have a service catalog with this script that I run to solve that issue. Right. But again, I need the Roomba to bounce around the room sometimes when I don't have great problem definition. I got to need to be careful with Roomba again on the trademark front. But this emergence of using reasoning through agentic AI where it's needed and then using traditional scripting and procedures where it makes sense, man, this is, I think the industry is really converging on how to leverage the power of both. It's citing time to be engaged here. Yeah.

I was at Cisco for six years selling closed loop network automation. Sure. And AIOps has been around a lot longer than LLMs, right? Sure. Yeah. But really, it's machine learning. You're applying machine learning to reduce noise because you got all these systems generating alerts.

You got a lot of telemetry, you got logs. So you can correlate all that into incidents and relate incidents to performance anomaly. So you got better observability. And then if you have an automation API that can be tied into those AI ops incidents, you can have closed loop automation. Maybe you have a human in the loop too.

I just think about all of the configuration that we automate and we test the heck out. of it for it becomes product ties and it's part of the product that you realize in this reference architecture. If you don't have all that, you just say, hey, Claude, please provision a BGP, EVPN for a tenant with my sonic CLI. What's going to happen? So I did an interesting personal experiment slash project earlier this year where I've really glommed on to the idea of spectraven design, a product management philosophy that predates AI, But now I can use AI tooling to walk me through the spec-driven design process.

And I found that to be incredible in, we talk about being a builder, right? I basically did a, hey, I want to implement this two data center topology with vendor A and vendor B in the different data centers. I want to run it on Google Cloud. I want you to generate all the infrastructure is code, Terraform for me. I want to make sure you update all my GitHub rebos. And I want you to keep track of all this because I'm going to use it in presentations in the future. This happened to be an OpenAI Codex boot camp. And I came with my page and a half of intent on describing the system I wanted instantiated.

And I said, you interview me for any other details that you need to know before you can generate the IAC bits and so forth. And OpenAI, whatever model was being used, I can't remember which one, took me through six rounds of interviews to flash out all the SDD specification markdown files. And it didn't ask a weird question anywhere along the way. Every question was spot on. I didn't tell it. You need a specific networking domain knowledge. But that's where I see, you know, AI, I ask this thought partner to help me get to all the right config bits,

even if I don't know them. I'm not an IAC guy. And I've never started anything in Google Cloud before. And that's why I pick Google Cloud as an example to see, okay, how well will this do? And I was really super impressed. Yeah. And for what it's worth,

Everybody on the Hedgehog Engineering team, we use cloud code. We've got enterprise license. And that rapidly just accelerates our dev cycles, our dev velocity. But the thing we do is once we've got that sort of known good configuration, we test the heck out of it. That's right. And let me pull on that thread just a little bit. Testing is key to building trust. And that's not an AI thing, right?

We've done this for decades. Yeah. Before we roll anything on it into production, we're going to have reasonable assurance that it does what I need it to do. Yeah, and I think a lot of people outside of networking don't really appreciate this, but the margin for error in networking is pretty small. Correct. And if you get it wrong, it has a really big blast radius. That's right.

And even more so in networking for AI, right? You lose a link, you stall a GPU. You've wasted a lot of time and you've inserted lots of idle time on those expensive resources. And so it's even more important in AI fabric networking. Yeah. Okay. You've got some great reference documents at NAF. There's a NAF framework for automation. Can you give us an overview of that framework? What are the components of it?

So let me give you just a little history on the framework. And I'll encourage anybody to go check it out. This is not something that Chris, my co-founder and I decided needed to happen. This is something that emerged from the community. And it's really, really interesting and exciting to see it happen the way that it did. There was a critical mass of about two to three dozen people involved, primarily via Slack. Some of them, probably most of them had never actually been to an auto con event. But they all decided, yeah, we think this would be useful. And what we did at NAF was basically provide room around the watering hole, kept the seats clean, brushed the dirt and the leaves off the seats.

And then the smart people who had a vested interest in seeing this come together came down to a group of four or five individuals that have really led the effort and have started presenting at AutoCon events, but also going outside to Nanog, to Chinog, and to other venues, not because they are under any mandate to go evangelize this. They see the value in it. And you, you've just at your initial blush here, it's like, yeah, no, I think this could be really useful. Companies like yours are starting to see, yeah, this is where we think we fit in the framework.

I see how someone almost said architecture. And it's not really an architecture. framework. So I am not as fresh on the actual details of the framework right now, so I don't want to misspeak. But I would say, go take a look at it. It's not hard to consume. You do not need to be an automation practitioner. But it calls out the different components of the ecosystem, like source of truth. I need to know what authoritative data I'm using for automation. IP address pools, interface descriptions, you know, endpoint identifiers and so forth. What's the authoritative information? How am I presenting this to users?

There's a whole bucket in the framework for presentation type issues and so forth. You'll even see that it doesn't necessitate Python as a mechanism. Oh, no, it's not implementation specific. That's right. That's right. And it's mental furniture for your automation thoughts to sit in, basically. Yeah. Really good document at first blush.

Yeah. In my last job at Cisco, right, I was in a role where it was mass scale network automation sort of partner strategy, right? And I was actually like trying to sort of standardize that discussion around a framework. I needed that document. Sure. Really. So that we could look at the landscape well.

And then I'm looking at it now and I'm like, oh, wow, that was a miss on Hedgehog. We should have been part of that discussion when you were formulating it and as we were designing and building the product. But you've had a little bit of time, at least look at Hedgehog. How well do we map to that framework? So here's an interesting thing. I'm not sure you fit well within. in it, but you're on top of it for sure. And I want to use this to call out a gap in some of what I've seen in our activities. Again, I think the cloud networking community knows how they have to

use automation to do anything at scale. I think there's plenty of lessons learned that can come from organizations like yours to educate the rest of the community on if you're going to be dealing with 4,000, 8,000, 16,000 endpoints, this is how you do it. I would say, say it's not too late for you to get involved. And there couldn't be that element of, okay, what does this framework entail at scale? It's not too late to get involved. I actually have had a couple calls this week on people asking to, how do I get involved in actually learning more about and impacting the development of the framework? And I'd leave that, you know, invitation open to you as well. Okay. Great. Looking ahead three to five years, how do you think the role of the network engineer

changes? What's going to be the ideal job of the future? I think in network engineering and operations, similar to other areas, there's this opportunity to elevate and think more like an architect, where I'm going to be using tools, be they traditional scripting or agentic or some combination of the two, to do more of the toil work, but I need to think more about how the pieces fit together. I still need to architect the system. You can call it being an agent boss. You could even think about it just being a manager.

but that whole theme of elevation on being the puppet master, right? And I'm directing what the tools do. I still have the networking domain knowledge. I know what I want to accomplish. I think that's a real opportunity and a reality for everybody in this business. Great. Okay. So for people who want to learn more about the many hats you wear,

where do they go to learn more about Solutional and Kerosoft and find these great reference documents that we were talking about? So for the NAF reference architecture, go to network automation. forum. It's unique. Forum is a real TLD. You can go see there. You can always hit me on LinkedIn, Scott Robon. I haven't met another Scott Robon ever, so you'll probably hit me very easily. Or just send me email at Scott at Solutional.com. I'd love to keep in touch with folks. Great. All right. Scott, thanks so much. Awesome conversation. I literally I could keep going for hours with you on this topic. We're both pretty busy and it's always good to be concise too. So thank you.

There's a great discussion and we'll see you out there. Awesome. Thanks, Mark. Really appreciate it.