>> Hey friends, you probably know that you can use
ARM templates to deploy Azure resources as a group.
But in most enterprises,
this may lead to these big monolithic templates
and it adds a lot of complexity.
Alex is here to show us how
Azure Blueprints will enable you to design and package
entire Azure environments including
your preferred policy and
your role-based access assignments today on Azure Friday.
[MUSIC]
>> Hey, I'm Scott Hanselman,
and it's Azure Friday.
I'm here with Alex Frankel and we're going to
talk about Azure Blueprints.
Whatever it is, I love the name.
>> Cool, that's good to hear.
Basically, so if you think about a large enterprise,
they almost always have a central cloud architecture team,
center for cloud excellence, all that sort of thing.
They are the ones who are responsible for
educating all the different application teams.
It could be hundreds and hundreds of
application teams on how to consume Azure in the right way.
What that has created is
this bottleneck because all these app teams need to
consult with the central body to make
sure they're consuming the cloud in the right way,
and so what we're trying to do with
Blueprints is create a really easy way to
package all these different infrastructure components
together into a Blueprint,
and then once it's in a blueprint,
it makes it really easy to stamp
out environments as app teams need them.
So, you can imagine like a Blueprint
for a Dev environment or a Sandbox environment.
You can imagine a Blueprint for like
a three tier application really anything that you
can imagine you can do an Azure that
can be packaged into a Blueprint.
>> Interesting because right now and big enterprises what I
see are a mess of PowerShell scripts.
Everyone's got a different one.
Everyone's got a Word document somewhere.
>> Exactly.
>> Funny thing about Word documents. They don't compile.
>> Yeah.
>> Right, and there's no way to really risking validate the stuff.
>> Yeah.
>> Right?
>> Yeah.
>> Somehow Cloud Enterprise Excellence Group
sends you a vision diagram.
>> Yes.
>> It says make it like that.
>> Yes exactly and it creates this huge process of trial and
error where they consult the dock
and they try to make it and it gets something wrong,
they go back to the cloud architecture team
and they go through that loop,
and we found that to go from
zero to production application in Azure,
it can take anywhere from like three to 12 months
because they're going through that painful process and they
all have this custom effectively custom orchestration system
and each one is making their own different things.
>> So, this was great. I've literally had
these conversations with customers
and with people internally and I'm like,
how come I can't go file new.
My company's enterprise application?
>> Exactly, and we saw
all these large enterprises
spending hundreds of thousands of dollars and
60 engineers to build effectively
their own front end in front of
Azure so that they could do something like that.
But that was all built with custom code.
All that PowerShell glue that you were talking
about and so this is taking all of
that knowledge and research and packaging it
into this native concept of a Blueprint in Azure.
>> Okay. So, then coming from
a place of ignorance how come this isn't just ARM templates.
I thought ARM templates. We're going to solve everything.
>> Yeah.
>> Then with the creation of software
based networking in v-nets we can all have our own network.
There's nothing very sophisticated.
Wasn't an ARM template style knew my app.
>> Yes. So, an ARM template is really good at saying
I want this resource to exist this way in a declarative way,
but where it starts to break down is when you start
composing these large environments,
and there are certain ways to
orchestrate larger ARM templates together,
but it becomes these monoliths that are hard
to debug and hard to manage and that's
when you see these enterprises transition to
a C-sharp orchestration system or
PowerShell orchestration system so
they can keep their arm templates small,
but have something to tie it all together.
But those all have their own problems, and so,
what we're really doing with Blueprints is giving you a way to
package ARM templates, policies,
R-back assignments into this native thing in
Azure and you'll see that that helps with things like
versioning and keeping
those environments up-to-date overtime which
is a huge challenge that people don't have a good way of solving.
>> Okay. That acronym.
R-back of course role-based access control.
So, I'm hearing you say that Azure Blueprints is a superset
or container for ARM templates and other policy.
>> Exactly.
>> It is not a replacement of. It's a bigger dam.
>> Exactly, so, all the
engineering in the world that you've done to build up
a repository of really great ARM templates
that feeds right into
blueprints. You don't need to change anything.
>> I Love it.
>> Yeah.
>> I love it. All right. Anyway so my diagram here.
>> Yeah. So, this basically just covered what
we just talked about where you're
composing this package of R-back policy
and ARM templates into a Blueprint and once you have
the Blueprint it becomes super easy to scale out and
stamp out those Blueprint environments in
many subscriptions or if you're in
a shared environment in a single subscription you can
have Blueprints define a few resource groups
and stamp out those environments within a single subscription.
>> I assume that this isn't production specific.
It could be dev and test and get
the staging load balancing for
testing and doing some load testing.
>> Exactly, and it can be parameterized really everything that you
want to be able to do in terms of
deployment infrastructure to Azure. It can be done in a Blueprint.
>> This is a native thing. This a Azure understands this thing.
>> Yes.
>> This isn't just Alex get this wisdom. PowerShell script.
>> Exactly, and that's really the key.
>> I love it.
>> Cool. So, let's do a demo.
>> Alright.
>> So, this is the Getting
Started page for Blueprints and walk through
some basic things like creating
a Blueprint signing that Blueprint to a subscription and then
tracking the life-cycle of that Blueprint over
time swell some good documentation.
The table of contents is
super straightforward just Blueprint definitions.
What does this Blueprint do
and Blueprint assignments what's gonna,
what's it gonna to look like when the Blueprint deploys.
>> Okay.
>> So, we'll start by creating a Blueprint from scratch.
When we do that I get some simple templates
here of things like common policies
or resource groups with R-back.
These are just built-in Blueprints to help you get started faster,
but we're going to start with a blank Blueprint template.
I have to give the Blueprint a name.
So, my new Blueprint.
I can give it a description if I'd like,
but I'm gonna skip that for now and then I
need to put the blueprint definition somewhere.
So, you've saved the Blueprint definitions that
either a management group scope or subscription scope.
A management group if you haven't played around with it
yet is really just a grouping concept for subscriptions.
So, by placing the Blueprint above
the subscription in your Azure hierarchy,
you can then do sign that blueprint to any child subscription.
>> That makes sense. That's nice.
I know I'm familiar of course with ResourceGroup.
This wouldn't be an appropriate concept.
I'm familiar subscriptions but if
you're in a large enterprise with hundreds
of subscriptions you might want to say that Developer Division.
>> Exactly.
>> The production people.
>> Exactly. So, we'll pick
a management group to save this particular Blueprints.
[MUSIC].
Her favorite organization Contoso,
and when I get to the Artifacts,
section this is really the meet of what a Blueprint
is I can start adding as many artifacts I need,
as I need to this Blueprint.
So, at the beginning I have
only one spot to put one of these artifacts,
and when I click Add artifact I get these options for
policy assignment role assignment
and ARM template or resource group.
I can create many different resource groups that I
defined in the Blueprint. So, we'll start there.
Like I said,
you can parameterize pretty much anything in a Blueprint.
So, I can choose to have the resource group name or
the location be hard-coded or
I can have it be determined at assignment time.
That's what I'm going to do with
this particular resource group name.
But the location, I always want
this particular environment to be deployed in East US,
so I'll hard-code that here.
So now, we've just added our first artifact
to the Blueprint, and as you can see,
I now have the option to add an artifact
to the subscription like I just did or
add an artifact within the context of
my resource group and that's what I'm going to do here.
So, I'll click "Add artifact" again.
I have a similar set of options, policies, roles,
and ARM templates, but obviously I can't
put a resource group inside of a resource group.
So, that's why that option went away.
>> Okay.
>> So, let's add an ARM template.
We're going to add a virtual network here,
and I have a place where I can copy and paste in my ARM template.
Obviously, we're walking through the UI right now,
all of this can be modeled as code.
So, you can keep all of your Blueprint
definitions in source control,
push them into Azure when you're ready and then you can
start assigning those Blueprints to your environments.
>> Is the Blueprint, is a JSON file?
>> Yeah, it's a set of JSON files,
which is great because then you
can manage the life cycle of each of
your Artifacts independently and
then bring them together in a definition when you're ready.
So I have my VNet template here.
This is just a standard ARM template,
there's nothing I did to make it sort of blueprint specific.
>> Okay.
>> I'm just going to copy and paste it in here.
Click "Add", and now,
I have my virtual network in my resource group in my Blueprint.
Again, there are parameters here,
I can choose to hard-code any of these values if I would like,
but I'm going to leave these alone.
I'll fill them out at assignment time.
But as you can see, there are default values here.
So, just like with ARM templates,
if I have any default values or allowed values,
anything like that, that all works with Blueprints as well.
>> The UI, a compliment to you, it's really nice.
Once you saved it and came back in its found
those parameters and it goes and sets it up very nicely.
>> It actually found that before I even saved.
>> Did it really?
>> Yeah.
>> That's impressive.
>> Yeah. I've got a good team behind me.
>> That's lovely.
>> So we'll save this as draft.
We saved the Blueprint as a draft
by default so that you can continue to
revise the Blueprint before you're ready to
publish it as a distinct version.
The reason why we're very careful about publishing is
because we need to track
where those Blueprints have been assigned.
So, if you turn around tomorrow and say, "You know what,
I need the security team to have
owner access to this resource group."
I can add it to the Blueprint definition, update the assignment,
and all my environments will get updated because we
understand what it looked like
before and what it needs to look like now,
so we have a lot of flexibility there.
>> Wow. That's cool.
>> Yeah. So, I'm going to take my turkey
out of the oven and go to a more
advanced Blueprint that I've been working on.
This is to set up a complete networking setup
for a given application team.
>> Okay.
>> As you can see here, I have
my AppNetwork resource group and I also have four ARM templates.
One for my VNet gateway,
my VNet, my network security group,
my public IP address,
and you'll also see here that I have the other types of artifacts.
I have a policy here to apply
default cost center tag
to all the resources in that resource group,
and I have an R-back assignment to give
contributor access to that resource group.
So, when I go through the assignment process,
I'll hand over access to
the application team as part of deploying the environment.
So it's really just one click and everything is good to go.
>> Right, that right there,
this screen really makes a lot of sense because it shows you
what lives with inside ARM and what is outside of scope.
>> Yeah.
>> That now becomes part of the larger Blueprint.
>> Yeah, exactly. It also makes it really
good for consulting with application teams.
I know as the central team can say,
"Hey, this is what your Blueprint looks like.
This is what's going to be deployed in your environment."
Instead of pouring over these monolithic JSON documents,
it makes it really easy to just look in the UI.
So, now that we have a Blueprint defined,
let's go through and assign
that Blueprint to a particular subscription.
>> Okay.
>> So, I'm going to pull up the assignment screen here.
The first thing I need to do is pick a subscription.
So, I have a bunch of subscriptions here.
These are all the subscriptions that live
within that management group where I saved the Blueprint.
So only the eligible subscriptions are showing up here.
I can give the assignment name,
I have to give the Blueprint a location,
and then here's where that version comes in,
if I want to assign an older version I can do
that but it defaults to the latest version.
>> Which is nice also to know that
Blueprints are being actively developed,
but your investments in
possibly existing Blueprints are maintained.
>> Exactly. So, there's all sorts of
use cases for keeping that old version around.
So, it's not as if you've published a new version
in that old one goes away and can't be used anymore.
>> It makes sense.
>> This feature of locking the assignment is really interesting.
So, today is a perfect example.
You'll deploy a network into a subscription,
and you need to give that application team owner
access to that subscription, right?
Because they need to give access to more people,
create more resources, all those sorts of things.
But that central team has
that network configured in a very particular way.
They don't want you mucking with IP addresses or
anything like that because that can
have really severe consequences.
So by locking the assignment,
it actually says only the Blueprint definition
can be responsible for modifying these resources.
Even if you're an owner in the subscription,
we've actually revoked access from those people,
so that really nothing can
touch those resources except for the Blueprints.
So, you still have a full life cycle around those resources,
but you've removed access from
any owners that you may not want to tamper with it.
>> How granular or not granular is that,
is that's simply a binary thing?
What if I want to change this VM from medium to large?
>> So today, it is binary.
So by turning the lock on,
you're locking all the resources in a Blueprint.
But we do have a lot of plans to make that a lot more granular.
To say, "You know what, I want
this resource locked down completely,
but this one I only want to prevent deletion,
but I want people to add to it."
So you can imagine, like a SQL database.
You want to be able to spin up a new database without
messing with the core config of the actual SQL Server.
>> Exactly. Scale up and out seemed like the first obvious [inaudible].
>> Yeah, exactly.
>> Cool,.
>> In progress.
>> I dig it.
>> Yeah, and then,
now it's asking me for all the different pieces of
information that we parameterized in the Blueprint.
So, I have all my resource names here.
It's picking up the default values from the template,
so I don't need to touch anything.
The resource group is also parameterized.
It's adding a parameter
to that resource group name, the locations hard-coded.
I need to give access to
somebody for this Blueprint to be created.
So, if you don't mind, I'll give
you access to this resource group.
>> [inaudible]. Do I exist?
>> I think you exist.
>> Am I a person?
>> There you go.
>> Oh, my goodness.
>> That cost center tag,
that we're adding to all the resources,
that's a defined set of allowed values.
So, it's really easy for me to pick from a set that have already
been approved by these central architecture teams.
The IP addresses have all been defaulted,
I can change this if I need to,
and the VNet gateways already configured as well.
So, all I need to do is click "Assign" here,
and what this is doing, it's kicking off the assignment process.
So now, the assignment process has started.
So everything's working well,
but it's in the process of deploying, right?
So let's look at what happens when
this Blueprint is finished deploying.
So, you can see here all the deployed resources are listed here.
These are all live links to
the real resources that are really
running and they're really locked.
If I went in and tried to delete an Nsg or VNet here,
I would get an error saying, "You know what,
you have access to these resources normally,
but there's a blueprint that's
locking these resources so you can't touch them."
>> Wow. So you went out throughout all of
Azure to make sure that this was baked into Azure itself.
>> Oh yeah. It's a core part of how R-back works in Azure.
We worked closely with
the Identity Team to make sure it worked really well.
>> That's powerful stuff.
>> Yeah, it really is.
>> All right. So, I can do this now.
This is in preview. Where do I learn about Blueprints?
>> So, you can go to this beautiful collection of resources here.
>> All right. Screenshot this everybody.
>> Yeah. So you have documentation,
we have a deep dive video from Ignite
that goes into way more detail,
and then if you want to take the next step of managing
your Blueprints as a code and putting it in source control,
you have a link for walking you through that as well.
>> All right. Awesome.
>> Cool.
>> What a fantastic resource available to us.
Azure Blueprints making it easier to roll
things out to your large enterprise and your organization.
I'm learning all about it today on Azure Friday.
[MUSIC]