>> Hey everybody, stay tuned
where Kristian and I will be talking about
Enterprise Landing Zones and digging really
deep into how you can implement them in your environment.
[MUSIC]
>> Welcome to the Azure Enablement Show.
We are talking with Microsoft experts to try and uncover some
of the questions or obstacles you might
face when you're on a Cloud adoption journey.
Now, we've been talking about Azure Landing Zones,
and how to choose
the right Azure Landing Zone for your environment,
and today to take a deep dive into
Enterprise-Scale Landing Zones is Kristian as my guest.
Welcome to the show, Kristian.
>> Thank you so much for having me here, Sarah.
>> Awesome. In the last episode,
Rob, came to demonstrated Enterprise-Scale Landing Zones to me,
but I'm hoping that you're going to even show
me a bit more of the architecture and a longer demo.
Is that okay, Kristian?
>> That's absolutely spot on and what I'm planning to do here,
so that sounds like a good plan.
>> Cool. So can you take me through some of
the different referenced implementations
that we have and tell me what they're for, please?
>> Yes, that's actually what I want to spend time on,
to build on what Rob
started when he had his 15 minutes of fame or so.
We're going to take that, we're going to dive deeper into that,
and actually explore, what's
the conversation like in the Enterprise-Scale contexts.
How do we actually identify and
realize some of the design principles that we have,
and how do we make it more real?
I've actually prepared a set of decks,
and I want to spend some time here to just talk a bit about them.
Then we're actually going to look at some visuals
in the deck itself to get an understanding of
how does all of this come
together for a given scenario, and things like that.
Then of course, we're going to do some hands-on
keyboard demonstrations and show you that as well.
>> Awesome.
>> I think let's start.
Rob, key shared likely
the deployment experience of the reference implementation.
The fact is that he had
three different reference implementation today that all shared
the same experience in terms of
what you can achieve as part of that bootstrapping process.
All of them are self-service,
one-click deployment experience in the Azure Portal
backed by Azure Resource Manager templates.
What's interesting, when you kind of dive a bit deeper into them,
and as Rob talked about as well,
is that in the Cloud Adoption Framework,
we have the Enterprise-Scale Architecture
and the design methodology.
If you open up and see there,
we have actually five design principles,
such as the Single Controller Management Plane,
we have Subscription Democratization,
Policy-Driven Governance, Archetype, Neutral Migration,
as well as Azure Native Services aligned to the Azure roadmap.
So all of this basically is coming together
as you deploy the Enterprise-Scale Reference Implementation.
Another thing that I also personally think is great,
is that many ask us,
"Hey, is this just a Greenfield?"
Because we realized, we know that the reality is that
very is likely there's some existing resources
in that Azure tenant from before,
and yes, this can be deployed
both into a Brownfield Azure AD tenant,
as well as the Greenfield.
But what I specifically want to talk about,
is the modularity piece of it.
We have three reference implementation.
We have the one we have categorized as Contoso,
which is using Virtual WAN as
the hybrid connectivity and networking
topology for the entire Azure platform.
The other option we have which is kind of
similar, is the AdventureWorks.
However, there the approach is using more traditional hub and
spoke approach to solve for that hybrid connectivity scenarios.
Then we basically have the Wingtip.
It's the reference implementation
for customers who just want to get started in Azure.
They don't have a specific requirement
for hybrid connectivity on the get-go,
and they just want to move on.
Does that make sense so far, Sarah?
>> Yeah. One thing I wanted to ask you
was, those reference implementations,
are they just for brand new customers to Azure that aren't
maybe attempting to connect their
On-prem environments up into the Cloud as well?
Is that the right way to look
at those ones you've just taken us through?
>> No. Absolutely, this is
referencing mobilization regardless of
where the customer is on their journey.
They can have an existing footprint as I said,
and then there might be different reasons.
Perhaps they have reached a limit,
they need to refactor and do anything,
and this is the architecture
that allows those customers to get on that,
we often refer to as into the pit of success,
whether you can have that sustainable architecture,
regardless of their scenarios and
scale points for their workloads as well.
>> Awesome. I am hoping you have a reference implementation
for customers who want to connect
their On-prem environment up into the Cloud.
Is that what you're going to show me next, Kristian?
>> Well, actually before that,
we're going to look at the modularity.
But to your point, we do have both Contoso and
AdventureWorks definitely cater for those scenarios,
where you have that On-prem environment.
You're going to bring it into the Cloud where you
wouldn't need that hybrid connectivity.
It's just slightly different implementation in
terms of using the new Virtual WAN
and also the more traditional virtual network
to a hub and spoke model.
But let's have a look and see how we're thinking
about this from a modularity and architecture perspective.
So assuming that, from this deck,
what we tried to illustrate here is how
does the Enterprise-Scale Reference Implementation
look like from a Workload Dial perspective?
The thought process here is that in this scenario,
you do not have the need for hybrid connectivity immediately.
So you can start off using that Wingtip reference implementation.
As you can see on this slide,
we have approximately 50 Workloads.
Those 50 Workloads, they goes into the Landing Zone.
The Landing Zone here is represented by a subscription rooted
into the Online Management Group
inside the Landing Zone Management Group.
On the left hand side though,
you can see there's also a Management Subscription.
This Management Subscription is inside
the Management Group located in the Platform Management Group.
This is a key thing I just want to double-click on,
on why this is such an important thing,
because already here from the get-go,
we have done a very important thing,
and that is really separating
the platform and what's identified as being the workloads.
So this means that,
as we going to turn the dial a bit,
you can see how do we think about scale from this perspective.
Already here, you have that clean path where
you can transition into whatever next is coming.
Now, I just want to turn the dial and see what that looks like.
We're going to turn into 100 Workloads.
Now, you can see the actual thing we had to introduce here,
and whether this is because running
into some of the subscription limits we may have in Azure,
resource specific limits, or there is
a new application team coming in and you
want to have a clear separation of duties,
we introduce another subscription into the Landing Zone,
so that Workload can continue to be deployed and moved into Azure.
Again, you can see the architecture based in the remains the same.
We have that separated platform side,
we now also have N number of
Workloads in N number of Landing Zones as well.
What do you say, Sarah, should we turn it up further?
>> Yeah. Go big.
>> Another common question is,
okay, this is great.
Previously, we had two landing zones
and they all Workloads landed there.
They shared basically some common characteristics
given that they were all put inside the online Managed Recruit.
Now, as new requirements comes along, in this case,
there is a special Workload requiring
other aspects since in terms of governance,
compliance, and things like that.
So we need to wait to place our PCI compliant Workload as well.
What we're doing here is that we're introducing
that PCI Workload Management Group
under the Landing Zone Management Group,
so that those workloads with those requirements,
they can actually land there.
The benefit here is that now we have actually an architecture in
the platform that allows for N number of
Landing Zones into the Online Management Group,
we also have a designated column for
any number of Workloads that needs to be PCI compliant as well.
What do you think, Sarah,
if we go to the extreme and just look at this
from a 10,000 Workload perspective?
>> Yeah. Let's turn that dial, Kristian.
>> Let's turn the dial,
and what you can see here,
and this is starting to look at
things and it looks perhaps a bit more complex.
There's a couple of things that's going on here.
One, you can see on the platform side now as well,
there are some changes.
We have the management subscription,
which is the subscription intending
to cater for all the audit things,
security and login thing for the entire platform.
But now, we have also connectivity subscription.
To your question earlier,
when we're going to migrate
from On-premises to Azure and what do we need.
This is where we have that dedicated subscription for
that global connectivity aspect of it.
We also have introduced an identity subscription to handle
for the authentication scenarios
inside the Landing Zones themselves.
As you can see now,
we also have a Management Group in
the Landing Zone identified as Core.
Those are the Workload that requires that On-prem
connectivity dialing back home for those migration scenarios.
But the beauty here is that both on
the platform side as well as the landing Lone side,
you can now scale those independently without impacting each other
and also not impacting
existing resources already deployed into Azure.
There's a couple of other things here that it's
not crystal clear just looking at this deck.
But one of the principles we have in
enterprise scale is this policy driven governance,
because a typical question we
would likely get by going through this is,
with so many subscription,
there has to be a management over it.
There is a burden. We cannot do this.
But with policy-driven governance,
what that means from our perspective,
as well as what the platform provide,
it means that no matter how these resources are being created,
and remember even a subscription is a resource in this conference.
It doesn't matter how it's created,
when it's dropped into the designated matched recruit,
policy will apply and bringing all of
those resources to its goal state.
There's no need, if you take that approach,
you actually have someone to sit and do
XYZ activities to make
that subscription ready for the application teams.
The policy actually enable
the autonomy for both the platform side,
as well as the Landing Zone side.
Again, regardless of scale point.
>> Excellent. That's sound fantastic and I do
love a good architectural diagram.
But I'm hoping you're going to be able to do
some hands-on keyboard and show us
in action rather than just in a diagram,
Kristian, is that okay?
>> That's absolutely okay and that's
exactly what I'm planning to do right now.
Let's move over to the environment,
and looking at what Rob started in his session,
we now have deployed enterprise scale.
We have the management group hierarchy,
the one I talked about,
specifically inside the Landing Zones,
we have the one subscription MI environment
because we just got this started.
But as I add more subscription into here,
they will all be subject to
the different controls that we have
applied using a policy-driven governance.
One thing I just want to show is that when this
subscription lands inside this Management Group,
we can actually go and take a look at
some of the policies that are applied for
the specific Workloads that will
land into to the Landing Zone itself.
If I look at the compliance here and I drill a bit down,
and again, this is a demo environment,
so there's a lot of stuff in flight here.
But if I go into a particular policy that says Deploy ASC,
if I open that up and actually look at it,
you can see that in the compliance result from this policy,
we have a resource here that is compliant.
>> Okay.
>> If we expand a bit on the resource type,
you can see that, "Hey, this is actually a subscription."
What this means is that this is written as compliant
because as part of that placement of the subscription,
Azure Security Center gets enabled.
We can actually just quickly explore the policy itself that does
that magic and what
we're going to look at here is that we have a policy rule.
It will look for the subscriptions.
If there is a type subscription,
and then it will check on a couple of resources,
and if these resources are not there,
it will deploy them using deployIfNotExists effect.
This will then start an ARM template that goes and target
that subscription and goes and enable Security Center.
Sounds fantastic, right?
>> Yeah.
>> If I now navigate to
Security Center inside the environment
that I have provisioned here,
you can see that these are all the subscriptions that I have,
the platform, the management,
the connectivity, but also the Landing Zone, they're all good.
You're secure, you're compliant from the get-go.
This is basically the platform side,
what this means is having this autonomy enabled.
What I also wanted to just spend some time on is,
what does this mean for
the actual application team that
are going to deploy their Workloads?
We're going to put on the Workload lenses.
Now, I'm inside one of the Landing Zones Subscription.
Here you can see I have deployed stuff and I've
done certain activities because I'm building stuff.
If we're going to look at one of the application,
we have HR Applications 01.
If I look into that, actually,
when I started deploying into here,
I actually went to the Azure marketplace.
I needed a Windows Server 2016,
and then I also need a Key Vault,
because that's where I started,
and later on, I added more resources as well.
Some resources were added using PowerShell,
some using CLI, and even Terraform.
>> Okay.
>> What happened then, you can see there's
quite a few deployments inside this resource group.
So if I scroll down to see the first thing I did,
I went to the marketplace and I deploy the Windows Server.
I also went to create the Key Vault,
and from there and onwards,
you can see there's actually
quite a few policy deployments happening here.
Then I added another machine and you can
see additional policy deployments.
>> Excellent.
>> Should we have a look and see what actually happens?
>> Please do. Yeah, please dive in deeper.
>> Let's go into the overview again and let's look
at this from a VM perspective in this case.
What happens when we deploy this one is
that the policy applied to
the Landing Zone ensures that VIRTUAL machines,
web apps, SQL, whatnot,
they're all brought to their goal state.
What that means from
this particular resource is that if I now go and look at backup,
I should now see that this VM is already
protected into an Azure Backup Vault
that also got created as part of the policy.
As an application owner,
I didn't have to think about that.
I didn't have to ensure that backup was part of my VM
when I created it because policy came
in and brought it to its goal state.
Similarly, if I now want to patch my VM as an application owner,
I can do that as well.
It's already wired up.
It's connected into log analytics.
It has the patching automation account
there to actually help me to
do the patching that I need to keep my machines healthy,
and similar for the inventory and all the other things,
you can see that we have that prepared.
It's already monitored.
We can see the inventory of the machine.
We can see what's the connectivity landscape?
Who is it talking to?
We can see the performance.
It's already there by
default as part of landing into this landing zone.
The last thing I want to show you here Sarah,
is that if I zoom out again
to the resource group and I
just want to look at the diagnostic settings.
We can also see that for all the non-compute resources,
such as the Key Vault, the Network Interface,
you can see that diagnostics is enabled for all them all.
If I just click on the "Key Vault",
you can see that it already has
the diagnostic settings and it's already reporting to
the designated log analytics workspace that is
located in the management subscription on the platform side.
This enabled that at-scale
horizontal view from a platform perspective.
But it also gives the individual application team the benefit of
consuming the same quality services from the same resources.
>> Awesome. I can totally see how you've taken
the diagrams you've shown us
and actually implemented them in Azure,
and also the benefits of actually
using these enterprise-scale landing zones.
Thank you so much for your time, Kristian.
You've definitely sold me on using
the enterprise-scale landing zone for my environment.
Now, if you're looking to use
Enterprise-Scale Landing Zones in your environment,
please just check it on description box where we'll
be putting some links to further resources,
and please do tune to in for
further episodes of the Azure Enablement show.
[MUSIC]