Zayo Reframes Networking for the AI Era

Hey guys, thanks for the thrill. We're here with Bill Long, who's the chief strategy officer for Zayo, and we're having a little chat about, well, what the heck is going on with our networks in the age of AI, because suddenly things that were predictable are not. Bill, welcome to the show.

Yeah, thanks for having me. Looking forward to it. I think we're going to look back in networking with a certain amount of nostalgia, where we used to be able to say, "Hey, you know what?

" And now in the age of AI, we have all these AI agents that seem to be accessing data in a, shall we say, more willy-nilly fashion. And this is getting hard to manage and difficult to predict. So what are we going to do here to kind of make sense of all this and maybe bring some order back to networking?

That's a great question. I think when a big trend or a shift like this happens, I try to look back in history to be like, what does this look like? What does it rhyme with?

What patterns can we see where it looks similar? And a lot of this looks like cloud in my mind, but on steroids. Well, especially for the enterprise network.

And so if you go back to when cloud first kicked off, AWS launched their service, and to get to it, you basically VPN in. You have an internet connection, you create a VPN, you connect into it. That was okay for hobby applications and uses.

Then once you really want to move business-critical applications up into the cloud, you want to have private connectivity, and yet you started to have AWS Direct Connect and Azure ExpressRoute, and other solutions. And then you had to start designing your enterprise WAN to have more of a distributed footprint that could be in distributed co-locations connected to the clouds that could connect to those private environments. But really, what you were connecting to was a sort of a distributed hybrid environment, so that your infrastructure, instead of it being in a sort of controlled data center in your basement, it was spread out, it was in cloud.

So those same design patterns of distributed infrastructure are very much what's going to happen with AI as well, because it's going to be multi-AI instead of just multi-cloud, but it's going to be on steroids. So it's going to be higher traffic volumes, more secure data, more performant applications connected to more locations at a bigger ecosystem. So it's all the things we had with cloud, but just squared.

As part of that, we're hearing this phrase "networking as a service" more often, but I'm not quite clear if people understand the difference in what that means. Because a lot of folks would be like, "Well, I had a leased line back in the day. " Yeah.

Networking service is one of those terms that everyone has their own meaning for it. For me, I think fundamentally, is it a different product? And I think for me, the answer is no.

What you're asking the network to do, connect the things that you care about in controlled ways. Internet service is still internet service. A point-to-point Ethernet is still point-to-point Ethernet.

A multipoint VLAN is still a multipoint network. The real benefit of NaaS is making it actually easy to use. So in the environment that I talked about, both with cloud and what we're seeing with AI, is when you're connecting to a lot more locations with a lot more workflows that have a lot more specific security and performance requirements, that becomes an extremely difficult environment to manage.

So having a toolkit that can allow you to connect to all the things you care about, that's much easier to manage, easier to operate, easier to secure, that's the advantage of NaaS. So when I consider NaaS, it's not fundamentally a different product. It's a different form factor from both a user experience as well as a commercial form factor for doing the things you've always been able to do, but just make it a whole lot easier.

In the same way that cloud computing, it's still computer. CPU is still a CPU, if it sits in Amazon or in your desk. And just creating a much easier form factor for being able to find, connect, and manage the things you want to connect to.

Is this an either/or proposition as well? Because I think some people might have a dedicated network or something that they already have running, but can they layer in NaaS on top of that? And does it become a question of kind of creating some available capacity as I need it on demand, or is it I got to go one way or the other?

That's a good question. We have a NaaS product we call Dynamic Link, and commercially, whether you deliver a DIA service or a point-to-point Ethernet as a standalone service or on our NaaS platform, we're basically commercially agnostic to it. Just choose which one you want.

But the ability to have that, what today is maybe a point-to-point connection, being able to turn that point-to-point connection into a multipoint network, and to create a drain on the internet to that multipoint network, doing it on the NaaS platform gives you that flexibility and future option value. So a lot of our customers are choosing to be like, "Because I'm commercially agnostic to whether I do it on the old dedicated service or on a NaaS platform that's more flexible for the future," choose to do it on NaaS because it's both easier to turn up and use the service you have today and gives you the option value for the future. So I think that you could certainly do it on either one.

You could have a dual world, but if you can do it on the same price platform that gives you more future option value, why wouldn't you? That's kind of what we're seeing. Unless you've been living under a rock, you might have noticed that the price of memory has gone up, and with it, so has the price of switches and routers and everything that uses memory.

Is this a time to think about maybe a more flexible approach to networking because, well, the capital outlay for equipment is, A, larger, and B, I think this equipment's becoming harder to find. Yeah, and it goes back to a little about what we're talking about with both cloud and AI, of being able to get to assets that you care about. So, what you just talked about was memory.

You go back 18 months ago, it was GPUs. You go back a little bit further, power is a really good one, where we're looking for where you could put data centers, where there's available power. Over time, what is the premium thing that you want to connect to is going to change.

So having a flexible network environment where you can be like, however the world evolves, if I need to connect to memory and there's different sort of stranded values of memory that are available, or power, or GPU pools, having a flexible network platform that connects to the things that matter, that's easy to connect to them, such that you can take advantage of, oh, these GPUs just became available in this data center in a cornfield in Iowa. Do I have a network way to get there in a sort of scalable, secure way? So that's where I think the world is going, where a NaS plus connected to an ecosystem of the destinations that matter is a really powerful tool to be able to sort of prepare you for the future, whatever the future constraint happens to be.

And that's what we're... Relative to AI, I talked about power, you mentioned memory, I mentioned GPUs. That's what we're doing right now, is we view AI as really a two-sided ecosystem where there's a set of supply of GPUs and compute capabilities, and the enterprises are really the demand.

And our job is to make sure that we're connected to all the supply and that we reduce all the friction for the demand to be able to connect to that supply. So having in our NaS platform, you can discover who's available to connect to where. I can create a private connection, I could spin it up for a day, to use their memory, their GPUs or whatever, and then I can spin it down.

So what we view is that our job as networking is to help you with that problem. You don't know what the problem of the future's going to be. We want to connect the places that matter, make it easy for the demand to get to that supply with a low friction, easy to manage kind of way.

Also, the volume of data that's moving across the networks continues to exponentially increase, especially in the age of AI, but it's also becoming, shall we say, there's a much wider variety of it as well. How is the way we think about managing networks, given that data volume changing versus back in the day where everything was pretty much a file? Yeah.

This is a great-- This isn't exactly pertinent to enterprise networking, but I think it's a good design pattern. So right now, much of the internet was designed for basically replicating and distributing the same bit. " The way that content is delivered, it is cached deeply in the ISP network.

So Comcast or Charter or T-Mobile, whoever happens to be your ISP, they cache that content very deep in their network. It's in the cable head-end, it's at the mobile switching center for the mobile provider. And so that content is delivered from a deep cache to the end user.

With AI, there's going to be a lot more personalized content. So it'll be a show specifically for Mike who likes to hang out in the mountains in Appalachia, and so there'll be an ad specific for him in that, and that'll be served up to you. But because that ad is specific for you, it can't be cached.

So what previously was 70 to 90% of the internet could be cached deeply, that can no longer be cached. So now there needs to be networking that goes from what was previously cached out all the way where that content's being originated. But that same design pattern of whether if you're an enterprise company and you're operating a warehouse that has robots, and those robots need to be sending what is no longer cacheable data or cacheable files, they need to be sending data back to a cloud or an AI inference center.

It's going to put big strain on the getting from sort of where historically content was more locally hosted back to where it's now going to be generated. And so we're working with content origin folks and ISPs to solve that problem I just outlined to you. But I think it's a good example of there will be things that rhyme with that in the enterprise space for where things used to be local, they're generated dynamically, and you got to be able to change your network for that reality.

Well, yeah. To your point about that, as you were discussing that, I was kind of reminded that one of the things we seem to be seeing in AI is that we are trying to cache more context so that the AI agent doesn't have to put all that into memory, and the more the AI agent spends on trying to determine context, the less memory it has to do its actual task, and then the more likely things are to go haywire. So will enterprises kind of have this moment where we are trying to bring more data closer to the point where it's being consumed and created by AI agents?

Does that make sense? It does. Who knows?

I think the biggest thing with AI now is we don't know, we don't know. We're solving a use case right now where there's a map company that has just huge terabytes of data that is way too big for them to be bringing the data to the compute. And so what we're doing with them is we're standing up a big honking network that connects to a lot of different compute sources.

And so when they want to be doing AI using their map data, they can use the network that we have to actually bring a small piece of the data to the compute and change it. So rather than the compute and the data living in a single location, your data, and especially as people are generating more synthetic data for training, that's evolving. Where your training data is to where your compute is, you need to have a network that can accommodate being able to let those two connect to each other at scale in a secure way.

Because the compute you want, as an example, the compute you want to use might not be the same. So the GPUs and the custom ASICs that you're going to have for protein folding are going to be different than movie generation, that are going to be different than stock research. So we think that where the data lives and the type of compute that you want to use is going to be a dynamic environment, and having a network that can open up a flat layer two network that can connect the data wherever it lives to the compute, the optimized compute that needs to be used.

We don't know how it's going to evolve, so having high optionality is a valuable sort of asset How virtual are our networks today? " But I got a feeling that that issue's been forced, but where are we on this journey? That's a real interesting question.

So we're pretty far. I'm going to answer the spirit of the question I think you were asking of how far are we in a CCIE engineer logging into a command line interface versus executing what needs to get done on the network in some other ways. In production right now, on our dynamic link service that I talked about, that you can establish a network that could connect out to the internet, connect private locations, set up firewalls, do load balancing, do DNS and DD, all those sort of things you want to do.

We have put a MCP server in front of it, and we've created Claude skills that have been trained on all the things that a Cisco engineer would know. And so you can describe, "Hey, I run a 15-location law office at these locations. " Sure.

" And so it will create all of the connectivity that an engineer would have or that it will come up with. It can go and affect those changes using the Claude skill and very light prompting to go and affect those changes on the network. The universe of the possible is very evolved.

Getting enterprises comfortable, that is a very sharp tool. That is a lot of rope for someone to go and hang themselves with. So we, I think as enterprises figure out how they're going to use that, how quickly it's adopted is the long pole in the tent now.

And of course, in that Claude skill, it has all these checks. These are the things we're getting ready to do. Are you sure you want to go do that?

These are the things that could go wrong. Here's the rollback plan. So there's lots of controls in it, but we're evolving from a very smart person with a command line interface all the way to a Claude skill and light prompting.

We've evolved real fast, and it'll be interesting to see how quickly the environment and the industry absorbs that level of change. Does that make sense? So how far will we get?

Because you do hear the phrase autonomous networks and things like that, and AI agents are going to be managing all this stuff. And is that something we're seeing today? Is it around the corner?

Or just how autonomous is autonomous going to be? You can do it today. With the description that I described with a Claude skill and an MCP server, you could set up an agent that starts with a blank slate that can design, quote, order, turn up, configure, manage, and monitor your network today.

So that's all things that are possible. How comfortable enterprises are in actually doing that is going to be the long pole, and I think it's going to be interesting to see how it evolves because I wouldn't build my network that way. It's possible, but I would want to have a person in the middle.

I'd want to make sure there are lots of checks and balances. I'd want to be looking at it. But the world's moving really fast.

So I think the universe of possible is big, and it's going to be interesting in I think 18, 24, 36 months. " That's a good question. I think j- just generally, the security policies that I see people implement, and I do think AI is a great tool for that.

The sort of security templates that they put on their firewalls are generally very poorly configured. So I think there's a lot of just additional security that I think is a big one. I think not planning for the future.

I think that just thinking that the world that I'm planning for today is going to be the world of the future, and whether that's in terms of enough bandwidth or a tool that's flexible enough, see people get flat-footed. I think a lot of people learn from COVID on that one, that the value of optionality is something that's worth paying for. So we're seeing, I think that's not as bad as it was.

And I think just people aren't quite ready for the degree of change that's coming their way and being operationally ready, looking at the talent you have. Is your talent ready to embrace the change instead of fight it? Because you're going to be connecting more things, just the rate of change that's coming, and your ability to be flexible with that change is going to be a big asset.

So I think that's the security and the flexibility and the ability to change are the big ones. There's an old joke that says that the only thing a developer and an IT admin can agree upon is that it's the network guy's fault. Yeah.

Is part of that issue, though, that we fundamentally don't have an appreciation for the laws of physics, and we expect everything to kind of magically run, and there's this thing called latency that still exists, and we need to just write our code a little bit better? That's a good question. I think what's happening is because the bars to actually interact with networking, kind of what I just described with a light prompting and the MCP server can execute things, the tools of what a developer can actually do and impact networking are getting much more able to affect change on the network that you would normally not allow a software developer to have.

So this kind of immersion, the evolution of software to care and to be able to impact more on network is becoming real. But there are, of course, like you mentioned, the physical limitations, and those are always going to be there. I do think that the ability for the network to quickly adapt, because it is so much easier to go and create a new VLAN, to create a new security group, to go and add more capacity, subject to available capacity.

It's becoming so much easier to make the change. I think it's those that are able to put the tools to make the change in the developers' hands, it unlocks a lot of power for those developers. So I think the line is blurring, and the ability to affect change is getting much easier, and the combination of those two makes the network a lot less of the issue.

To your question on latency, I think this is a very unpopular sort of sentiment. I think latency is a tool that equipment vendors use to sell you a lot more gear. It takes 100 milliseconds to blink your eyes, and the fact that people are like, "Oh, you got to have special chips at the base of a cell tower because it needs one-millisecond latency," I'm like, "For what use case?

" So I think that if you're solving for a network latency budget of 20 to 30 milliseconds, that gets you a couple of hundred miles. That solves the vast majority of use cases. So yeah, you need to think about latency, but think of it in the right context of what you really need.

It takes 100 milliseconds to blink your eyes. You can get around the world in 100 milliseconds. All right.

Folks, you heard it here. Check your networking assumptions at the door because, well, networking isn't like it used to be by any stretch of the imagination. Bill, thanks for being on the show.

Great. Really appreciate it. All right, and back to you guys in the studio.