 Hello, and welcome to our session. My name is Vinicius Napolinario, and I'm a Senior Cloud Advocate at Microsoft. I'm Thomas Maurer, Senior Program Manager for Azure Hybrid. All right. You're going to hear more from Thomas in the second part of this session. But now, I wanted to take you through the journey of modernizing your application, where and how you need it. Now, you might have heard about Azure Migrate, and Azure Migrate provide a lot of options for migrating applications from on-premises into Azure. You have a few options, for example, for applications that are sitting in an old server running on VMware, running on Hyper-V, or even running in another Cloud, for example. You can take the application sitting on that VM, and just move to a VM in Azure. Now, when you do that, you're not changing any operations practices that you might have. You're just taking advantage of the platform services that Azure provide. You have other options. You can move your application to a Windows container and then you can modernize that application by putting it on Azure Container Instance, Azure App Service, or Azure Kubernetes Service, and then take advantage of all of what the platform has to offer. You can even put the application side-by-side with new applications that are being developed for containers and Kubernetes. With that said, let's take a look at the demo and how to do that for your application. All right. Here is my application running on-premises. You can see that I can click around. The application is running fine. I can see the content of my application, but this is running on an old server. What I want to do is I want to modernize this with Windows Containers. I'm going to switch to Adcontronization on Azure Migrate, and this is the tool that is going to extract the application from that server and put it in a Windows Container. This is a ASP.NET web application. I'm going to target Azure Kubernetes Service, but I could target even Azure App Service. I'm going to click Continue. I'm going to go through the prerequisites for my environment. I'm going to log into Azure, and I can select what is the tenant I want to use, and then on that tenant, what is the subscription I want to use. Here is the fun part where we're going to start discovering the application. I'm going to select what is the server I want to target, what is the username and password to talk to that server, the password, I'm going to validate, click Continue. Next, we are going to look at the application itself. Here is the full website that I have, and I can select what is the name of the container image that I'm going to create, and I can select even what is the application configuration, what are the additional folders that I might want to put in the image, and I'm going to continue to look at the Azure Container registry where my application is going to be hosted as a Windows Container image. We're not going to do that, so just so you know what the process looks like, we're going to build the container image on an Azure Container registry, and from there you can deploy whatever you want. You could deploy on-premises, you could deploy to Azure, it's your choice. Next, what Azure Migrate will do here, but we are not going to go through because I have this deployed already is you're going to provide the deployment specifications for your YAML file on Azure Kubernetes Service, and then finally deploy the application into Azure Kubernetes Service or the application to run there. Now, what I'm going to do is I'm going to switch to Azure Portal and show that I have a lot of resources here already created by Azure Migrate, and the first one I want to show is the Azure Container Registry. I'm going to click here, I'm going to click the repositories, and you can see that I have my container image here already, and this is the version one of my application that I created with the Azure Migrate. The cool thing again, like I said, you can deploy from whatever you want, to whatever you want from Azure Container Registry. For example, I have it running on a Azure Container Instance, and an Azure Container Instance is great if your application is more like an immutable application. It's not going to scale up or down, you're not going to change the application, you just want the application to run in the Cloud. You can see that I have the IP address of the application, and if I click here, this is my application running on Azure Container Instance. It runs exactly the same as it was running on-premises, I can click the links over here, and I can see the content of my application, everything is working exactly as it was, but now I'm in the Cloud. I can also deploy to App Services, and App Service is great for web applications where you want to have more control about this scale, control about AP testing options, and those things. Now, again, this is exactly the same application, so if I go to this URL, you can see that I have exactly the same content that I had on-premises. Now, if you need even more flexibility, you have Azure Kubernetes Service, and with Azure Kubernetes Service, what you have is you have a managed Kubernetes Service where you don't have to take care about infrastructure, you want to take care about the nodes and the application itself. Let me show you the application here up and running, I have the workloads, you can see that I have my IIS sample. If I click the services, you can see that I have the service of my application with the IP address, so if I go over here, this is the application now running exactly the same way, but with all the flexibility of a Kubernetes platform. All right. Now, let me hand off to Thomas to talk about the options of running Azure Kubernetes Service either in the Cloud or on-premises. Thank you, Vinicius. The next step in our application modernization journey is to provide developers with a platform where they can run their Windows and Linux containerized applications, and nothing better for that than our Azure Kubernetes Service. The Azure Kubernetes Service is a host of Kubernetes Service, which allows you to run Kubernetes apps on top of it. It can run in one of our Azure regions, or it can run on-premises or edge locations using the AKS hybrid deployment options together with the Azure Arc integration. Let's have a quick look. Here I'm in the Azure portal and I can see here, I have two Kubernetes clusters or AKS clusters deployed. The first one is running in one of our Azure regions, and the second one is a hybrid deployed one running on-premises on Windows Server or Azure Stack HCI, together with Azure Arc integration. Both of these clusters can host Windows containers as well as Linux containers. To create a new AKS cluster, it's fairly simple. We can use the Azure portal, we can use the CLI, PowerShell, APIs, or other management tools to do that. On-premises, we can even use existing management tools we are all familiar with. If you are managing Windows Server, you're probably already familiar with Windows Admin Center, which allows me to manage Windows Servers, Windows Server clusters, and even Azure Stack HCI clusters. We can also manage AKS running on top of these. Let's have a quick look here on how I can manage my Kubernetes cluster on top of that. Here I can see that I already have installed the AKS Hybrid on top of Windows Server. You can also see here I created a workload cluster in the Kubernetes cluster where I can deploy my containerized apps on. I can also easily create a new cluster directly from Windows Admin Center. But I want to show you a new experience we just showed you at Microsoft Ignite. You can now also deploy and provision new AKS clusters running on-premises and at the edge directly from the Azure portal or using the Azure CLI or ARM templates. For that, you would just create a new cluster here. Then you can see here you get a very familiar experience in the way that you could deploy a AKS cluster in Azure. As all of these options, as I mentioned, we support Windows and Linux node pools here. Your applications can run Windows containers and Linux containers side by side. Now, let's have a look at the management experience for both of these types of Kubernetes clusters. This is the Kubernetes cluster, the AKS cluster running in one of our Azure regions. One thing I did here is I use GitOps to deploy an application to that cluster. Now, GitOps stores the application and the configuration of this application in a Git repository. This can be hosted on GitHub or a private Git repo, whatever you prefer, and then the Azure Arc integration, the Arc agent will basically go out and get that configuration and make sure that this application is actually deployed, and it will also check if there are changes to this application. If I now go to our AKS hybrid deployment, so you can see here immediately that we have a very similar management experiences, and also that I have GitOps integration with that AKS hybrid cluster as well. What you can see here is I have basically deployed the same application here. Again, in this case, the Azure Arc agent is pulling the changes from that application. Let's have a quick look at the application itself. Here we have the deployed applications. I took all my web design skills to design these. Now, on the left side, you can actually see that I have deployed this application on a AKS cluster in Azure using a public IP address so users can access it. On the right side, you can see the same application running on our AKS hybrid deployment running on premises on Windows Server or Azure Stack HCI, and using a private IP address. Both of these applications look exactly the same, but we can see here that Tailwind Trader did a mistake on this in their writing, or they should basically update their website. Let's have a look on how we can do that, and let's go to that Git repo where the application is stored. Here is the Git repo where we actually stored the application configuration. You can see here which containers I'm actually running from which repository and how much replicas I'm running, and then you can see here we also have the message here. Let's change that and update that to 2022. I'm going to do that, and usually a developer would do this using their favorite development tools such as Visual Studio or Visual Studio Code, for example, and then you would obviously not directly do that to the main branch as I do that right now, but it choose another branch and do a approval step and a merge process in that case. But for now, let's do that change to the repo, and let's go back to the application and see if it's updated. Let's refresh the application running on Azure first, and you can see here it is already up to date now, and now let's refresh the application which we run on-premises on our AKS Hybrid deployment and hit refresh on that, and you can see here also this application running is now refreshed as well. The GitOps integration into Azure, and especially with our Azure Kubernetes service and our AKS Hybrid deployment options using Azure Arc, allows you to manage applications and Kubernetes clusters directly from a single control plane. Let's have a quick look on the AKS Hybrid architecture, which allows you to run our Azure Kubernetes service on-premises and at the edge. Now, for that, you choose one of our validated hardware solutions for Azure Stack HCI or you use Windows Server, and that allows you to basically run your Windows and Linux VMs with your traditional applications. But with our AKS Hybrid deployment options, you can also now run your containerized applications running Linux and Windows containers, as well as even our Arc-enabled services. This allows you to run past services from Azure on-premises or at the edge, and that helps you to build and run your Cloud-native applications, and all of that managed through Azure Arc. So if you want to learn more about Windows containers, Azure Kubernetes service, and our AKS Hybrid deployment options, check out the following links.