What is NaaS (Network as a Service)?

Networks can sometimes feel like a maze of licenses, tunnels, and 2 a.m. pager alerts. We sit down with Graphiant CEO Ali Shaikh to unpack how Network as a Service makes connectivity on-demand, consumption-based, and finally as flexible as the cloud it serves. From the SD-WAN wave to the pandemic reset, Ali explains why the old build-and-forget model couldn’t keep pace with multi-cloud, remote work, and fast-moving partnerships—and how a stateless, metadata-driven fabric changes the game.

We explore two clear buyer paths. Pragmatic teams want turnkey connectivity that lowers cloud egress costs, reduces NAT and transit complexity, and keeps operations calm. Futuristic teams need dynamic, auditable data exchanges for AI workloads, research projects, and payments ecosystems—publisher-subscriber connectivity that negotiates policy and stands up in days, not quarters. In both cases, the network becomes evergreen, with new capabilities landing in the service rather than hidden behind feature licenses. Pay for what you move, not for buttons you can’t press.

Security shifts from signatures to assurance. In an AI-fueled threat landscape, we focus on what should move, where it may travel, and who can subscribe—then we detect anomalies and lock down exfiltration. Ali digs into continuous audit trails, sovereignty-aware routing, and why pushing complexity to the edges keeps the core lean and reliable. Expect candid talk on cloud cost traps, how to cut NAT sprawl, and the reason a hollow core with metadata labels beats hop-by-hop state.

If you’re ready to trade SKU spreadsheets for clear outcomes—and want a network that can spin up for a week and tear down without drama—this conversation will reset how you think about connectivity. Subscribe, share with a teammate who owns the cloud bill, and drop a review to tell us where ephemeral networking would save you the most.

Connect with our guest:
https://www.linkedin.com/in/alifshaikh/

https://www.graphiant.com

Purchase Chris and Tim's book on AWS Cloud Networking: https://www.amazon.com/Certified-Advanced-Networking-Certification-certification/dp/1835080839/

Check out the Monthly Cloud Networking News
https://docs.google.com/document/d/1fkBWCGwXDUX9OfZ9_MvSVup8tJJzJeqrauaE6VPT2b0/

Visit our website and subscribe: https://www.cables2clouds.com/
Follow us on BlueSky: https://bsky.app/profile/cables2clouds.com
Follow us on YouTube: https://www.youtube.com/@cables2clouds/
Follow us on TikTok: https://www.tiktok.com/@cables2clouds
Merch Store: https://store.cables2clouds.com/
Join the Discord Study group: https://artofneteng.com/iaatj

Chapters

• 0:00 Setting The Stage And Intros
• 3:20 From SD‑WAN To The NAS Idea
• 8:50 Pandemic Shock And On‑Demand Networking
• 14:10 Defining Network As A Service
• 20:05 Consumption Model And Evergreen Features
• 25:20 No Hardware: Software Across Edge And Cloud
• 31:10 Cutting Cloud Networking Costs And NAT Pain
• 36:40 Pragmatic Vs Futuristic Customer Paths
• 42:20 Risk, Five Nines, And Operational Reality
• 48:10 Beyond SASE: AI‑Driven Threats And Assurance
• 54:00 Compliance, Auditability, And Stateless Design

Transcript

Tim: 0:12

Hello and welcome back to another episode of the Cable Clouds podcast. I am your co-host Tim McConnaughy as usual. And with me is my other guy, the other guy that's on the podcast with me. What's his name? Oh, Chris. Right, Chris, Chris Miles. Really good friend of mine, as you can see. And we he has been gone. He's been in Japan. I've been jealous. I've been missing but missing you and hearing all the stories. But uh anyway. We also have a guest with us who has not been on the podcast before, but he and I go way back. Uh Ali Shaikh, the new CEO of Graphiant. Congratulations, by the way. Uh now go ahead and introduce yourself for the everybody else.

Ali: 0:54

Hey, uh, thanks for having me, Tim and Chris. You know, once uh once I became CEO, one of the first things that came to my mind was I'm finally famous enough to make it to this podcast. Let's go.

Tim: 1:09

Yeah, he really did say that. And I was like, what are you talking about? But it is great to get you on here. I don't know why we haven't done it uh already. Uh wait, we're waiting for him to get CO. Oh, that's right. We were waiting for him to get CO. Sorry, sorry, I forgot about that.

Ali: 1:27

Long, hard years to get here, guys.

Tim: 1:30

You made it. You made it. We were waiting for you. Round of applause. Anyway. Um, no, no, it's really it really is it's good to have you here. So for those that don't know, Ali and I go way back. We met at Cisco right after the Viptela acquisition correctly.

Ali: 1:47

2017. We get absorbed in uh into the Cisco mothership uh by the Viptela SD-WAN acquisition, the when the wave of SD-WAN consolidations got triggered and all the startups got bought by the big guys. Big guys, yeah. We we came in over at at Cisco, and uh you're one of the first people back then who's gonna go, oh yeah, this this is gonna be a wave. This is gonna be a lot, and then shortly thereafter, Chris, you were in the mix too. It wasn't too far behind. Uh but we'd been in in the trenches for a while. Yeah, uh, but yeah, it wasn't so long ago. I know, but the years, you know, it so much has happened since then, right? We we went through like that ST WAN phase and that happened. And then when while we were at Cisco, even that was starting to okay, we're doing this, but this is coming to a head. New stuff is coming, and it's coming fast. Where is this gonna go? And I know we used to have the conversation like even at that point, cloud is already big, but in our world, it was still early. Still so new to networking people and like large-scale networks. But yeah, man, fast forward now, 2025. We went through a pandemic, started a new company, and now I'm finally famous enough to be here.

Tim: 3:17

Yes, and congratulations to that again. Um, let's so let's rewind it a little bit because actually this is this is really good. So we know, so you know, the cables of clouds podcast, we've been doing this for what, three years now, Chris? I think it was about three years. And yeah, something like that. And when we launched it, the goal was to do hybrid networking. So like part cloud, part on-prem, and mostly just where networks meet each other, right? That was that was like the always the goal was like where where networks meet each other. And so we've flirted off and on with the with the uh network as a service model. We've talked to a few people about it, we've done lots of news episodes around it of Graphian and some of the other ones as well. Um but now I think it's time finally to like actually bring someone in, which, you know, first on our list, to talk about network as a service, specifically like, and you, and you set it up perfectly, by the way, but saying like, okay, we had the SD Win, the cloud became big, and kind of what was the next big thing. And that was actually right about the time that NAS really started taking off, it was right around there. So tell us a little bit. I mean, because you were literally like, you know, ground zero on this on this whole thing getting launched, really. So tell us a little bit about it from your perspective and the graphian perspective.

Ali: 4:30

Absolutely. So for us, the the journey really starts uh around 2018, 2019. We've ridden that SD-WAN wave where people start to move off of private networks and start using the internet, which I mean, we're we're talking like the mid-2000s at this point. The internet is a new thing. Well, for businesses it still was. And at that point in time, we start seeing, okay, now people are starting to use AWS and Azure and Google and everything else is starting to happen. Even then, right, we're still thinking, most people have still already been using this, but businesses, corporations, enterprises, they weren't. They were still very much uh their own private data centers. This is around 2018-2019, we start having to deal with these networks that are changing, that are being asked to change very frequently to accommodate not just one cloud, but multiple clouds. What a cloud is, its definition starts to become quite large, right? We go from on-prem to hybrid to public-private.gov cloud gets a flavor. So everything starts to, well, now cloud is sort of a general stroke that we apply to pretty much anywhere there is compute. Uh so now that starts to become its own thing. And the network, we who have been much more focused on for years about reliability and connectivity and making sure everything works in a predictable fashion, we're being told it's not predictable. Abandon this religious view you have about predictability, and accept the fact that you're gonna get a request Tuesday to get a network up by Thursday, and you're gonna already be two days behind. So that was where for us it started to begin to look at: well, SD-WAN's not gonna cut it. It's still too rigid, it's still too policy-centric, it's still too vendor-centric. The clouds don't really care about solving networking. They've got the compute, they've got the stores, they've got every service, but they don't really care how you get there. As long as you get there. Like, okay. So they're not really, they don't really care either. You go to the telecom providers, and the telecom providers are with all their infrastructure, they're like, yes, we would love to have this. We don't know how. And who's gonna build it? So this is where for us around 2019-2020, and then you get the mother of all changes, the pandemic hits. Yep. And then everyone's like, well, the whole network has to be overhauled overnight, and we band-aid and glue our way together all kinds of remote worker VPNs and this, that, and the other. And that's when it really was a case of we're going to need not just a technical, but a business element that makes network as a service possible. You're going to have at a technical level, like a foundation of this should be on-demand, this should be programmable, this can be spun up with one cloud, two cloud, ten cloud, 50 clouds, any number of branches, any number of data centers, any number of equinexes and DRTs. It has to be that on-demand service at a technical level. So you're going to need a fabric that can do that, but it also has to be commercially an as a service. I cannot swim through 19 layers of features and which license I had to buy for those features and how many vendors I have to jump through to do that. It will have to be a true as a service. So this is what starts the Graphiant journey. All right, that's how we ended up creating Graphiant going, okay, we could probably write the tech, but we also need the commercial piece, and unless we really think through the consumption model around this, classical vendors, their licensing model doesn't allow us to do that. So we has to be technical in business. This this, I think, is the start. That's what kicks us off. I know there's like a lot of things we're going to be able to talk about along the way, but that's really what kicked us off.

Tim: 8:53

I like that. Uh, and the timing was perfect too. With the pandemic, the need for agile, quick like solutions, if you will, uh networking especially, um, were uh was right on time, right? I mean, I remember everybody very quickly trying to figure out what work from home looks like or what temporary connectivity looks like, VPNs everywhere, like all of that, right? And so that was really good positioning, really. I mean, terrible for the entire uh you know, world, of course, but but it'd be hard to ask for better positioning for that for that kind of product, I suppose.

Ali: 9:29

Absolutely. I think this is where the next couple of years for us, it was a lot of building a lot of fundamental elements, uh, building that networking layer that has to be that has to be able to meet these demands, that has to be multi-tenanted, and it has to be fundamentally for the providers, for the telecom providers, because they have the global infrastructure of all the connectivity that can then facilitate the end users, the businesses, the clouds to use that. So it took us the next couple of years to build that out, and we started with sort of like that foundational layer of there is that network element, and there's that cloud element that have to be married together natively. Then we're gonna get into the more futuristic things, and we'll definitely get to how you handle security, how do you handle sovereignty, and then of course, AI. But all those things came later. The foundational element was still a case of if you're going to be practical and pragmatic, there has to be this network that connects all things. That isn't just endless amounts of configs and VPNs and having to figure out which tunnel points where, and oh no, we need that tunnel to point somewhere else. And oh no, the AWS TGW doesn't have enough configurations put into it the right way. Well, the whole thing now isn't routing half the business. Those things had to go away. So a lot of protocol innovation is what was needed.

Tim: 11:03

Yeah, so actually that's a good segue. Let's step back for a second, because there's there's gonna be people listening to this that don't understand what fundamentally defines network as a service as compared to their traditional job as a network engineer today, right? Could we step back a little bit and talk about what the network as and you've talked about it a little bit already, but just yeah, if you don't mind, as a service. The as a service piece is really what's what's at play here.

Ali: 11:26

The as a service piece, I think the way I'll describe it is twofold. There's a part one of how you consume it, and a part two of what it does. The part one is an important piece to understand how you consume it. Network as a service fundamentally has to be a consumption-oriented thing, which means you're going to consume some unit of capacity of the network. And so this fundamentally is a case of it's not user-based licensing, it's not branch-based licensing, it's not feature-based licensing, it's not any of those things. It has to be consumption. If I use more, I pay more, if I'm not using a lot, I don't pay a lot. So that's fundamental to network as a service, the consumption aspect of it. This allows you to start thinking about all right, if I get network as a service, I get everything the network can do. And when I consume a lot of it, I pay more. If I don't use a lot of it, I don't pay more. Then the next part comes in, which is a part two of what does network as a service do? What is its functional attribute beyond how you consume it? The functional aspect of it has to be that it connects all of the things that you have. So branch, data center, cloud, public cloud, private cloud, whatever flavors you have. But what it also allows you to do is create ephemeral networks, on-demand networks. I need to be able to set up connectivity for a day or a week with a business partner, with someone else, with if I want to create a data exchange, I have a merger or an acquisition. The nature of ephemerality has historically not been there in network. When we build a thing, that thing is there for the next 20 years. Right? That's how we've historically built networks. We don't think of them as casually tear down a network, you know, during December. We don't do that. We build it, it stays, and it stays there forever. So that's that nature of network as a service has to be that element of it can be on demand, I can build it, it can go away.

Chris: 13:53

Yeah, I think that's a good point. Like they've never, to your point, they've never been these ephemeral things like many other things in IT. Um, but I guess that also would you say that relates to why um and when you say it has to be consumption-based, I don't know if you mean from the from the consumer side of it or from the uh the NAS provider side of it, but are you saying is that why you think it has to be consumption-based because of those two in the relation?

Ali: 14:21

I think it's there is that dual relationship aspect, right? Which is when you think about from an end-consumer point of view, and this was this highlights a journey even for Graphiant as it happened, where in the early years we were met with this, well, how would that work? Like, why would you do it this way? Because we've historically bought boxes or bought a software license from a vendor. Why are you making us change? Like, well, the telcos are already set up for this. And fundamentally in network, we have to think about the network capacity. Right? It's it's you're basically taking speed. You're taking speed with quality of service, with protection, with guarantee, with DDoS, with all these things, but somehow we moved away from the fundamental nature of the pipe, which was to transport data, to charging people for all these layers of licenses on top of that. And so the analogy I would always draw to people is the network is still at the end of the day a highway. And the best way you decide if a highway is good is how quickly it gets you there, not how many HOV lanes it has or how many signals it has. How well does it get you from point A to point B? That is its philosophical nature. And that's what you know, net network existentially is that. So that's why I think it was important to go back to that.

Tim: 15:53

So you talk about the licensing. You mean like, for example, the way Cisco or I guess probably any of the vendors do it, where you're less licensing features essentially, and then you're using those features to build your thing.

Ali: 16:04

Exactly. It's a case of so this is where one of the things we did ourselves, and this is why when we work with our partners and our customers, was the network has to be evergreen. It can't get out of date. Which means if I build a new security feature, it goes into the network. If I build new telemetry monitoring capabilities, it goes into the network. And you're not paying for that. You pay for when you use the network. Right? If uh if we get better traffic cams or if we build I mean, I know I'm using bad analogies because uh governments get sort of messy. But it's a case of when you build infrastructure, it's really a case of when people use it, there's value in it. And the network's fundamental value is transport data from point A to point B. That's what its fundamental point is. But everything else is to make that experience better, but the purpose of the network hasn't changed. So if I add security, if I add DDoS, if I add data sovereignty to make sure it doesn't leave you know the national boundaries of where data should be, or if we add additional protections, or we add quality of service, you know, we add all these different capabilities. Those are meant to make the network experience better, but not change the purpose of the network. Transport. So a customer shouldn't be forced to buy a feature or see a button that says, you could do this thing, but we won't let you unless you pay for it. That's that's really frustrating, and that really gets me. So you know, you get all these trial products, you see all these SaaS things, and I'm like, I you see that, and you're like, I'd like to use that. Oh no, you can't. Oh, it burns. Bit burns. So like fundamentally it was a choice of when you use our network as a service. If you like it, you'll use more of it. And it'll be great, and you'll pay us for it. If you don't like it, it's okay, don't use it. But I'm not gonna force you to artificially have to buy features. That that seems wrong.

Tim: 18:14

That's that's good. So actually, then in in that case, we'll back up a little bit. If we're not buying features, uh and I'm I'm I'm still thinking from the delivery perspective, really. So, like, you know, there are lots of different NAS vendors out there, and they all do it a little bit differently. In Graphiant's case, is Graphiant delivering hardware? No hardware. I didn't think so. I didn't think so.

Ali: 18:41

Nope. It's all software. I mean, you gotta run software somewhere. Uh so you'll have compute somewhere, but we don't build hardware, we don't deliver hardware. So it's always meant to be software. But the software capabilities can run directly, and they do run directly at the edge. So they run in the customer environments, they run virtualized, they run on machines, on compute. They run inside the telecom infrastructure. So you start transforming the telecom to network delivery capabilities as they think about delivering private services or public services to end customers. And then they run in the clouds, and then they run in the equinexes. So it creates a full service environment that is running in the clouds, that's running in the telecom infrastructure, that's running in the equinexes, and it's running in the customer environments. So from a customer's point of view, they're not designing uh their wide area network. They're subscribing to a service that connects them to the Equinexes, that connects them to the AWSs, the Azure's, the GCPs, the DRTs. It connects them already because it's already there. It connects them to the Verizons, the Lumens, the ATTs. It connects them to all of them. But they're not having to think about the design of that network. They're not building the tunnels, they're not worrying about configurations. They don't even have to really think about the topology because it's delivered to them as a service. And so the more data you put on it, that's what you benefit from. This also opens up when I have business partnerships. If company A wants to talk to company B, one's a pharmaceutical, one's a research firm, and you want to do a data transfer, set that up. If you're a payments company, there's like I mean, 19 different banks that have to handle a transaction. Your microcard card gets swiped, your merchant banks, your all layers and layers of banks. How do you stitch them all together? So those things become much more as a service. I can build something on demand for a purpose. Let's say that business goes away or you know it got sold off to some other company. Well, I need to turn that off and build something new. That kind of flexibility to just think about its network. That network should be flexible. If I want to consume a lot of it, I can consume a lot of it. And if I don't want to consume a lot of it, I don't consume a lot of it. That that piece, I think, on the NAS side, right? I'd be curious as well as uh I mean lots of people are doing it differently, but I'm seeing the telecom partners get really excited about this aspect, and I will throw in before I ask you guys what you think about this, I will tell you the first couple of years of Graphium, it was so hard to get people to why are you doing this? This is complicated, it makes us think about a thing we've never had to think about. We just go to Cisco and buy a license, and it comes on a SKU list that is 19 pages long, and that's what the bill of material says. Uh they just gotten used to it. And then something happened that for all other reasons we can talk about it, it made us it made our lives a lot easier to explain was what tokenization has done inside AI. You don't think about if you're gonna buy an additional feature. You get tokens. And you can use that against different models. Some models use more tokens, some models use less tokens. You want to use a ton of it, you use a lot of tokens. You don't want to use a ton of it, you lose a you use a lot less. And that made it so easy for us to talk to people. Now, the explanation is really short. So I could have gone the shorter way with you guys as well. They're like, hey guys, it's tokenization, just like the way AI companies do it. Game over. You would know it right out of the gates.

Chris: 22:50

Yeah. Yeah, it's it's it's very interesting you put it that way. And like I'm thinking, you know, as we kind of talk a little bit more and more about NAS and maybe the foundations of NAS, uh, I mean, related to this podcast, it feels like this is kind of like an extension of what cloud was in the first place, right? You know, it's just another kind of version of cloud. Um but one thing that I'm hearing is, you know, we talk about how networks aren't typically treated as ephemeral. And and something that the cloud providers have done, uh obviously they they've done a good job at letting these services be ephemeral, you know, spin up hard out. But they've given people some of the aspects of that long-standing nature and benefits of that, right? So they've got you can do revert reserved instances, etc., things like that. But you don't really have those options for network services, right? You you still pay, you know, you know, to put it you know, kind of harshly, you get nickel and dimed for every AZ you cross, all this kind of stuff. So I guess from your perspective, if that's purely consumption-based, um how should how should people tackle that with kind of a NAS provider in between?

Ali: 24:05

So the way, and you raise a good point, right? It's the the piece of the problem that's been amplified that people realize is cloud has done a great job for a lot of things. Cloud has made networking really hard for a lot of people. Where when you think about the NAT gateways, the transit gateways, the different network constructs that you have to get really familiar with. And then even as an engineer, you eventually go, Okay, I can't do L2, I have to do these things, I have to do all that stuff. And then you find out the billing mechanism of wait, every bit that crosses this triggers a charge? That's really painful. Yeah. So networking the cloud hasn't done a great job in helping networking. And I think it stems from the cloud players themselves had no real incentive to do so. They knew the data was coming to them anyway. As long as they focused on compute and storage and databases and platform capabilities, you have no real incentive to change anything. For us, it really becomes a case of okay, if those things aren't done as well as they could be in the network inside a cloud, can it be done elsewhere? We have networks, we have the capabilities to do these things. So one of the things that I think about is how do you take so much of the NAT stuff out? Why we even have NATs, right? We have IP conflicts, we have overlapping addresses, all these kinds of problems. What if it could be solved before it even got to the cloud? What if the network, the transport network, could solve it before it gets to the cloud? That would be something significant. Uh which AZ you should get to, which region you should point to? Why does everybody have to home into the same region for symmetry purposes and stuff? There's ways to solve that too, and the network has those abilities. You don't have to do it in the cloud. The problem is where would you do it? We hadn't built that. That was what was so much for us was why build so many nets? Why build so many VMs inside the cloud to terminate IPsec tunnels? Like, why would we do this? We can solve this, we don't need to do that at all. And that's where it was the transport network, the internet, the telecom providers. They already have it. We just need to make a couple of modifications here and there. And you can drop the costs that you're incurring on the network side for clouds to like 60-70%. You don't need like a carrier-grade NAT-like state machine inside the cloud. What am I doing that for? So that's, I think, it's just uh we can do this. We have the technology. It's now a case of, you know, let's make it happen.

Tim: 27:07

So walk us through a little bit about. So a customer, either you go to a customer, a customer comes to you and says, like, I have a need to connect network X, Y, NZ, you know, uh, maybe it's like a partner network, or you know, I need to connect my WAN together, I can get my sites together, and I have the cloud. Like, how do you as a network, uh as a service provider, kind of go down the menu, if you will, with the with the customer, like to size that for them or whatever?

Ali: 27:37

So I'm gonna be very honest, it's a it's a very vanilla way that I try to do this. With a customer, the first thing I go to is is this a pragmatic customer or a futuristic customer? I will before, like that's gonna dictate a whole bunch of things.

unknown: 27:54

Okay.

Ali: 27:55

If you're a practical, pragmatic, you are thinking about cost saving, you have a huge bunch of burdens on you, and you need something that works and works simple. And that's just gonna run out of the box. If you're a futuristic looking person, AI is in your mind. You want something there, you want some esoteric data exchanges because you're trying to solve really complex problems for things that are coming down the road. So that starts as a first set of questions. Now, if it turns into someone that is futuristic, it's like I have a data exchange problem. I have a hundred different business partners. These are business transactions, maybe they're payments data, maybe it could be anything these days, but it's pharmaceutical data, it's research data, it's like sensitive. But I don't want to invest a hundred million dollars in building a network for a product line that is not even known if it will succeed or not. I don't know yet. But I need to transfer that data, I need to exchange that. How do I do that? How do I do it in a way that's compliant with all these different industry standards, with risk and audit, and you know, it's not gonna cause problems when a vulnerability happens, or I can actually respond to ransomware or something. So there's that element of so this is where we would go in and say what you're looking for is either our AI or our data exchange capabilities. What you're looking for is the ability to create a publisher-subscriber style relationship for data. You don't want to think about VPNs and configs and VPN concentrators, you want to think about pub and sub. You're a publisher, this is the app you publish. Here's a bunch of subscribers, their networks and your networks should be able to negotiate the parameters without you. Having to do anything. That's the pub-sub relationship. We've had segment routing, we've had MPLS VPNs, we've had SD WANs, we've got the tech. So there's ways to do this. Negotiation is like the original networking magic of doing all these things. So that's what you're fundamentally looking for if you're looking for that future-looking problem. If I have a much more practical customer, they're gonna come and say, my cloud bill is really high. That's way too high. My SD-WAN licenses went up 4x in cost. I don't even have that many branches. I have so many remote workers, but these licenses are very expensive. And my operational cost for all of this is really high. Because, and you both know this really well, these are not simple technologies to operate if you have to operate them in-house. So that really starts to turn into a this is a turnkey network. You will never have to figure out how many tunnels you're building, which data center is aggregating your tunnels. Uh, what the cloud egress will be will drop from this rate to this rate because we have private AWS direct connects and express routes and fast connects and so on. So it's really a math problem of you're gonna have to do less work and it's gonna cost you a lot less. So we end up with really two flavors. You're practical and you just want to save money, it's got to be easy to operate. Or you're looking ahead to the wild world that's coming, and you're like, help me make networks that negotiate themselves because I'm gonna have to do this all the time. New app comes up, new data service comes up. I have a new AI product that needs to be interconnected into 20 different partners. How do I do that? It'll come down to those things. And it's still I know I can get on a soapbox quite easily, but this is the it's still human at the end of the day. Some of us, our jobs are hey, be less risky, save money, be thoughtful. And some of us have jobs which is go do crazy things because that's what makes big money. That's really what it is at the end of the day.

Tim: 32:28

Yeah, um, so like uh network people generally, uh, you know, we've been like to joke, and uh maybe it's not really a joke, but we are like the most downtrodden of all of the uh the IT folks because it's it's kind of on us to make sure that there's more than anyone else that you gotta have the five nines of uptime, and we have to provide that, right? So that tends to be the thing that is first and foremost on every network engineer's mind is like how do I avoid getting called at two in the morning? You know, how do I avoid getting you know all of these uh meetings to sh, you know, talk about what wrong and have it be my fault, whatever. So, you know, the the ability to offload risk to provider is very attractive generally to like the C-suite and and you know leadership, but less so for usually for the actual operators, because they're like, Well, what am I gonna do when it breaks? Who do I have to pick up a phone and call someone? Like, you know, I don't know if you've noticed that or if that has been your experience, but generally it seems like the operators are are far more keep it close to my chest and don't let anybody take it away from me. And the leadership is like, get it off my plate, get it off my plate, get it off my plate. So, like, what has your been your experience like with that?

Ali: 33:40

I think with network as a service, that wave is probably where the networking people are, in my view, coming to uh to the position that I think we painted ourselves in the corner. We imposed on ourselves the five nines and the the rigor. Because everybody else gets to have like full-blown outages, but we get yelled at and we and we yell at ourselves the most. I think we were our own worst critics, we're harshest on ourselves. Uh, so I I I always tell like networking people, give yourself some grace, it's okay. It's okay. Uh, but NAS, I think, is that wave, which is I think the telecom operators are seeing this as an opportunity with everything that's happening with the AI space, with the new data centers that are being built literally all over the planet, which we still have yet to figure out what we're gonna do with them, but we're gonna have to connect all of them anyway. So, alright, let's do this. So the telecom operators definitely see this as this is the time for transformation. For the end customers, right, for the businesses, I think it's even more realization of networking is hard. Like if someone can make it operationally simple and do it for us, we'll just take it as a service. It's we don't want to have that level of complexity and understanding if it could be a utility. We we've already done that with compute to quite an extent. We've done that with storage to an extent. We've done that with databases. Those things used to be really precious to people. And now you get managed databases all the time, you get managed Kafka buses all the time. So we've we've accepted that. And this is where I sometimes ask, and I'll ask you guys, right? On the network side, sometimes I think we we're we're religious. It's like, hey, if you don't build a network right, the whole thing's gonna crumble like a house of cards. Gotta have the right people build the right network. And it's like, you know, it's okay.

Tim: 35:56

Yeah. I don't know. I don't know, Chris. What's your feeling? I mean, I definitely think there's definitely a little bit of holy war to it, but it's not all it's not entirely self-imposed. I mean, the business expects it's like water and power. We talk about this on the pod all the time, right? Networks are like water and power, right? You just expect I'm gonna flip the switch, light's gonna come on, I'm gonna turn the thing, the hand the faucets, water's gonna come out. And when that doesn't happen, it creates an extreme emergency, just as it would if your your your water and power didn't come on when you wanted it. So I definitely think there is a lot of uh what would I pressure from leadership to deliver those five nines. But you're right. I mean, we we we're just as afraid of it as anyone, and so we we we definitely impose on ourselves. I don't know. What do you think, Chris?

Chris: 36:42

I mean, I think I think it partially comes back to like if if you have a hammer, everything looks like a nail, right? Um if you've if you have one solution that you've been tasked with designing that needs five nines of uptime, it has to be ultra reliable. You tend to spread that to things that don't need that type of reliability and you over-engineer a lot of things, right? Um and to Ollie's point, you know, give yourself some grace. Like sometimes shit can go down if it's not that important, you know what I mean? So like you have to be able to be pragmatic and not um, you know, kind of go full force at every single problem.

Ali: 37:19

I think, I think, Chris, you you just said something right now that's that I think runs even deeper, which is uh you're so spot on is that when when we've specialized on building a thing that needed five nines and it extended everywhere, I think it's like and you think about it, networks weren't built per application or per segment or per business unit. We had to build the network. And it had to support everything that has ever come before.

Tim: 37:48

And comes after, yeah.

Ali: 37:51

And it's like that element of it's a it's a thankless job in that sense, where you have to support everything that has ever existed. And and you're like, well, not everything needs five nines. Some of the things you can't even give five nines, uh, but you're you're stuck in that corner. You've painted yourself because it wasn't built that way.

Tim: 38:15

That's really good, actually. Yeah. I mean, I I talk all the time about how we should not be trying to build Rube Goldberg's network with like 10 layers of failover because ultimately what's going to happen is it's gonna get so complicated to troubleshoot that you're gonna end up with more downtime than if you had just built something simple that fails fast. So we're really digging in on it here.

Ali: 38:37

And and I think that's where we had we had uh what the classical IPv pns, MPLS VPNs for a while, and you had no alternative. So it was what it was. We get ST WAN, we get the clouds, and suddenly we have a thing that's different. But it has a whole lot of complexity and it does break down a fair bit. There's all kinds of weird things that happen, and it you know, so many applications have to be supported on it. But we don't have it as a service. We can't turn it on or off. It's it's kind of all or nothing. I think this is where with NAS that is that opportunity here to say all of these technologies can be blended and you can consume as in what you need for the types of applications and businesses you need. Not everything in my business needs five nines, but I don't really want to have to think about that. Let the network profile that. You can we have the technology we have the intelligence to do that, even on a security side, right? I don't need the most stringent security on someone watching YouTube. Like, what's the point of sending all of that through layers and layers of proxies and gateways? There's there's ability to do that, and I think NAS is that point. For a long time, people were like, well, is NAS a technology set? Is NAS this? Is NAS that? And especially working with the the telecom providers, the governments where we're involved, it is that sense of make it easy to consume, but make it easy to think about the future where things will be unpredictable. And that sometimes goes against our own DNA, which is it's gotta be predictable. It's like, well, it's not predictable anymore.

Chris: 40:41

Yeah, that's a great point. And one thing I recall that I believe you brought up when we were kind of having our internal discussions before we recorded the show. Um the only reason to bring this up is I think it will probably relate to people that are listening, um, and they'll say, you know, Ali, I'm already solving a lot of these problems that you're talking about, or I think I'm solving a lot of these problems with uh something like a sassy solution. Um and and you made the point, I think internally, that the humans aren't our only problem anymore. So can you kind of expand a little bit on that and and and say uh what you mean by that?

Ali: 41:18

Absolutely. I think we are going to be entering a beyond sassy space as well. I think just like SD WAN has run its course, SASE has run its course as well, because it was meant for people in offices or a Starbucks accessing a service that was in a cloud or a data center. I mean, that's what it was. SD WAN was the network piece, SASI was a security piece, and they blended together. And it took some time, not just for the technologies to merge, but to get everybody to get along and work together in that way. Uh but that isn't even the challenge we're faced with. Signatures of threats can change because you can generate new threats really quickly. The AI world now means we're gonna see attacks of all kinds. Uh we used to think about DDoSing. DDoSing is a lot easier now. Infinitely easier. Uh generating I mean you're seeing stupider malware come out because its code is pretty junky and clunky, but it's so easy to generate now. You think about zero days zero days every day now. So you're gonna have to start thinking about okay, if the attackers can be weaponized this quickly, how do we respond to that? We're going to have to think about our infrastructure, and the network's gonna play a critical role in that. Is how do we quantify for risk? We we now have to sort of accept that bad things are gonna happen and a lot of them will happen until we develop AI that can fight AI, which is a whole other conundrum to deal with. But at this point, it's a case of what's the risk? How do you quantify that risk? How do you provide assurance that while bad stuff might be happening, the business critical stuff can't be touched, moves only from point A to point B. I think this is where in on our side in at Graphiant, we were very focused on this is where the security space will be important. We're focusing network on the practical side for the cloud and for the network build, and we're focusing on data exchange and AI for the futuristic side, but security will have to be this warm blanket that makes everyone feel safe and warm and comfortable. But the way we think about security is it has to be assurance focused, it has to be risk focused. Is something bad happening in a way can we predict this this is not right? This data should not be moving there. Data exfiltration becomes the the big piece of the puzzle. Did something show up in the network that had never existed before? Can we profile that out? We used to have all these conversations way back in the day about you know micro-micro-segmentation. Some people used to even go down a nano-segmentation. Like, no one's saying build VRFs and VLANs down to the nth level. That's madness. But you can profile the movement of data. You can stop that, you can control that, you can define risk parameters, and the network can adapt to that. And that's an assurance-focused network. So if I have a practical network where new things aren't being introduced, I can impose a much stricter assurance framework to say no weirdness allowed, no anomalies allowed. Data moves from this point to that point and never shall it go anywhere else. Okay. I've got some understanding of what that is. If I have a futuristic network, I can carve it out and say weirdness is allowed here, but within these bounds, with these kinds of partners, with these kinds of data flows. This is where I think we we approach an assurance-based approach at Graphiant, because we'd tried that dance before in our previous lives of the marrying the SGTs to the VXLANs, to the VLANs, to the SD WANs, to the by the end of it, you're like, what are we doing here? Does this work? And whose problem did it solve? I don't know.

Tim: 45:49

So how does this is interesting? Uh and I I know we're running out of time, so I but I really want to uh and I will definitely have to have you back. I have a thousand more questions, but uh just so we have um you bring up a very good point, right? Which is the risk profile, and like it it immediately makes me think also of things like compliance and audit risk and whatnot. And so when you're utilizing the services of an as a service vendor, a lot of the proof, a lot of the proof ends up being something that the service vendor has to be able to provide back to the security team. So, what does that look like?

Ali: 46:26

With us, because of the approach we took around one, making our network stateless. So I never have any customer information ever. It means my PII compliance, my DPA reports, oh, they're easy, really nice to do. I don't have anything. If someone compromises me, okay, can't compromise anybody else. Uh from there, it goes into our SOC2s, our ISOs, our PCI compliance, the FedRAMP work. Because we built assurance in, we have constant auditability, constant traceability of everything that has ever happened, of this data moving from point A to point B. We don't know what that data is. Only the end client knows what that data itself is, what the payload is. But where did it go? Was it ever intercepted? Did it take a path that it shouldn't have? Is it trying to access a resource in a country it's not supposed to? All those kinds of behavioral patterns we have, and we can report on that. So risk people, audit people, compliance people who always ask, it's more than just a log. Can you show what happened all along the way? When did it start? Right? These days, when you think about attacks like Sol Typhoon and stuff, they they get in, but you have no history of what happened and how long it had been happening. With this, at least you have all of that timestamped, which is even if weirdness gets introduced into the network, you can tell when it started and where the data moved. And so this will really as we think about a more AI-driven future, and we don't know where the value will yet come from, the real question is gonna be, right? It's uh where is the data? Who has the data? Did they move the data? What did they do with the data? And that really is is that change in thinking about security that way.

Tim: 48:31

Okay. I think that's fair. Although now I've got to wonder, are you storing the logs or are the customers storing the logs? Because that seems like a ton of data of logging data to be able to show the auditing for it.

Ali: 48:44

So in the in the raw format, uh, I think it's customers because they have to have the sims and they have to maintain those compliance logs and stuff. For us, uh, we don't have to keep it in the raw format at all. For us, there's different data structures we can say for this data pattern, these are all the data patterns. So it's like you don't want to keep raw net flow. That's rough. But you process that and you you turn that into something useful.

Tim: 49:10

Metadata, yeah. That's what I was curious about. Because otherwise you're sitting on a data lake in Utah or something.

Ali: 49:16

And what am I gonna do with that? Right? It's like it's gotta have value.

Tim: 49:22

Exactly. Uh any other uh questions, Chris? I know we gotta wrap soon, but this has been excellent.

Chris: 49:29

Yeah, I do I do have one thing that's been on my mind since since uh Ollie brought it up early in the pod, and I didn't want to I didn't want to go too far down the technical rabbit hole, but uh I'm I'm really curious. Um so you you talked previously about um kind of letting the network do the negotiations from that kind of pub sub model, right? Um and I feel like this has been This has been tried many times, right? Um the idea of letting um if we talk about RSVP, you know, back in the day, you know, the the idea of allocating a certain amount of the network for uh an application or a flow or what have you has been tried. Um and it seems like everyone was just like, this is too hard. Let TCP do it and we'll we'll figure it out later. Um so I'm curious uh if you've if you all have taken a different approach to that and and what your idea is there.

Ali: 50:21

We we definitely have, because I think a lot of us have been burned by some of that as well, which was okay, we're not gonna be able to get IP to change its behaviors. All right, it's two set it's in its ways, it is what it is. Doesn't matter how religious you are about v4 or v6, it's IP. It's gonna do IP things. And trying to go to the standards body to change it, uh pointless effort. So it's more now a quest question of can we create metadata that allows us to handle that at the point in the network where it needs to be, which means I could do it directly at the edge, right, just before the traffic actually enters the custom the network in a in any shape or form. I can do any kind of transformations, right? To pre-translation, post-translation, one-to-one NAT, pat ports, whatever. All of that can be done before it enters the network. I could do it right at where the application resides. They just see a source IP address and they'll interact with it. But I don't have to build all that IP state machine at every intermediate point in the network. And I think that was one of the things that as an approach, we probably at Graphiant, I think was innovative, learning from where in the past we used to try and rely on every intermediate device having almost an entire picture of the network and knowing what to do. And almost make a local decision at a hop-by-hop basis. Right? When we think about BGP, when you think about OSPF, when you think about all these things, there's a lot of network state at every intermediate point. And the moment you introduce NAT or application symmetry, it gets messy. And so that's when it was, okay, the network itself should be as hollow as possible because then it becomes metadata based. Or like if you proof you're religious about segment routing, it's a segment routing label. Right? You can do those things without needing to think about all the IP state. You push that right to the boundaries and transform all of the IP layer aspects into metadata. So, yes, there's some NCAP, there's some TLVs, there's some modifications that allow you to do that, but that's the piece, right? Fundamentally, you'll see, and I'd love to come back and almost do like a lightboard and go, guys, this is how we're doing this, is to really say it comes down to the fewer people that need to know should know. The whole network doesn't need to know everything.

unknown: 53:20

Yeah.

Chris: 53:21

Everyone's on a need-to-know basis.

Ali: 53:23

Exactly.

Tim: 53:24

I mean, that's the that's the segment routing slash like go back further MPLS type of idea, right? Is that nobody needs to know everything, right? Just know enough to get to the next the next decision. And uh we we do have precedent for this, by the way. We have YouTube videos where we've had people come on and explain stuff to us. So don't uh be afraid of what you're you're signing up for.

Ali: 53:44

Not at all. We love that. We love that.

Tim: 53:47

Nice, excellent. Um, this has been awesome. We will have to have you back. Uh it's been great catching up with you and just being able to have this discussion. Uh just yeah, thanks for coming on, man. Uh and congratulations again on uh being coming famous enough to join our pike.

Ali: 54:03

No, honestly, I'm really, really glad uh that I was able to come onto the podcast. Like, and it was nice, right? Sometimes when you're in the different roles, right? You're you're selling, you're pitching, you're trying to convince a customer, trying to convince a partner, doing all these things. Sometimes it's just nice to just be able to talk about hey, there's it's an exciting time to be alive. I mean, what can I say? I'm really, really excited uh with whatever lies ahead.

Tim: 54:28

Awesome. Uh any closing thoughts there, Chris?

Chris: 54:32

Uh no, I was just gonna say, Ollie, maybe if you want, you can uh let the listeners know where to find you and if you have anything to plug.

Ali: 54:40

Yeah, uh absolutely. So uh our website is graphiant.com. We're a network as a service company. What that fundamentally means is if you want a really simple to use network that's able to handle your futuristic needs for AI and data transportation, and you only want to pay for when you use it, just come on by. Everything you want to know about us is out in the public domain. We don't like to hide what we're doing. We want you to know what we're doing, and if uh you like what you see, start using.

Tim: 55:20

Sounds good. All right, everybody. Uh I'm Tim, this is Chris, and our guest Ali, and uh we'll see another episode of the Cables to Clouds podcast.