>> Hey, everybody, stay tuned for Brian and I talking
about deployment acceleration and
how it can help on your governance journey.
[MUSIC]
Welcome to the Azure Enablement show
where we're having technical conversations with
Microsoft experts to solve some of the questions or
obstacles that you might face on your Cloud adoption journey.
Now, continuing on our governance topics,
we are talking about deployment acceleration today.
To navigate through that topic,
I'm welcoming back Brian to the show. Brian, welcome back.
>> Hey Sarah, thanks for having me again.
>> It's awesome to have you. The governance topic
is something that can
often have a collective grown around the room when you
mention it because it can be sometimes seen as a blocker,
and a way for management to control how people do with their jobs,
is that something you face,
and if so, how do you tackle that Brian?
>> All the time, and
that's where a deployment acceleration comes into play.
If governance is a way to stop people from doing things,
it's not going to be looked on very kindly by
the developers or the business or the workload teams.
When we think about deployment acceleration,
it's important that we think about governance as a team sport.
A little bit of a diagram,
Harold pull up, that just talks about that a bit.
When we're working with Teams on Cloud adoption,
we help the Cloud adoption team that's doing new things.
If they're doing new things alone at some point,
they're going to hit a barrier of security,
or operations, or other forms of governance.
Deployment acceleration is the mindset
of the governance team not being the barrier,
but the collective glue that brings them
together and brings in the security team,
brings in the operations team,
brings them all together to have a conversation early.
When you do that,
it makes it to where you can create
guardrails that let those teams innovate safely and
confidently and not get to
that sticking point at the end where you
have to say, "That's great, but."
>> Cool. Deployment acceleration Brian,
what does that phrase actually mean when we're talking about it?
>> It's that very thought about how do we use governance to
deploy faster and not be that roadblock?
A great example of that is,
I worked with a customer in the US awhile back,
that had some really cool innovation.
They could deploy quickly,
they could build quickly, but they couldn't get to production.
It was a real shame, because what that customer
had was this really cool digital teddy bear,
that grandma and grandpa could record a saying, post out on Azure.
A child squeezes the teddy bear and it plays that saying back,
and it really creates that close bond
with the grandparents or parents or whoever.
We built it out, we developed a solution,
we built the teddy bear itself,
everything is ready to go.
As we took the solution of production,
the governance and security team came
on and realize that there were
ways that you could easily penetrate
that software and send inappropriate message to the bear.
By not having that team early,
it paused that engagement,
sadly it paused it by a year.
So the product never hit market,
it never came out,
never saw the light of day, and it was a real shame.
Deployment acceleration is the thought of
when you are doing that early stage design,
the governance team has a partner that comes
in and helps you with the design and says,
"If you're doing that,
here's a couple of things you want to think about."
Just really help get to that
final production deployment state a little more smoothly.
>> It seems like there's a change in how people can think about
deploying things or a mindset change
with this deployment acceleration.
How do people or organizations make that shift, Brian?
>> The shift occurs culturally first,
just by asking questions,
trying to be involved.
It really takes a step from
the governance team to come forward and say,
"I'm not the bad guy, I'm not trying to stop you,
what can we do together?"
What we see from an organizational structures
is the overall work can help encourage this.
When we look at the CCoE model
or the Cloud Center of Excellence model,
to organization, that helps quite a bit.
In that organizational structure,
we bring together governance, platform, automation, and security.
We bring them all together under our Cloud Center of Excellence
is there to help train and support those Cloud adoption teams.
That structure is a way to create the teams that are there to
demonstrate that support beyond
just individual saying, "I'm here to help."
We've seen that'd be a very valuable approach,
and that's all facilitated through things like
the Deployment Acceleration discipline
of the Cloud Adoption Framework.
>> That makes sense. It sounds like there are a lot of changes
an organization has to invest in some Teams set up etc.
What are the motivations for
an organization to actually spend time
doing this and shifting towards the deployment acceleration,
many say, if they don't do it,
Brian, are they going to mess up?
What's the benefits of them actually doing this?
>> Gladly. The Deployment acceleration
is purposely the last discipline in Cloud governance.
We generally suggest the governance teams
get really good at things like cost management,
security baselines, resource consistency,
and figuring out identity.
Once you have those basics of governance down,
you've already made some of that shift.
You start to do that work and engage those teams,
it's not as big of a leap.
If you can't wait that long and you want to jump in right away,
then you can go straight there,
there are going to be some learning curves
and some growth patterns that you have to go through.
But ultimately, as you get through those growth patterns,
what you'll see is faster time to market,
less roadblocks, less blocks to production release,
because you've got those guardrails in place.
The more you automate governance,
the more development teams can understand what's expected of them,
the more they can even do things like run
a policy that tests for things that you're looking for,
so that they accidentally leave in something that
wouldn't pass governance, it's caught right away.
It's all about acceleration and getting
the market faster and doing so with less effort.
Now, that only matters if that's really important to you.
If you're in a highly regulated organization that's more concerned
with control and limits and security protections,
maybe the work trends aren't as high.
But when innovation's important to you,
deployment accelerations are a pretty important place to invest.
>> That sounds really good. If they
are investing in this deployment acceleration,
can they maintain shifting towards that?
Are there any indicators for them actually going on that journey?
Can they show how they're being successful?
How do they show they're actually doing deployment acceleration?
>> There's a number of key indicators and
there's actually tools to help with that as well.
If we look at the tool alignment,
a couple of the key tools that people use are Azure Blueprints,
Azure Policy, things like Grouping,
Tagging, Resource Management Templates.
I share the tools first because these are easy indicators.
Azure Advisor probably being the one that
stands out really heavily,
Azure Advisor provides notifications of
things that you could possibly do to turn your environment.
If you have a lot of Azure Advisor notifications,
maybe there are things that your missing,
and some learning opportunities.
Tracking and bringing down
the number of notifications from Advisor is
one great indicator that has
both deployment acceleration and operations management benefits.
Other things are the number of
environments that are governed by blueprints
or the number of policy audits that
pass without making any changes.
In particulars, Azure release in the production.
Ultimately the biggest one is how much of
the environmental configuration is
in a share repository like GitHub,
and how much that is used during the deployment cycles.
Those are all great indicators that
help determine growth in this particular discipline.
>> That sounds really good.
If people want to get started with deployment acceleration,
Brian, where can they go to get
some more information and get started on it?
>> This one, the disciplines in the Cloud Adoption Framework,
that's an easy place to start.
In particular, the disciplines that are outlined
are things around process integration,
which you can find right from
the overall corporate policy section
related to deployment acceleration.
There's also guidance there,
around how to engage and build
out CI/CD pipelines and infrastructure's code skills.
More directly, if you want to take action today,
the biggest action you can take is stand up,
GitHub or Azure DevOps repo,
to start centralizing and sharing those templates,
get those out to your end-users
or start working with Azure landing zones.
Because while they are about environmental readiness,
they each come with infrastructures code structures that you can
use to make it easier for people to
start looking at the world through these new lenses.
Finally, as you start to mature,
you might see things,
see opportunities to use service catalogs,
to take not just a single ARM template, but a whole solution,
and package it up so that it can be quickly and easily
deployed out to your internal customers.
Those are a couple of things that we outline in
the Cloud Adoption Framework that you can use as best practices.
There's also some things that we can show in
the Azure portal that you can start doing right away as well.
>> That'd be great.
>> Cool. Let's switch over to the portal
here and we'll do a little bit of demos.
We talked about using
Azure landing zones as one way to
get started with deployment acceleration.
If you look at the overall landing zone options,
we've got the CAF enterprise-scale landing zones
that you can use a variety of options for.
These give you a really rich Blueprint, Policy,
ARM template configurations that you can deploy out,
they take your really far down the path.
Something might be a little easier to start with is
something more like the Foundation blueprints,
and I'll demo that just a little bit here.
If you're looking for inspiration of what can we do with
deployment acceleration and infrastructures code,
and all of these capabilities.
Let's actually start with enterprise-scale architecture.
In enterprise-scale, there is
an architectural view that we've laid out,
that shows ways that you can structure,
how identity and access management is deployed.
How you manage identity in a separate subscription,
or management groups in one subscription,
with all the operational management capabilities,
or how you manage connectivity.
The reason this one is a good reference is because
this takes deployment acceleration to the next level.
Rather than saying we're going to write
an ARM template that can connect your network,
we're going to provide a dedicated subscription
that all it does is on-prem connectivity.
Now, the next time the development team says,
"I could really build this,
but I can't do it without getting
connection at that SQL Server on-prem."
They don't have to think about that,
they don't have to build that connectivity,
they just simply asked for a VNet peer between their environment.
Now, you give them a really simplistic ARM template that says,
"Add this to a Virtual Network,"
and now you've got that access that you need.
It's controlled and governed,
same thing with operations management.
Standing up an environment that
has operation management capabilities,
make sure that the development teams can build,
but not have to worry about whether or not they're deploying
all the tools that the operation team
is going to need later in the cycle.
Also give some insights into things like log analytics,
so that they can start to get queries and
alerts and other things about what they're building.
Those are the type of things that a development team
really values and prizes if you can give it to them ahead of time,
and create those guard rails or just general accelerations.
>> That sounds great.
>> Awesome. The enterprise-scale version is one way to do that.
If that's something that you want to build on your own,
a great starting point is to look at the more start small option,
that we have outlined and the CAF Foundation blueprint.
This blueprint, you can apply to any subscription,
and it starts purposely with a very small set
of policies and ARM templates that you can use,
you can add to that from there.
I'm going to search for things that are pretty common for
governance like tagging your cost center,
or enabling Azure Security Center
so that you can test for security.
Also put some parameters unlike allow
locations and allowed locations for resource groups,
so you end up with the resources in the right place.
This is a good starting point
because it makes it really easy for you
to add on things that are valuable to your developers.
Let's say you're working with a team that's building out,
lets say Data Lake Solution.
If we look at policy assignments and do a quick search for daily,
we can see there's a couple of Data Lake policies there already,
like diagnostic logs should be enabled in Data Lake Storage.
What this does by adding
that particular policy assignment and
applying this blueprint to a development environment.
Those developers now have your requirements for governance,
but they also have requirements to
setup the tools that you know they're going to need,
so they don't forget to add these things later.
These are examples of deployment acceleration,
working with the teams to get ahead of what they're going to need,
and using the tools that are available on
Azure to put those in place
automatically or with very little implementation
required from those workload teams.
>> That's awesome, Brian, thank you so
much for taking me through that
and clearing up what deployment acceleration was.
I really appreciate your time today.
If you want to check out some of
the resources that Brian has been mentioning today,
please do help our description box,
we will be dropping the links.
Remember to tune in for other episodes
of the Azure Enablement Show.
[MUSIC].