Cloud WAN Connecting networks for the AI Era with Google Cloud

My name is an Ruda. Uh, I'm a product manager here at Google Cloud, part of the cloud networking team. Uh, again, my focus area is primarily around Cloud WANs.

Uh, I'm sure all of you have heard the excitement and the buzz, uh, that we had, uh, post our cloud next session. And again, what makes this extra special this year is, uh, having a call out by our CEO Sundar, uh, in his keynote. Uh, and again, it just goes on to say the, the volume of importance that this has, um, especially now that we are truly and well into the AI era.

So again, getting this session started, uh, as customers have kind of, uh, onboarded the cloud adoption over the years, or over the, at least the last decade or so, um, the access patterns have still been more or less the same. So we haven't seen a lot of changes there. Customers over time have built these bespoke networks, which again, might rely on lease line infrastructure or MPLS providers, which may not give them that, that agility or, um, the, the fast pace that they need to adopt cloud and all of the new things that are coming out with ai.

So what we have often seen is by having these multiple bespoke networks spread across all areas of their network, uh, the consistency in terms of applying the same consistent security posture is often a challenge. Uh, not to mention managing a lot of these providers has its own set of challenges from a, from a day-to-day operations perspective. Uh, customers often complain of not having, uh, that visibility, the end-to-end visibility that, you know, we often need, uh, when it comes to having observability into our traffic flows.

And again, finally, uh, by dealing with these bespoke networks, we are often seeing, uh, the adoption, uh, is a lot slower. So, you know, customers are slow to adopt, slow to evolve to the new requirements, uh, slowing their overall pace of innovation. So finally, uh, the solution that we have for you now is Cloud wan.

Uh, this is our one network, which is built for the enterprise era. Uh, again, it's a fully managed backbone solution that is backed by Google's planet scale, highly performant, highly reliable network. And this is the same network that we have, which powers billions of users across the globe.

You know, every day when, when you come to access YouTube, I heard somebody access YouTube, right? So when you come to access YouTube maps, photos, even our cloud infrastructure, all of it, all of this is powered by the same network that now we are opening up to our cloud customers. Uh, what we are trying to achieve here is, again, from, uh, the, the, the, the architecture here is having that any to any connectivity.

So as you can see, we want to position Cloud WAN as that centerpiece when it comes to enabling all of the connectivity that you have. Now, that could be your branch offices, it could be your data centers, it could be other cloud providers, uh, services applications running in the cloud on the internet. And, uh, and the works.

The benefit of Cloud wan and the way we are trying to position this is while offering a lot of these additional value added services, we are also able to allow customers to get up to 40% savings when it comes to their total cost of ownership. Now, again, while we are also giving them the benefit of, uh, reducing their total cost of ownership, we are also giving them the benefit of getting up to 40% improvement in the overall application performance. And again, this could be based on the overall end-to-end applications performance, the overall latency.

So again, it's effectively a win-win win for our cloud customers. Looking at some of the use cases that we are tar trying to target to unblock by using Cloud wan, uh, the two that immediately come to mind is enabling high performance connectivity. Uh, and again, this is where we are trying to have that one network presence where it comes to connecting data centers, branch offices, other cloud networks.

And the other use case that we are trying to unblock with Cloud WAN is migrating those branch offices, migrating those campus network and consolidating them into, uh, this Google ecosystem by getting, by allowing customers to get the benefit of, uh, the high performance, the high reliability. So let's look at the first use case. Uh, so again, when you look at a typical customer's cloud onboarding journey, right?

This is kind of where they are at. Uh, they might have data center presence, they might have co-location facilities. Uh, they already might have a presence in, uh, Google Cloud.

For some of the more advanced, more mature customers, they might already have a adopted that multi-cloud approach. So they already have, uh, other cloud providers, uh, in addition to Google Cloud. Now so far, we already have a couple of services that have helped customers get that highly reliable, highly performant network that Google has to offer us.

And by that I mean your cloud interconnects, which lets you enable the site to cloud connectivity. This is, again, an SA backed high bandwidth, low latency network. And we also seem, we also have offered, started to offer cross cloud interconnects, which lets customers for allowing customers for connecting from, let's say, Google Cloud to some of the other cloud providers.

Now, these two services have been around for a while now, where, uh, a lot of customers have seen great adoption of, uh, having that multi-cloud approach, having, uh, a reliable, uh, direct connection into the Google Cloud network. But if you look closely at the co-location, uh, piece there, any site to site connectivity, even today, is relying on the lease line infrastructure, or it's relying on your MPLS providers. So that often puts customers in a situation where they're dealing with a lot of these individual providers, individual networks.

Often these networks are not ready for scaling and quickly adapting to the newer cloud requirements. So here's what we are announcing, where in addition to the cloud interconnects and the cross cloud interconnects, we are now also offering something known as cross site interconnect. Cross site interconnects.

Now bridges that last piece where in addition to having site to site connectivity, in addition to having site to cloud connectivity, cloud to cloud connectivity, we are now also offering site to site connectivity. Cross site interconnect, again, is, um, something that allows customers to have layer two connectivity across their different sites. And again, the benefit here is it's still relying and still dependent and backed by the same infrastructure that the cloud interconnect is powered on.

The cross cloud interconnect is powered on. So the customers can now expect the same level of performance, even when using cross-site interconnect. Uh, with layer two connectivity, again, Google Cloud becomes the first major provider to allow customer traffic to be onboarded onto its network at layer using layer two.

Uh, again, this network that we talk about, it's global, it's highly reliable. It's a fully managed SLA backed network. So in that sense, customers can be guaranteed of, you know, all the wonderful features that we have to offer when it comes to performing, uh, giving high performance, uh, providing part diversity, uh, and also the reliability that comes along with it.

Uh, customers can now choose from, uh, a capacity, a physical capacity, which could be either, uh, 10 gigs or a hundred gigs or multiples of these to have that end-to-end connection built across their different sites. The other benefit that you can see here is, um, in my, in my diagram here, you see there is no reference of a VPC network or a cloud router. So what we have effectively done is we have decoupled the cloud infrastructure from the site to site connectivity piece, so that way customers are able to still get the benefit of having site to site connectivity while delo decoupling their cloud infrastructure.

Okay? Now, some customers, again, when we work with them, we often get this question, well, but why, why do I need cross site interconnect? Why can't I just build all of this by myself?

Uh, short answer is, it's hard. It's very hard in today's day and age to have a global footprint of a fully managed, scalable network, which has part diversity, which has the, the capacity to scale up to your needs. So that's where, uh, some customers opt for a DIY approach where they might be purchasing or pro procuring wavelengths from different providers in different parts of the world, and then stitching them together.

So the problem with that approach is when you're trying to do this self stitched network, you're often losing out on that end-to-end visibility. You're dealing with independent providers, you're dealing with independent SLAs, you're not able to get that one network, which lets you give, lets you get that end-to-end visibility into, into your traffic, especially when it comes to, uh, an outage situation. Now, again, a lot of these, uh, you know, deployments are running under the sea.

It's subsea cable optics. In case of a failure situation, there is now different providers the customer has to work with. It could also lead to a cascading bit of failure where every bit of fiber that's backed up is also being impacted.

So this is where the, the value proposition of, uh, cross site interconnect is we are able to present ourselves as one Google network to all of our customers. So they're not dealing with disparate, you know, providers. Uh, you, I'm sure you've heard this already, but we already have 2 million miles of fiber presence across the globe.

So that's a lot where we are owning and managing and operating these, uh, subsea cables. Again, the number of subsea cables that we own and operate are about 30 or more, which is, again, probably the highest in the industry. So again, considering all of that, uh, cross site interconnect does offer this, you know, wonderful value proposition to, uh, our customers, uh, that they can use for site to site connectivity.

Is this Guy Courier future? Is this roughly a, like a virtualized or abstracted managed service that you're providing? Essentially like, uh, because you know, you have way stations to deal with and your own connection points, but it's, it, it, it, it it's presented as something unified, but you're just managing that, is that right?

Uh, I would still go on to say it's a, it's a Google managed, owned, and operated offering, so that way we are still in control. So we are not relying on our third party providers or, you know, one of the other, you know, vendors to, so to speak, connect, or offer that connectivity to our cloud. So we are not trying to, uh, you know, to use the word, subcontract it out to other providers.

So this, once you get on the Google Backbone network, that's our network that we manage. We have our SRE teams that, you know, maintain, monitor, audit, these networks, uh, constantly. Mm-hmm.

So it's always gonna be our network, uh, that we are able to offer to Our, those data center endpoints. Those are not necessarily, uh, Google Cloud data centers, correct? Right.

Yes. So, so there must be some regional variability, The regional Based and inter-regional variability and avail in availability of, of the cross site enterprise? Yes.

The, the Edge locations, so the co-location facilities are still going to be a, a shared infrastructure where, you know, you can pick up any one of the, the major co-location providers. We might have a presence there. So that's the shared bit of, uh, uh, infrastructure that we are offering.

That's where the customers connect into our backbone network. Uh, but broadly speaking, the network itself becomes that one Google network that Do, I guess in the end. Do, do customers have to concern themselves first with your availability map against their current?

Probably not. You know, our, uh, uh, topology Yes, yes, That's, that's the wrong word, but yeah, they, they should consider that first. Absolutely.

So I think, uh, having the right presence at the right co-location facility is also important. So yeah, to your point, right, uh, let's say the customer has presence across EU in apac, in the North America, we have a list of co-location facilities where we are able to offer this connection. Uh, and again, they can have a dropout in any one of the other locations as well.

So it is important to kind of have a close alignment between what we have in terms of our co-location and edge locations and the customers, uh, availability to also meet us at that point. Okay, Thanks. So the site to site requires an SD-WAN vendor?

Great question. So, uh, I do, okay. Uh, let me, let me actually get to that.

So The, yeah, okay. Okay, go Ahead. Yeah, so short answer is no, uh oh, no.

So the benefit there is, since we are offering this at a layer two level, uh, we are basically just handing it off to the customers to basically provision their visor on top of it. And it doesn't actually, like, they could prefer to have an SD-WAN overlay if they want to, but there is otherwise no dependency that they have to deploy an SD-WAN implementation. They could just terminate it on their existing routing infrastructure and also still provision the pseudo wire that they, And that's for the colos as well?

Yes. Okay. All, And, and just just so we're clear, I know we have titles on slides, but, um, there's the, there's this notion of the Google Cloud partner interconnect, partner interconnect.

Yes. And then there is the advantage of what the guy is, you know, this, this notion of you're within the Google network mm-hmm. And then there's the extension of that Google network possibly to a real estate investment trust, a third party, a colo mm-hmm.

Uh, an adjacent campus. Mm-hmm. Um, that connection, that's the partner interconnect.

Yes. Slightly different. Okay.

Uh, the, the partner interconnect. So I think, um, that term is primarily associated with our cloud interconnect offering. Okay.

So when you are dealing with cloud interconnects, customers have an option to either pure directly with Google. So that's our dedicated, uh, interconnect. Uh, but let's say if customers need a sub 10 gig connection, and that's where our partners come into play, where they get the partner interconnect provision, and again, that helps provision the site to cloud connectivity piece.

Um, and that's, that's the partner interconnect. And so this layer two connectivity that you're referring to, that was like high capacity, low latency, not necessarily a Google managed end to end, though, uh, where's the demarcation? Uh, So yeah, the, the, so the de up to the demarcation, it would be, uh, the Google provided network.

Yeah. And then it kind of fans out to where the customer wants it to be. So Jim Rinky for ZDC, um, just curious, uh, with companies like Oracle down the street, um, expanding the number of regions they have.

Mm-hmm. Um, it would seem to me that this would be a compelling case for them to latch onto your environment, right? Mm-hmm.

Put their stuff in your data centers and, and so forth and so on. But question, what about government level? Are there different levels, you know, like L four, L five for this as well?

Or how would this play out? Right. So I think from a security standpoint, uh, I think that stack is still evolving, is what I would say, at least at this point.

Uh, the, the target again at this point was more of our enterprise cloud footprint, where, you know, more of your, you know, banking infrastructure or other, uh, FMCG providers, I think they are the ones that we really want to kind of immediately kind of focus on where they typically have these branch office connectivity. But it's a great point you bring up in terms of, you know, having some level of regulation also tied into this, uh, offering, right? Uh, which we can also then, uh, have our government customers, uh, right.

Use it for. Okay, thanks. Uh, quick time check.

Okay. Nine more minutes. Okay.

Uh, so again, uh, the, the proof is in the pudding. So we like to call out, like, you know, one of our key customers here, uh, who've kind of, uh, deployed Cloud WAN for their infrastructure. And again, the benefits that they had to call out there was it helped enhance, uh, the stability and the reliability of their, you know, broad network.

So, uh, it's something that we've already deployed, try, tested with our, uh, you know, live customers. Uh, so we can definitely, you know, bring that up as a success story, uh, when it comes to using Cloud wan. Uh, moving on to that second use case, right?

So this is where, uh, we really want to focus on the SD WAN uh, implementation. So the second use case that Cloud WAN helps to unblock is consolidating these branch offices or, uh, these different networks that customers have built over, you know, over the years. Uh, the benefit, uh, here is, or the, the value proposition that we are trying to picture is bring in your sdwan head into cloud.

So this is where you are now deploying, let's say from one of our partner ecosystems. You're bringing in a vendor, you're deploying that virtual appliance into Google Cloud, and now you're also pairing that up with our premium tier networking. So, premium tier networking has also been something which has been around for a long time.

What we are trying to pitch here, or we are trying to deploy here, is bring in that SD WAN appliance connect all of these branches into Google Cloud using our fast premium tier network. And again, the benefit here is as you kind of, uh, sorry, I skipped here. As you still bring in these, um, SD WAN headends into cloud, there is a cost reduction that customers have often quoted where, you know, now we don't have to deal with, you know, these bespoke MPLS network, lease line contracts, things like that.

Just by offloading everything to premium tier networking, we are able to bring in and consolidate a lot of our networks from a partner ecosystem perspective. We have quite a few vendors listed here in the SD WAN space. Uh, so again, I'm sure most of you are familiar with these vendors.

And again, the list, uh, is growing. So we have a lot of options when it comes to selecting an SD appliance provider of the customer's choice. Now remember I mentioned two things, right?

There is the first part, which is bringing in the SD-WAN appliance, but how do we make sure the connectivity is fast? How do we make sure the connectivity is reliable? That's where our premium tier networking comes in.

So again, premium tier networking is not something new. It's been around for a long time where we offer this way of routing traffic as close as possible to the source. So again, as you can see from the, from the, from the, from the graphic here, traffic enters the Google backbone network as close as possible to the edge.

So that way we are able to absorb and ingest that traffic right into our network as close as possible to the edge. So that way the customers are now not dependent on the health of the internet, you know, suboptimal routing things that happen typically with ISPs and get on our backbone network to get the performance benefits, uh, that we call out before. So when you look at the traditional, um, you know, routing that, that we see in the internet today, you'll typically go from a branch office through ISP 1, 2, 3, so on and so forth.

And every time you add a hop, every time you add an ISP, you're introducing a latency. That's the performance penalty that customers are often complaining where, Hey, our cloud infrastructure is fast, our data center infrastructure is fast, but this last mile connection is often re reducing or hampering that connection into cloud and cloud services. Uh, the reason we are able to get as close as possible to the user is, as you can see, we are ranked number ones when it comes to the BGP peering ranking amongst all cloud providers.

So that's the reason why we are able to get as close as possible to the user, uh, and their ISPs to get their traffic onto us. Now, another little piece of this, uh, puzzle is also what about the last mile? Even that last ISP is something where customers come back to us asking, give us your best recommended, give us your most reliable ISP that can help us connect into Google Cloud.

So that's where we have kind of also launched a new program, which is the verified peering program. This is a way of, for us, Google to badge these ISPs as vetted, validated, highly performant, uh, reliable ISPs that can help enterprises connect into Google Cloud. So again, normally an approach similar to the partner interconnect story, right?

We also have a direct peering story where, uh, ISPs typically have peering relationship directly with Google to get the public ips announced. Enterprises often don't have the bandwidth to, to go through the process, to go through the, the requirements, meet the requirements, and be onboarded onto direct peering. So that's where VPP is the solution, where as you see, we have a list of these ISPs that are now able to, uh, that customers are now able to reliably get on, uh, to get to the fastest, uh, Google backbone network that we have.

Uh, real quick, yes. Uh, Jay, again, from Nexus Tech, when you've added these VPPs, are the VPPs signing up for like, and here is the Google supplied, you know, appliance that's gonna be deployed into your network operation and you're going to give those telemetry, uh, information back to Google for processing to keep you in that verified vetted state. Great question.

So the VPP program is primarily meant for validating the access pattern itself. Uh, the telemetry, the observability, that's more, uh, something that again, the customer, because again, the customer is still working with the ISP Is a shared, shared responsibility. There is a shared responsibility, uh, but some caveats there is, we have a few ISPs that are also able to offer the last mile SLA.

Okay. So just to kind of complete that story, we have the SLA built into, you know, the Google Cloud infrastructure. We are now also able to have some VPPs who are able to give us that last mile SLE as well.

So given Yeah. Verified. Not guaranteed.

Yeah. Verified. Verified.

Exactly. Thank, yes. So just to clarify, so if, um, if the location is on the Google backbone mm-hmm.

Then you don't need SD wan, but if it isn't, then you need an SD WAN overload. 'cause it's gotta be, right? Yes.

Okay. Okay. Alright.

I, I'm just trying to rephrase the question, right? Yeah, no, no. Right.

So the question has, has sort of smoothed out by like, depending on it is an existing on the, on the Google, on Google backbone. Yep. Or not, or not.

And then it has to be on the SD one. Yes. Alright, fair enough.

Okay. Uh, so again, uh, we, we need success stories, uh, which again, speak volumes to the benefits of using, uh, and unblocking these use cases with Cloud wan. So again, uh, Nestle was another success story that we have.

Who adopted Cloud wan, uh, in their existing network deployment. Uh, again, kind of the, the scope of their deployment was, you know, across 120 countries, 1500 branch locations. So they had a pretty large footprint.

Uh, and the way their architecture was structured is they had, uh, a managed telco provider who kind of helped build that MPLS network for them, uh, manage that connectivity, manage that SD WAN overlay. Uh, while Nestle was managing the cross-cloud connectivity aspect of it from a security standpoint, they had a lot of these physical devices that were sitting at their data center locations or the CO of facilities to actually do the firewall inspection or security inspection. Now, the challenge that Nestle had was, again, they wanted a cost efficient, scalable, and reliable system that was still able to give them that end-to-end visibility into all of their traffic.

So this is where Cloud WAN kind of helped support that, uh, supported that requirement. By first onboarding, uh, the SD WAN headend onto Google Cloud, they were able to completely decommission, uh, their MPLS networks and use premium tier network to connect directly over the internet into these sd-wan. So all of these branches are now able to run these SD-WAN overlays on the internet using premium tier network, uh, with a VPP provider to consolidate all of this connectivity into Google Cloud.

Now, the benefit that they called out was, again, this is coming from the customer, is, uh, they were able to see, uh, uh, an up, you know, up to 40%, uh, improvement on the latency by onboarding onto premium tier networking and VPP. Uh, there's obviously a cost, you know, benefit by decommissioning a lot of these old MPLS circuits. They were able to see a lot of value, uh, in terms of, uh, using premium tier networking.

And finally, now they have the ability to even go ahead and decommission these older firewall and physical devices, which are sitting in their data centers, but instead have a managed stack running in Google Cloud, uh, with the integration of, uh, NCC Gateway. So again, uh, I'm right around 10 seconds. Can I, can I ask you?

Go Ahead. Yeah. Um, so, so is this integrated?

I mean, is it exposed, managed? Does it look like another Google Cloud service, essentially? Is it part of the same admin console or is it separate?

Yes. Great question. So everything that we've talked about is available through your console.

So when you, when it comes to deploying cross site interconnects, when it comes to deploying cloud interconnects, cross-cloud interconnects, uh, SD wan, which could be our out appliances, a spoke of N-C-C-N-C-C gateway, all of this is now part of that same console, uh, that, you know, customers already use today when accessing Google Cloud. And what's the onboarding experience? Uh, onboarding?

Onboarding experience? Onboarding Experience? Yeah.

So if you're qualifying in terms of locations and all this other sort of stuff, you kind of sit around and get some progress reports and then ity boom and there it appears and, and, uh, you know, Yeah, sure. So maybe I can answer it slightly differently where the onboarding experience again, comes down to there would be a physical aspect to it where the customer's provision the physical connectivity, and you go through the LOA process, you go through the connectivity, the connectivity testing process. Uh, and then once all of that is set up, you can go ahead and build whatever overlays that the customers want.

So again, that could be based on the SD WAN use case, or it could be based on the site to site use cases. So I, I feel like there's a benefit here that I've been feeling and not realizing until now, which is that, um, it's, it's the same contract, it's the same relationship. Um, and you know, there's a certain simplification in terms of say global application management.

Yes. Because you don't have a second provider to work. Exactly.

Yeah. That's exactly the case where we are kind of presenting this as that one network and it's a one-stop shop where customers can get all of these different use cases, uh, kind of served.