1 00:00:01,440 --> 00:00:04,980 The tool that we need to know about for our AZ‑801 exam here is 2 00:00:04,980 --> 00:00:08,890 called Azure Migrate App Containerization, all right? And this 3 00:00:08,890 --> 00:00:12,670 supports development trends like microservices where instead of 4 00:00:12,670 --> 00:00:16,070 having big monolithic apps, you've broken them out into small, 5 00:00:16,070 --> 00:00:19,160 relatively independent components that you can patch 6 00:00:19,160 --> 00:00:22,470 separately, that you can scale and secure separately, and 7 00:00:22,470 --> 00:00:24,090 then when you're integrating changes, 8 00:00:24,090 --> 00:00:27,990 the idea is that it's an easier integration, all right? You 9 00:00:27,990 --> 00:00:32,060 also, trend wise, have this Docker container and need for 10 00:00:32,060 --> 00:00:34,140 scale with Docker containers, 11 00:00:34,140 --> 00:00:38,090 which is what AKS gives you. Now, just like I mentioned a little 12 00:00:38,090 --> 00:00:41,300 while ago with regard to the App Service Migration, 13 00:00:41,300 --> 00:00:46,040 the Azure Migrate App Containerization tool is under development, 14 00:00:46,040 --> 00:00:50,480 and as of this recording, again, in summer 2022, it supports 15 00:00:50,480 --> 00:00:54,830 ASP.NET and Java applications, and you wind up at the end of the 16 00:00:54,830 --> 00:00:58,780 app containerization process running either Windows Server 17 00:00:58,780 --> 00:01:00,760 containers or Linux containers, 18 00:01:00,760 --> 00:01:05,140 depending upon whether it's an ASP.NET or Java application. 19 00:01:05,140 --> 00:01:09,250 And you can push those to App Service or AKS clusters, like I said 20 00:01:09,250 --> 00:01:13,100 before, okay? Now the tool performs these main actions. 21 00:01:13,100 --> 00:01:14,840 You've got discovery, 22 00:01:14,840 --> 00:01:17,780 which is going to automate looking at your application and 23 00:01:17,780 --> 00:01:19,900 determining what its dependencies are. 24 00:01:19,900 --> 00:01:24,830 It'll build the image for you and even push the image into a container registry 25 00:01:24,830 --> 00:01:28,710 and ultimately into your cluster or App Service environment. 26 00:01:28,710 --> 00:01:33,730 This is some really nice engineering that Microsoft has done, and in my opinion, 27 00:01:33,730 --> 00:01:38,420 the biggest value that it gives is that it's going to help businesses who are 28 00:01:38,420 --> 00:01:41,940 just on the leading edge, or the beginning edge I should say, 29 00:01:41,940 --> 00:01:45,440 of adopting some of these development practices. you know. You 30 00:01:45,440 --> 00:01:48,950 may have a monolithic application and you're not sure where to 31 00:01:48,950 --> 00:01:51,660 start in terms of creating containers, 32 00:01:51,660 --> 00:01:56,440 well, run an assessment using Azure Migrate App Containerization, 33 00:01:56,440 --> 00:01:59,290 and that may be the bulk or all of what you need. 34 00:01:59,290 --> 00:02:01,340 Isn't that beautiful? 35 00:02:01,340 --> 00:02:03,860 This is an AKS reference topology here. 36 00:02:03,860 --> 00:02:07,630 Let's take a look at it from a bird's‑eye perspective. We have our 37 00:02:07,630 --> 00:02:12,340 workflow, which may or may not be integrated in CI/CD build and release 38 00:02:12,340 --> 00:02:15,040 pipelines, it doesn't really matter at this point, 39 00:02:15,040 --> 00:02:19,100 but we're using the Azure container registry as our point of authority 40 00:02:19,100 --> 00:02:23,210 for our docker images, and those images are ultimately being started as 41 00:02:23,210 --> 00:02:27,380 containers running in Azure Kubernetes service. And notice, we've got 42 00:02:27,380 --> 00:02:31,200 role‑based access control with Azure Active Directory, we have 43 00:02:31,200 --> 00:02:35,150 monitoring with Azure Monitor, we have the ability to fetch certificates, 44 00:02:35,150 --> 00:02:39,410 keys, and certificates seamlessly from Azure Key Vault. These are all 45 00:02:39,410 --> 00:02:43,860 benefits of the integration that Azure Resource Manager offers us. Now, 46 00:02:43,860 --> 00:02:48,070 from an application ingress standpoint, there your connecting clients 47 00:02:48,070 --> 00:02:52,070 will normally come in through some ingress vehicle, it could be an 48 00:02:52,070 --> 00:02:56,960 Azure application gateway, sometimes you can use like an NGINX 49 00:02:56,960 --> 00:03:01,160 container as a gateway. And then from there, that gets too much into 50 00:03:01,160 --> 00:03:02,130 developer land, 51 00:03:02,130 --> 00:03:05,020 we don't really need to worry about that, but I just wanted to show 52 00:03:05,020 --> 00:03:10,170 you an example of a reasonable microservices architecture. And what I 53 00:03:10,170 --> 00:03:14,000 want you to see again from a bird's‑eye perspective is that because 54 00:03:14,000 --> 00:03:17,390 the application is decomposed, you might think on one hand, 55 00:03:17,390 --> 00:03:21,270 well, wait a minute, aren't we dramatically increasing the administration, 56 00:03:21,270 --> 00:03:25,500 the development, the troubleshooting, the orchestration? I would say yeah, 57 00:03:25,500 --> 00:03:29,500 maybe on the front end, but over time you're going to find that because 58 00:03:29,500 --> 00:03:34,390 these components are individualized, or individuated might be a better term, 59 00:03:34,390 --> 00:03:39,940 you can handle updates and patches and scaling separately without worrying 60 00:03:39,940 --> 00:03:44,170 that your change is going to have a cascade effect, and affect the rest of 61 00:03:44,170 --> 00:03:46,340 your system in a negative way. 62 00:03:46,340 --> 00:03:49,290 So, it's ultimately a very solid design pattern in 63 00:03:49,290 --> 00:03:54,000 my experience, I hope you agree. Now, let's do that second demo.