Awesome. Well, I'm going to go ahead and kick it off. Hello everyone, and welcome to today's virtual event, Modernize Business Operations for Regulated Environments. I'm Laura Dunn with Megaport marketing, and I'm happy to kick off today's virtual event. For the next one hour, this presentation, followed by a Q&A, will discuss how to develop a practical and effective hybrid cloud and/or multi-cloud strategy for businesses in highly regulated industries. Pull up a chair and listen to this engaging discussion featuring fantastic speakers from Digital Realty, Google, and Megaport. Before getting started, we have a few housekeeping notes to share. If you have any questions throughout the discussion, feel free to type them into the Q&A section, and we'll do our best to get to them by the end of the hour. Feel free to add any comments in the comment box on your screen as well. All of our panelists would be happy to continue the conversation with you after the event. Please feel free to reach out if you would like to connect with them directly. Okay, let's get it started. It is my pleasure to introduce the first speaker for today's virtual event, Don Atwood, Senior Solution Architect for Digital Realty. The virtual stage is now yours. Thank you, Laura. Hopefully we have no technology problems this morning. Good morning, good afternoon to everybody. I'm glad to be here to talk about this important topic. We have some fantastic speakers and content for everybody today. There we go. What I'm going to do is I'm going to set the stage here and tee it up for the brilliant gentlemen who are coming after me to talk in depth and go over a lot of architecture conversations about how these worlds connect and the great platform that the three organizations and companies as a holistic solution house together, and how effective that is and what it can mean for you. I want to set the stage, since everybody here might not be familiar with who Digital Realty is. We are the largest colocation provider of data centers worldwide. We have an expansive footprint. I'm sharing the map, which shows most of our locations, although there's a lot of growth happening. I think we're over 300 locations at this point. Also on the map, you'll see the picture of the subsea cables. I want to highlight, we have strategically purchased and built assets geographically where these subsea cables connect. We have an internal philosophy, in addition to having great data centers that are up all the time, to have an any-to-any connection philosophy. We know the world is a hybrid world. We know that there's really good reasons to be in cloud, there's fantastic reasons to be on-prem. Most customers we have, in the thousands, have a version of hybrid or multi-cloud, all with a baseline backend within our facilities. Being strategically placed where the bandwidth flows is important to us; also, partnering with other great companies like Megaport, and Google, and others, is also very important. This is just the view of our data center footprints around the world, and later you'll see where Google sits, and you'll see a lot of correlation and linkage between those, which is important to having success. I mentioned Google. Google is one of the many cloud providers we have on-ramps and access to. I would say Google is one of our very growing strategic partners. I think last year they were the fastest-growing infrastructure cloud provider on the planet. Super aggressive, unbelievable company, which we'll talk through today, and we'll actually talk through multiple use cases of customers that sit on-prem with us and also burst out to the cloud for various reasons, and there's a lot of scenarios and a lot of different reasons why people do that. So, we see a bright, bright future grinding with Google together. Of course, all the others are available as well, all the ones you'd expect. In that any-to-any philosophy, we want to be able to connect you, whether it's all of us or not. We want to connect you to all your partners, customers, providers, CSPs. We have that ecosystem, and that's an important component of our growth. Just a little housekeeping before we jump into it. We are going to be referring to Service Exchange today a lot, which can be universally used with the name Megaport. Megaport is the backend of Service Exchange. Service Exchange is Digital Realty's white- label enhanced version of Megaport. The backbone is still Megaport. We, through our partnership, have taken that already fantastic platform with that any-to-any philosophy and enhanced it within our facilities. If you have Service Exchange powered by Megaport in your solution, you'll know that in our facilities, everything is fully redundant, diverse paths. We know that uptime is of the utmost importance, and so when it's built within our facilities, it's fully redundant in every way. You're going to see some fantastic architecture drawings here in a bit. Whether you have data or network or control hubs or whatever you're running on the backend within our facility, as you burst into different providers and customers, you'll know that you're fully redundant over the Megaport backbone. Let's jump into regulatory and talk a little bit about it, and we'll kind of kick it off, and I'll start with a use case right after this, before I hand it off to Google. Obviously the regulatory world, compliance is a huge deal. We have this conversation very commonly with our customers. Lot of needs for FedRAMP, healthcare, government, financial services. There's all kinds of logos we could put to the right of compliance requirements that you probably have. Often we hear a lot about SOC 2 and HIPAA and FISMA, and those sorts of things are the most common. What I want to highlight here is the compliance that's required, depending on what industry you're in, is not just for the cloud or just for the data center side. It is an ecosystem compliance, right? When you go in and have a FISMA or a HIPAA review and there's audits, they look at end-to-end. It's an ecosystem. We have a place, Google has a place, Megaport has a place, and it's that ecosystem that has to be compliant. We take it super serious on our side. We have many customers that have achieved these certifications wherever they happen to be within our facility worldwide. We are a large chunk of that component. Now, depending on what country you're in, what regulatory requirements there are, there's a thousand different scenarios, a big equation, if you will. Some things are better suited for the cloud, some things are better suited for only on-prem or somewhere in between. We can't go through every scenario, although you're going to see some examples in the architecture later. A lot of the conversation that comes up with us and our customers on a daily basis is about data loss prevention, compliance reporting, right? A lot of times you have to have things centralized, even if a customer has an edge deployment in many of their locations, sometimes they have to have the compliance centralized in a certain country based on what they're working on. There's a lot of deviations to that. Data sovereignty, data replication needs. Encryption's a big deal, right? Both in transit and at rest. Not only encryption, but where do you store the keys, right? If you have data, for example, in a controlled country, they might not let you store a key in another country. Understanding and managing all that is a big piece, and why we spend a lot of time helping customers achieve the certifications, which is pretty routine for us and certainly a requirement under regulatory that umbrella. We see a lot of controlled country requirements, especially when you talk about the EU as an example. Germany, I can think of, the goalposts are moving constantly, and it's our job to keep up with that. We work with our customers quite often, making sure that our side is in compliance. We know our partners are as well, and so that's a piece of the puzzle. As those goalposts move around and regulations change, it's our responsibility to make sure that you are compliant and can meet all of those requirements, which we routinely do. A controlled country, by the way, is a big one. Obviously places like Russia or mainland China, there's some challenges there. We work with customers throughout their journey to accomplish that when required. Let's jump into a use case, Biotech. This is in the medical side. Had to strip a customer name because we honor privacy. We have a joint customer between Digital Realty, Megaport, and Google. This is kind of a relevant conversation today with all the COVID stuff happening. We're all probably sitting in our living rooms. Google is running a massive parallel computing cluster for this biotech customer that's doing antiviral research and drilling into billions of molecules each week to figure out what are the best antivirals available. This customer has a core base within our data center. They are a Megaport customer, and they burst to cloud for a lot of the analytics and using their massive compute resources. They have to be compliant across all three to maintain their certifications and requirements. This is just a great example of how those worlds connect together and how the ecosystem with compliance has to work. Fantastic partnership example. At Digital, we have thousands of customers that we have to meet these standards for every day, in many different countries. This is a super important piece to us and something that we can help you with as that topic comes up. We'd be happy to share with that. With that, we have a great panel coming up. I'm going to hand the ball off to John, and thanks. By the way, at the end, I just want to mention, there'll be an offer to have some free connections to Google and try out this ecosystem for about three months. Stay tuned for that. I'll hand it off to John. Thanks. Great. Thanks, Don. Good morning, everybody. Or good afternoon, depending on where in the world you're calling in from. My name's John. I'm the Application Modernization Lead for Google Cloud's Partner Engineering team. What that means is I work with our services partners, as well as our customers, helping them with anything that falls within our Application Modernization portfolio. Things like containers, CI/CD, and hybrid and multi-cloud, which we'll talk about today. Today, I'm going to give a brief overview of Google Cloud's solution to hybrid and multi-cloud, which is called Anthos. I think I just skipped ahead a slide. Okay. Before I get started, there's a couple of things to note. First, Anthos isn't a single product, but it's actually a suite of products. I'm not going to go into detail of every component, but I'm going to briefly highlight some of the core components. Second, I'm going to try to keep this high level, but I might dive deep every once in a while. However, the key takeaways should be the business value that you can get from Anthos. If anyone at your company wants a deeper understanding of the product, I'm happy to have a follow-up conversation or connect with your Google Cloud team. Most organizations have either taken the leap to public cloud, or at least they have a cloud strategy that they're exploring. We understand a lot of workloads are still going to remain on-prem, and this is going to continue for a while. There's various reasons for this. It could be proximity to your end users, compliance or data locality rules, a lot of things that Don just mentioned. While organizations are building out a cloud strategy, a big component of that is to understand how do you handle hybrid cloud or multi-cloud. When you start to adopt a strategy, you are faced with some challenges. Security versus agility. This is a big one. Developers want to push code to production very quickly, no matter where that infrastructure is. Security teams want to ensure the code is safe and the tools used by the developers are verified and trusted. This sometimes slows down the development process. Reliability versus cost. When people think of reliability, they think of adding redundant machines, data protection tools, and other services that increase your cost. Lastly is portability versus consistency. When I start to run a modern application across different environments, like an on-prem data center or multiple different clouds, I want my application to be portable, but I also want a consistent experience. My infrastructure teams want to deploy, let's say, on-prem, in Google Cloud, or even another cloud, without having to make any significant changes or adopt a lot of new tooling. How does Anthos help with all this? First, I'm going to reiterate, Anthos is not a single product, but it's a suite of products that, when together, help solve challenges I just mentioned. I'm going to briefly discuss the components over the next few slides, but before that, here's a list of some of the benefits that Anthos does provide. Write once, deploy anywhere. What this means is a developer doesn't have to build their application differently depending on the environment it's being deployed into. Consistency across environments. This is for a security professional or an infrastructure admin or a developer. It doesn't matter what role you're in. Anthos is going to provide a consistent set of tooling that you can leverage no matter whatever environment you're in, on-prem or in the cloud. As I speak of some of these components, you'll see how the rest of the benefits are achieved. Before I jump into the components, I've mentioned a few roles already, like security engineers, infrastructure admins, and developers. I think it's important to note that the different components of Anthos provides various benefits depending on which one of these roles you're in. As I talk about components, I might mention that this is why it's valuable to a security engineer, or this is the value this component would have for the infrastructure team or for maybe an app owner. It's also important to note that a lot of Anthos components are built on top of open source products. This helps avoid any sort of vendor lock-in, and it allows our apps to be portable. This goes to that portability versus consistency challenge that I mentioned before. Okay. Let's actually talk about what is Anthos and where can I deploy it? Like I mentioned before, it's a suite of components, and it helps with things that you see on this slide. Things like policy management, cluster management, and so on, and it can be deployed on-prem, at the edge, or across multiple different clouds. When I drill down, you see some of these components, which I'm going to discuss. Things like Anthos GKE, Anthos Service Mesh, and a few more that you can see here. Note at the bottom, we have the deployment options. For on-prem, that could be VMware or bare metal. We also support running in AWS or Azure. Then on the right, you see something called Anthos attached clusters. This means is you can actually connect a non-Google Kubernetes cluster, and I'll talk about Google Kubernetes Engine on the next slide, but we can connect a non-GKE cluster into Anthos. That helps provide that single pane of glass visibility to all my clusters, as well as some additional features. This is important because let's say you're already running a large Red Hat OpenShift or SUSE Rancher environment on-prem, or maybe you're using EKS or AKS in Amazon or Azure, and you start to leverage Anthos, but maybe you're not ready to migrate those clusters to GKE just yet. You can still connect them back to the Anthos hub. You can see them in the control panel, you do have some additional management capabilities that you can leverage from Anthos. Okay. One of the core components is Anthos GKE. It's really important to understand what is GKE and a little of the story behind it. Admittedly, Google was late to the cloud game. When it comes to Kubernetes, we have the most experience and the most mature offering out there. That's really important. It's not a secret that Kubernetes is the de facto standard for container management. It's also no secret that setting up Kubernetes isn't easy. It's really hard and cumbersome. Not only that, but it becomes more confusing when you start to look at things like day two operations, right? Upgrades, monitoring, logging, security operations, and so on. In fact, a lot of customers that try to deploy Kubernetes on their own oftentimes fail because they don't have a good plan on how to handle those day two operations. That's why having a managed version like GKE is really important. GKE assists our customers to make cluster creation easy. It provides a lot of advanced cluster management features, things like load balancing, auto-scaling, auto-upgrades, and repairs, as well as logging and monitoring. All of this with very little effort from developers or infrastructure teams. Once your code is in a container, you can create a cluster using the console, the Command Line Interface, or the API. It's really easy to do, and it doesn't require you to have an intimate knowledge of Kubernetes. As I mentioned, Anthos is a lot of different products bundled together. At the core, we have Anthos GKE. What that really is taking our managed version of Kubernetes, which is mature and enterprise-ready, that we already provide to our GCP customers, and we're bringing it into your own private data center or even another cloud. Here's what you see in the console. It's kind of hard to see. I know the screen there is a little small, but it shows all of the clusters you have deployed. There's some that say GKE, so those are Google Kubernetes Engine running in your Google Cloud environment. You have a couple clusters that say on-prem, so those could be running in your data center. Some that just say GCP. Those are actually just open source Kubernetes we threw on some VMs just to show you that we can connect them back to the hub. If you had AKS clusters in Amazon, you could actually see those here as well. Another component is Anthos Config Management. Imagine that you have one team deploy a Kubernetes cluster. That team has to worry about enforcing policies for that cluster and putting security guardrails in place, which might not be that hard for one single cluster. Imagine that team starts using Kubernetes a lot. They go around, they tell all the other teams within your company that Kubernetes is amazing, and everybody wants to start using it. Another team adopts it, and another team. You have clusters running across your entire company. Some on-prem, some in Google Cloud, maybe some in another cloud. Even if they're in the same type of environment. Imagine that I'm a restaurant, or a retail chain, or a bank with a lot of branches, that I run Kubernetes in each store or branch to handle various things. Inventory, point of sale, a lot of other operations that would happen in store. This is actually a common trend right now, that a lot of stores are doing this. In these scenarios, how do I ensure that the policies that I set are actually enforced? How do I ensure that an IT admin at a single store or bank branch or whatever it may be, doesn't make a change to a cluster that's running there? The answer is Anthos Config Management. Anthos Config Management allows you to define and enforce policies across all of your Kubernetes deployments. You basically take a central Git repository that manages things like access control policies. RBAC, resource quotas, namespaces, whether it's on-prem or in the cloud. Anthos Config Management's also declarative, so it's continually checking the cluster state, and it's applying that desired state to enforce your policies. What it's doing is it's going to put security guardrails in place. As an administrator, you need to create a consistent environment that's going to offer security by default for your developers. You can deploy new environments very quickly, and you're going to have that confidence that the desired cluster configuration that you've set is going to be applied. Anthos Config Management also helps to maintain things like cluster sprawl, which I mentioned earlier. If I'm starting to grow clusters in all these branches or whatever it may be. As more and more teams start to leverage Kubernetes or grow their environments for redundancy or to expand to new geos or for whatever reason, you start to increase the overhead in managing these separate configurations, and that's the point of config management. It's going to solve that problem by delivering a single centralized place for multi-cluster management. The last component I'm going to mention is Anthos Service Mesh. If you're not familiar with the service mesh, don't worry. All you really need to know is that a service mesh automates a lot of functionality into your network. A lot of the benefits that you get are things that a developer might have to code into their application. With ASM, developers don't have to worry about any of that. It's automatically handled. The three main things that I like to highlight when I'm talking about a service mesh is observability, operational agility, and policy-driven security. With observability, Anthos Service Mesh or ASM monitors things like error rates, latency, saturation, and traffic out of the box, which allows you to create an SLO based on those metrics. It also builds topology graphs for you in the console that show you which services are communicating to which and which services are not communicating to each other. It's a really good tool just to kind of see how your applications lay out. The second thing is operational agility. What that means is, when I'm deploying an application, as a developer, I have to account for things like what happens when one service fails. Is that failure going to cascade down and impact my other services? We can do circuit breaking with ASM, which would essentially say if that service fails, we can cut it off from the rest of the application. Your application still runs, but that one service might need to be repaired. How do I handle routing traffic between different applications? What if I have an application that's running in my on-prem data center and I want to start sending some traffic to that application, but in the cloud? Maybe it's a canary rollout that I'm testing some stuff. Anthos Service Mesh can do all of that for you without developers really having to modify their code or make any changes. Lastly is policy-driven security. Anthos Service Mesh handles certificate management as well as authorization and authentication between my services. It also is going to add mTLS to encrypt traffic. We could talk about each one of these components, Anthos Service Mesh, Anthos Config Management, or Anthos GKE, probably for hours each. That's not even everything that's included. There's other components like Binary Authorization API that helps you build a secure software supply chain, which I know is very important with a lot of the recent news about some of the security breaches lately. There's a lot of other components out there that we could talk about, I think the key takeaway is when you start to build out a hybrid cloud or multi-cloud environment, you're often faced with multiple different software licenses, an inconsistent experience, and added work for your infrastructure teams and application owners, right? They have to make adjustments for each new environment. With Anthos, all of this is handled for you. You might be thinking, what about legacy applications, right? Maybe I'm not containerized, or only a portion of my workloads are containerized. Can I manage virtual machines or Windows workloads? Anthos has support for virtual machines coming very soon. It should be before the end of the year. We can already run Windows containers in GKE or in GCP, and that support is coming to other environments to follow. Happy to chat about those if you have any questions. Definitely feel free to reach out. For now, I'm going to hand it off to Nick, who's my colleague from Google, who can talk a little bit more about the networking piece. Great. Thanks, John. Good morning or good afternoon, everyone, depending where you're calling in from. As John mentioned, my name is Nick. I am a Network Specialist Customer Engineer with Google Cloud. Really, what that means is I spend most of my time talking to customers about our network products and services within GCP and helping them build and architect network solutions within GCP. I specifically focus on the hybrid cloud portion of it, a lot of my time is spent with hybrid cloud connectivity concepts, such as the one we're going to talk about here with Partner Interconnect. Today, I'd like to talk to you about how you can use Partner Interconnect and how the product works, and really how that can help you extend your connectivity from an on-prem network, an on-prem workload, through a highly available, low latency connection. All right. Let's talk about the architecture. I'm going to go a little bit more into a deep dive of how the architecture works specifically with Google, and this is really the Partner Interconnect product. I'm going to start on the right-hand side of the slide and then go to the left in terms of the components. On the right, you can see here you have an architecture within Digital Realty. This would be where you would have your Digital Realty connections, so your on-prem physical equipment could be located within a Digital Realty facility, so either locally there or you're cross-connecting into a Digital Realty facility from your actual physical on-prem environment. Here you can see, for those familiar with networks, there's routers that sit there. Effectively, you need to establish a connection between your on-prem router all the way to Google. The important part here that I want to point out is in the right-hand side of the diagram there, that is actually, to John's presentation, what they were talking about in terms of Anthos, right? This is really where you could effectively see an Anthos cluster being deployed. It could sit right there within Digital Realty, could be connected there, and this is really where that extends that communication path between Anthos all the way to GCP, specifically from an Anthos on-prem workload. As we move to the center here, this is where the Partner Interconnect product really sits. This is the Service Exchange that we talked to with Megaport, earlier that Don mentioned. This is really how the magic happens between a connection between DRT and Google. Here, there's some key points that I want to bring up in terms of how the communication really is established. In this case, Megaport here has a connection to Google, to what we call our Google Edge Network, which is our Peering Edge equipment to our network. This is pre-established in the various Digital Realty facilities. The two key points here that are important are these concepts of the diverse zones. Why is this important? Well, within our facilities, we have two separate zones, which are actually separate maintenance domains, really. They're separate availability domains, but the main key part is that they're used to make sure that if there's any specific type of maintenance activities occurring, only one zone in the same metro will be taken down as part of a maintenance activity. This is really a critical piece when you're building a topology with Google, and especially when I talk to customers about building a highly available connection, depending on the types of SLAs that you're looking for. It is absolutely critical to build a redundant connection in both Zone 1 and Zone 2, but specifically within the same metropolitan region. Meaning if you're in a Digital Realty facility on the East Coast, that specific facility and that specific metropolitan area, you would need to build redundant connections within the same metropolitan region. This is really critical because maintenance activities are scheduled within a metro. Specifically when you're building this is a very critical point to keep in mind. Now, you can see if we extend all the way to the left, you see the Google Cloud Platform component. That's your projects, your Virtual Private Cloud or your VPC, and then eventually a region that's deployed there with specific compute infrastructure. That could be your Anthos workload sitting in GCP. That could be APIs that you're communicating to within GCP, BigQuery storage, et cetera. How the communication reaches GCP is through a concept called the Cloud Router. The Cloud Router is our managed BGP control plane speaker, which effectively exchanges routes between your on-prem network and GCP. You can see the line between the Cloud Router and all the way to the router on the right-hand side. These are what we call interconnectA ttachments or VLAN attachments that you're effectively building between the router on the left and the GCP Cloud Router on the right,and the Cloud Router on the left. By building these attachments, you're effectively able to exchange routes and establish that private low-latency connection from your Digital Realty workloads all the way to GCP. One of the really cool things here is that you can see I have a workload here, for example, in US-WEST 4, which is our region in Las Vegas. I also have an example of US- WEST 3 in Salt Lake City, US- WEST 2 in L.A. We actually allow, within GCP, routing globally within our VPCs. Our VPCs are global, so there is a configuration that you can do within the VPC to allow global routing. What that means is if I have a workload that sits physically somewhere, let's say on the East Coast, I can connect to a Cloud Router in a region on the East Coast, our US- EAST 4 region, for example, in Ashburn. Then from there, you can actually reach other workloads that sit in different regions within GCP. You can do that using our backbone. Effectively, you just need to create a single connection or a pair of redundant connections to a region within GCP, and from there, you can actually use our backbone to route traffic to other regions within GCP. I'll talk a bit about some of the reachability that you can have from a workload physically somewhere in the continent to a GCP region as well. We have some important key points there as well. All right. Let's talk a bit about the GCP interconnect costs specifically, right? I'm not going to talk too much about the dedicated interconnect product itself, but effectively, the dedicated interconnect is a customer owns the GCP port, right? Instead of having a connection through a partner, it would be a direct connection to Google. In this case, the customers build their attachments directly through the Google Cloud Console. They own the actual port to Google, so it's no longer a shared fabric that's being effectively resold, but it's effectively just bought directly from the customer. That's a cost that's passed down directly from Google to the customer to own that entire port. From the Partner Interconnect product, which is really what we're talking about here with Service Exchange and Megaport. In this case, Megaport owns the GCP port, so they own that connection to Google, and then they effectively resell these virtual circuits to their customers, right? Customers build these attachments via the service provider portal itself, and then they effectively provision and activate these within GCP. The VLAN attachments, which are these virtual circuits that you saw on a previous slide, the customers really provision these VLAN attachments at different levels, and they're charged on a different hourly basis. For Partner Interconnect, there's a different hourly fee based on the bandwidth capacity, and we have different attachment capacities, as you can see here on the list, that the Partner Interconnect product effectively supports. You're able to dynamically increase or decrease the bandwidth that you need on demand, depending on the type of traffic that you have. It's actually really useful if you have bursty workloads. You can actually start with a specific attachment need, 650 Mbps, and then increase all the way up to 5 Gb if you need at a different point in time. Going a little bit into the networking components themselves here, for those network-savvy folks, right? This is an eBGP session that's established between your on-prem routers and GCP. You need to support BGP for that. There are some specific MTU settings that you need to configure. We support both 1440 bytes and 1500 bytes, and there's multi-hop eBGP configuration that needs to be done as well. The VLAN attachment I mentioned earlier about the reachability between different regions globally. One key point I want to mention here is that you can build a VLAN attachment to any metro edge that's in the same region within the same continent. What that means is if you have, for example, you're creating, or you're connecting to a physical on-ramp to Google, the Megaport connection that you saw in the middle there. If that's actually located somewhere in North America, you can build a VLAN attachment to any other regions in North America directly. Say you want to have connection to a region on the West Coast, but you're on the East Coast, you can actually build that VLAN attachment from an East Coast on-ramp on the Megaport side, all the way to a Google Cloud region on the West Coast. This allows you to effectively put data on the West Coast and serve directly there. You can build redundant circuits that way as well, so that you can actually deploy workloads in different regions. That's one of the key points in terms of being able to build that type of redundancy and that type of availability across the continent. Now I'd like to talk a little bit more about the Anthos piece in a little bit more detail. John's covered a lot of these components. I just want to put into perspective where the Cloud Interconnect product really sits here, right? You can see in this diagram, you see the actual implementation of the technology stack. You can find GKE and GKE on-prem at the compute layer, right? You can see here on the right-hand side and on the left-hand side, one is sitting on-prem, the other one is sitting in GCP. The key point I want to bring up here is the Cloud Interconnect component between the two, right? That effectively allows that private connection, that dedicated low-latency connection between your workloads on-prem to GCP. You're effectively able to move traffic through the data plane between these two workloads through that private connection. You no longer have to rely on the public internet to move data between these two. As John mentioned, as you can deploy workloads in Anthos and deploy workloads seamlessly within GCP and then extend your cluster to on-prem, you can have that seamless connection between the two environments through that Cloud Interconnect connection. That's really a critical piece there, that you're able to establish that end-to-end. Mike from Megaport is going to talk a bit more about this as well as it fits into the solution. I just wanted to touch a little bit about this in this diagram. Here we can add on top of that, the Anthos Service Mesh that John mentioned, the ASM workload itself. You can see here it creates that connectivity fabric between the clusters, again, utilizing the Cloud Interconnect component. Really, the Anthos Service Mesh, all the traffic that is established within the Anthos Service Mesh between your on-prem workload and GCP allows you to traverse the private interconnect connection that you have. Again, not relying on any public network, not relying on internet circuits to do this. You're actually establishing that communication path through that private connection. Lastly, here we have the Anthos Config Management, which John mentioned. It's the single source of truth for your cluster configuration, right? It's kept in a sort of Git repository, which you can see here in this illustration, we have it on-premise. Again, you have the communication path that can occur through the Cloud Interconnect component, which is again, the key point that I want to bring up here as part of the connectivity solution, is you're able to, again, utilize that private connection and put these two components together and connect them privately. With that, I know there's a lot of topics. If you have any questions, please feel free to reach out. Happy to help and discuss these in more detail. I will hand it off to Mike from Megaport to talk a bit about the Megaport solution. All right. Thanks, Nick. Appreciate it. Hi, everyone. My name is Mike Rockwell. I'm the Global Head of Solutions for Megaport on the direct side of the business. Just a little bit about Megaport. We are a global network as a service provider, so we operate across 24 countries today. We're deployed in over 700 data centers. Really our solution was built to solve the problem of access to the public cloud from the data center environment. We specialize in on-demand data center to cloud connectivity. We also specialize on hybrid cloud connectivity through our MCR, which I'll talk about a little bit here today. We most recently rolled out what we termed the Megaport Virtual Edge, which allows our customers to seamlessly integrate our on-demand platform into their SD-WAN deployment. I'm honored to be here with you all today and certainly looking forward to adding to the conversation. Where Megaport primarily sits in the conversation is we're really, from a network connectivity perspective on the private side of the network, connecting your on-prem environment, with Service Exchange, with Digital Realty in the data center, to your cloud environment. Specifically with our partner today, we'll talk a little bit more about Google, but we'll also reference how you can set up your hybrid and actual multi-cloud connectivity through other cloud providers as well. First, before we jump into it, really where we specialize is consulting our customers on the hybrid and multi-cloud private connectivity component. Some of the common challenges and typical conversations that we engage in are really around the challenge of geographical distance. As Nick referred to earlier in his presentation, if I'm trying to access an Availability Zone or an edge location with GCP, there's a couple ways that I can do it. I can cross-connect. If I sit in a data center that has an on-ramp or edge location with GCP, I can simply run a cross-connect, but if I don't sit in that data center, I have to understand physically where the edge of that cloud provider network sits. With Service Exchange and Digital Realty, with Megaport, there's multiple options for the customers to accommodate that need of data center to cloud and set up ultimately the lowest latency connections that can be configured. If you look at some of the solutions that we build, if a customer is located in the U.S. on the West Coast or on the East Coast, we have on-ramp access to each one of the cloud providers. If a customer is looking to route cloud to cloud and also back into the data center, we're able to solve that for them in each one of these regions across the globe. The other thing that we typically talk about is performance and reliability. While latency is a primary component in understanding the geographical distance between your physical presence in the data center and the regions with the cloud providers, performance is also a key part of that. Customers are typically looking for that consistent performance. Through Partner Interconnect and Service Exchange and that private connectivity platform, performance is one of the key drivers of our solution. Where our edge of our network sits within the data center and our edge of our network sits within the cloud providers, you're looking for the shortest path to get the best performance between those two edge points, and I'll talk about that a little bit more here in a minute. The other thing that we typically consult on is cost. Many times customers maybe move directly, set up their hybrid cloud environments, they set up their resources within the public cloud. They may initially access those resources through a public internet connection instead of VPN tunnels. One of the things that's a negative to that is that there are additional egress charges that are applied. If you look at the egress charges from a bandwidth perspective, most of the cloud service providers, if you route over the internet and you're pulling the data down, so egress data, you're pulling out of the cloud back into your data center, they're going to charge roughly $0.09-$0.10 a gig. As you move into a private connectivity model, which is what Nick reviewed from a Partner Interconnect perspective or a Direct Connect with AWS, those charges move down more into $0.025-$0.02 a gig on egress. Typically what we see with our customers when we start discussing cost, they're not always aware of those egress fees that are charged. Typically, if a customer is using an internet connection, then they look at the private bandwidth or the private connectivity model. They're going to see the better performance over a private consistent path. They're also going to see the cost reduced on the egress perspective, that typically is going to cover the cost of setting up that private connectivity and then some. The next piece that we talk about is what's always on everyone's mind. Again, a lot of the customers that we work with around security, they do initially set up connectivity through the internet, or they may set up connectivity through the internet, see issues with the performance when it comes to latency and throughput. There's also the typical security concerns that are going to drive them to that private connectivity model. You look at complexity. When you start thinking about hybrid and multi-cloud, you're connecting to multiple different endpoints outside of your data center. You also might want to route cloud to cloud. Once you start thinking about adding multiple clouds into the mix and you add in your data centers, if you're going to set up those VPN tunnels between each one of these locations and have a path between each location, that can be very complex and tough to manage and also can add to some of the security risks that's involved as well. As we talk through some of the different designs, we're going to cover each aspects of these and how they can be solved through a Megaport Service Exchange type of solution, accessing the cloud providers. The other piece then is picking the right CSP for the right workload. One of the things that can be part of that discussion is, when we talk about latency and if we're wanting to route cloud to cloud or we have a multi-cloud type of deployment, definitely want to look at the regions of where we're deploying those resources. As the cloud providers build out regions and continue to build out regions across the globe, if you do want to have a multi-cloud type of deployment, you're relying on a low- latency connection to get between those two cloud providers. You do want to understand where those CSP workloads are deployed within those regions and what the latency is going to be between those two different cloud regions to access those resources to make sure that your applications are going to perform in the optimal manner. We'll talk a little bit about a virtual router or our Megaport Cloud Router with Service Exchange and Service Exchange Cloud Router, and how that can solve for some of the multi-cloud region to region and connectivity needs. I'm just going to touch on this real basic or real quick because Nick talked a little bit about it. As we're reviewing setting up private connectivity for hybrid and multi-cloud, there are really key components that we're going to evaluate. One is going to be the data center, the other is going to be the cloud edge and the connectivity in between the two. When we're setting up private connectivity, there's really two models of doing it. One would be typically via dedicated connections. Digital Realty has locations where Google has deployed their edge within their data center, and customers may choose to set up a dedicated connection. In most cases, when a customer is building out from a data center to one of the cloud providers, that edge location isn't going to sit right within the data center that they're deployed. They have to have a strategy to get out of that data center to the edge of the cloud provider network. One of the great things about Megaport and Service Exchange is you're building out a multi-cloud, a multi- hybrid cloud type of environment, is that Megaport's already built out the physical connectivity to edge locations with Google for Partner Interconnect. We have Oracle Cloud, AWS Direct Connect, Azure ExpressRoute, and on down the line. While maybe you're connecting directly to Google today or you want to connect to Google, you can also add these additional connections. You're going to go into your Service Exchange management console. You'll deploy a port, cross-connect to that port, and now you have access to all of the cloud providers, no matter where those edge locations sit. The other piece that you're also going to have to consider is from that edge into the cloud provider region. Nick touched on this in regards to Google and Partner Interconnect, that you could connect at any edge location within North America and ultimately route across the Google network to get to that region. When you're taking all the components together and understanding the latency and the performance that you're going to be required from a private connectivity standpoint, all of these key components are factored into that equation. Certainly, from a Megaport perspective, when we're consulting with customers on any one of the cloud providers that we're working with, we're typically going to drop them off at the edge location that's closest to their physical data center. We have tons of on-ramp locations, and I'll go through those here in a minute, of where you can ultimately do that. Nick really covered this in his presentation, just as a high level to tie in the Service Exchange and Megaport component of it, you can easily go into either Megaport or your Service Exchange console. You're going to deploy a 1 Gb or 10 Gb and potentially a 100 Gb physical connection into the network. You're going to set up a 802.1Q VLAN trunk port. You'll assign a VLAN on what we term as a VXC or a Virtual Cross Connect with Service Exchange. We're then going to provide the private connectivity to the zone or the Partner Interconnect zone or Edge Availability Zone on the Google Cloud provider network. You're then going to use your Partner Interconnect attachment to connect to your Cloud Router. In this particular situation, you have full control over your routing between your on-prem network that's going to peer directly with your VPC or your Google Cloud network. When you start to think about how you want to build those hybrid multi-cloud solutions, one of those key components that I mentioned earlier was you want to connect to an on-ramp or a cloud provider edge location that's close to your data center, also close to your region if you have low latency concerns around connecting from a hybrid perspective. One of the benefits of Service Exchange via Megaport, and Megaport is that we have more cloud on-ramps than anyone across the globe. Whether you're connecting to GCP or you're connecting to AWS or Azure with Azure ExpressRoute, if you're using that Service Exchange fabric, you're going to have multiple on-ramp locations that are going to sit in those major markets to where you can access the cloud provider network on a short path for low latency, but then also connect to the cloud provider directly to that region that's the closest to your data center. I highlight our locations, where we have Partner Interconnects set up. Don, at the beginning, showed specifically where GCP is actually deployed physically in the Digital Realty data centers. This just really expands the footprint. If you're not sitting in the Digital Realty data center where you want to connect to Google, or you want to have a multi-cloud type of approach, and you have a single connection in the data center, you can now connect from a Digital Realty data center through Service Exchange to any one of these endpoints that Megaport's built out the Partner Interconnect. The other advantage of this is in each one of these dots, these would be metro areas for Google or for GCP. We've built out physical connectivity to Zone 1 and Zone 2. As Nick had mentioned earlier, if you want to set up a 99.9% or 99.99% SLA, you can easily facilitate that through Service Exchange and Megaport, and we've already built out the physical infrastructure to support that at the edge of the Google network in each one of these locations. Really to bring the full conversation together today, there's a couple different models that I'm just going to walk through of what you can deploy through Service Exchange. We've talked about on-prem, we've talked about Kubernetes and Anthos and the management platform that sits on top that can manage all these resources on-prem in each one of the cloud providers. Megaport's really the glue that holds it all together through Service Exchange. Customers simply can connect in that Service Exchange or Digital Realty data center to the platform. They can build Partner Interconnects into Google. They can also build direct connects into GCP, and they can manage that all via Anthos over the top. Really, through all the partners that are on the call today, you can seamlessly manage these environments and also build out the private connectivity and the resources on each end to support your business. This is, I think one of our best use cases, and this is available at megaport.com under our use case section. Intercontinental Exchange, ICE is a Fortune 500 company and provider of marketplace infrastructure, data services, technology solutions, a broad range of customers they support, including financial institutions, corporations, and government entities. ICE operates regulated marketplaces, including the New York Stock Exchange. A pretty powerful use case from a finance perspective. Really, the issue that they had, and where they came to Megaport, was that we've been a trusted advisor for them for some time. Really, what they've done is they've incorporated us into their ICE Global Network. One of the things that they started to see is customers wanted to pull data feeds out of AWS and Azure and GCP, and their ICE Global Network was just sitting within their private data centers across the globe. Typically, customers would go in and pull feeds from those data centers. ICE would then have to build out connectivity for each one of those customers into the cloud providers. Megaport really fit that need, and where ICE expanded their solution is they built what they call the ICE Global Network platform. Really the ICE Global Network platform and the underlying infrastructure is powered by Megaport, to where ICE has physically connected their network to the Megaport Virtual Edge within data centers that we're located. Then now they're able to, on demand, build out single private connections out of their network into each one of the cloud providers that their customers are looking to access to pull down each one of these feeds that they may be looking to pull down, whether it's the ICE Trade or eSignal or ICE Unicast, any of these data features or data services that they're trying to access. Megaport's really the unique value proposition is this, as I mentioned at the beginning, is we're a global company. We work across 24 different countries today. Same with ICE. They're in North America. They have a network that's deployed in Europe and APAC as well, and they built out their underlying cloud connectivity platform through Megaport. When we look at building the private connectivity, the security, the ease of use, I think really this statement from ICE was powerful from a financial vertical perspective in that ICE, obviously, they have very stringent requirements for security, resiliency, performance for their customers. Any provider they work with, they must have the highest standards, as well to provide for their global customers with both speed, and choice and coverage. Really, from each one of those marks that they were looking to achieve, the Megaport network fit the form. What the design looks like, so this gives a look from a regional perspective of what each one of these designs looks like. They've connected to the Megaport network in each one of these locations across the globe. Once they've physically connected in the data center, each time their customer wants to deploy the Global Connect service, they're able to build the private connectivity across the Megaport network to get to each one of the cloud providers. Whether they want to build connectivity into AWS, Azure, or GCP, all of that can be solved via the Megaport platform. The last thing I'm going to touch on is more around multi-cloud connectivity, but then also hybrid back into the data center. Potentially a better way for you to support your multi-cloud solutions. This is going to go into the Megaport Cloud Router or the Service Exchange Cloud Router. We have published documentation with Google on how customers can set up this service with Megaport and with Partner Interconnect through MCR, but also to other cloud providers. Really, a seamless solution for setting up multi-cloud connectivity between clouds. I know we're getting close to the end here, so I'll wrap this up. The biggest advantage of the MCR is now customers don't have to route all that traffic back into their data center. If they do have environments within GCP or AWS, the MCR allows them to keep that traffic local and route between their cloud environments without having to hairpin that traffic back into their data center. If you look at, say, Google US- EAST 4, and you look at AWS US East Northern Virginia, if a customer wants to have a very low latency profile between their applications between these two environments, between US-EAST 4 with GCP and US- East- 1 with AWS, they can see 5 ms in latency between these two regions deploying a Cloud Router that sits right at the edge of the cloud provider networks there in Ashburn, Virginia. They can also utilize a single route path or a single BGP peer back into their data center as well. Really, incorporating a multi-cloud and hybrid cloud solution. Real quick to summarize it, the benefits of the MCR is you're shifting the responsibility to the Megaport network, so you don't have to backhaul all that traffic into your private network. You can offload that to Megaport. Megaport Cloud Router is going to manage the peering relationships with each of its endpoints, so you can route cloud to cloud and also back into the data center. Geographical distance. When we're talking about latency and the best way to support applications, MCR is prime for that. Again, you can see 5 ms in that U.S. East region. It's fully integrated with the CSPs. If I'm deploying with Google, for instance, on the MCR, it's automated in its functionality of setting up the layer- two connectivity between Megaport and GCP, but it also sets up the peering relationship as well. It also has route filtering. You can do BGP filters, you can also do more specific prefix filtering, and you don't have to be knowledgeable of CLI. All of it's in a easy-to-use interface on our platform. No physical presence required. Multi-cloud, if you just want to route cloud to cloud, you can certainly set up an MCR. It's also on demand, and there's no locked-in contract. If you just want to try out the MCR for a short period of time, you can turn it up and turn it down with no penalty. It also simplifies that routing experience. Route cloud to cloud and just manage a single point connection back into the data center. As you add other peers, you can add them to the MCR, still manage a single peering relationship back into your data center. That is the end of my presentation here. I'm going to pass the ball back over, I believe, to Don, and he is going to run through our promotion. Yep. Thanks, Mike. Appreciate it. Thanks, John, Nick. Just to wrap it up here. You've heard a lot of great things, great architecture. You understand hopefully a little bit more how we do the interconnect. This is the offer that we collectively have come up with. We want to give you an opportunity to cross-connect to Google, try it out at no cost to you. We're offering basically, if you're an existing customer with existing ports, three free months virtual cross connects to Google. You can do this four different regions. There's really not a limit. Try it out. If you're a Digital customer and you're using Service Exchange, we're making that offer for free. If you need new ports, you can even LAG ports together to get more bandwidth, and you want to connect to Google, that also is free. Basically, the offer is through the end of the year. You get three months free connections to Google. I would also just extend that if you have a port and you're trying out Google, it also gives you an opportunity to try out other B2B connections and virtual cross connects as well. Those, of course, will be paid. For the free promotion with Google, take advantage of it. It's a great opportunity. As long as you're in a Digital Realty facility worldwide, this is available, and you can reach out to us for more information. Either Megaport or Digital Realty can help you with that information. With that, I'll hand it to Laura to close out here. Perfect. Thanks, Don. Appreciate that. Thanks, everybody. We are at the top of the hour, so thank you for everyone that attended and hope you found this presentation beneficial. We'll be sending a recording of this to all attendees as a follow-up. If you would like to connect with any of our speakers or do have any questions that you'd like us to follow up on, just don't hesitate to reach out. Other than that, just have a great rest of the day. Thank you.