The tool that we need to know about for our AZ‑801 exam here is
called Azure Migrate App Containerization, all right? And this
supports development trends like microservices where instead of
having big monolithic apps, you've broken them out into small,
relatively independent components that you can patch
separately, that you can scale and secure separately, and
then when you're integrating changes,
the idea is that it's an easier integration, all right? You
also, trend wise, have this Docker container and need for
scale with Docker containers,
which is what AKS gives you. Now, just like I mentioned a little
while ago with regard to the App Service Migration,
the Azure Migrate App Containerization tool is under development,
and as of this recording, again, in summer 2022, it supports
ASP.NET and Java applications, and you wind up at the end of the
app containerization process running either Windows Server
containers or Linux containers,
depending upon whether it's an ASP.NET or Java application.
And you can push those to App Service or AKS clusters, like I said
before, okay? Now the tool performs these main actions.
You've got discovery,
which is going to automate looking at your application and
determining what its dependencies are.
It'll build the image for you and even push the image into a container registry
and ultimately into your cluster or App Service environment.
This is some really nice engineering that Microsoft has done, and in my opinion,
the biggest value that it gives is that it's going to help businesses who are
just on the leading edge, or the beginning edge I should say,
of adopting some of these development practices. you know. You
may have a monolithic application and you're not sure where to
start in terms of creating containers,
well, run an assessment using Azure Migrate App Containerization,
and that may be the bulk or all of what you need.
Isn't that beautiful?
This is an AKS reference topology here.
Let's take a look at it from a bird's‑eye perspective. We have our
workflow, which may or may not be integrated in CI/CD build and release
pipelines, it doesn't really matter at this point,
but we're using the Azure container registry as our point of authority
for our docker images, and those images are ultimately being started as
containers running in Azure Kubernetes service. And notice, we've got
role‑based access control with Azure Active Directory, we have
monitoring with Azure Monitor, we have the ability to fetch certificates,
keys, and certificates seamlessly from Azure Key Vault. These are all
benefits of the integration that Azure Resource Manager offers us. Now,
from an application ingress standpoint, there your connecting clients
will normally come in through some ingress vehicle, it could be an
Azure application gateway, sometimes you can use like an NGINX
container as a gateway. And then from there, that gets too much into
developer land,
we don't really need to worry about that, but I just wanted to show
you an example of a reasonable microservices architecture. And what I
want you to see again from a bird's‑eye perspective is that because
the application is decomposed, you might think on one hand,
well, wait a minute, aren't we dramatically increasing the administration,
the development, the troubleshooting, the orchestration? I would say yeah,
maybe on the front end, but over time you're going to find that because
these components are individualized, or individuated might be a better term,
you can handle updates and patches and scaling separately without worrying
that your change is going to have a cascade effect, and affect the rest of
your system in a negative way.
So, it's ultimately a very solid design pattern in
my experience, I hope you agree. Now, let's do that second demo.