>> Hey everybody, stay tuned today
where Jeff and I will be talking about start
small and expand landing zones and how
you can deploy them within your environment.
[MUSIC].
>> Welcome to the Azure Enablement show.
In this show, we're having
technical conversations with some Microsoft experts around
the questions and potential obstacles that you may
encounter along your Cloud adoption journey.
Now in today's episode,
we're going to be talking about the start
small and expand landing zone.
In order to have that conversation with me,
I'm welcoming my guest, Jeff.
Jeff, welcome to the show.
>> Hey Sarah, thanks glad to be here in the project.
>> Awesome. As I said,
we're talking about start small and expand the landing zones.
Jeff, could you tell us a little bit about them,
and why our customers would be thinking about using them?
>> The idea here is that,
you want to get started in the Cloud you want to start to
set up an environment
for the workloads that you're bringing into the Cloud.
You have to have some basis to start with
some construct of what the requirements are going to be,
and how to align them.
The customer needs to flesh out
what their Cloud adoption plans are going to be,
and better understand things like governance,
the network security requirements for the adoption.
The Azure landing zones start small
and expand it helps them with being able to
pull all those requirements together and then
start learning more about the Azure platform.
>> Awesome. Now, I've heard people talk about
design areas within these landing zones.
I take it they're very key to working through
the process of picking the right landing zone
and going through that.
Is that correct to say, Jeff?
>> Absolutely. As we were just mentioning it is that a customer
has requirements around what
they need for their workload inside of the Cloud.
Let's just take a look as we've got some designers
to help customers with this and we take a very practical,
systematic approach to this.
Let's look at these Azure landing zones by designer here.
We have put in there are eight critical areas for a customer
to consider as they go to adopt the Cloud.
The first one is the enterprise enrollment.
What this represents is the billing mechanism.
The alignments from a billing standpoint
of your relationship with Microsoft.
Then we have identity.
Identity is about I am.
It's about the access
controls that you would need in the Cloud in order to
be able to securely operate those workloads.
Resource organization is the construct of how you organize,
not just things like
subscriptions within Azure or resource groups in Azure,
but also how you're going to tag things,
how you're going to align them when you're adopting the service.
As always, it's important as you design how
you're going to organize their solutions
is how they're going to connect.
Whether they need things like internally,
the Azure talking to the network,
or externally talking to a headquarters or a branch office,
or even within Azure different data centers.
All of that networking and connectivity is a design area.
The business continuity and disaster recovery.
This is making sure that you have a business plan in place.
If there were any kind of disaster to happen,
that you would be able to quickly get business back up and
rolling as any interruption that would happen.
Governance discipline. This starts with number 1,
making sure you've got an inventory,
you understand the assets that you have in the Cloud,
you understand who has access to those assets.
You also wanted to create a model
of governance that allows you to understand
the investments that you're making in the Cloud.
Then two that really go
together it's deployment operations and operations baseline.
Because the deployment options,
they are about how you're going to take
your resources and configure them into the platform.
Operations baseline is what must be true when it comes to all
of those requirements that we talked to you
earlier about the network and security.
The operation's baseline is
the minimum standard that you need to achieve,
minimal viable product that you need to
achieve when you talk about
management and operations for your workload within Azure.
These are all the design areas that we
really look to address within
a start small approach and then we expand that out through
iterative cycles of improvement for the customer.
>> Once our customers went through
all these design areas and thought of their requirements,
how do they actually implement their
starting small and expand landing zone, Jeff?
Is it a case, of they have to go into the Azure portal and
deploy various different resources,
or is there a template that they could
maybe even use to get started with this?
>> That's a great question. There are
a number of ways to get started.
In the Cloud option framework,
we want to make sure that a customer has a plan and
that they've gone through in development strategy for the Cloud.
As they get ready in
the ready phase of the Cloud option framework,
it's time to start making it real.
We have arm templates that are available that customers can use.
These are Azure Resource
Manager tooling in order to be able to standardize how you deploy.
But the one thing that comes to mind first is Azure Blueprints.
I'd like to just show up Azure Blueprints for a second
and what we can do with Azure Blueprints.
>> That would be great
>> Take a look here. I've got the Azure portal open.
To get to this,
you can just simply type in
blueprints in the top of the browser and you can get here.
But looking at our blueprints, we have,
if you go into the definition,
so what is the blueprint definition?
A blueprint definition is a recording of a set of
artifacts that you can deploy for your Azure platform.
Let's go ahead and create one.
We'll create a blueprint.
In doing so, one of the resources that we have available for
customers who are wanting to start with
their landing zone is we have the CAF Foundation,
the Cloud Adoption Framework Foundations start small landing zone.
We also have one that is for migration.
These are pre-built blueprints
that you can go into the Azure Portal like I'm about to do.
I can just select this foundation.
To get started I'll go here and add a blueprint name.
I'm going to call this CAF Foundation 2,
for my deployment here.
Then I happened to find a scope that is called location.
I'll go in and I have
a WVD deployment that I'd be getting started on.
I'll select my WVD subscription
here and go ahead and save this draft.
I'm saving this draft now because I've created a blueprint.
Here we go, it's done now.
Here's my CAF Foundation blueprint that's now in my subscription.
I've gone ahead and created
one and it had a little bit of customization to it.
Let's look at what's in that blueprint.
If I go into that blueprint here,
I can see I've got some Azure Security Center template that's put
in place along with some policies
that are included in this blueprint.
Then there's the section down here
that's about shared services for deployment.
We've got log analytics deployment and we have Key Vault.
Then I've customized here the LZ so for my VNet,
so my VNet is included in my blueprints, to deploy.
I go back to blueprints,
you'll see that once you've finished a blueprint,
there's also an assigned blueprints.
I can then say, I have a subscription,
I want to assign this blueprints,
that subscription and have it deployed.
CAF Foundation has been deployed I have it assigned here.
In my subscription list under my WVD subscription,
you'll see that it's actually assigned into that subscription.
>> Excellent. That looks really easy to get started.
The one thing that's going through my head when you're
demoing that though Jeff is what
happens if something changes if
a design requirement changes after deployment,
or even during deployment,
can you change this or is it a case of you need
to delete it all and start again, how does that work?
>> I think that's one of the challenges that customers face
is change management and configuration drift.
Blueprints has versioning inside of it.
When there's a change that's been made, number 1,
you could honor that using Azure policy, number 2,
you know that that configuration for your platform,
you can go back to in your blueprint created
a second version, a blueprint,
allows you to have a module for
your landing zone that is the same configuration each time,
it's deployed and then as there are changes that need to be made.
You can modify that blueprint, update it,
and redeploy it or reassign it you can get those updates put
into in your production environment.
In the same way, you could have
another subscription that was specifically
for what's called a user acceptance testing environment.
You could make changes to that blueprint
until you've got your golden image, so to speak,
is where traditionally in IT we had
this Golden Image philosophy when it came to the creation process.
This is like having a golden image for your landing zone.
Now you can define a track and keep
changes in the entire process of deploying in Azure.
>> That sounds great.
Now, I know you talk to a lot of customers.
Jeff, do you have
any stories you could maybe
share about some of the common mistakes that
you see customers makes so that the audience
can learn from those mistakes and
not actually follow them as well?
>> Sure, absolutely. The first thing as always is to be ready.
Have your plan ready.
Start with the a critical design areas,
meaning know what those requirements
can be and document those requirements.
You want to treat the environment that you're deploying
in Azure as though it is going to be production,
which means gathering all those requirements across your network,
across your governance model,
and having them put in place.
Second thing that I see with customers,
so the first thing is just gathering your requirements in the lab.
The second thing that I often see is that
you don't have a set process when a customer starts,
and so that can cause rework.
What happens is when you start deploying into the Cloud,
you're just trying to get something up and going for production.
What I'd say there is, if you
utilize something like Azure Blueprints,
you can have a standard way to track your changes as you're
learning and get used to how you're going to operate the Cloud,
we call it the Cloud operating model.
With start small and expand,
you can start with just addresses and
storage inside of the blueprint and then identity.
Then you could think of things like role-based access control
and you can build iteratively on that blueprint.
That is a process by which you're going to
become more familiar in the DevOps,
what I'd like to say, repetition creates
mastery, it's a common thing.
Creating that freedom to fail and to deploy something where
you're going to have the opportunity to make it better in
each iteration is the ideal environment to create.
I think that gives a clear path to success.
>> Thank you for sharing those tips.
If our customers actually wanted to go and
implement then start small and expand landing zone,
is there a great place for them to
go to get some more resources and have a look at that?
>> Absolutely. Within the Cloud Adoption Framework,
we have an Azure landing zones section.
Within the Azure landing zone section,
there is a start small and expand section here.
In the start small and expand section,
we have links for
the Cloud Adoption Framework, migration landing zone,
as well as a foundation and helped with understanding some of
these concepts around landings on
operations governance and security
and provide us with guidance there as well.
These is the key place that a customer getting started can
go and gather more information
and probably get started for deploying your workload management.
>> Awesome. Thank you so much for your time today.
I really do appreciate and I've got a clear idea of what
that start small and expand landing zone is.
Now, if you're looking
to grab some of the resources that Jeff talked about,
please head over to our description box.
We will be dropping the links for those and please as well
stay tuned for future episodes of the Azure Enablement show.
[MUSIC]