You’re Paying for the Same Network Twice

You’re paying for your network in ways you don’t see. Most teams don’t catch it until the bill shows up.

Traffic leaves the cloud for inspection, then gets sent back in. Every step adds cost. Most teams never map the full path, so it goes unnoticed.

Max Clark sits down with Doug Houghton from Alkira to break down how double egress happens, why costs can spike by 300x, and how these decisions quietly lock you into inefficient infrastructure.

If you’re responsible for network or cloud spend, this is the kind of problem you only catch after it’s already costing you.

What We Get Into
00:34 — Why SD-WAN Didn’t Solve the Problem (And What Broke Instead)
06:31 — MPLS at $3,500/Month — The Problem That Started It All
14:30 — SD-WAN Promised Simplicity — It Delivered Complexity
18:08 — When “SD-WAN” Meant Anything (And Nothing)
20:31 — $54 Billion Lost in a Day — The Real Multi-Cloud Risk
25:35 — 500 Sites, One Mistake: Asking the Wrong Question
34:33 — Eight Figures in Cloud Spend — And No VPN
43:07 — SD-WAN Didn’t Fix It — It Doubled the Problem
53:00 — Why Most SASE Architectures Break in the Real World
01:05:58 — 1,400 Stores, One Bad Design: The Michaels Case
01:13:05 — Legacy vs. Broken: What Should Never Have Been Built
01:43:41 — The Double Egress Problem Explained: Why You’re Paying 2–3x Per Request

What We Mentioned
Cloud egress pricing models
Zscaler architecture and traffic inspection flow
SD-WAN design tradeoffs
Multi-cloud networking complexity

About Doug Houghton
Doug Houghton is Director of Global Channels at Alkira, where he works with enterprise teams designing and scaling multi-cloud network architectures. His focus is on helping organizations navigate the cost, complexity, and tradeoffs that come with modern cloud and network infrastructure.

Connect with Doug: https://www.linkedin.com/in/douglas-houghton-9b77882/
Learn more about Alkira: https://www.linkedin.com/company/alkiranet/

About Signed
The IT market is built for sellers, not buyers.

Signed is the podcast for the buyers. Host Max Clark, CEO of ITBroker.com, sits down with CIOs, CFOs, operators, and founders who’ve lived inside real enterprise tech deals — the ones who can tell you what actually determined whether the deal worked, not what the deck promised.

New episodes weekly. An ITBroker.com podcast.

Full Transcript

Creators and Guests

Host

Max Clark

Founder & CEO of ITBroker.com

What is Signed?

The IT market is built for sellers, not buyers.

That's why 80% of tech buyers regret their last major purchase. Deals take longer than they should. Teams get locked into platforms that don't fit, contracts they can't escape, and vendors they wouldn't choose again. The pitches, demos, and analyst reports are built to close deals, not help buyers make the right one.

Signed is the podcast for the buyers. Host Max Clark, CEO of ITBroker.com, talks with CIOs, CFOs, operators, and founders who've lived inside real enterprise tech deals — the ones who can explain what actually determined whether the deal worked.

Plus weekly Playbooks breaking down the moments that matter most: renewals, M&A, compliance mandates, office moves, budget cuts, and the specific plays that separate buyers who get it right from those who regret it.

If you're responsible for choosing, negotiating, or living with the consequences of enterprise technology, this show is for you.

New episodes weekly. An ITBroker.com podcast.

[00:00:00] So I leave the cloud to go to the Zscaler proxy, get the traffic inspected, return to the cloud. Now mind you, I paid egress as soon as I left the cloud. And it's either nine cents a gig an hour over internet or about four cents over a layer two circuit, like a direct connect interconnect from Google or ExpressRoute from Azure.

And go back to the user.

I have a ton I want to ask you. I'm trying to, I've been thinking about how to start this, which is before we get into the customer stories, I want to go a little bit out of order, which is like inception founding idea, right? Because founders came from other SD-WAN platforms and let's start there. Okay. So [00:01:00] I work for a company called Alkira, as you're well aware, and Alkira was founded by two gentlemen, they're brothers, Amr and Atif Khan, and I've worked for them before at Viptela.

And it's probably good to go back to 2012 at the birth of, and even farther, or further rather. So Martin Casado comes up with all of these patents, and ultimately those patents evolve, or the ideas behind those patents evolve to, as you're probably well aware, software-defined everything, right? So Martin's at VMware at the time, I think, when he's getting these patents.

And then he goes to become an investor, like a lot of guys who make a lot of money in the Valley, they go and find small companies. And I happen to land at CloudGenix, right? I was the second sales guy hired at CloudGenix. And I get an opportunity to meet Hans Robertson, who's one of the founders of Meraki, and Martin Casado, and we're all hanging out in the bar, and it's [00:02:00] me and the CEO and a couple other folks right there.

So I'm kind of picking Martin's brain because you don't really have an opportunity to do this very often, right? And this is, you know, if you're a networking nerd, he's one of our heroes, right? So he's telling me this, that, and the other. And CloudGenix had kind of a really interesting architecture. It was Kamar and Manny and Mukhtiar and all those guys who founded CloudGenix.

They came from Cisco WAS, the wide area acceleration, whatever it was, solution. And it was an inline solution, right? So you've got data center. There's no separation of control plane and data plane, which is kind of an issue when it gets to scale and funny story. We had about a whole bunch of gear inside of, let's just say, a big American bank.

And, uh, there were a bunch of bad DIMMs. You probably remember this, uh, dual in-line memory modules that came out in, uh, what [00:03:00] this would've been? 2014, '15, '16, right? Around that time. And everybody suffered the same problem, right? The DIMMs caught fire, the data center caught fire. The customer's like, "Hey, my data center's on fire, and your box is the cause."

And so, I mean, to CloudGenix's credit, we got that box replaced. When I joined Viptela, 2015 area, you know, and started working for, uh, Amr and Atef, um, they had a different architectural approach, and it's relevant to both Viptela and Alkira. At Viptela, we were virtualizing the underlay, right? Which is what Martin really came up with.

But we're also decoupling control plane from data plane, which gives us a scale. So nothing's in line effectively, right? I've got a, I've got a bunch of nodes basically connected to a bunch of BFD tunnels that are getting instructions from control element or an orchestrator that's been decoupled from, from the [00:04:00] data plane.

So the forwarding plane stays up. And the reason this is important is when AWS East-1 goes down- Never happens ... uh, it happens so often. When the cloud region goes down, if you're, if you have an inline solution like CloudGenix and now Palo Prisma, you... And this is not, I'm not, you know, talking trash, I'm just stating the architectural facts.

You're a bit limited on what you can do on the forwarding plane, right? If you lose your data center node that's driving the traffic. When you decouple control from data plane, all, you know, the tunnels, the BFD tunnels that at Viptela, you know, we would just advise people, "Well, don't make any control or orchestration changes.

Don't make a policy change in the orchestrator- Right ... that would influence the data plane, because effectively, you know, they're separate and they're... And you've got this outage." So with the most... And, and, and that philosophy [00:05:00] is kind of one of our, the driving forces be- behind Alkira, but we'll get to the founding story in a second.

Why it's relevant in outages is you can route around things like AWS East if you have a forwarding plane that, um, is, is not dependent on the control element. Same with a CrowdStrike. You push... I'm driving across the country, so the wife and I move out from Washington DC to California. You know, we've got some family stuff we need to take care of.

So we're on the drive and CrowdStrike pushes the bad code, right? And it's like 4:00 in the morning and I'm stopping to get gas, and I get my credit card out and I hit the POS and nothing. Yeah. And I'm like, "Well You know, I typically pay my bills. So I try all the credit cards and none of them work. And I'm like, this POS machine is down.

I go in and the guy goes, yeah, none of that's working. It's cash only. And I'm like, well, is the ATM working? No, the ATM's not working either. I'm like, well, [00:06:00] you know, that's a problem. So yes, I call into support at Alkira, right? Because it's during my tenure at Alkira. And I'm like, are we up? And sure enough, we are.

And it's largely because we're able to The forwarding plane exists as its own separate element effectively, along with the orchestrator and the management plane as well. Early SD-WAN was let's get rid of MPLS. Indeed. That was a big part of it. And then we get all these different SD-WAN implementations.

People have different – you talk about CloudGenix, now Palos, and there's a lot of different approaches to it. How much of Alkira was we're going to solve a problem or we're inventing a new solution, right? Like it's on that scale, like, oh, we did it this way. It wasn't the right way. We're going to do it a different way.[00:07:00]

Or was it just like there's just a different problem out there we need to solve? Amr and Atef are trying to solve a different problem. We are solving a different problem. And that is between all the different cloud service providers, from AWS to Oracle to Tencent to Ali to IBM to Azure, GCP, all of it.

They all speak a different native networking language. They have different native networking constructs, right? And so they set out to remove the complexity of multi-cloud networking. But, and maybe more interestingly, they really, they took a look at the Equinix model and the Megaport model and all of the on-premise data centers, which are really the, you know, and have been the gateway to cloud, right?

It's a cross-connect inside of each of those. It's 18 inches. You know, you're moving from one port to another port to get up into this ephemeral [00:08:00] abstraction we call the cloud. They go, well, why don't we just build a virtualized co-location facility inside of each of the cloud service provider AZs, the availability zones.

And, you know, these are routing guys, right? Which is really the sort of the kernel or the birth of the idea. If you start with routing, you never really go wrong. And you'll get arguments from Jay at Zscaler, right? He'll say, yeah, you don't need any routing. Okay. But again, let's go back to the AWS outage.

Let's go back to the CrowdStrike outage. And let's go back to any sort of routing where there's You know, like, it was maybe three or four weeks ago, we're on with a customer in AWS. AWS, by the way, has had, uh, I know that you're aware, they've had a fairly significant brain drain. And y- there were a ton of smart [00:09:00] people at AWS, and there still are, don't get me wrong, but there are not a whole lot of routing guys left.

Yeah. Right? Yeah. So we do a lot of support for AWS, and we do it ostensibly through our customer who's having a problem. And, you know, at, at first it's always, and you're, you're in the business so you get this, it's always everybody points fingers. It's always the network. Yeah. It's the first one, for sure.

I... No, it's always DNS, but- That's not exactly an inside joke, right? Everybody should know that joke. I think at this point everybody should get it. Right. So we, we end up supporting AWS to solve various customer issues, and it's always some sort of routing issue inside of the AWS stack. And you're just like, "Hey, what happened to all your good, you know, sort of routing nerds," right?

Well, they retired, they got riffed, they got laid off. They're, they're working at some b- some... They're working at GCP now, or something like that. [00:10:00] So Amaranath have set out to virtualize a co-location facility in each of the cloud regions and to normalize the communications, uh, between the different cloud service providers.

They do it with a, a routed overlay that sits on top and uses and iterates on the cloud infrastructure. So not only do we use the... You know, what we effectively do is attract customer traffic to a big VPC that contains our stack, right? Or a VNet or a VCN, whatever. And, and that, that's cool, but what the, the really neat thing is, is if you overlay all of public cloud and you normalize those communications, you don't have any barriers to enter the cloud.

And when I s- it's not a financial barrier in the traditional sense of barriers to enter a market or what have you. It is a, it's a technical... Uh, [00:11:00] it's a, "Hey, I need to go get AWS certified, GCP certified, Azure certified, OCI certified," and that takes time and effort and money. If you, you know, like I wonder, and I'm sure you do too, like remember it used to, the guys with a CCIE number less than 5,000 were making big dough, right?

Because they're, they were the cream of the crop, and they went through the program. Um, they had all those technical certifications. There aren't a lot of those guys left In the last 15 years, networking has gone to basically zero. Right. Like, it's, it's, um, uh, you know, you have, I have lots of conversations with new companies, new clients, and you get this perception of like, "Oh, it just works at my house.

Like, I just, you know- Right ... like, like I, that's what I want in the office. Like, I just wanna be wireless everywhere. We don't need to have wires. We don't need to have a network. We can just be wireless." And you're like, um, you know, you wanna put, [00:12:00] you know, 600 devices in this footprint. You, you know, like, it doesn't work this way, you know?

And, and you can't... But there's a lot of things where it's like you can't, you can't... People have to experience it before they understand it, uh, to a certain degree. You can't, you can't get into a conversation with a CTO who's never had any experience with running physical infrastructure and explain to them like, "This is not how physical infrastructure works," or what the trade-offs or the, or the negatives of this plan that you have is.

Some- you can counsel, but sometimes you just have to let them experience it, and then they experience it and say, you know, like, "Okay, we're gonna do something different." And the cloud is, the cloud's been really interesting in this one because, you know, this idea of like, y- you know, you say like there's the, this drain of, of, of routing, of router nerds, right?

Like, I'm, I'm a n- router nerd. The no, nobody has any idea what's going on anymore. Uh, you, you mentioned earlier also- It's sad ... you mentioned earlier with, with, uh, you said some- two, two things I, I wrote down here. It's always the network. [00:13:00] Um, I had a, a framed plaque in my office years ago, and it said, "Don't blame me.

It's a network problem." And of course, I was a network engineer, right? So that was the inside joke. CloudGenix, um, my fr- a friend at CloudGenix coined the term, you know, time to innocence. And CloudGenix architecture, you know, in terms of what they were doing on the edge, was really interesting and, and tracking and making, um, path decisions based on the actual layer seven, you know, performance was awesome.

But then you, you start unpacking the rest of the architecture and you're like, we have to pin all of this in a hub-and-spoke back into a data center, you know, and, or, or, or multiple data centers. You know, like, what problem are we solving here, you know? It's like you're solving a problem for the edge connecting to, uh, centralized resources if you're a large bank and that's what you have 'cause you still have physical data centers.

Um, and then Palo buys CloudGenix and, and, and then overlays Prisma on top of it, and then you... W- when you start whiteboarding out that solution, [00:14:00] I, I don't know why you would implement it is basically where I get to. Is no comment an option on this? No. Uh, I think you are exactly right. Right. So when we started the conversation about MPLS, what- The deprecating your MPLS bill was sort of the goal, right?

If I can remove some of that cost and come up with a way to virtualize the underlay and move traffic between links, I can take advantage of internet. And internet along the way, you know, CloudGenix was founded just like every SD-WAN vendor before in 2012 when MPLS was still $3,500, $4,000 a month in most markets, right?

And that's when you've got the 600 sites, it becomes cost prohibitive, or at least it's a big nut that you have to contend with, limits your ability to scale up from a personal perspective and do interesting and elastic things. And then you've got this, and we'll get back to the CloudGenix architecture [00:15:00] in a second, but you've got this sort of new domain space, right?

And the new domain space is just sort of an ephemeral data center, right? You're abstracting a data center out of a data center and you're providing tools to build applications and you're doing all of this cool stuff, right? You've got storage, you've got databases out there, you've got different application vehicles that help people build the front end of application.

And then you start really taking advantage of what the elasticity of the cloud and what it has to offer and the speed to market. Not only does the time to innocent change, right? But if you look at traditional architectures, that time to innocence almost increases, right? Dramatically. [00:16:00] Because you now, remember when SD-WAN first came out, we got rid of MPLS, we moved to an internet and MPLS.

So you still had a little bit of it left. And then you had more stability in internet, you had more pipe for less money and people go, well, why can't I use two internet circuits out of my SD-WAN appliance? I can do all this cool stuff. I can move voice traffic over from link to link. I can, at a layer seven perspective, take a look at loss latency in general and different application metrics like round time stuff, round trip stuff.

That was really cool, right? But when you now have a new domain space at the top of the stack and largely applications, a giant subset of applications have moved to this new domain space, then you've got a new and evolving issue, which is, hey, I've got workloads in data centers that I don't [00:17:00] have the talent to manage, right?

And I see that as sort of the first problem, right? This complexity. And that's what Omron Auto set out to solve. Time to innocence, as I recall, was coined by a fellow called Vijay Sager. Is Vijay a friend of yours? So, um, I got it from a- another person at CloudGenix. Oh, okay. Right on. Fair enough. But- Vijay's a great guy, by the way.

But that, that was a really good experience, you know? The, the, the, the... This has gotten really... The, the frustrating thing about technology for me is you get into this situation where you're trying to simplify and make people's lives easier. I mean, that's like my... And we talk about we're trying to make people's lives better, right?

That's like our underlying mission statement. And technology improves the human condition, right? Like it's, it's this thing that like, it makes the world better. But then we get into a [00:18:00] situation where it's like, are we creating more complication than we're simplifying along the way, right? So we have this SD-WAN thing come out, right?

And then everybody wants to run in and say, "We're SD-WAN." Right. And you have the original SD-WANs in, in 2012 that were solving, you know, MPLS, like how do we get rid of this $3,500 cir- dollar circuit and, and move it to something so we can have only one or m- or none and use the internet? And then you find out like, oh, there's all these like hairy things about the enterprise that we didn't think about.

You have NAT traversal issue, NAT boundary traversal issues with like voice traffic and real-time media, and like all these other things you have to solve. And so then you have to now account for a gateway, and you have to have that gateway routing traffic back, and then you have all these things and, and, and your visio just gets worse and worse and worse.

And then what's the next stack in this one? You know, and then of course every vendor's like, "Oh, we're cloud managed. We're SD-WAN," right? So now we've got these boxes, all these boxes that claim that they're SD-WAN, and you're like, "You're not SD... Like, what are you actually doing?" I'm not gonna name names, but I can get on that rant.

Talk later. Yeah. Um, so we go down that path and then, and [00:19:00] then it gets even more complicated 'cause then we get SSE and SASE, right? And like, you know, and then the, and the people that coin the terms SSE and SASE c- you know, can't even really define what SSE and SASE is anymore. Right. Um, and then of course in the modern enterprise, depending on where you are in that life cycle, do you have a premise?

Do you not have a premise? Do you have a data center? Do you not have a data center? Are you in-- Do you have cloud infrastructure that you're managing? Are you single region? Are you multi-region? Where are your SaaS applications actually housed out of? And, and you start to unpack this, and I don't think a lot of people really spend a lot of time thinking about where their applications and their data actually resides, and what problem are they trying to solve anymore.

Right. They're, they're-- I think that they're starting to. Uh, so GCP had a really, uh, you know... I think you and I are of the, the same mind that the objectio- the objective for a business should always be to provide a simplified [00:20:00] operational way to make a problem disappear. Mm-hmm. Right? To solve, uh, we always focus on solving a customer problem.

But- Sometimes it takes a while for the customer problem to present itself or to evolve. And I'll give you a great example. So GCP, they have a big Australian pension fund, right? And the pension fund one day, it's an Australian pensioners fund. It's $54 billion worth of dough. And it's basically, you know, for all intents and purposes being stored in GCP offices.

And then there's an issue, probably a DNS issue. But they lose a bunch of the Google VPCs that contain the $54 billion worth of pensioner dough. They had to go back to the tape, [00:21:00] believe it or not, the tapes They had it. No kidding, right? Yeah. Otherwise, you know, you've got no idea how to The money itself is not going to disappear.

Just the record of who owns the money and how much it was is really what we're talking about. Those are fairly large stakes. I'm not sure that was the first instance where enterprise customers decided we need to be multi-cloud, but it certainly was a pretty good reason to sort of not keep all of your eggs in a singular basket, right?

So, okay, you solve a problem at the same time you're now creating another problem, which is, hey, GCP is great. They're great tools. Google is an ongoing concern. I don't think they're going to go anywhere. Yeah, we had a little blip. We lost $54 billion, but, you know, who's counting, really? So you move some of your assets into AWS, and maybe [00:22:00] you're aggressive and you go Azure and Oracle as well.

Your guys are GCP guys. They don't know jack about those other properties or those other data centers with those different tool sets and native networking constructs. How do you remediate that lack of knowledge, of FTE knowledge? How do you get through that new problem gate easily? And that's the whole purpose of Alkira is to decomplexify the different cloud service provider native networking constructs and to make it so that a username and password and a little etch-a-sketching your network together.

You said Visio earlier, which kind of made me laugh. Yeah, going way back there. We just do it in real time now where we're architecting. We automate the attachment of all the cloud workloads. We automate the attachment of the WAN workloads. And then we allow you to instantiate services in the middle as virtualized network functions, [00:23:00] right?

So it finds the fastest path to your SaaS app. And you take a Palo Alto Net Checkpoint or Cisco firewall. As a VNF, you put it in the middle of our stack. And let's say, you know, we're full mesh active-active, right? So, uh, and we always deploy in HA pairs. So customer brings the packet to my virtual port, our virtual port.

The Palo's sitting right there, and it's talking back to the Panorama 'cause I'm gonna get the IP address. The customer's gonna enter the IP address of the Panorama server. So they're reusing the same policy that they've always had, right? And that CXP operates in AWS the same way it does in Azure, and our CXP is the cloud exchange point.

That's our virtualized co-location or n- our network infrastructure that we are giving to our customers to use and build their networks. Now, you've got a CXP and GCP Azure in AWS, and they all operate the same way. It's the same workflow. They speak the [00:24:00] same language. And so if you're the pensioners who've lost $54 billion and the folks that need to support that fund, you can move that, those zeros and ones from one cloud to another with no, no issues, because it's gonna operate the same way.

It's a username, password, and then you construct a really simple network. That's very complex, of course. Thing that's, that's, like, rattling in the back of my head as we're talking about this is

from an architecture standpoint and what's actually deployed, let's just s- focus on the edge for a second. Sure. You s- they, they... You still need something on the edge. Absolutely. You know? There's still something providing, I mean, what we call now SD-WAN for most people really just means, like, path selection of our internet circuits, right?

Sure. Because y- you are taking and building IPsec tunnels to some- or the, the edge is taking and building an IPsec tunnel to you- Right ... and then you're providing routing. So what's interesting about this [00:25:00] architecture for me is you're, you're, I don't wanna say virtualizing routing function, but, um, you're providing this orchestration and control for routing for a diverse set of workloads and, and applications.

Yeah. So let's start with the edge. If I've got... I had a really interesting, uh, conversation with a partner. Um, as you know, I take care of all of our partners. And he comes to me and he says, "I have this gaming company, and they have, uh, 500 sites, and they need to update the, the ISRs, the Cisco ISR routers in these sites."

And my first thought was, uh, "Why?" "Oh, well, they're at this end of sale." And, like, I've worked at Cisco. When they're end of sale, you got another 18 months, two years probably. You can go gray market and- And you can go gray market. Yep, yep. And then, you [00:26:00] know, you've got a lot of people out there that can support C- Cisco appliances and- Yep

so I, I say to him, "Uh, okay, well, what are you gonna replace the ISRs with?" And he goes, uh, "The customer's thinking about putting the PANs in there." And I'm like, "Okay, wait a minute. So you're gonna put firewall in, in there, right? And you're gonna put tunnels in and out of the firewall?" "Yeah." I'm like, "Okay.

How many sites?" And, and right now I'm... I know you're shaking your head, and I was- There's so much. There's so much ... there's so much wrong with that deployment, but whatever. Because it gets worse. I'm like, "Okay, where are these, where are these, uh, the ISRs that you're gonna replace?" "Well, here's the funny thing.

They're all in casinos." I'm like, "Well, what's your change window and timeframe look like?" And he goes, "Well, that's kind of the rub." I'm like, "Yeah, because these places are open [00:27:00] up on Christmas- Yeah ... and 24/7 all the time, you're gonna take their n- device down and replace it. So what's that gonna cost you?"

And he's like, "12 million." I'm like, "Okay, wait. The Palos and the trucks, plus the labor, and getting into the casinos, which is gonna take you years. All right, I have a better idea. Don't buy the Palos. Sweat the asset, maybe kick the can down the road a little bit, but as long as it can build a tunnel, you can then tunnel out to the virtual port on our exchange point in the cloud.

So there's, you know, it's like a... Gone are the days of thinking about an on-ramp. Ours is just, here, I'll give you a little bit of a Python script, and you paste it into a CLI, and then you find the virtual port, and you join a global network with a high throughput, low latency backbone that rides across all [00:28:00] clouds, gets you into China and out of China, all of that stuff, right?

What about that idea?" "Well, the customer really likes Palo."

I'm like, "Okay, man. If you can lead a horse to water." It's- But I have the same issue as you do. Uh, I- I, I got introduced to a company, and they were a complete Cisco shop, and they had hired a, a new CTO, and the CTO, you know, the first time I spoke with him, it was, "Oh," you know, um, what was his phrase? It was something like, you know, "C- Cisco isn't great, so we're gonna replace everything with Juniper."

And, and my first question was this: "What do your employees know?" You know, 'cause Cisco CLI and Juniper, you know, at that point it was iOS. They weren't on iOS XR, which I get it, if you were on iOS, you wanted to be off iOS, right? But, but it was like, "Oh yeah, we're just gonna teach... Everybody's just gonna learn Junos and become Juniper people."[00:29:00]

I'm like, I- I'm like, "This is not happening for you. Like, I, I'm sorry," you know? Um Wow. Needless to say, they spent a lot of money and they didn't finish the project. Like, it was just... It's, the change management, I had this explained to me by, by a, a similar story going through it and you're like, "Okay, we wanna roll out a software patch."

You know, like you have 1,000 endpoints, you know, firewalls deployed or, or routers deployed in your field, you know, which is not a lot of equipment. 500 sites, two devices, it's 1,000 devices, right? And you're like, "We have to go through a change management process before we can certify and apply a patch."

And you're like, you can only do so many in your, in your window, in your windows once a week. And you're like, "Okay, if you can do 10 devices a week, you've got 50 weeks, you know, 50 or 50 locations a week, you have 50 weeks to roll this thing out." So you're like, "Great." So by the time you patch your entire fleet, you're like y- y- you know, you, you never catch up.

You know? It's just, it never f- it never ends. Right. And, um, but it [00:30:00] also, it's like th- the role of your, the role of your edge and your accom- what you're trying to accomplish changes a lot. I had a, um, I had an executive tell me, you know, he was trying to build networks and his phrase was, "I just want these things to be fancy Starbucks."

You know, "I don't want any, any sophistication on the edge. Like, I want nothing there." Right. You know? "I want people to have internet access." And it worked for them 'cause they were AWS native and they were all SASE native, and they didn't have any prem inf- I mean, this is years ago. This is, this is a long time ago, so he was new to the party in this mentality, but they were already there from an infrastructure standpoint in the business and they could justify it because they didn't need this stuff, right?

Yeah. They didn't have a phone system, you know? Like, it was one of these things. But now I see a lot of companies, you know, mid-market companies, 1,000, 2,000 employees, they've got one network engineer, you know, like to support your entire operations, you know? Like... And, and it, it, it's, it's a, it's a really interesting thing.

And of course, some of the big brand name firewall [00:31:00] vendors do a really good job of convincing executives that they're the only game in town, and if you're not running them, there's something wrong with your infrastructure and y- they, th- you know, your, they cast a sus- uh, the suspicion really well. Yeah.

There's a, a whole lot to unpack there, right? But I,

I think the, the majority of legacy vendors are interested in protecting share. Mm-hmm. And that they don't always... While the intention when they started and were founded was admirable and well-intended, I think maintaining that share has its own sort of, you know, bankrupt, um... It, it, it just because look- This isn't the thought, this isn't a- You, people engineer complexity into their, their networks to satisfy a vendor relationship that they have.

They don't always find the easiest [00:32:00] way of doing things. They don't always say, "Why do I have 500 Fortinet boxes at the edge? I'm five milliseconds away from the cloud. If I put a couple of 40s up in the cloud, tie it back to FortiManager, doesn't that accomplish the same thing?" I, I mean It-- By, by the way, uh, if you listen to earnings calls from any of these companies, this isn't like I-- and I think.

I mean, they will talk about what their replacement rate's based on, you know, um, generations of when equipment's sold, right? So- Right ... you know, part of financial management for any of these companies is if a box is sold in 2020, how long does that stay on service, and what's the replacement cycle for that box they're predicting revenue down the road for?

Right. And then where are they in that, in terms of that rep- what percentage of that fleet has been replaced, and is it tracking? Is it non-tracking? And, you know, now all these companies have to move into this, like, SASE idea, but that's a really complicated thing for them because it changes architecture and, and you have to do it in a very specific way because if you push people [00:33:00] too hard into this idea of SASE and, and cloud security, now you're opening up competition to come in, and do we have to evaluate architecture?

Do we wanna stay with you, or do we wanna go somewhere else? And, and that's complicated as well. And, and then of course you have the real complicated things, which is what do your employees and your support partners know and understand? And what can you maintain long term, and what can you get parts for long term?

And, and, you know, change management from, like, a rip and replace from a l- you know, a logo on a box is really complicated when you get it. It's easy if you don't have any infrastructure. If you're 10 sites and you've got nothing, like, who cares? Right. But, you know, you get into, like, this, these bigger things, it becomes a big problem.

How m- how much of this... You know, I, I know a lot of-- We work with a l- I, I can't. I can't say how specific I can get with this. I'll say I know a lot of companies that are single region AWS environments, and a lot of them have played with this idea of multi-cloud, and it usually was a workload, right? Like, let's [00:34:00] put, uh, you know, um, TensorFlow looks really fun.

Let's put BigQuery and, and, yeah, and, and TensorFlow workloads into Google. Yep. And, um, you know, the economic decisions that then force other architectures come into play. Like, are we-- Do we have an EDP? Are we under our spend threshold on EDP? Do we need to move stuff back over here because we need to l- You know, like, that becomes a real concern for companies, and there's, you know, this migration of data back and forth.

Um, you talk about complexity, and these clouds talk different languages. Mm. You know, I was introduced to a company, eight-figure spend on the cloud, right? And they were having a problem establishing a VPN between infrastructure. They were, they were looking at bare metal, and they couldn't get the VPN up.

And I was talking with their, with their team, and I was like, "Okay, you know, let me, I'll help you troubleshoot this VPN issue, and what have you done?" "Oh, we went and we clicked the button for VPN in the console, and it didn't work."

And I'm like, I don't... [00:35:00] And but, but, uh Okay. Of course it didn't work. You didn't configure anything , you know? Like, but VPN, but that's the thing, right? Like we talked about SD-WAN. I supported Cisco for a long time as a network engineer, right? Like every time I got a Cisco VPN up and running, I couldn't tell you why it was working.

You know? I was a fairly competent network engineer, and like it would work. It'd be like, "Okay, don't breathe on it too hard," right? Like... Yeah. Again, there's a lot to unpack in there. Um, I, I, I was thinking earlier that when have you heard a Palo guy come into a shop and say, "You know what? We're lowering the price on the, on the refresh gear"?

Oh, no, that's... Come on, that's not gonna happen. Right. There's always- It's a bigger box with more capability. Well, absolutely. There's a new... It's faster, feeds and speeds. It's, it's got all these new whiz-bang features. Deep packet inspection. Right. Right. [00:36:00] Um, although I have run into a pretty cool couple of companies doing some interesting work in DPI, uh, recently.

Uh, but anyways, that's, that's a different, different topic. You know what my question is whenever I hear that come up? Yeah. I ask, I ask the actual IT team- Mm-hmm ... show me your, your Outlook folder where you filter all of your alerts into. I wanna see what that looks like. Yeah. And, and that's the answer. All the DPI, if you turn it on, it's like one of two thing, uh, two things happen.

Either you turn it on, you kill your box, so you turn it off, or you turn it on, you get a lot of alerts. You filter the alerts out 'cause you don't have time to even look at them. Right. You know? Yeah.

I think our bias, uh, you know, for, for me, it's easy. I go and I talk to our partners about, um, disrupting traditional architecture. So we go back to the edge and go back to the SASE stuff. I think that's an, sort of a step along the way to probably what's a never... Uh, architectures are always evolving, right?[00:37:00]

Uh, m- my thing is it, all the architectures you should, uh, you should adopt or that you adopt should be extensible. You should be able to extend your architecture to w- without a whole lot of effort to a different place, to a different workload, to a different person. The person on the ground, and I've heard the Starbucks thing before as well, I like that model of just having an access point, whatever it is, and then doing, you know, some identity and context before you allow the person to access the corporate network.

I think, I think that's a good idea. We said in Starbucks, you hop on your VPN, you go through your credentialing, you've got a couple of, you know, your dual authentication, and you And then you're on that. And then you've got access to a subset of applications that allow you to do your job, right? [00:38:00] It shouldn't be any more complicated than that, but there are- It's so complicated though

a gazillion point solutions to address just that from, from edge to corporate network, no matter where the- I, I mean- Right? I mean, I mean, your description, I'm thinking about it in my head, there's like 11 acronyms at play, right? Right. Right. I mean, uh, uh, so you know the one of the things that we've been thinking a lot, we just turned up an NC- a, a MCP server, and I made a kind of like, uh, 'cause I'm old school, we're probably about the same age, right?

I made a Tron joke. It's... Remember the Master Control Program? Of course, that's where it comes from. I mean, let's be real. Exactly. This is what I thought. There are no accidents in tech naming. No, there aren't. Are no accidents. So, okay, so now you have e- entirely disaggregated applications checking different data sources, running across the entirety of your, your network, right?

How do you, [00:39:00] how do you secure that? How... I, I mean, you know, u- unless you have an extensible network that you can extend to all workloads, all data sets, all infrastructure, all people, and that it's not a barrier to, uh, the outcome you're seeking. And 'cause we all, you and I, we serve the business so that they can go on and do what they want.

And we forget a lot about that. IT becomes sort of, a- as you know, a business blocker sometimes because there's too much complex- Like my wife, my wife's in leadership at a big, giant, multi-billion dollar commercial construction firm. We'll just put it like that. And every time she has an issue, I'm like... I end up troubleshooting it, for starters, which was not part of the arrangement when I got married.[00:40:00]

But it is what it is, and I, I, you know, she's, she's got all the layer eight issues that you can imagine. Yeah. Yep. So I sit down at her crap ass Dell box and, pardon me, I, I should edit that out. Okay. My bias, Dell, to myself. And I solve her problem, right? And it's invariably, it's, you know, it's something simple that she's overlooked or something like that, and I get her back into her construction management program that allows her to plan the job and to, or do her MSR or to do this, that, or the other.

But I always think to myself, these guys are the IT shop at her, uh, her, her place of business They've got an impossible job. They've got an absolutely impossible job. And I have a lot of sympathy for them, uh, you know, sort of paired up with the criticism that I have [00:41:00] of them as well , which is not the, the kindest thing in the world.

But whatever. With... I'll move past my own shortcomings. So they've got job sites that, thousands of job sites that you turn up that you have to secure with a whole bunch of people hanging off of that job site, right? With a whole bunch of different appliances, with different, you know, different code, different OSs, different everything on them.

Further, they're gonna go and access a whole bunch of data center applications and a whole, whole bunch of cloud workloads and stuff. And, you know, it's a, a company that started in the Bay Area and was, you know, three guys that started it, and then they had a really good culture. They still have a really good culture, but it grew like wildfire.

And I'll go back to the extensibility. Unless you have an architecture that's extensible, [00:42:00] you can't address new domain spaces like cloud. You can't address, you know, the deprecation of a data center or trying to turn something down or a, a, a switch from MPLS to Direct Connect, ExpressRoute, Interconnect, or SD-WAN or IPsec, right?

You're... Y- I, I think their job is very difficult because there are no constants. It's all variables all the time. Well- I know you know ... the, the friction with IT for a lot of organizations is that IT is not making the decisions, right? So a b- the, a business unit makes a decision, um, fill in the blank, right?

Mm-hmm. But then IT has to run and own that decision, which then creates a lot of problems because, you know, you get into the cycle where, you know, shadow IT, right? Shadow IT comes about because people just wanna go get stuff to run their work, [00:43:00] and IT doesn't like that because now they're responsible for it, but they didn't choose it, which is the normal cycle anyways.

So then, but, you know, if you're in a, if you're in an environment where, um, you get yelled at when stuff goes offline because the business can't function, but you didn't pick what the, the choice was, and so now you have to try to engineer to keep the thing online when you didn't choose it in the first place, but now you own it, right?

Like, it, it, it's, it's designed to fail from the beginning, really, you know? And, um, y- you know, and it becomes really complicated. Y- you know, most companies, you know this, like most companies' IT teams are not reporting into technical leadership, right? They're an administrative function that, that's attached to finance.

And How does finance manage things? Okay, what's your cost expenditure on this? You know, we get these horrible terms I'll rant about forever, ROI and TCO. It's like, what are we comparing this to? We're comparing this to what we had beforehand, right? So now you're in an acquisition cycle where you're like, "We're trying to replace something because we can't qu- you know, we can't [00:44:00] explain the business requirement properly to actually justify this against revenue or expe- or whatever it is- Right

so we can, we can justify it against what we're currently spending. We're currently spending this much money on MPLS. We can replace it with this other thing, which is gonna cost us less money. Success. Let's go do it," right? And then you find out, like, was that actually a good idea or was it a bad idea? But now you're on a life cycle of five, seven years on this stuff now that you have to, 'cause you're not gonna get budget to replace what you just did for a long way down the road.

And, and that leads to other problems, which is, like, over- overprovisioning. I see more IT projects die because the IT team is trying to bank in overprovisioning because they know they'll never be able to get budget for this thing in the future, and then the, the company sees it and they're like, "No, we're not gonna spend that money on this thing," you know?

And, and it's, it's, it's crazy. Um- Think of capacity planning. I'll, I'll tell you a funny anecdote ... how do you capacity plan when you're not involved in the process in the first place, right? Exactly. So early in my [00:45:00] tenure, I used, uh, at Alkira, uh, we would, uh, we talked to a lot of partners, but we also talked to a lot of customers, right?

Uh, uh, attached to those partners. And I'd always ask this one question, right? I'm like, "How many VP..." If they're an AWS shop, "How many VPCs do you have?" Do they know? The thing is, is they always come back with a number that was fairly specific. "Oh, we've got 12 to 15 VPCs." And then you go into the console, and they have, like, 50 that they're unaware of.

Because, you know, the great thing about a new domain space, and the bad thing about a new domain space like cloud, its sort of evolution into our lives technically, is that it does become sort of the, uh, the, the playing field of all the shadow IT that goes on. So I mean, think about all the d- developers that have their own VPCs and they're just testing a function inside of an application.

Yeah. Right? And then that VPC has no firewall. It's internet-facing sometimes, [00:46:00] and you're like, "Wow." This show exists because of what we do at itbroker.com. If you're in the middle of a real tech decision right now, new technology, vendor selection, a contract that doesn't feel right, an M&A event that just landed on your lap, and so on, we help buyers like you get it right.

Independent strategy, sourcing, and contract negotiation. No kickbacks, no sales quotas, just someone in your corner. Schedule a call at itbroker.com. Back to the episode.

So as, as from the Alkira perspective- Yes, sir ... how much of this is fixing routing And how much of this is like future proofing around this merger between the network and the security stack?

So, uh, I, I mean, I think I... Well, I think you [00:47:00] know where I fall. I think I'll- the routing, the lost art of routing, um, which we automate, it's a BGP overlay, right? Um, will always be seminal, right? To, to-- We are who we are, right? We're networking people. We wanna get a packet from here to there, and we want to find the best path, right?

The best and most uninterrupted path. Um,

what-- I mean, what we discovered was is that there are problems within problems. There are always... Right, and I was talking about this earlier, you s- you s- with the pension fund. You solve one problem and you create another problem. Anytime you create another problem, there are interdependencies that become problematic as well, right?

And if I'm a person sitting at [00:48:00] Starbucks and I need to access my corporate network, again, you said it, there are 12 sort of things I need to contemplate just to attach that person to my corporate network, right? So it's always gonna be about routing for us. But, um, that's the foundation on which we grew the solution.

Now we're moving into sort of more nuanced terri- territory. And what I mean by that is like, okay, I kinda see the world as flat. I mean, I know the, the Earth is round, but I don't participate in that camp of craziness. But I see with a, a forwarding or data plane that can go everywhere and can accommodate, uh, connections from every corner of the world and every device on the planet is the ultimate objective, right?

The network, [00:49:00] yeah, should be kind of flat and should be really easy to operate. Uh, so we start with routing, and then we start addressing larger problems. And remind me the second part of your question, 'cause I started thinking about all the routing anecdotes and then- No, I was just like, what is, what is the future state problem here that we're building to?

Okay. So let's go back to capacity planning. You had, you had argued that, um, IT really no longer rolls up through technical leadership, that they're sort of chained to the- Depends on the company, but yes. Yeah, it depends on the company. Yep. Okay The, the IT folks are trying to do capacity planning, and they're, they're making the requests to, uh, get budget for that, right?

And they get shot down, and they can't do any capacity planning. Well, if you have the elasticity of cloud and you can... You know, we've k- we're, we're sort of transitioning, I think, and I'm getting your future state question, but we're sort of [00:50:00] transitioning to a, a consumption-based model. And I, I, I like this because it allows me to, if I'm a retailer at Christmas, to increase my firewall coverage area and/or to increase the resources available for the point-of-sale machines so that I can make more sales and create more credit card transactions and, uh, you know.

And if it's, uh, if it's usage-based or sort of an OPEX thing, then you can scale down after your busy season. And I see compute and storage in that way. The network had never really been that, right? We, we, we have in China... Let's talk China for a second. So we have a half dozen customers with facilities in China that they wanted to add to their corporate network.

But if they [00:51:00] did that in a, in traditional networking sense, they'd need to go get the three Cs, right? They'd need to get the Chinese certifications with not only, you know, the government and CIS. But AWS and Azure are there, right? And AWS and Azure have done business in mainland China for a while now, not just Hong Kong, you know.

So having-- With the geopolitical stuff that's going on and with the tariffs, despite the, you know, what I read in the various papers about, you know, Xi Jinping and our president making a deal to remediate the, the impact of the tariffs. Okay, there's still geopolitical winds that will influence, um, some companies' ability to operate in, in mainland China.

And so if they go in in a usage base or-- and they just consume what they need when they need it, right? And if it's [00:52:00] competitively priced, I can get my sites in China connected to AWS and then distribute that packet, that data traffic across to the, the corporate network from rest of world with a username and a password today in minutes.

And all I need on the other side, on WAN side, is an IPsec tunnel from the Chinese Office to the virtual port on our exchange point in, in China Two, two phrases I hate, and I'll -- are consolidation- Mm-hmm ... and convergence. And- Okay ... and consolidation I think is a good thing, but it's, it's applied incorrectly in a lot of places.

The- Agreed ... you know, but part of this whole thing becomes like, uh, hey, analyst releases some new acronym, so everybody tries to rush into that acronym, right? And people that maybe were good SD-WAN vendors or were, were solving a specific problem in the SD-WAN space or the networking space then [00:53:00] have to become also security vendors or go partner with some security vendor that has, so they can say, "We're, we're a, we're a full, uh, SASE shop."

Right. And then you look at the SASE shops, and you're like, you know, from a, from an engineer, right, from a network architecture standpoint, I think about these things and you're like, "Okay, we have functions that we have to deliver," right? Do we deliver this and do we solve this problem by putting in a SASE solution and use a CASB to access our SaaS application and, and have authentication and audit and, and then what do we do on our edge?

Do we have an edge? Do we not have an edge? Do we just have some sort of STP software running, you know, a, you know, fancy VPN software running on, on the client, right? But, like, where do we s- stick all this stuff, right? Do the firewalls have to exist? Do they stay on the edge? Do we reuse existing firewalls?

Do we, you know, what's doing the routing function? Okay, great. So y- you know, it, it feels like, you know, we've got this, like, ever-evolving, shifting Lego block, you know, kinda thing that's like, does it sit here? Does it sit here? Does it sit here? And it, like, and it, and it flows back and forth a lot, right?

[00:54:00] Yeah. And what I love about what you guys do is, okay, we don't care what's on the edge, right? Right. Build an IPsec tunnel to us. Right. But then you, you know, so now we shift part of the problem, but you still have the other problem, problem as well, which is how do I, how do I do authentication into, you know, my SaaS application and, and partition, you know?

And, and, and there's lots of people trying to solve this in different ways, and that's why I'm asking, like, like, how does this change the goalpost, you know, as this rolls out? So back to your future state question, right? If ... It largely depends on what the outc- the outcome the customer wants, right? And what they

I, I don't ever, uh, I, I guess I'm of a mind that there's no real end state that we're ever gonna get to, that there's gonna be this constant evolution in technology that enables better business, right? Easier access to ... Yeah, we've got this whole AI sort of evolution that's going on, you know. I always think of [00:55:00] AI as like a 911 GT3 RS or something like that.

It's a very fancy car, except it's, you know, h- you're driving on a largely legacy-riddled pothole highway, right? And so you, you kinda have to create a new highway system Right? Uh, to reach that future state and to solve that problem. I don't, you know, the, uh, y- the funny thing about the analysts are, you know, this is...

Most of them are really wildly smart, right? Especially the, the analysts in our space. But again, the vendors that they review participate in that market. Right. Okay. So, um, I, I look at SASE and SSE as sort of, um, an interim step on the way to a, [00:56:00] um, another evolutionary sort of apex, right? In, in our space.

You know, what you should be able to do is you should just be able to... The browser itself should be secure, and you should, right, you should have, like, a RBI on everything. Yeah. And it should come up to a secure environment. And like Hashi, that, you know, those guys are... I don't know if you've ever... I'm sure that you've explored Hashi and, and watched all their videos.

Like, that guy Armand, man, he could teach me how to make chicken soup, and I'd probably just be fascinated for hours on end, right? You watch his videos, I'm like, "Oh, yeah, I get it. I know what Vault is now," and all of this cool stuff. Look, uh, uh, I mean- Such a good product ... it's such a great product. We're a Terraform provider as well, by the way.

Yeah, but- And anybody who wants to create infrastructure through code, it's really cool, right? The, the ability to spin up in- [00:57:00] infrastructure and to spin it down, and to do so with four lines of code is really neat, in my opinion. And, uh, I... Look, for us, we believe in the, the, the idea of extensibility, and we believe in the idea of u- use what you need, and when you don't need it, don't use it and don't pay for it.

So our architecture supports sort of unlimited extensibility. And ag- a- again, it's really just, it's a very big fabric, and you've got a whole bunch of gateways and nodes hanging off of it, no matter what they are. And that, to me, is, um, a, a, a pretty good architecture. Okay, keep me honest. Yes, sir. Alkira is dominantly, um, network device o- you know, like IPsec to an existing router, an existing firewall.

We're not talking about client software that's running on- That's correct ... a computer. Yeah. So [00:58:00] from an architecture standpoint- Mm-hmm ... when you're, when you're making these decisions Is the first decision just really, like, what your network management or what your control point is, right? You know, do you want your...

You know, are you managing the network or are you managing devices, right? 'Cause this is a big thing with SASE. Well, forget SASE, let's just use SSE. Sure. You know, are you installing software on a PC or a Mac or a phone, and then that's creating the tunnel and doing the authentication and getting you somewhere, and then, and you're hoping that the underlay, whatever you're on, is stable.

But fundamentally, you're deploying to a computer, right? Right. In Alkira, you're deploying to the network and you're connecting networks together- Right ... in, in a dyn- you know, in dynamic ways. Right. Well, uh, uh, okay. So there are a bunch of... So after the SSE, SASE sort of revolution or, you know- Mm-hmm ... uh, interim step, then you get into zero trust.

Mm-hmm. Right? [00:59:00] We could have a long, arduous discussion about zero trust. Let's not. But, and, and just like SASE, and just like a secure services edge discussion, it's largely the OEMs that are defining the framework for zero trust network access, right? Mm-hmm. And the analysts sort of pick their horse, and we know how that plays out, right?

And they pick a couple of horses and they put it in a nice little quadrant. Okay. So it's helpful if you're a customer and, you know, there used to be an expression, and I'm sure you're familiar with it, nobody got fired ever buying Cisco. Uh, nobody ever got fired buying Cisco. That's the expression. I'm not so sure that's true anymore, but it, it probably is, right?

Because they've got... Cisco's got fabulous support, and yes, some of their stuff is, is difficult to deploy and implement, and sometimes it works, and sometimes it works on slides. Okay. But when [01:00:00] you... At the edge, we, you know, we do have a client. It's, uh, we have a ZTNA client. Um, but, uh, we'll work with any ZTNA client, right?

'Cause it's just the machine bringing us a tunnel. So whatever the client software is on the box that the end user is employing, we don't care. It could be ours, and it could be somebody else's. That, that's cool. We are very much sitting 5 to 10 milliseconds away from every office in America and most global offices around, or most homes in America.

And you have your ZTNA client on your box. You bring us that, that traffic, it lands on the virtual port, and then we distribute it, route it across and to where it needs to go on this sort of iterative overlay. Um, [01:01:00] yes, that's our approach. We don't care what's at the edge Uh, that's ... And on the LAN side, that's an entirely different domain space as well.

I'm not ... We don't go on the LAN side. We go from the other side of the router on the WAN or other side of the switch or the firewall, whatever is creating the tunnel, and take the traffic from there. It's in a VRF, right? It's in a segment. It's got its own isolated L3 routing table. And then all the way for the whole transaction, you know, you've got this secure finance traffic that's running from point A to point B no matter where those two points geographically are located.

And, you know, it's a high throughput, low latency network, like I mentioned. Um, so at the edge, that is not, um, an in- insignificant part of the network, of course. It's just not something that, uh, we do. Um, and it keeps us... [01:02:00] I wanna say it keeps our hands clean, right? That what we're really providing is network as a service without any hardware.

Or what, um, it really is, is network infrastructure that we are renting from the cloud and then re-renting to our customers. Doesn't it expose you though to... You know, we were talking about fin- finger pointing earlier, right? Right. You know, now you're dependent on client hardware at the edge to actually connect to your service.

Right. Is their internet connection stable? Do they have the ability to fail over if they're having latency, jitter, packet loss- Hmm ... TCP reset, whatever it is. Right. You know? 'Cause not all SD-WAN is the same. And also if you're using an SD-WAN implemented on top of a firewall, depending on which firewall vendor you've chosen, it's got a very different idea of how it selects a circuit, right?

And- Yes ... so how do you manage and maintain that service reliability and that visibility back to a, a network [01:03:00] team when you don't have control over what that connection is? Uh, that's a, a great question. We do... When the edge device initially makes the, uh... builds a tunnel and makes the connection to us, we get access into that last mile from the edge appliance through the rest of the, the route map- Mm-hmm

to wherever it's going. So we've got all sorts of governance and visibility tools inside of our solution that will tell you, "Hey, you know, this last mile isn't stable. Um, we're seeing, you know, latency increase or jitter increase or packet loss increase," all of that stuff. Uh, we do get engaged and we white glove everything, right?

We're still, we're a seven, seven-year-old company. We've been generally available for five years. Um, we haven't been down. Uh, our solutions, uh, stayed [01:04:00] Up during both of those earlier, you know, uh, instances I mentioned. But, uh, while I can't tell you anything that's happened on the LAN side of the device that's creating the tunnel, I can tell you everything that's gonna happen on the WAN side from a visibility, as long as we've made that c- Like, well, look, if last mile is down, we're not gonna see any traffic.

Right. Right? Um, if there are issues with the traffic, you know, your traditional sort of loss latency and jitter issues, we're gonna see all that stuff. We've got Wireshark con- uh, Wireshark embedded in the tool. We've got other tools as well. Um, uh, we build connections to various SIEMs like, uh, Splunk and, um, we've got a connection to ServiceNow for ticketing and all of that stuff as well.

But it's all API, right? You can build anything you want, um, and you could probably have your AI agent do it now through the MC- uh, MCP server. But [01:05:00] while we do give visibility, you know, uh, if the last mile provider isn't stable, that's admittedly outside of our domain space and not something we're gonna be able to remediate without engaging the, the ISP.

One of these firewall vendors we've talked about, their appliance for SD-WAN, right, has a five-minute default for failover built into their config. Like, their default config, if you enable it and say, "I wanna do, you know, SD-WAN and, and, and link selection." Mm-hmm. By default, it's looking for hard outage, and it's gonna give you a timer for five minutes before it fails over to another circuit, right?

It's like- Yep ... until you experience that the first time, you're like, "Oh, whoops, maybe that's a problem." But that... Right, because it, it, it It's always this interesting thing for me on, like, what's on the edge and what's not on the edge- Yeah ... I guess is the question. I don't know which ones of these I can t- we can, I can name publicly here, but- Uh, they're all public references, actually.

Okay. So, um, let's talk about [01:06:00] Michaels. Yeah. Because I, I, I think this is a- It's a great story, isn't it? A perfect one. So, um, background. Yeah. Michaels comes to us l- I think it's last year. Could be the year before, because they just kind of- Mm ... the older I get, the faster the years go. Right? I blame COVID. I have no sense of time anymore.

I, I have a really difficult time tracking when things start. Uh, any which way, so they come to us in September, end of September. They've got a freeze because they're a retailer on November 1. Really smart. Okay. Yeah. Um, most giant retailers have a freeze period, as you're well aware. And no IT gets changed.

There's no change windows. There's no nothing happening. And of course, stuff breaks during that period all the time, you know And that's probably when you make the majority of your money troubleshooting people's environments between November and January. The beginning of November to the end of January, Max is [01:07:00] making dough.

Okay. So they come to us and they're like, "We have a problem. We are-- Our point of sale machine is... We've got a database up in GCP. We've got the client device out at these 1,400 stores." The, the architecture was we're running the, from the client POS to the Michael's data center up to GCP. Okay. Right? So they're hairpinning the traffic from the edge through the data center, and they come to us and say, "We got-- We're having poor performance out of the point of sale machines.

A lot of them are not functioning properly, and we're a little nervous that we're gonna have a bad holiday season." Right? And it's end of September, mind you, right? And so we're like, "Okay, let's do a [01:08:00] tiny pilot to validate that we can solve your problem, and we'll take a half dozen stores or whatever and we'll, we'll turn them up and we'll show you the process and we'll do a proof of value, proof of concept and start this pilot."

And they agree, and we do this, and we show them that if you redesign how you architect the solution, the point of sale machines are actually quite stable. I mean, these are... Point of sale machines use what? Like at most three meg to five meg worth of traffic. It's like my Commodore 64 could've run that POS machine.

Right. Did you have a Commodore 64? I did. Okay. What kind of storage device did you have? Was it a tape cassette? Cartridges. Yeah. Yeah. Nice. All right. So, so we demonstrate by re-architecting it. We bring the point of sale machine out an IPSec tunnel, out of the store, straight up to the exchange, virtual port on our exchange, which is, as I've mentioned a [01:09:00] couple of times, five to 10 milliseconds delay at most.

And the point of sale machines magically, they start working again. We're like, "See?" You know, we... So then they're like, "Well, now here's our real issue. Um, our real issue is we have 1,400 stores," and now we're in, into the start of second week of October, I think. Do you think, Alkira, that you can get these 1,400 stores up?

Because there's also, there's a financial incentive as well, is because a lot of stores still have MPLS, right? So we're back to the MPLS game. We're like, "Yeah, we think we can do it." So we start rolling it out, and we send a little, you know, a little script. They... And this takes quite a bit of project management work on their side as well, because we're working with them and we're- On every turn up, right?

We're doing a turn up at 50 stores, uh, every day, right? That's what we start with. And, like, [01:10:00] everything goes... We, we email them the code or whatever. We, we send them the code, they paste it in the CLI, and they bring the store up, right? And we're able to validate that the stores get up, and it's like that.

It's really quick. And they're like, "Okay, now we wanna do 200 stores." We're like, "Okay, let's see. Let's do 200 stores." And same setup, right? They've, they're well-organized, they're motivated, they have this problem, and they have a compelling event, right? Which is, you know, in, in our wheel- world, that's, um, that's a really cool thing, right?

When you've got this event that's gonna happen, and if you don't bust ass... Uh, yeah. So at the end of 10 days, we publicly, we talk about 14 days, but at the end of 10 days, we had all the stores done. They were all up and running. There was no more MPLS in the environment, and they had largely bypassed the data center that they ulti- ultimately ended up, [01:11:00] you know, uh, getting rid of.

That's, uh... And then, uh, Srinivas, um, he's the, our champion at, at Michaels, and he ran the network. Uh, we, we were out at the GCP conference and, you know, and he did a bunch of press for us and stuff and said, "Look, I'm really excited about what we've been able to do. We've greatly simplified our environment.

Uh, TCO savings, I know you hate that word, but the TCO savings are significant- Yeah ... because we did get rid of the data center and we got rid of the, the MPLS that were, was in the environment, and the network is super stable. We can troubleshoot easily. We have all sorts of governance. We can tag traffic."

So, uh, you know, we do, in addition to segmentation, we do micro-segmentation through a, um, a group, grouping strategy. So you've got, for instance, y- in, in your, your segments are, think of them as, um, it's an isolated L3 routing table, like I said earlier, but they're [01:12:00] also, like, macro segments, right? Where I'm gonna put my production traffic in a segment, my non-prod traffic in a segment, my finance traffic, my sales, my POS traffic, my PCI POS traffic into, into a segment.

But then you get down to the micro-segment level, and I see this use case evolving a lot as well. Like, people will build applications in AWS, but they wanna use BigQuery in, in GCP. And so you're crossing clouds and there's, you know, uh, how do you do that? Because you've got two different sort of native networking languages and all that stuff And we use microsegments for that, right?

So the front end of the application, because that's all east-west traffic. And that's where you get yourself into trouble, as you're well aware, right? So that front end of the application is accessing that, from AWS is accessing that database inside of I can talk. It's just my tongue is like not so dexterous.

In GCP. So that application can only talk to that database. And anybody from [01:13:00] WAN side accessing the application is going to come up to the AWS front end and then, you know, you go get the data set. How much of this is legacy and how much of this is just bad design? Not in Michael specifically, but like when you talk about it from like an industry standpoint, like Michael's architecture makes perfect sense here, right?

What do they have? They had a legacy application that was in a data center, right? Because they've been around for a long time. See, so you have a data center and you have a legacy application. How do you service your POS? You have MPLS because that's what you need, right? You start moving your application in the cloud.

How do you connect to it? Well, you still have this MPLS network that's getting, right? This is a legacy, legacy, legacy, legacy, right? You've got all these layers of things that were implemented over the years and now you have to figure out how to modernize and it's not easy, right? But the other side of it, you know, which is like, I think the, let's say the bigger industry issue, like how much of that is just bad design?

Because you could still have, you know, do you need to have a hub and spoke architecture in today's world? Are people still building it? Are firewall vendors forcing people into this idea of like hub and spoke? [01:14:00] That's a great question. So I think, you know, people use the tools that are available to them at the time to seek and get the outcome that they want, which is, hey, I need to go from here to there.

You know, it's funny, but I used to work for the guy who built the first DMVPN network with MPLS for Deutsche Telekom. He was one of the early founders of Votela. There's all that stuff out there, right? So I think there is always a bias for us as human beings to, because we get really comfortable really fast with things we know.

And a disruption comes along like software-defined wide area networking or multi-cloud networking. And, you know, you try to take [01:15:00] what is and ultimately evolves into a bad architecture, a bad design into, you drag it into a new domain space. For instance, the SD-WAN is a great example, right? SD-WAN and cloud is, what happened with SD-WAN, as you're well aware, is like if you're a global company and you have an SD-WAN deployment, there's a lot of latency that you have to contend with.

So you end up building two or three disparate networks, right? And you've got a European network, and those guys might like the Fortinet SD-WAN vendor. And then you've got the guys here, and they like Viptela/Cisco SD-WAN, you know Yep. Everybody's on a different division, has their own rules. Yep Everybody's in...

Uh, uh, exactly. But you've largely adopted that strategy based on a technical problem you had, which is, hey, it would be better to have a singular SD-WAN network, a singular policy architecture, a single [01:16:00] OEM that everybody could learn and then ultimately on day two support, right? But because the Earth is a big place, and because we have a global, you know, business with offices spread all over the world, we have to build these three different sort of islands of SD-WAN networks, right?

All right, so cloud comes along, and the... You wanna drag this legacy technology, which is... And I know it sounds crazy to say that SD-WAN is legacy technology, but you wanna drag it into cloud because now you realize, oh, 50%, 60% of my applications have been refactored, and now they're in the cloud, and I've got this data center I wanna get out of, stuff like that.

And so what happens is you end up, you know, putting a virtual... I can tell you a funny story about PwC if you want in a minute, and the reason I left Cisco. You end up putting a, a virtual instance of your SD-WAN router in the cloud. Okay. And then you [01:17:00] have to do what? You need to peer, route, and configure with, if you're in AWS, the transit gateway, which is a beast, right?

It's like putting HA Palos in a VPC, right? The manual's 600 pages. Like, I'm not gonna read the manual. I mean, maybe I should. Uh, but okay. So your question originally started as, is this a bad design? I, I think it's a function of the tools available at the time, the problems that arose as a result of the tools that you employed, and the new domain spaces sort of entering into the market to enable different business outcomes.

That's what I think. So SD-WAN, you put the virtual, you do all the peering and routing, and then something changes. You know, uh, somebody comes and says, "Hey, you know, uh, Microsoft's gonna give us a smoking deal with their ELA." How many [01:18:00] times have you heard that in your life? "And we're gonna move all this stuff to Microsoft."

All right, so you start refactoring all the applications, then you have to migrate all the workloads out of cloud, and then you gotta point the, every device that you have on the ground to Azure, and, you know, Azure's got a fantastic network, right? Uh, I'm not sure that anybody works at Azure. They all seem to work at Accenture.

But that's a different topic, and I hope that makes you giggle inside like it does me. But okay, so instead of putting the SD-WAN router up there Right? And instead of, uh, paying... Because no, you know, it's a Cisco router or it's a Juniper router that you virtualized, or it's an Arista, uh, piece of equipment, or it's an HPE router, right?

It- whatever it is. You're virtualizing it, you do the routing, peering, configuring that you need. It's talking back to that service router inside of the cloud, the transit gateway, the VNet gateway, the VWAN, uh, the [01:19:00] GPC peering point, all of, all of that stuff. That's-- Those are complicated sort of transactions inside of the cloud.

Instead, why don't you decouple the virtual SD-WAN router that's in the cloud and supporting that traffic that's difficult to figure, and just bring it into a stack like Alkira, where, you know, you've already got the traffic coming in the virtual port on our exchange point. You've got a VNF of the, let's call it the V manage, uh, um, uh, whatever Cisco's calling the orchestrator now for Viptela, right there in the middle of the stack, and the transit gateway's largely been obfuscated, uh, because it's part of that, the same Alkira stack, right?

So now you've removed the complexity of transit gateway and the virtualized SD-WAN endpoint in the cloud, and all that routing, peering, configuring that needs to go on, and you've moved it into a different domain, but yet you've put it in the middle of all that traffic. So back to the hub and spoke, 'cause I think, I think a lot [01:20:00] about this too.

We keep... Think when you started, you started in probably... Like, I used to work at IBM, and I, I wrote big SQL queries inside of the AS/400s. And I- it was a great job. They paid me... I started at IBM, and it was, this was a long time ago. It was $28,350. And dude, I thought that was like the bee's knees. I had my own apartment.

I had a girlfriend. I could go shopping and get all of this stuff. I-- Oh, man. But I never talked to anybody, of course, which is my problem. Right? So, uh, but that was the environment I started in, and you would just have all the clients hanging off of the AS/400, and then I would just work inside of that database and find all the cellphone traffic that I needed to and all the billing tra- you know.

And I would write these giant queries, and it was really cool, except for the fact that I didn't get to talk to anybody, like [01:21:00] I said. And then you had an iteration, right? You had, uh... W- we've gone from client server, from mainframe to client server back to mainframe it almost seems like, in my opinion. Yep.

Right? Yep. And so, and along the way, everybody's well-intended, right? They're always trying to solve a, a, a business problem that gets them to the outcome that they seek, which is lowering costs, improving extensibility, or doing, doing whatever their, their objective is. Turning, making business easier for their business users to access the applications that help them do their jobs more efficiently.

Let's say that. And yet all of this stuff has evolved just like, you know, and will continue to evolve. There's not... I don't know if there's-- I mean, I don't have a crystal ball, but I don't think there's ever gonna s- IT is always gonna be evolving. And, and it happens in shorter and shorter [01:22:00] cycles now. And so the problem pretty much just stays the same, and the tools we employ and the solutions we employ, um, uh, hopefully change with it.

A lot of... It's very expensive to deploy large firewalls on the edge. Mm-hmm. You know, there's expensive a lot of different ways, but just like the capacity you need, all of a sudden you start saying, you know, gig-E is inexpensive to put into an office at this point. It used to be really expensive. It's very inexpensive now.

Right. 10 gig-E is relatively inexpensive. So the demand on the firewall on the edge is increasing rapidly. When you price out what it costs to deploy these firewalls, even though that cost is coming down, it's still, it's, it's shocking. You know, people have these moments. And, you know, you go back 20 years, and you had a lot of service providers and telcos come into the market and be like, "Hey, you don't have to run firewalls anymore.

We can run firewalls for you." And they go out and they buy these big appliances that they can virtualize, and they put it into a POP, and then you end up in these architectures, again, hub and spoke. [01:23:00] It's like you never escape it- Right ... where, you know, your edge is pinned to a device in your region, you know?

And, and if you're a, you know, company based in Southern California, near Los Angeles, you're pinned to a device, you know, in SoCal, right? If you were with Level 3 at the time, you were in Tustin, right? You know, it's just where their stuff was. And then you have an ex- Sold. Sold. And then you have an executive who goes on vacation- Yeah

and is, is golfing in Scotland, and then something happens, they need to get onto your network, and they have to pin their traffic from Scotland back to Los Angeles- Right ... to go back to whatever resource in Scotland. Right. And then all of a sudden it's not so great. Or the other version of this we s- I, I still see all the time, it's like, you know, you have this cross-border issue between Canada and the United States Or depending on where your IP addresses are presenting, you get different services from your SaaS applications and, like, it thinks you're in a different market because guess what?

You are. In the case of [01:24:00] modernizing these networks, right, MPLS or let's say you've gotten out of, off of MPLS and you've got some sort of, you know, manufacturer firewall edge going into a data center and now you're moving applications into the cloud, how much of this is just the change management issue of being like...

You know, 'cause you could, you could... A, a firewall manufacturer gonna come in and say, "Hey, you can build a VPN endpoint from your device on the edge into your new Google Cloud, AWS, Azure, Oracle, whatever you're, whatever it is that you're using- Right ... just as easily," right? Like, they're not gonna say you can't build VPN endpoints to it.

It's, it's auto-magic configuration, right? Um, they offer SD-WAN, right? So that's why you circle back to, like, is this, how much of this is legacy and how much of this is just bad design? Because when you start talking with these firewall manufacturers and, and force them to actually whiteboard out their architecture and their design, you know, two and two does not equal four, you know?

Like, it's, it, it, it gets really interesting very fast if you dig into it. [01:25:00] So, uh, th- this is a super great question because I don't... A- again, like, you, let you and I start in whatever, early '90s, right? And we are trapped in sort of a mainframe world, dumb clients hanging off a mainframe. And then you had things like Citrix come along, right, where you're doing VDI and all sorts of cool stuff.

I, I, I thought that was really cool technology. I still think it's cool. It's, it's shocking that it's not ever been adopted in a mass scale. There have been... Well, yeah, there, there are a bunch of cloud players that are talking about this topic as well. I, I, I know them all, but I mean- Yeah, exactly ... but in terms of, like, actual end user adoption, it's always shocked me that it hasn't been adopted that much.

I, a- again, I'll go back to the idea of I think we get trapped in this idea of... I, I, I use this example a lot. Imagine being the first [01:26:00] fuel injection sales guy, and you walk into Ford or GM or Chrysler and you say, "Hey, I've got this killer new technology, and it's going to regulate the amount of gas, air, and electricity or spark that gets into the cylinder, and it will do so at multiple altitudes, and there's no day two maintenance."

Ford tells you, GM tells you, and Chrysler tells you, "Hey, the carburetors worked for 100 years. We've got a whole line. In fact, everybody, every manufacturer in the world has a whole line set up to just build carburetors The first fuel injection sales guy is the most frustrated person on the planet. I suspect.

And because he or she can argue, "Look, this is a better solution to the problem you're trying to solve. It solves more use cases, and [01:27:00] it, you know, uh, it's, it's cost equivalent." There's still a bias to rely on designs that are tried and true, and I don't know how you eradicate that, that, that bias. And so, yes, there is just an absolute ton of crap-ass designs out there, right?

From the three separate SD-WAN global networks that you're maintaining and the different firewall. Uh, y- you know, I've heard certain people argue early recently that firewalls, especially next generation firewalls, are, are no longer relevant. I don't even know what that means, that term, by the way. I, uh, again, that was an analyst term.

Yeah. Actually, I think Palo came up with that term, right? By that term. Um, I, I, I think we're, we're sort of, we're trapped in our own bias, uh, as professionals because if, if the carburetor works, we stick with it [01:28:00] until we're forced to move. Now, you drove here in a car today, and I was driven here in a car today, and there's no more carburetors on the road, man.

How did that happen? The f- I, I love your analogy. Thank you. I'm also gonna argue with you about it. Please do. If you watch any videos... Okay, so now every car for fuel efficiency standpoint. So, so fuel injection, way more efficient. Mm-hmm. You know, your example, right? It can-- It works at altitude. If you've ever been in a carbureted car and you change- Right

altitude, right? Like, it's a problem. Yeah. This is a serious issue. Fuel injection solved that problem. It's way more fuel inf- uh, uh, fuel efficient. Mm-hmm. Next iteration is cars have to stop and start. Right. So cars that stop and start create more fuel efficiency. They're using less gas. Mm-hmm. Byproduct of that is it requires a lot more complexity in the system now- Yeah

because the car's constantly starting and stopping, you have issues with your temperature regulation for your cooling system. Right. Videos [01:29:00] of people, mechanics taking apart engines to fix thermostatic couplers in these systems, right? You know, so you go back to your carburetor, the carburetor had a, had a valve- Right

right, that was like this thick and, like, this big around and a hose that was- Right ... opening and closing based on temperature. Right. Now, you know, if you had a, a-- We were on a road trip and our, our, our thermostat failed, right? But, you know, it turned out that you could just un- you know, like the- Take the, the hose off

tow truck guy was able to just, like, unplug it, remove it- Right ... go in, we were able to get to a shop. Nowadays, this part is like, you know, this long and six inches around and has 47 hose fittings on it and a computer control chip and, like, everything else, right? It's, it's... So You know, so that analogy, I love the analogy- Right

but at the same time, that analogy is introducing a lot more complexity- Indeed ... you know, into this environment. Right. It's, uh, uh, so I have a, I have a good story. So Koch Industries was one of our early customers. Koch Industries has about, whatever, 75,000 employees. They've got 100-plus [01:30:00] business units.

They own Infor and TNS and Windix, you know, all of- Mm-hmm ... all of their sub-brands roll up to, to Koch. Uh, fair disclosure, Koch Disruptive Technologies was one of our, uh, investors in one of our early rounds, and Koch helped us, uh, with feature and functionality early in the cycle. And they, Matt Hogue, who's their CTO, is a friend of ours from the Viptela days, where he, you know, also helped us develop, you know, 'cause he's the, he's the customer.

He is the ultimate operator and end user, and he, um, had some really good guidance for us early in our tenure here at Alkira. Um, he had a really robust, um, deployment in AWS, and he'd spent, I think, six to nine months developing automation to, uh, take his hundred-some-odd business units and his 75,000 employees from the 70 different countries and get them attached [01:31:00] to various AWS tools.

The thing about the automation that he built is I think of it as kind of static. I know that's counterintuitive, but it's... Ultimately, you never wanna automate complexity, in my opinion. And you're absolutely right, uh, about the fuel injection, right? When... Have you ever... I remember one time I had to replace a headlight on one of my vehicles, and the mechanic says, um...

So I look it up on YouTube 'cause I'm gonna do it myself, right? And, um, I have to take the front bumper off of the car and then disassemble, like, a whole bunch of other stuff to get to this, you know, uh, it was one of the modular headlights that, uh, it was a German car. I'm like, "This is stupid." Like, you know, just in terms of the cost-benefit analysis of me taking the three or four hours that it's gonna take to do this and then, you know, going out [01:32:00] and getting that extra tool, like the impact wrench or whatever that I'm gonna need, is, it's, that's not gonna work, so I'm gonna pay somebody to do it.

So the, yes, uh, what we've really sought to do is to remove the complexity, right? So we are largely a routing engine. There are a whole bunch of compute and service nodes inside of our stack. Uh, it's sitting in the cloud. Um, but your point is taken, right? It, in Matt's example, Matt Hogue's example, the CTO, what he discovered after this deployment, and it was almost by accident, when his boss comes to him and says, "Hey Great job on the AWS stuff.

Can you now go do it in Azure? Because we just bought a company and they're entirely in Azure. And Matt's like, "No, I'm not gonna do it in Azure. That's insane. And it was a, it was trouble to just do it in, in, in, in [01:33:00] AWS, and I've automated a lot of complexity." Right? So what we... One of our design principles was to not automate complexity.

But, you know, it's, a network is a complex and living thing, and it, it, there is a certain amount of complexity because you're making thousands of connections and things are traveling at, you know, a million miles an hour all the time. What's an ideal customer for you? You know, because a single location, you know, I've got Microsoft 365 or Google Workspace- Right

and Salesforce and like a, you know, traditional kind of like knowledge base, like that's not gonna be a, a good- No ... Lcare customer, right? So what's... You could solve problems for them, but they're not gonna come seek you out, right? Right. They're not, they're not gonna associate that pain in terms of like go f- go fix it.

Right. What is that, what is the line that crosses and really segment, you know, separates like, like this is [01:34:00] where we solve problems? Uh, a- another great question. Thank you. Um, so I think if we go back, so I've been here four years. I think the problem that we solve, remediating complexity and normalizing communications between the various cloud service providers and providing network infrastructure that they can use when they need it and not use when they don't wanna pay for it or don't need it, um, is, uh, we were early to market, right?

There were, again, four providers in the space. It always seems to happen in fours in the Valley, right? Um, there... One was purchased, um, one closed up shop, and you've got sort of two remaining, and the third that was purchased was purchased with no customers for way too many millions of dollars and it's been integrated into a big OEM and they don't do a whole lot.[01:35:00]

There's your context for you. The, th- the cutoff of the line where it makes sense is everybody is... The market's now more mature, and the problem, like we've been working and white-gloving everything along the way, and our customers are, have t- traditionally been very large enterprises. That doesn't make our solution any less relevant for the person with 10 offices and a cloud workloads in two AZs inside of AWS across two different regions.

It, it does. It, it, it makes us, you know, we're still useful for that It's an incredibly complex environment. I mean, it's- That, that's right. Yeah. Uh, but now the problem is more pressing. Uh, the, the large enterprises obviously wanted to be multi-cloud because of the earlier example I gave about GCP's losing of the $54 billion pension fund, right?

Which is, [01:36:00] you know, not ideal. So everybody distributes workloads, and they use different things and different... You know, you use SharePoint, O365 inside of Azure, and you might use Copilot, and you wanna distribute Copilot to all the ends of the earth, and you can't get it in China and stuff like that. Uh, we can, right?

Um, which was pretty, pretty cool for one of our customers. That was one of their use cases. I thought that was really neat. Uh, we're like... So the market's now more robust. More customers of different sizes are multi-cloud. But it-- we used to think of it as if you had 10 separate cloud workloads, right? Or something like that, and let's say a half dozen offices, and you had an AWS guy but no Azure lady, or you had a GCP person but no Azure or AWS person.

That was, [01:37:00] you know, kind of the benchmark or the threshold for when it made sense. From, um, a cost perspective, and, like, because when you adopt Alkira, right, you are, uh, re-architecting. You, you know, just by definition, you're bringing us the traffic directly. You're avoiding a landing zone. You're avoiding configuring any of the cloud service barrier routers, right?

Like the transit gateway, VNet gateway, all that stuff. Um, and you're able to con- I'm gonna use your least favorite word here, consolidate services, uh, by virtualizing them and putting them in as an NFE or a VNF, whatever you call it. So the, it should be, the savings should be significant. The larger environments have more savings.

The smaller environments, there's sort of a cost equivalency that you're working towards. But in term- and then in day two, operational savings is significant, right? You are operating a complex environment in a simple way with less [01:38:00] people, so that saves you dough. So I guess it's, it's a hard question to answer 'cause it's sort of a moving target.

As the market matures and the problem starts to rear its head in more enterprises and SMB spaces, um, people will go and, uh, search out multi-cloud networking, network as a service, cloud networking, cloud internetworking, all of those things. Or even a cloud VPN or something like that'll get you to us, right?

Um, right now I think having... You can have a single cloud, but multi-region. And even with two or three VPC, VNet, VCNs or Google VPCs, that makes sense. Because that, even though it's a fairly modest environment, is still r- quite complex, as you, as you know.

I'm, I'm... My brain's spinning, like listening to this because- [01:39:00] My brain always spins One of the things that's really interesting to watch is vendors that come out to solve a problem that technology inevitably solves. And what I mean by that is, like, there's SD-WAN vendors that came onto market, and the problem they were solving was for high latency, low bandwidth links.

You know, and if you were operating a gas station chain on, on the interstate in the middle of nowhere and you couldn't get fast internet, that was a big problem for you 'cause you had a point of sale terminal that you had to support, right? Time passes, and now we have Starlink, and you can get phenomenally fast bandwidth everywhere, right?

So no, you no longer need an SD-WAN solution that solves for low latency links. So what does that, you know... And that, y- you know, so it's, it's, that like frame is interesting of like, are you solving a problem that something else is going to solve for you inevitably, right? There's, I've seen ven- you know, it's like if it's cost, like, uh, instead of, yeah.

But here we're talking about [01:40:00] solving a problem that is this driving complexity that will never leave. We're gonna buy a company. We're gonna sell a company. We're gonna move into a new market. We're gonna leave a market. Right. We're going to go from one cloud to another. We're gonna change a productivity app, right?

All this stuff happens, and there's a lot of complexity that always gets injected with that, right? Change, right? So now we're talking about how do you, how do you support people through change, right? As the, as the driving factor here. From an architecture, I get back into this idea around, you know, what is on your...

If you have an edge, and you have an applic- and you have users at the edge, now you have SD-WAN on the edge to manage your bandwidth, right? Right. An SSE vendor will say, "Hey, give us the IPsec tunnel, take it to us, and then we're gonna manage all your connections with us. Then we're gonna do, you know, that function, that routing."

And you're saying the same thing, which is, "Hey, give us an IPsec tunnel, take it to us, and then we're gonna provide this routing for you." Right. So kind of like, um, how, how does somebody, like, manage that, [01:41:00] that f- friction between these two decision points?

Uh, uh, well, it... So let's peel the onion a little bit, and I, I think it gets down to what outcome you're seeking, where you're distributed, how many workloads you have distributed across different cloud properties, different data centers to include Equinix, Megaport, QTS, DRT, all DRT here, as we said in Dallas.

Um, if I'm using, um, if I'm using a Zscaler and I've got a ZIA, my-- and my iKeep storage in AWS, one of the buckets in AWS, fairly, fairly common deployment. What I do as a [01:42:00] user, if I don't necessarily have a data center, is I might go up to cloud, um, to access an application resource. But because I've got Zscaler, and this is, you know...

I was-- I'm sitting in a hospital the other day, uh, with my mom, and I'm trying to get on the hospital's Wi-Fi, and I was looking at vehicles on autotrader.com, believe it or not, and I couldn't get through the, the tunnel. That was not... I'm like, "What the hell is going on here?" The architecture's funny, right?

So I leave the cloud to go to the Zscaler proxy, get the traffic inspected, return to the cloud. Now mind you, I paid egress as soon as I left the cloud, and it's either nine cents a gig an hour over internet or about four cents over a layer two circuit, like a Direct Connect inter- interconnect from Google or, uh, ExpressRoute from Azure.

Those are fairly common egress, and they're all gigs per hour, right? So I come back in the [01:43:00] cloud only then to leave the cloud again and go back to the user. Okay. So with all that in mind and that crap-ass architecture, um, back to your question. Yes, bring us an IPsec tunnel, bring us one of the aforementioned cloud layer two circuits.

We give us an MPLS circuit. We'll peer with the provider and their VPC, VNet, VCN, or whatever, and then bring the traffic back to our stack or SD-WAN fabric, land the SD-WAN fabric on our virtual port. You have some-- You know, you go and get the resource, the application resource, the storage, the database, whatever you're looking for inside of the cloud, and there's no double egress, right?

And so I'm-- Uh, not everybody does that. Zscaler's a special sort of example, right? And, uh, I, I don't wanna knock them. They're a great product. I just don't wanna pay the double egress for ZIA at least. ZPA is a different thing, right? Because they keep most of the, the private stuff in the cloud. It's just prohibitively [01:44:00] expensive, as you're well aware.

And we have a lot of customers that are leaving Palo Prisma because of cost and limited route functionality, and you know all the stuff about that as well. And so they've-- It's a tough question 'cause the ask is, uh, what you see in the, in the OEM space is you see m- like, if you look at Megaport For instance, I, and I have f-friends, uh, lots of friends over at Megaport who probably won't be my friends after this podcast, but that's okay.

I can live with that. Megaport sells... Like four years ago, uh, we were talking to Megaport about, you know, potentially partnering, and then all of a sudden their messaging shifted a lot, and it looked a lot like our messaging, and the stuff that I was talking to them about and how I was talking to them about.

And it was me and my architect, David Klevanoff, who's a genius and the real reason behind Algara's partner success. [01:45:00] Anyways, Megaport does exactly the same thing that I w- we were talking about with the virtualized SD-WAN router in the cloud, right? They don't ha- Megaport is an on-premise data center company that provides connectivity globally, and they're really good at it.

But a lot of applications, if not the majority of enterprise applications now, are hosted in cloud service providers, or they're some SaaS app in some data center that has been virtualized already. Megaport was started to solve two problems. Mm-hmm. They were, they were started to solve connectivity between different data centers, especially different data center vendors.

Yep. And they existed... You have to remember, when Megaport started, you couldn't talk natively between AWS West and East. Right. There was no infrastructure for Am- between Amazon to facilitate that for you. Right. So you needed a Megaport in order to actually connect regions. And so, you know, a it's really [01:46:00] easy to bash on companies for being single region on Amazon, but if they're old enough, they started in a time where you couldn't be multi-region in Amazon- Right

because there was no support for it. Right. And so Megaport solved those two problems really well, and then other companies started that solved the Megaport, you know, what, what Megaport's, you know... Megaport has a lot of facilities globally now. Mm-hmm. They've got a different legacy issue now. What's the speed of their links?

How do you scale these things? And then, but then of course the, the, the ground shifted underneath of them. You know, eventually the clouds, you know, AWS came in and said, "Hey, you can natively talk between regions now with us. You have to just click a few buttons." Mm-hmm. Right? That changes what problem they're solving- Right

for a lot of people. Um, and, and that's, y-you know, it's like this thing. It's like are you, are you a feature or are you a product? Right. You know? And if you're, if you're in the business of solving a feature need on somebody else's product, like your days are limited. They will eventually catch up with you.

Absolutely. Like at some point it'll get there. [01:47:00] I think, though, that Megaport, and I'm not arguing with you at all, they made a really smart strategy early, and it was probably by, by... It was not a strategy of convenience, it was a strategy of need, where they partnered up with Equinix and a bunch of other colocation providers to expand their reach, which I think is genius, right?

It, it lowered the It increased the cost of goods sold to Megaport, and the margins that they paid partners to build those relationships were costly, right? Um, but then you have, you know, the evolution of cloud and multi-region cloud, right? That has impacted. So the ground, you're exactly right, the ground sort of shifted under their, their feet.

But remember, a cloud is an abstraction. It's a cross-connect from every colo provider and data center, colo provider and data center provider in the world. Yes, except when you start getting into the technical re- requirements from some of these cloud [01:48:00] vendors to get an interconnection with them- Right

you know, like, oh, you have to be at two different facilities inside of a metro in order to hit this service tier, and then it requires this and that and the next thing. And, you know, you talk about, like, network engineering being a dying art, uh, y- you know, like the amount of people that can actually configure PGP has gotta be like...

I mean, we're not talking about a, a, a big population that understands- No ... this stuff. No. Like, um, you know, whiteboard, you know, OSPF configuration as like a, you know, like a, as a thing, right? Like- I don't see it anymore. Right. It's, it's a- Do you? Well, I get paid to solve these problems. I'm gonna say it's a no.

Right. Right? Like, ultimately, you know, I solve, we solve application performance problems for a lot of enterprises. Mm-hmm. And, you know, I guess this is where, like, it, it's, it's worth it to be the old guy with no hair now, right? Because we've been through this. I've, I've seen a lot of this stuff. Um, but it is, it is weird.

It is weird how, um, how that's changed. And [01:49:00] the, the part that I'm, I always come back to, and I f- um, I think about a lot in our conversation here, just talking about, it's like, you know, how much of this is solving legacy? How much of this is solving bad design? Maybe the third part of that is just how much of that is solving capacity?

You know, and just the, the do you have the resources internally to actually manage this stuff? And the answer is no. Like- Yeah ... I don't know a single organization that can effectively, like, like- Right ... like you just, you can't. I mean, this isn't a knock on anybody. Like, no IT team is staffed at the, at the level that they need to be in order to even think about, like, maintaining one cloud vendor, let alone being like, "Okay, we want you to now maintain a second cloud vendor, and on top of that, we want you to maintain the network.

Oh, and now you have to also maintain the applications." And we just acquired three new companies, and they have, uh, 3,000 locations, and they're distributed globally, and they use a different cloud than we use. Oh, and by the way, we're also, you know, selling off this division, so you have to separate that off our work as well.

You have to, it's a divestiture. Get, get [01:50:00] started. I got a funny story for you. I was at Cisco at the time and down, uh, at the Lennar offices, which is a home builder in South Florida, and they had just purchased an entity. Um, and you, I think you'll appreciate this. I hope you will And the entity actually, the, the other home builder that they bought was, like, some local South Florida place, right?

And they had, um, and I'm not kidding... I said, "Well, when did the purch-" I'm sitting in office, I'm like, "What's that over there?" And like, "Well, we did this to, uh, you know, we purchased this company." And I'm like, "Well, why is that Cat5 cable hanging out the, the window?" "Because we're running it across the parking lot."

And I'm not kidding, dude, it, it went through an oak tree, or what I thought... It may not have been an oak tree, and it was hanging over there, and then it went to the other office. It must have been, it was a long cable. And I'm thinking, "This is an odd way to combine [01:51:00] corporate networks." And but it was the way that was fast and expedient, not very costly.

But so in your example, uh, yeah, there are very, there's a subset of human beings on the planet now that can manage BGP effectively, right? I, I, I love this story because I've been that guy. Right. And what's funny about that story, and the reason why I'm laughing, is knowing the conversations and the meetings that occurred before that cable was just thrown through a tree, because that wasn't the first path, right?

There were there was probably, like, 200 hours worth of meetings that fed into that. And, um, you know, and, and of course, I have this other saying, which is there's no such thing as a temporary patch cord, right? And so now you've got this probably non-UV shielded cord running through a tree- Right ... that's just slowly baking in the, in the Florida sun and degrading, right?

Yeah. And it's humid as heck there, [01:52:00] so- Ugh ... all the best- Yeah, I've- ... electronics ... I've, I've been that guy. I've got lots of stories along those lines. So we were, you know, uh, M&A happens to be kind of a specialty of ours. We, since, uh, because we were early to market with sort of a very disruptive technology that people looked at and said, "Oh, well, we don't have that much cloud yet," and, you know, come back to us, we found ourselves gravitating to use cases that we could solve faster than anybody else in less complex way, and one of those was M&A and divestiture.

Uh, so I'll give you the-- We can, I guess we can talk about Kellogg's, uh, not a customer yet. And then I'll give you S&P, right? S&P wants to do a merger with IHS, right? It was part of, it was part of an acquisition. And they're like a lot of different entities, [01:53:00] very diverse entities, very globally distributed, of course.

I had no idea that S&P was so global in nature, right? And they had anticipated it would take two years to do this M&A, right? To bring the other entities into the corporate environment, corporate network of, of S&P. Um, when they got engaged with us, it was Guru, who's the VP of infrastructure and cloud there now.

Um, he wasn't that when he started, but he, he's done a good job and we helped him, and he's kind of risen up in- inside of the stack, inside of S&P. So, uh, you know, S&P is a global research company, right? And they provide market data all over the world, and they have customers like traders and researchers and analysts that consume their research and, and do so from different entities, from banks, from financial advisors, from, you know, this, that, and the other.

But this IHS merger created some problems. It's like you're talking [01:54:00] about how many different types of routers, switches, firewalls, how many different types, different clouds, how many different office locations, how many different SD-WAN vendors in there, how many different policies that the, the various firewalls had that all of this stuff needs to be taken into consideration, as you know, as you're making this giant, uh, integration or this giant change.

So they thought it was gonna take them two years to get done. Uh, it, it took, you know, like six or eight weeks after we, we got involved. 'Cause they use us and, you know, it's the same reason that our big banking customers like us as well. It's the ability to extend a VRF from their VPC to the customer VPC, VNet or VCN or data center, whatever, and to do so securely in that, in that segment.

And it's immediate, right? It's like, okay, let's start this process of bringing in this other entity, [01:55:00] combining the IHS and the N- N- S&P Global. You know, when they look at a two-year timeline, that's all they're doing for two years, right? If they, if they can do it now, um, then they can move on to the next project, which may be some sort of AI thing or something.

You know, that was... Something about that example is a light bulb for me. I think it just, it just, it just really clicked off. And think about, like, routing architectures. We're talking about, like, BGP and OSPF and, I mean, EIGRP. Pick your, pick your flavor, right? Such a Cisco guy. Listen. Fair enough. Me too. Uh, what-- Just as a segue, being able to call some rando shop in the middle of the night in some market and say, "Can I get a part that I need?"

When you look at hardware selection, like, [01:56:00] nobody's gonna tell you that Cisco's the bleeding edge of anything Or the fastest. And there's a lot of other stuff that I... Arista's amazing, Juniper's amazing. Yes. Like, these boxes are unbelievable. Yes. But when you have sent a network engineer to drive down the freeway to meet somebody who has a part at the halfway point and then drive back to you, like, I, I think about this stuff, right?

Like, it's, it's, it's a part of my selection criteria now of like- Right ... you know, we've got this box that now we have to maintain for the next seven years. Like, how do you get parts for it? Right. So, um, now, now don't get me wrong, you know, running 6500s and 7600s through, you know, the BGP table climbing rapidly and, and having to maintain those things was very stressful, you know.

And finally getting into ASRs and, like, seeing these other things, and ASR finally introducing functionality that Juniper had had for years, like, you know. But anyways, that's a, that's a big segue. Meaning that feature? Oh my goodness. Right? As, as a, as a sub- Come on. Yeah. I mean- It makes a little bit of [01:57:00] sense, doesn't it?

It's like copy and paste on an iPhone. A- Like, come on, man ... listen, I've, I've, I've, I, I can remember, I mean, I, I mean, very late '90s MPLS network. When I say MPLS network, I mean, really what we're talking about back then was, like, um, frame relay. Right. Hub and spoke. Right. Um, rolling out a, uh, rolling out new infrastructure, new...

And, and doing a live routing table replace on the edge with Cisco. And, and basically applying the config very strategically, because as soon as you paste it, you hit that line, and then you lose the connection, and then you have to sit there and stare at the screen while your ping is running and just exactly praying for the config to come back online.

And, and if it didn't, your fallback was calling the person on site and telling them to go unplug and plug the device back in and praying that the previous config was loaded properly. Don't wanna do that ever again. But I, I'm going, [01:58:00] going back to this thing with the light bulb here is even today, I don't want to deal with complexity myself.

And from a architecture and routing standpoint, knowing what it takes to deploy routing across just a single network that's got different locations and what the peering of those routing tables has to look like, right? You talk about BGP. You know, this is a very specific issue where with each device that you add onto the network, the amount of connections that you have in your router grows exponentially.

Like, it's- Yeah ... you know, and s- and, like, BGP solves it by having route reflectors, right? Right. But, like, but you look at this and you say, "Okay, I would be willing to pay to not deal with that complexity on my network," especially because it requires less hardware for me than, I mean, to manage. Like, the, the issue with routers becomes You [01:59:00] have to have enough horsepower to process the routing table, like what's in the RIB, what's in the FIB, how big is your, you know, what's your TCAM?

Like, all these things become real big selection problems for you in sizing your hardware, and then you s- then you say, "Okay, great, now you have to double your, your adjacencies overnight," which is really not like a doubling of your adjacencies. Like, it's a, it's a, it's a big issue. Um, do you even have the hardware capacity in dealing with that, right?

And then how do you do a segmentation? Like, and so I'm, I'm, I'm, I'm trying to regurgitate a little bit of what you've told me here that's, like, it's really clicked off of not having to deal with that as a network engineer. I'm all in too, like 100% on board with. Yeah. Right? Um, especially if, you know, and my part of it always became can you simplify and can you lower, can you get into commodity?

Can you buy simple devices? Could you still run these really inexpensive ISRs in the edge? Can you have a really inexpensive firewall that's doing SD-WAN for you on the edge? Right. Um, my favorite redundancy is N+ spare, [02:00:00] right? Like, single device running with something in a box that's not even plugged into the network, right?

'Cause it's really simplistic. You don't have to deal with it, right? Like, oh, it failed, it went down, we have to replace it. Somebody has to go unplug the, you know, take the box out and plug the new thing in. Uh, and, and I know people think I'm crazy when I say that, but adding HA into a lot of these environments on the edge, like that's, that's a significantly more complex environment that you have to maintain and configure, and then you find out that you didn't configure it properly and it went down, you know?

A, a good story. A shoemaker with a whole, uh, 400 retail stores in LATAM, um, let their Fortinet firewalls that were creating the tunnel for the POS machines to get back to data center in America, uh, let them go end of life. The boxes were, um... So they're n- unsupported, and they've got no way to effectively get [02:01:00] new boxes in without paying a, a fairly substantive tax bill as you go, right?

Importing gear in- Yep, yep ... to most countries is significantly more expensive than not. So what we offered them was, "Look, point the existing Fortinets to," you know, I think we were going to Mexico City at the time, right? So we dropped those into the Mexico City AWS pop that's down there. It's got a transit gateway, right?

We have a CXP instance there, and we get, you know, we remediate the near term, this box could die at any minute need, and we take the top 50 stores where we, the boxes are the oldest, uh, plumb those into the, the virtual port- And then swapping out the boxes becomes a lot easier 'cause effectively you've gone from having a point-of-sale machine dependent on a Fortinet router that's end of life, end of support, and [02:02:00] you can't get new parts for, and you can't afford to, because it's a discount shoemaker, right?

A discount shoe seller. You can't get the box in there, so what we did was, is we did 50 stores at a time, right? We identified the oldest boxes first, and then removed the, that they had picked s- uh, I can't remember what they picked, but they picked a different hardware manufacturer, and they brought the boxes in.

And we were able to sort of... It wasn't so much a wholesale rip and replace. What it did was it helped remediate their risk, uh, you know, 50 stores at a time, right? And they were able to source the boxes where they didn't pay as much taxes from a distributor inside of Mexico, which is really the way to do it, and they probably pay a little bit over premium for it.

But they were able to do the, the stores and get everything up without, you know... Yeah, they took a risk, right? Because they were doing 50 stores. But because we're so easy to turn up and so quick to bring stuff online, we were able to tell you, uh, we were able to get [02:03:00] that environment turned over pretty fast.

There's still a perception that dedicated circuits are faster than using something over the internet, right? So this is, like, part of the thing with MPLS. Now we see it with cloud connections. Oh, we need to get a physical circuit to connect us to our cloud. Right. Pick, you know, Direct Connect, ExpressRoute, whatever it is.

Yeah. Right? Um, I don't care, I don't prefer that inf- architecture, right? Because now you're going to some sort of, you know, telco provider and saying, "I want X speed circuit at this location." You're waiting for their provisioning time, you know, weeks, months. Yep. You are capacity limited based on whatever they give you.

You've got, you know, a failure point that you have to deal with. And, um, and you're still riding the same underlying infrastructure to the cloud. It's just like, what are you actually riding on top of? Where, where you... But because there's less pieces in that puzzle usually for most companies, the circuit is faster, right?

Because it's just a [02:04:00] layer two connection that's running up, and they don't have all this other m- gobbledygook, you know, that's there. How, how do you help people with that? Like, change that mentality and say, "Look, you know, you can, you've got a device over here that IPsec into us. You don't gonna have to get into this crazy stuff.

You don't have to go out and provision this thing. You've already got enough bandwidth to it. Just try it. You know, just plug this in and turn us, turn..." When I say plug us in, you know, like, you know, type on the keyboard and configure us and turn this on. There's perception out there that the private circuits are more stable than internet.

I, I don't think that's, uh, far away from the truth, but I also think that, you know, Riverbed would still be in business or at least productive if the internet wasn't so robust and so stable. You know, WAN optimization would be still a technology that we employ, and I actually sometimes I still run into WAN op boxes, as I'm sure you do, right?

For critical workloads between long distance [02:05:00] sites or what have you. We... So again, we're the middle mile, right? But we're dependent on the last mile. What we typ- w- what I typically see and is they'll put, uh... and we can do 10 gig IPSec now, right? Um, and then you're sort of unlimited in the cloud, right? Our b- uh, our boxes, I call them boxes, but our stack, our virtual colos in the cloud can go anywhere from 100 meg of networking to 20 gigs.

And we're deploying two and they're HA. We maintain both, uh, on behalf of the customer, but the customer pays one, and we pay for the other one so that we can upgrade in production. We'll swing the production workloads over to the backup, do the bug fixes and feature stuff that we need to do, and we do this every 30 days.

Then we swing the production workloads and do the reverse on the, uh, and do the same on [02:06:00] the backup, the HA pair. So when what we see mostly is people adopt a direct connect or some sort of private circuit out of their data center 'cause they think that's still a critical, you know, technology that's never gonna fail.

But I, my bias is if you, you know, if cloud is the new data center, internet's the new, you know, MPLS or new, new transport option, right? And it's stable and there's... I'm-- Dude, there are 100 gig stuff out there. There are 400 gig requirements out there. People are doing some crazy stuff. Doing eight right now.

Dude, I know. It's so crazy. I'm like, what is, are you moving the Library of Congress every millisecond? It's, it's, it's amazing. Uh, the stock exchanges, we have a couple of stock exchanges, right? These are Singapore Stock Exchange and Hong Kong Stock Exchange. They're just... And then they'll, although they're not a customer, London Stock Exchange.

That was the first, like, 100 gig requirement I had heard of a couple years ago. I'm [02:07:00] like, "Really? What are you gonna use it for?" I mean, that's a lot of throughput. Come on. You, uh, you're jamming just, I mean, every piece of data on the planet through that pipe Per second? Not slowing down. No, I know. We're, we're, we're- I see AI evolving to use it

we're a couple years away from terabit networking as- I know ... a common construct. It's, it's amazing. Right. It's, uh- Uh, anyways, we help people, um, from just orchestrating an easier architecture in whatever they bring us, we terminate, right? It doesn't matter. It could be an Akamai Prolexic fabric. It could be any of those L2 circuits we were talking about those cloud service providers have, IPsec, SD-WAN, MPLS.

I talked about the- Yeah ... how we, how we pair with that. Um, we, our, our, our solution is like we're not... We're gonna give you some guidance, but we're also gonna accommodate everything you have, and that's... I talked about [02:08:00] Matt Hogue earlier. He was really instrumental into a lot of the stuff that we're doing 'cause we were helping him replace that automated AWS and get him sort of like for like in both Azure and AWS so you could accommodate the new thing.

But, like, we always accommodate or we try to accommodate what our customers wanna use. Because I could talk all day long about CloudGenix's architecture and how it's inline and, and, you know, what happened to us at that big bank and that dual inline memory module and catching fire, and that's not a popular thing to do in the data center all day long.

But customers are still going to have a bias for solutions that they've used in the past and have secured their environments and, you know, uh... And it just, it, it, I think it lengthens the sales cycle to fight with them about that. What y- what we do is provide them with an easy-to-use, better extensible architecture.

What they have in their environment are things that they [02:09:00] have deep, deep attachments to. And try, and you know this firsthand. Like, why are you still on the ASR platform when Cisco's charging you 10 grand for every extra port you consume or something like that, right? The Juniper box is pretty good.

Arista has a great solution, right? So for- All layer eight issues. Right. Exactly. People have, uh, they, they just sort of have this agreement with themselves, makes them comfortable, and they're, and they know they're gonna get support, and Cisco's never gonna let them down, right? And having been on... Funny story.

Big, big accounting firm. Uh, there was a balance of trade between Cisco and this firm. I walk into this. I didn't sell the deal, but it was $11 million worth of Viptela stuff that we sold. The rep leaves. Uh, I move into the enterprise slot, and I'm a Cisco [02:10:00] PSS, and it's me and Katie Sikora, who is hands down the best network engineer in the world for, for my money.

Hands down. She's, she's at Alkira with us now too. She and I are on the phone every day, Monday through Thursday, with this shop because we can't build an IPsec tunnel between two different regions out of the virtual ISR router and the vEdge, for that matter, between the two AZs inside of AWS. And we're like, "Okay, you know, this is never gonna end," right?

They wanna... We figured it out after 90 days, but it really became the... You know, Katie looks at me one day and she says, "I wish we could do what we say we do," you know, with respect to all of this stuff. And so that, that's kind of shaped how we go to market. It's like, look, we do what we do, and we do what we say we do, and it works, and we haven't been [02:11:00] down, and our customers are, are sticky, and we haven't lost any.

And so I don't know. You're never gonna solve for people's biases. It's just Nope. Just try to make their lives easier in the process. Yeah, exactly. That's it for this episode of Signed. If you got something out of this, share it with someone in your world who's staring down a tech decision, a CIO, a CFO, a founder, a procurement lead, whoever.

That's how the show grows. Everything from today lives at itbroker.com/podcast, show notes, transcript, links to anything we mentioned. If you're in the middle of a real tech decision right now and you want someone in your corner without the vendor bias, that's what we do at itbroker.com. Schedule a call on our website.

Buy tech without regret. I'm Max Clark. Thanks for listening. See you on the next one.