Opengear Frames AI Automation Around Resilience

Hey guys, thanks for the intro. We're here with Patrick Kirk, who's president and general manager for Opengear, and we're about to have a little chat about, well, IT people, as always, keep being asked to do more with less or the same. The problem is there's a lot more stuff than ever, so this equation doesn't seem to be working out as well as it should be.

Patrick, welcome to the show. Thank you, Mike. Good to be here.

Ultimately, what's your assessment of what's happening here? Because if I look around, the IT environments are becoming more distributed with each passing day. There's more platforms, more things to manage.

There's things all the way out at the edge. There's things in the clouds. There's all kinds of new AI workloads, and yet I don't see the IT teams getting any bigger, in fact, maybe the opposite.

So how does this- It's always, yeah. How does this equation come together in your mind in a way that is, shall we say, sustainable? Yeah.

So I think what's interesting is this has cropped up multiple times over the last 15 to 20 years. I don't know how much you follow NASA and the space programs and stuff like that, but there was a big concern back in the early 2000s about all the brain drain that was occurring with rocket scientists and people in that field. Now, you had companies like SpaceX get founded and Blue Origin, and there's a lot of innovation that happened there and brought in a whole new cohort into that market, and we're kind of seeing the same thing on the IT side.

So I think a lot of these are the result of the de-emphasis of the trades that we've had. And not just in the US, I think this has been a global phenomenon where we've said that the best pathway for success is to go to college. But in a lot of ways, the technicians and the network operators and...

There's a lot of opportunity there, and we cut off the funnel that fed into it probably for the last 10 to 15, or 15 to 20 years. There's been a revival here in the last, I think, four or five years that's really started to help. But fundamentally, a lot of these industries are now having, and networking and IT is no different, right?

We're now having to deal with effectively what is a brain drain that occurred in this space. And then I think you laid it out pretty really well that no matter what metric you look at it by, number of sites, number of IT gear, amount of data that's moved, the amount of data that flows through to data centers and out into the distributed compute. Any metric you go by, the volume is increasing, the number of sites that you have to manage is increasing, and as you said, the number of people actually managing it is decreasing.

And then I think the other factor that plays into this is we have a real hesitancy now to put humans in the loop, right? So we want to automate everything, and in order to maintain safety and maintain control, we want automation in order to be able to do that, so it's replicable and you can get the right level of quality out of it. The problem is, is it's almost impossible to automate everything, and humans have to get involved somewhere, right?

So the big issue to me is really about, and if you go and look at data center outages and network outages, over 70% of them, and I don't remember the exact statistic, but it's in that range, are actually caused by human error. We tend to think that it's bad actors coming in and creating havoc in our networks or whatever it is, but the vast majority of it is some update got pushed to the wrong thing, or some configuration changed and you didn't match it. And so, augmenting a already taxed workforce with more and more automation and higher expectations is really where the problem lies.

Well, to your point, we all meet the enemy every morning when we look in the mirror, right? But- ... here's my question to you.

Historically, the problem always was, is that the folks that had the knowledge to automate a workflow didn't usually have the skills to create the programming code around that in a way that would be scale and consistent and didn't need to be babysat by somebody, and therefore defeating the purpose. So- Yep ... is it getting easier to automate things and can we think about this differently?

Yeah. So certainly with the advent of, really, the automation tools that started to come into a lot of this over the last eight to 10 years have really given a lot more scale to each individual worker, right? So that has absolutely been a boon and has helped offset some of this, the mismatch that we've got.

But with the advent of AI, there's no question now that the level of tools and the ability for almost anybody to be able to go in and increase their output and efficiency and create more tools to be able to help them has grown. The big question, though, just comes in from a control and governance perspective. So, like you said, we had the developers that would go off and build an automation for somebody who's going to go off and execute it.

Well, now you've got the person who's actually responsible for the execution of it can go create it himself. Okay, but what are the governance rules you're going to put around that, right? So does an agentic AI that's going to go in and affect your network operations or your IT space, whatever it is, what roles and restrictions do you place on that, and how do you make sure that that agentic system doesn't go off and make the exact same mistakes that a human would make?

But guess what? It's not going to give up. It's going to keep trying, so it could actually have a worse outcome than a human who would back off because they know that, "Hey, I can only hit- ...

eight or ten units in order to be able to do a test rollout of this. Hey, that broke, I can stop it here. Whereas, if you tell an agentic system to go off and do it, it's going to keep trying, and that cascading effect there is really, I think, the concern with this ability that we've now opened up for everybody.

Well, that's where the human supervision should come in, because the AI will keep trying regardless of what it costs, and sometimes it seems like the AI will go try to access systems it shouldn't, and even if you tell it it shouldn't, it will still look for some other way to do that, and- Right ... I talk to folks, that's driving a few of them around the bend. Yeah, for sure.

But that kind of is getting to the heart of it, right? So I think whether it's a tool that a human is using to augment their capabilities, or it's a truly agentic operations where you've got an agent that's actually running, they need to have the same level of access control rights, and you need to treat them like they're a human effectively, and make sure that you are walling everything off and containing the surface that they can get into. And so in some ways, you almost need to treat the problem now like you would treat a cybersecurity threat space, right?

So you want to minimize your threat surface when it comes to any kind of cyber attack surface and everything else. So we need to be applying those same kinds of rules to agentic, whether it's a true agent doing it, or even if it's an agentic tool that's having approval by humans, right? So kind of thinking about minimizing the attack surface, making these things as small and as contained as possible with the same level of governance and probably more even than we would put onto a human operator.

As we kind of work our way through this, I feel like every day, you wake up and some big tech company's talking about how they laid off tech people and shrank their squad. But the bulk of the economy is driven by mid-market companies, and I have always felt that they are, shall we say, IT poor. And so are we going to wind up seeing maybe a shift of where larger enterprises are running things at scale with maybe fewer people, but more of those people are going to wind up working for other companies that previously couldn't afford to hire the right kind of IT talent in the first place.

" Yeah. I think you've just described our industry, right? So I think you're exactly right, because there's this trickle-down that always happens, right?

Like you said, the larger enterprises, whether we're talking about kind of the hyperscale or the Big Five, whatever, even a scale down from that, they have the resources to be able to go off, build the tools, manage everything themselves, evolve it, and keep it efficient and productive. But that next tier down, like you said, where the vast majority of business is done, they literally do not have the people or the expertise to be able to go and do it themselves. And so, to me, that's where it becomes incumbent on companies like ours, where we're a provider into the market.

We need to recognize that, right? And we need to take those capabilities that are being developed by the very high-end, well-financed, well-outfitted companies that are able to go in to do this. How do we take that, distill it down, and make it elegant for that mid-market customer so that they don't have to have somebody with huge level of expertise or a large team in order to be able to go and execute on their network operations, their IT operations, whatever it is.

Right. Now, we may have a bias about this, but it seems to me your ability to compete is going to be increasingly determined by your technical expertise. And big companies- For sure ...

they, for better or worse, have the resources to get the talent they want. Of course, sometimes they wind up being so big they can't get out of their own way, but that's another issue. But then there's these smaller companies that are going to wind up having more IT expertise.

So do you think that at some point, this playing field between the smaller and the larger companies could become more level as IT becomes more evenly distributed, or the expertise becomes more accessible across the board? What do you think? Yeah, I think that is certainly one possible outcome, because as you said, if the larger companies are laying off these expert workers and they start proliferating down into mid-market and lower-market firms, then absolutely, there's going to be a democratization of capability, right?

And that's something that I think that the AI tools and even kind of, as I was saying, from a supplier into this space, we're trying to incorporate those things into our products and solutions to make it easier for essentially that democratization of capability all the way down to the lowest level companies to be able to execute on. So I think you're spot on. So as you look forward into the coming year in terms of automation, what are you excited about?

What are the things that you see happening that people should be thinking about more and kind of start planning for now, because automation will become, hopefully, more accessible to us all? Yeah. So, I was recently at the Cisco Live in Vegas a couple of weeks ago, and there were a few companies there that were doing some pretty interesting things around how do you convert automation in the agentic age effectively.

And so, what looks to be the most interesting is It does kind of fall into that democratization of capability because companies like ours, and even people who are operating in mid-market, they've now got access to the tools, as you said, right? So that ability for anybody to be able to go off and generate something that is unique and solves a problem, and that we can then proliferate back out into our broader customer base, that to me is an opportunity that I don't think we've seen in quite a while. And the other area that that touches on is kind of in and around cybersecurity and vulnerability management and things of that, that lifecycle management of all of your equipment.

I think, the AI and kind of the agentic age in this space around network operations, IT operations, and security operations, I think those things we're going to start seeing a convergence there, and people are going to be able to get a much better view as to what their threat surface is and how they can maintain their IT operations and compliance better than they could previously. Again, with the same staff or maybe fewer, depending upon how it goes, right? But that, to me, is the most exciting thing around automation, is that we've got tools now that are going to make everybody better, everybody faster, and everybody more productive.

Now, they could also be used on the flip side from a bad actor perspective, but I tend to be an optimist around these things. So, I'm kind of looking at it from the perspective of it's giving us an advantage to get in front of where the bad actors might have originally had an edge. We now have the edge back, and we can use that to help protect your operations from cyber attacks or even involuntary human mistakes, as it were.

When I look at it, the upside is we can now basically express an intent, and the prompts will get created to therefore create the code or whatever it is we need to create to go automate the thing. Yep. And that is a good thing.

The downside of that is, it's one thing to be wrong, and it's another thing to be wrong at scale. And so if I have my intent- For sure ... that's not right in the first place, I'm about to wreak some havoc.

So how do we kind of strike a balance between what it is we want to automate and our good intentions, which we all know that road is paved with. Or, is there some other way to think about maybe some way to roll these things back or test them before we let them go completely live at scale? Yeah.

So I think you're hitting on a construct that really goes into kind of what is the definition of resilience. So when you think about a resilient design, and in our case, we're mostly focused around network resilience. So in order to have resilience, as you said, you need to know what your intent is, right?

What is your design point? How is it you want to operate? The next thing you have to be able to have is insight or visibility into it.

But if you have those two things and you don't have control, insight without control is just awareness. If you can't do anything about it, so you mentioned kind of rolling something out at scale. Well, if you break something and you don't have the ability to go in and control it, that intent and that insight, again, it's just awareness, and you can't do anything about it.

So in order to have true resilience, you also have to have that third leg, which is the control. And so, I think the next generation of automation and tools in order to be able to manage networks and IT infrastructure is that concept that kind of three-legged stool of resilience, where you do have the intent and the ability to be able to know what the current state is. Does it match?

So do you have insight into match? Is your design state exactly what you intended it to be at the current time, right? And then, when the crap hits the fan and everything goes wrong, do you still have the ability to control it?

Can you still get in and remediate any problem that might have occurred as a result of a poorly written automation script, or it could be a cyber attack, or whatever it happens to be, whatever it is that then causes you to not have traditional control through it. So I think that to me is the key, is that idea of resilience around those three pillars. So ultimately, what is your best advice then to IT professionals out there who are all probably having this conversation with themselves?

On the one hand, I've yet to meet one that wasn't excited about automation because there's- Yep ... plenty of things that they do every day that they hate doing. On the other hand, they also have this feeling in the pit of their stomach that maybe, am I automating myself out of existence?

I don't know. All right. So you've kind of hit on two things that I like to talk about.

So the first is that, my recommendation is design it assuming it's going to fail. So if you're talking about if it's a greenfield or you're going into a brownfield, whether it's the network infrastructure or your overall IT infrastructure, your security infrastructure, whatever it is, you need to make an assumption that it's going to fail at some point. So if you assume it's going to fail, what would you change in the design in order to be able to help remediate it when it does fail?

So assume it's going to fail, adjust your design to be able to handle it, and then you can recover and have that level of control afterwards. So to me, that's really, I think, the key piece of advice I would give out in this space. All right, everybody, you heard it here.

Think like an engineer because that's how engineers build things. Because they put in resiliency- Exactly ... for failures, and they understand the implications of dependencies, which is probably the worst thing you can probably have if you're an engineer.

But hey, you'll all figure it out. I have faith. Patrick, thanks for being on the show.

Mike, I appreciate it. You have a great day. All right.

And back to you guys in the studio.