# How Netflix, Spotify & Uber actually run multi-cloud architectures

## Метаданные

- **Канал:** TechWorld with Nana
- **YouTube:** https://www.youtube.com/watch?v=IQZPC0sFqMk
- **Дата:** 30.03.2026
- **Длительность:** 39:44
- **Просмотры:** 19,082
- **Источник:** https://ekstraktznaniy.ru/video/49396

## Описание

Multi-cloud sounds simple — use the best of AWS, Google Cloud, and Azure together. But the reality? Managing multiple clouds can double your bill and triple your complexity before you even deploy your first service.

► Git repo: https://gitlab.com/twn-youtube/multi-cloud-crash-course

🔶 Control Plane provides a unified platform to deploy, secure, and manage your entire multi-cloud infrastructure from one place.
🔶 Check them out for a 30-day free trial: https://controlplane.com/

In this video, I break down how companies like Netflix, Spotify, and Uber actually run multi-cloud architectures — and more importantly, what makes it manageable at scale.

You'll learn:
- The two multi-cloud patterns and the real problems each one creates
- Why credential management, networking, and infrastructure duplication are the hidden killers
- The abstraction layer concept that makes multi-cloud actually work
- A practical demo deploying a containerized app across AWS, Azure, and GCP using Control Plane

## Транскрипт

### Intro - How Netflix, Spotify & Uber actually use multi-cloud []

If you've been working with cloud platforms, you probably heard about multicloud architecture. The idea of using multiple cloud providers like AWS, Google Cloud, Azure, all in the same application. And you will see that many large tech companies use this approach when they build their infrastructure. Netflix, for example, runs most of its infrastructure, including streaming and largecale analytics on AWS, but its open-source tools like Spre, for example, is explicitly designed to support additional cloud platforms such as Google Cloud and Azure for multicloud deployments. Spotify uses Google Cloud as its primary cloud for backend and data infrastructure, but they also leverage AWS for specific services where AWS has better offerings. Uber, for example, is moving to a clear multi cloud setup, running big workloads on Google Cloud and Oracle Cloud infrastructure while also using AWS for some specific services to overall optimize for cost and performance in different regions. Now, these companies are not using multicloud because it's trendy. They're doing it because it solves real technical and business problems. But here's the important point. Managing multiple clouds is genuinely complex. You're dealing with different APIs, different security models, different networking configurations, completely different ways of doing everything. Now, what about your cloud bill? Well, it can literally double just from the operational overhead of managing all of this infrastructure in multiple clouds. So in this video I want to show you how multicloud actually works in practice. We will start with real problems you will face when you start using multiple clouds and explain these problems in detail. Then I will explain the solution conceptually like what architecture patterns actually make multiloud manageable so that you understand the wise behind and finally I'll show you a practical example of deploying a containerized application across AWS, Azure and Google cloud in a very simple

### Realistic Scenario of Multi-Cloud [2:06]

way. Now let's start with the problem because understanding the problem is really the most important part here. Okay, let's say you're building a modern application and you want to use the best services from different cloud providers, which actually makes sense, right? So, here's a realistic scenario. You want to run your main microservices and APIs on AWS using EC2 and EKS because your CI/CD pipelines, monitoring, networking setup is already built around AWS and your team has expertise in it. But for analytics, you want to stream your application events from AWS into Google Cloud and store them in BigQuery where your product and data teams can run simple SQL queries over several years of data of user clicks and billing to understand user behavior and they will then create dashboards in tools like Lucer Studio to visualize all that data. Now for machine learning features, your backend will call Azure AI services, for example, ready-made language and image models that can read documents or check content because these pre-built models already solve your problem and save you the effort of training and running your own machine learning systems. So you want to leverage that from Azure cloud. And on top of that, even though we run our main application on AWS, we also want to create fault tolerance for our application. and we want to replicate it on other cloud platforms as well. So we want to run our workload on AWS, Google Cloud and Azure. So you are thinking perfect I will use the best tool for each job. I will have backup and fault tolerance for my application and all of that by leveraging multiple clouds. But now let's walk through what actually happens when you try to implement this setup.

### Two Multi-Cloud Implementation Patterns (And their challenges) [3:52]

setup. First let's understand how multicloud actually works in real systems because there are two different patterns and both of them add significant complexity. The first one is where most of our application runs in one main cloud let's say AWS. So all your services live there your team deploys there. All your monitoring and logging assumes AWS, but your application also needs to call services from other clouds like Google Cloud's BigQuery or Aszures AI services and so on. Now, here's what this means in practice. Your application code needs different SDKs, right? So, you have the AWS SDK for accessing AWS services, the Google Cloud SDK for Bitquery, and Azure SDK for their AI services. And each SDK obviously has different patterns, different authentication methods, different error handling. So your code becomes more complex because you're integrating three different cloud platforms in your application. But it's not just the code. You also need to handle authentication for each cloud. Like your application running on AWS is going to have AWS AM credentials to access different AWS services. But how does it authenticate to Google Cloud's Bitquery? Well, you will need Google Cloud service account credentials. How does it authenticate to Azure? You will need Azure service principle credentials. So now you are managing credentials for three different cloud providers for one application. Second is networking between clouds. Like when your application running on AWS calls Google Cloud's Bitquery service, that request goes over the network. So, are you calling it over the public internet, which is slow and expensive, or do you set up a private connection between your AWS and Google Cloud with all the network configuration? Well, same issue when calling Azure services. You'll need to configure how your application running on AWS reaches Azure services securely and efficiently. So even though you have one home cloud where your application runs, integrating services from other clouds makes your application logic and platform setup significantly more complex. The second pattern is more advanced. In this use case, we're running the application in one cloud and calling services from others, but we're also running copies of our entire application in multiple clouds. Now, why would you do this? For resilience and fall tolerance. For example, if AWS has a major outage, which has happened before, your application can fail over to Google Cloud and keep serving users without having any downtime. So, you are protected against cloud provider level failures. But here is what this actually means in practice. You will need to deploy your services in each cloud. So, let's say you're using AWS and Google Cloud. You're going to need compute infrastructure in both clouds. If you're using Kubernetes for example, you will need EKS cluster on AWS and GKE cluster on Google Cloud. If you're using just virtual machines, you will need EC2 instances on AWS and Compute Engine instances on Google Cloud. You will again need to configure networking in both clouds. You will need VPCs on AWS with subnets, security groups, load balancers, and you will need VPCs on Google Cloud with its own subnets, firewall rules, which work differently than AWS security groups, load balancers, which also work a little bit differently. And again, we have identity and access management, which basically means permissions and how different services can be accessed securely. So on AWS, you will set up AM roles and policies for your services. On Google Cloud you will have to set up service accounts and IM permissions which is also pretty different system different concepts different configuration. So you are essentially maintaining two complete infrastructure setups and everything you do in AWS you will also need to do in Google cloud. If you're using Terraform as infrastructure as code you will need to have one for AWS infrastructure one for Google cloud. Most importantly you will need global traffic management. So you will need a way to route user traffic to the right cloud. Maybe use DNS-based failover where if AWS is down, DNS automatically routes traffic to Google Cloud or maybe use a global load balancer that sits in front of both clouds which of course adds another layer of complexity. So considering all these challenges and all these complexity that you introduce by using more than one cloud for your application, how do you actually make multicloud work? What's the solution?

### Abstraction layer [8:23]

Well, the complex way is to do what I just described, which is just managing two different cloud providers, having two separate Terraform codes and so on. But a better solution would be to have an abstraction layer. So that's what we're going to talk about now. Let me explain this concept clearly because this is the key to everything. What is an abstraction? Think about how Docker solved a similar problem. Before containers, deploying an application meant you had to understand the specific operating system. Are you deploying to Ubuntu, CentOS, Amazon Linux, Windows? Each has different package managers, different file system structures, different ways of managing processes. So your deployment scripts were full of operating system specific logic and your application had to be configured differently for each environment and Docker created an abstraction because your application now runs inside a container which is always the same. The container packages everything your code dependencies libraries configuration and docker handles making it work on different operating system. You don't write operating system specific logic in your application anymore so that it works on different operating systems. You write your application once package it in a container and docker handles the complexity of running it on iuntu on CentOS or any other OS. That's an abstraction layer. It hides the underlying complexity. If we wanted a simpler solution, multicloud would need exactly the same approach. So instead of application dealing with AWS specific APIs, Google cloudspecific APIs or Azure specific APIs, you have an abstraction layer that your application talks to and that abstraction layer handles the cloud specific details and that's exactly where a tool called control plane comes in. The engineers at control plane reached out to me and asked me to try the tool and check all its capabilities and after seeing what actual important real world problems they solve they became our sponsor. So how does control plane implement this abstraction and solve all the problems that we just discussed. Control plane is essentially

### How Control Plane works [10:25]

a virtual cloud. It sits on top of AWS, Google Cloud and Azure or any other cloud provider or your on-remise infrastructure and gives you that abstraction layer that we talked about. So let me explain how it works and how it solves all the problems that we just discussed. First one is universal cloud identity which is control plane's solution for managing credentials for not only different cloud providers but different services of those cloud providers. So your microservices don't have cloudspecific credentials. They don't have AWS keys or Google cloud service account files. Instead, they authenticate with control plane using a universal identity. So, this is how it works in practice. Let's say your application needs to read a file from AWS S3. Normally, your application would need AWS credentials such as an access key and secret key. You would have to manage these credentials, rotate them, keep them secure. With control plane, your application has a control plane identity. When it makes a request to read from S3, it authenticates using its control plane identity. Control plane receives this request, sees that the application needs to access S3, translates the universal identity into temporary AWS credentials, makes the request to S3 and returns the result to your application. Your application doesn't even know that this translation happened. From its perspective, it authenticated once and got the data. And same application, same identity can now access Google cloud storage or Azure blob storage where again the application code does not have to embed provider specific secrets. Control plane maps that identity to the right cloud credentials behind the scenes. Second one is that with control plane you can mix and match services from different clouds in the same application. Again let me give you an example. Let's say you are building an e-commerce application and you decide that you want to run web front end on AWS because you're already using AWS CloudFront and CDN, but you want to run the recommendation engine on Google Cloud because you're using BigQuery to analyze customer behavior and train your models. And you store product images on Azure blob storage because let's say you negotiated a good price with Microsoft. Now, these services need to all work together. The front end needs to call the recommendation engine. the recommendation engine needs to access product images and so on. With control plane, you deploy all these services to the platform. Control plane handles the networking between clouds automatically where the front end makes a request to recommendation service. Just the DNS name. No need to know that service runs on Google Cloud. Essentially, control plane routes the request through its network fabric to the actual service on Google Cloud. The recommendation engine then requests an image from image storage service. Again, just a name control plane routes it to the actual Azure blob storage. So all the complexity of connecting AWS to Google Cloud to Azure is handled by this abstraction layer and your services just communicate with each other using simple service names. Then we have another big advantage which is pre-integrated infrastructure stack. Have you ever set up a Kubernetes cluster and configured all these third-party services to make it production ready like installing Isto installing vault promethuse and graphana search manager and so on control plane has actually integrated all those capabilities or features into the platform. So when you provision Kubernetes cluster you're not starting from bare Kubernetes and then wiring together your own service mesh metrics logging tracing and so on because all of those come pre-integrated and configured into the platform runtime configured when you provision Kubernetes cluster on control plane. So when you deploy an application to control plane platform, observability and metrics collection just works. Logs are automatically aggregated. Distributed tracing is automatically configured and you get dashboards showing everything that's happening in your application. You didn't install Prometheus. You didn't configure Graphana. You didn't set up open telemetry collectors. The platform provides all of these out of the box. The same way security policies just work like TLS encryption between services is automatic. Certificate management is automatic. You just define which services can talk to which other services and control plane can enforce this using the built-in service mesh. And finally, another huge benefit when using multicloud is the cost optimization because cloud costs even on a single cloud platform can get very complex very fast. So, control plane actually gives you very precise control over resource allocation. So, instead of saying I need a t3. large large instance and then that instance runs all the time whether you're using it or not or using just 50% of it or not. You basically say my application needs two CPU cores and 4 GB of memory and control plane provisions exactly that. When your application needs more resources because let's say traffic increased, control plane scales it up. When traffic decreases, down. So you're not overprovisioning just because you can't manage resources granularly and you're not paying for idle capacity. You provision exactly what you need and the platform adjusts it automatically based on actual demand. And control plane itself claims that customers typically see on the order 60 to 80% in cloud compute costs compared to running and overprovisioning their own Kubernetes and surrounding infrastructure directly on the cloud providers. The savings come not because the underlying cloud services are cheaper, but because you're not wasting capacity and paying for something you're not using, plus you're not paying for all the engineering overhead of stitching everything together manually.

### Practical demo: Deploying across AWS, Azure & GCP [16:08]

So, this is what we're going to do in the demo part. We're going to take an example application, which is a very simple JavaScript application with nojs back end. We're going to dockerize it. We're going to build a Docker image out of it, push it to a Docker Hub registry, and then we're going to take that image and deploy it on multiple cloud platforms at once on Azure, AWS, Google Cloud in Kubernetes clusters with a very simple workflow. And there are two interesting details about our application. The first one is that our application actually connects to S3 bucket on my AWS account. So I actually have an S3 bucket which simply has some random files in it, some images and our application connects to S3 bucket on my AWS account. It fetches some data and displays it in the UI. Which means when we deploy our application on multiple cloud providers, we're going to have to give our application access to the S3 bucket on AWS cloud platform, right? And it's going to work the same whether our application is running on Azure cloud or Google cloud or AWS. And in order to visualize that our application will actually display exactly from which region of which cloud platform it's serving the request. So it is a very simple demo visually but there's a lot of technical complexity behind it because of this cross networking between multiple cloud providers with accesses between them and so on. So let's get started. I'm going to guide you step by step through the demo so you can work along with me. So first of all, let's check out our application just so you understand what it does. It's super simple. Of course, you're going to find the link to the Git repository. So you can just clone the code locally and you have the same entry point as me. So we have this backend code. Let's check it out. Super simple. The application, the only thing the application does is basically just connect to an S3 bucket on my AWS account. And for that I'm using an AWS SDK. and client for S3. And we're connecting to this bucket right here. So that means if you want to follow along, just go to your AWS account and create a bucket. You can call it whatever you want. And that bucket name is going to be right here. So this is the name of my bucket. Just I have just uploaded a few files in there. And the application basically makes a call to my S3 bucket. It fetches the information and it simply sends the contents to the front end. So that's simply what our application does. Fetches the data from S3 bucket and then it sends it to the front end. So this is our simple front end and it basically just displays the metadata about the files one by one. This is index html and some styling. So as I said you don't need to understand the code but I'm going to point out the things in the code that are interesting or important. And this is also our super simple package. json file. And that's it.

### Step 1: Setting Up the Multi-Cloud Infrastructure [19:05]

So now the first thing we're going to do is we are going to create or provision environment on which we want to deploy our dockerized application. So now we're getting hands-on. The first thing we're going to do is we're going to create what's called a GVC, a global virtual cloud. Um I'm going to call this Techorana GVC. And this is an interesting part. If I go to locations, this is where I can actually select different locations on different cloud providers that I want to use in my GVC. And that's why it's called global virtual cloud because I'm basically creating like a virtual cloud that is made up of multiple cloud providers and different regions from those providers. So I can mix and match whatever I need. So, I'm going to take the one that is closest to me, which is central Europe region from AWS. I'm also going to take an Azure region and let me also grab US Central in GCP. So, I have three different cloud providers that will make up my global virtual cloud. If I click on create, this is actually going to provision all those locations for me without any setup effort. So, as you see, these are not my accounts. So, I can actually get started without having to connect my own cloud provider to test it out, which of course means I can save myself the initial setup overhead. And I can also add any other regions or locations if I want to. So, let's add S. Paulo. And as I said, it's super simple to do, but there's a lot of technical complexity going on in the background because now I have a global cloud that is made up of multiple cloud providers in different regions and infrastructure in the background is provisioned with all the necessary setups to basically run my dockerized application on top of it. So infrastructure and Kubernetes clusters are provisioned on these underlying cloud providers with all the settings so that I can literally throw my Docker containers into it and it's going to run them in a Kubernetes cluster. And that's exactly what we're going to do. And since we added a location, we can update this one. And there you go.

### Step 2: Deploying the Application [21:23]

So now let's dockerize our application. I don't have a Docker image yet. So we're going to build that together. And we're going to then deploy that Docker container on our virtual cloud. So back to the code. There you go. This is our very simple Docker file. It basically just grabs package. json. It installs all the production dependencies. It copies the Node. js, the backend code, all the front-end code in public folder and starts the application on port 8080 and then just runs npm start which basically translates to node app. js, right? So it just starts the back end and the application gets started. So let's build the image and push it to docker hub repository. So this is our docker build command. And let me explain quickly what we are doing. We're basically building an image from the docker file in the current location. That's what the dot here stands for. We are calling the image tagana/ the name of the repository and the tag. So this one obviously needs to match the repository name here. If you're a beginner in Docker, I suggest you watch my Docker crash course where you can learn all these details. But if you know Docker, we can continue here. So we're naming and tagging our image. And since I'm using a new MacBook, which has Apple's M1 chip, which is obviously not compatible with Linux MD architecture. basically just providing a flag that says build this image to be compatible or to be deployable on a Linux AMD architecture. If you have Mac OS with Intel chip, then you don't have to use that flag. It's going to work by default. But if you're on a new one with M1 chip, then provide this flag. And once we build the image, we're pushing it directly to the repository. So we're doing all this in one command. So let me execute and let's check our image. There you go. We have our image tag. This is the architecture that we built the image for so that it's compatible for Linux systems. So this is a public image which means I can directly pull that into any location. And that's what we're going to do right now. And let me show you how easy that is. So we are in the GBC with our locations. So now in this GVC section, I'm going to go to workloads and this is where we're going to create our workload with the Docker image. So I'm going to click on new. Let's call this Techana app and we are deploying this in our TWWN GBC. So this is just metadata, but this is where the image is configured. So I want to tell control plane which image to run the workload from. So control plane has its own docker repository. So you can push images directly to its docker repository but if you're using any external one like I am doing you can simply click on external and let me simply copy the name of my repository and we tagged the image with 1. 0 and there you go the port number we are exposing our application or running it on port 8080. Yeah which is already configured here and that's it. So now let's see what happens when I click on create and then we're going to see a couple of very interesting things. So let me create this and make sure to set it to public so that we can access the application on browser and instead of us going and configuring the firewall rules we can just literally just click a button like this and we can also allow outbound traffic for our workload and let's see what happens. So we just created a workload and if you go to deployments you're going to see that our Docker application was automatically deployed in all the locations in our virtual cloud. So we have the AWS regions the Azure and GCP. This one is still coming up. And we also see the status that says our containers are ready. So this is from Kubernetes cluster. It's in ready status and one out of one containers are up and running. And for each region you actually have the links to check the application itself. So let me click on this. So this application is served from EU central. And if I go to summary, you also have this global endpoint which basically load balances the request to whichever region is closest to you and of course whichever region is healthy or has the healthy version of the application running. So if I click on it, it's going to show me the same application with a global endpoint. Now this is the interesting part. Our application is accessible. It's displaying something but it shows us an error. Could not load credentials from any providers. So that's the next thing we're going to configure in our application. And this is actually very interesting concept in control plane but generally about connectivity between cloud providers and cloud provider services.

### Step 3: Add Authentication to access S3 bucket [26:25]

services. So containers are healthy. You can even connect to them right here. You can get the terminal and we are inside the container. This is the app folder that we created here and we have the package JSON and some other code files right here. Right? So you can debug and basically troubleshoot your containers like this and of course you have the logs that tell you what's happening the container logs and the events from when the container started. All right. So now let's fix this error that we're seeing here. But first understand what's happening. So we are trying to access this S3 bucket and list all the files here. Right? So if I go back to my application, this is the bucket name that we're connecting to. We're trying to connect. But there is nowhere in the code any reference to the credentials, right? So obviously the application needs to have access to AWS account which has the bucket and it has to have permission to access the bucket and list the files inside. So we haven't configured that anywhere. So obviously the application is saying hey I don't know how to connect to this AWS account because you didn't give me any credentials. The only thing we're providing to the application is AWS region which is the region where my bucket is living in. But it doesn't even know which account number what accesses and so on. So typically you would configure that using environment variables or a configuration file or some secret injection in the application configuration itself. However, with control plane it works differently. So we're going to go back to control plane and we're going to connect control plane to our cloud provider which obviously you can also do if you want to run workloads on your own cloud accounts and we're going to do that using cloud accounts feature. So right here I'm going to basically say I want to connect control plane to my AWS account so I can do stuff with it. I can either create new services or I can allow the application that is running as a workload through my control plane platform allow it to access resources in my AWS account. So that's what we're going to do. So we're going to call this technana AWS and we're connecting to AWS cloud platform. And right here this is the most interesting part and the only thing we need to configure here actually for the connectivity is we need to create a role in AWS that allows control plane to connect to it. Right? So we need to create the connector between those two platforms and I'm going to click here and follow the instructions of how to create exactly that AWS role so the control plane can connect to it. So let's open the AM service and let's grab our account ID and provide it here. So first of all we're telling control plane which account are we connecting exactly to and once we have that and in that account we're basically simply just going to follow the instructions right. So we're going to go to the roles create new role for AWS account which basically allows third-party platforms like control plane to connect to our AWS account and we're going to click on next. We're going to name the role with this one right here. And we're going to create this role. There you go. Now, we're going to create a new policy with this policy description, which basically allows or that policy gives permission to create new roles. So, it gives AM permissions to create a new role, create policy, attach the policy, and so on. So, I'm going to paste in the JSON here. the policy name and let's create the policy. There you go. So now we're going to take our RO and attach the policy that we just created to it. And I'm actually also going to give I'm admin access. Obviously, you should only give it access to whatever it needs to do in your AWS account, especially if it's a third party. I also want to give readonly access to the AM roles and let's also do read only for S3 bucket and this is the final step where we take the trust relationship. So we are establishing a connection a trust connection between control plane and AWS account and we are in addition to telling AWS hey you can trust this third party platform control plane because it's our account we are also defining exactly for what it can trust it right which permissions does control plane have in this account because we want to give the minimum permissions to keep our account secure so that's why we defined these uh policies here in the trust relationship we're basically saying that control planes um AWS account can assume this role in our AWS account to do things that role has permission to do. So that's what we're doing. Go to trust relationship. I'm just going to copy in the JSON trust policy and update. Perfect. We are actually done. And when I close the wizard and I do create, let's see what happens. There you go. The cloud account was connected to our control plane. And let's actually test that we have the permissions and we can do stuff uh with browse. Let me see. There you go. So I have access to the buckets. I can list them and see what's inside. If I click on IM, I also have access to see the roles including the role that we created and so on. Okay, so the connection was established between control plane and my AWS account. Now the question is that's all good but how do we actually give our application access credentials to the AWS account to this S3 bucket while it's running on the workloads managed by control plane how does that connectivity actually work because again technically it's actually pretty complex right so in the GVC we have this thing called identities which basically is a concept a control plane concept or abstraction of permissions for different cloud providers, right? So here I can say give me an identity that has permission to connect to S3 bucket on this AWS account specifically and list the files there has read permission and that identity is a logical entity in control plane and regardless of whether my application runs on Azure or Google cloud or AWS or another AWS account not the same one the same identity can be used by that application to connect to my AWS account and grab the resources from its service. And that's the key here. We don't have to create permission between the Azure account here and the S3 bucket, the GCP and S3 bucket, this other AWS account that control plane manages and my S3 bucket. We only create one identity that is shared that is then translated to these individual cloudspecific permissions. Let's create it. Let's call it Techorana S3 access. And we're going to create this identity in our GBC. And we want that for AWS. Which means we're creating this identity to have access to this AWS account which we just connected right here. Right? So this one and obviously we want to say what permissions does this identity have? What can it do in this AWS account? And since control plane has permission to list all the uh you know policies and roles, we can search the ones managed by AWS directly here. And let's search for S3 bucket because that's what we need. We actually simply need read only access because we're just listing the files. And again, you want to give as little permissions as possible. And that's it. So this again creates identity that has access to this AWS account with the permission to view S3 bucket contents as read only access to it and that's what we're creating. So let's do preview. So let's create the identity and again we can see the events. So now we have this identity in the GVC and we have workloads running in the GVC. So now what we can do is we can say you know what this TWWN app workload needs that access. So in the workloads identity I'm just going to select what permissions the workloads that are running here will need from the list of identities. And as I said, this is an abstraction of the permissions that in the background will basically translate to if this application is running on Azure, how does it connect to an S3 bucket on my AWS account? Or if it's running on GCP or another AWS account, how does that connectivity work? So all of that will be taken care of in the background. And let me update this and that will redeploy the application. And you can see the version. So, we got a new version of the application for let's wait until everything is up to date. And now we can use the global link. There you go. It needs a few seconds, but now we actually got the list of files from my bucket. These ones right here displayed in the UI. I can do refresh. Let's say let's actually delete this one for example. And let me do the update or refresh. And then we can see the up-to-date list of files. And there is one final thing that I want to point out which is this part right here. So right now I'm using the global endpoint right here that basically just load balances the application request to one of the locations in my GBC that has the healthy version of the application in the region which is closest to me. And this is my closest region obviously because I'm in Europe and that's why I'm seeing request was served from AWS EU Central 1. And let me also show you how that is configured in the application so you understand the context. It's actually very simple. Right here we have this environment variable called CLN location. So control plane location which is automatically set when I run my workloads on the control plane platform. So it's one of the environment variables that makes control plane available for all the workloads that are running um on the platform. And I'm simply reading that environment variable and setting the location and sending that location information to the front end and just displaying it there. Right? So we know which location it's being served from.

### Step 4: Testing Failover [37:20]

So now let's do one thing which is let's simulate that EU central region goes down. So we have this application running in multiple locations. For some reason there is an outage in the EU central region and it basically just crashes right. So our application is not available on this platform. Now if I refresh it will still work because it's cached because it's a static website. So I'm going to grab that global endpoint and access it in incognito mode. And as you see the application was now served from Azure region. And again, pretty straightforward, but we can still test it out. Let's say AWS has a complete outage. So, all the regions are down. Azure has an outage. So, everything is completely crashing, but we still have one cloud provider that is up and running. And that means only one cloud provider is running our application. It takes a little bit of time, but we see that the application was now searched from GCP, which we simulated is the only cloud up and running. So we have that fail over in case something happens to other regions or other cloud platforms. We can still leverage the third cloud provider to still have our application available. Awesome. So that's how simple it was to take our Dockeriz application and deploy it as a workload across Kubernetes clusters on multiple cloud accounts which we didn't even have to set up by ourselves. So if you want to test it out or try it out, it's actually simplest to get started because you can get started with control plane managed cloud providers in the background. And with a very simple use case, you actually saw how control plane abstracts away the network connectivity between different regions on different cloud providers plus abstracts away the access control between cloud platforms, which are two very important concepts when you're talking about multicloud. And as I said, all the links are going to be in the description. The best way to practice and learn is by doing. So, make sure to also do the demo because that's where you learn the most and most effectively. And make sure to share your learnings and your feedback in the comments below how helpful this video was for you to at least understand the use cases and concepts behind this topic. So, I hope you learned a lot. You can share it with one friend or colleague who you think will be interested in this topic. And with that, as always, thanks for watching and I'll see you in the next video.