(bright music)
- Up next we take a look at updates
to the Azure Landing Zone guidance, which provides a proven
best practice architectural blueprint
and tooling also sets you up for success
as you build new cloud-based services and migrate
or modernize what you already have.
We'll show you new tools
to assess where you are in your cloud journey
and how to automate the buildout
of recommended foundational services
to host your workloads in Azure.
And to walk us through everything, I'm joined today
by Azure and Azure Landing Zone expert, Matt McSpirit.
Welcome to Mechanics.
- Thank you.
Thanks for having me, it's good to be back
to share the updates.
- And thanks for joining us today.
This is really an important topic, because anyone
who's building on the cloud a lot of the time,
you know, you don't know what you don't know.
So instead of going through the pain of experience,
this gives you a clear path forward that really helps you
to avoid specific gotchas from the get-go.
- Exactly. And that's critical,
because oftentimes we see a driving force pushing you
towards considering the cloud.
Maybe you're in a data center, or as we saw
with the pandemic, maybe you need to move fast
to accommodate new circumstances for your organization.
You also might have started experimenting with new services
and, before you know it, that experimental workload
is playing an essential role in your operations.
And for various reasons, the long-term foundation
for your workload might be overlooked.
So this is about setting you up properly
for future growth and scale,
and not just about addressing the current realities.
- And I got to say, what I love about
the landing zone guidance is it's not just academic,
like ITL and ITSMF guidance,
that stuff that I grew up with,
you know, the tooling automates out the provisioning
of recommended services for you.
- Absolutely. And that's something we'll dive into today.
Services are pre-provisioned through code as
running services with lines of separation for sub-workloads
and user roles, which I'll explain more in a moment.
There are real implementation lessons encapsulated
in this approach, so much so that the latest updates
to the architecture are a lot more prescriptive.
It's now a single destination that builds out the services
for scale, security, governance, networking,
and identity that you need for hosting your workloads.
And it's relevant, no matter your organization type or size.
With these services in place, you can run
just about any app workload.
Now on the periphery, you'll see identity
and access management, policies for governance,
management and monitoring tools, networking,
and other shared services.
And at the center of the applications themselves,
each with their own set of resources,
including compute data and storage,
plus how they interact with the foundational services.
- And the key here really is that, you know,
this is all going to be scalable
and repeatable regardless of your workload type.
- Yeah, and it's a modular approach.
You can extend what you deploy to various platforms.
Which might be workload specific,
for example, building an app running
in a Kubernetes cluster is going to be different
than managing an Azure Virtual Desktop environment.
And what I showed you before was
the simple architectural view.
Now, if you look at a more detailed,
but still high-level view of the architecture,
you'll notice at the center everything is broken down
into separate subscriptions within Azure.
There are subscriptions for identity,
management and connectivity,
and all of those subscriptions sit
under the platform management group.
In the middle,
you can see the more app-specific Landing Zones
with their own set of resources.
Then you'll see decommissioned subscriptions
and sandboxes for retired apps or apps in development.
Now, the management group layer above all
of these subscriptions is significant, because it means
that each area can have their own unique policy controls
and the right amount of separation.
- And this all sounds and looks like how an organization
might decentralize their own operations, you know,
using different departments or business units
or even maybe their different app workloads.
- It does. And in fact, management groups
and subscriptions are a great way to delegate control
in a logical way.
And along with policies, they're really the secret source
to organizing your workloads for governance and scale.
Now management groups help you create a logical grouping
of subscriptions for services like networking,
management and identity.
And they're separated from your applications and workloads.
Now this separation helps because
the number of applications in your environment
is going to grow exponentially faster
than the shared platform level resources,
which are going to have a one to many relationship
with your apps.
Then policies set boundaries and rules
that reduce the amount of manual intervention
as your environment grows and protect against missteps,
like accidentally allowing a public IP address,
something that shouldn't be accessible externally.
They also ensure the right privileges
and access permissions for the growing number of teams
and stakeholders interacting with your environment
as you scale too.
- That said, this is great to know as you start
to build out workloads, you know,
but you might be at different stages operationally.
So how does this then help organizations
that might be in a different place?
- So, while a destination's the same,
built into the guidance is the acknowledgement
that your starting point will be different.
You can think of these phases as on-ramps.
So if you're at the beginning of your cloud journey
or starting from scratch, what we often call greenfield,
you'll be on the Start on-ramp.
This is like a blank canvas, and you can start
with the right structures and services
in place following the Landing Zone guidance and tooling.
Now, if you have an existing environment,
this is what's sometimes referred to as brownfield.
In this case, you're going to have a few services
perhaps running in a single management group
or subscription in Azure.
So you'd be on the Align on-ramp, where you'd need
to do some modification,
like establishing the right management group
and subscription hierarchy
to match the Azure Landing Zone target architecture.
And if you're already in line with best practices,
with a few more workloads and progressing well,
but looking to add a few more controls,
we call this the Enhance on-ramp.
For example, you might be looking to add security controls
like Microsoft Sentinel to an already mature operation.
So you can focus your efforts depending
on where your organization falls.
- And with the exception of greenfield, you know,
there's a bit of nuance in terms of how you might choose
between the Align and Enhance on-ramps,
because you'd have to have a good handle
for how far along your organization really is
to get started.
- Right, it does require some investigation,
but the good news is there's a new assessment
that's just launched that can help with that.
It's called the Landing Zone Review,
and I'll walk you through it right now.
Now, to find it, just go to aka.ms/assessments
and you'll land on the assessment home.
Now I'm going to select the Azure Landing Zone review.
Here you can choose your top interests
and assess them individually.
And if you just start with a few of these,
you can always return and add more later.
Now, to save time, I've pre-selected everything.
And on the left
you can see the corresponding questions across categories.
It's assessing things like our business priorities,
operating model and capabilities in our team.
I'll hit Start.
Now, in my case I've answered everything
with some of the most typical responses.
My organization's got a few workloads running in Azure,
but we're looking to improve things.
I'll fill in this last question
and choose the second option.
And now when I hit view guidance, it shows me my results.
And as I suspected,
it looks like I've got some room to improve.
On the right, you can see how my organization fares
by category, and we'd like to improve identity
and management categories in particular.
When I scroll down, first I can see a few hero links
for the Azure Landing Zones accelerator
that I'll explain in a moment,
a link to the Cloud Adoption Framework guidance
and the Azure Migration and Modernization Partner program,
where you can get help from partners in your area.
Below that you'll see a custom set of recommended actions
to take as you implement Azure Landing Zones.
I'll expand this one for identity,
and there are three recommended actions here I can follow.
For configuring emergency access, RBAC,
and logging in Azure Monitor.
And since management scored the lowest in my assessment,
I'll expand that category
and see three more recommended actions.
In fact, I'll click on this one for workload management
and it links me directly to design considerations
in the Cloud Adoption Framework's ready resources.
And I can immediately see here, for example,
just how important it is to use Azure Monitor
for analysis, insights and alerts.
- Okay, so now you know all the concepts
behind Landing Zones, you've mapped everything out
then tailored to your specific organization.
How do you go about building out the Landing Zone?
- Well, now that we're ready to action this,
that's where the Landing Zone's accelerator comes in.
So it's a fully-automated Azure resource manager template
that builds out the full architecture of management groups
and subscriptions along with all the core services
for the Landing Zone.
Now, before you get started,
your user account needs root level permissions
for your Azure tenant, and you can check that
from the Azure portal
in your Azure Active Directory properties here
under access management for Azure resources.
And you can see I'm good to go.
Now from there, I can navigate to aka.ms/alz,
which takes me to the Azure Landing Zones documentation.
And if I click this link on the right,
it takes you to the accelerator.
You'll see it takes me right to the section on the page.
And with this button,
I can start deploying my landing zone in Azure.
Now, once I click that, it'll take me
to a wizard experience walking me through the deployment.
These settings comprise all the variables necessary
to get everything configured in an opinionated way,
reflecting the prescriptive architecture
across the subscriptions that you define.
I'll walk through all the tabs in the wizard.
And again, to save time,
I filled in most of the fields in advance.
So here for deployment location,
there are a few basic configs for directory and region.
Then in Azure core setup, this is where
you'll set up a short management group prefix.
I'm using ContosoMe.
Next is platform management, security and governance,
where you'll choose your management subscription
and configure core management services.
Then platform, DevOps and automation.
This is where you'll connect your GitHub org
and define a service principle.
Now, in this case,
you're not configuring an Azure subscription,
but using GitHub as a proxy for that.
And in my case, I won't deploy an integrated CICD pipeline.
So I'll select No above.
Next, in network, topology and connectivity,
you define the connectivity subscription
and have options to deploy a few topologies
to support your workloads.
Under identity, you define the identity subscription
and the associated network settings.
And the landing zone configuration,
that's where you'll define subscription details,
Vnet configs, and additional settings below.
Now I can run a validation check against everything.
And, after I review everything one more time and create,
it'll kick off the deployment.
- So now everything's running in terms of the deployment,
how long does something like this take to complete
and what does it produce?
- So, this process will take several minutes
to deploy everything.
So let's fast forward a bit
until the deployment is complete.
And you'll see the environment's been created.
So I'll start with the tenant hierarchy
and take a look at the management groups.
And when I expand this one for ContosoMe,
you'll get a good idea of our structure
and that it matches our management topology
along with the corresponding Azure subscriptions.
And of course, behind all this
it's provisioned quite a few Azure services,
policies and configs.
It's all done for you.
And by the way, if you're using Terraform now,
there are options to create Azure Landing Zones
at aka.ms/ALZ/Terraform.
We also have guidance on GitHub
for using Azure Bicep directly
to deploy resources at aka.ms/ALZ/Bicep.
- So you're ready to start building out different workloads
inside of the environment with the right services
and hierarchy in place as well.
You know, we went through everything pretty quickly today,
I think, and for anyone who's watching, looking to learn
more or get started, what do you recommend?
- Well, the good news is you can get started today.
First, assess your organization where it lands,
and to get tailored recommendations,
go to aka.ms/landingzonereview and start your review.
And everything I've shown today is part
of the Cloud Adoption Framework.
You can find everything you need
for landing zones at aka.ms/alz.
- Thanks, Matt, for joining us today
and sharing all the updates to Azure Landing Zones.
And of course, keep checking back to Microsoft Mechanics
for all the latest updates.
Subscribe, if you haven't already.
And thank you so much for watching.
(bright music)