>> Hey everybody, stay tuned today where
I'm talking to Brian about how to manage
your cloud operations according to
the guidance within the Cloud Adoption Framework.
[MUSIC].
>> Welcome to the Azure Enablement Show.
In this show, we're having
technical conversations with Microsoft experts about some
of the common questions or obstacles that you may
face on your Cloud Adoption journey.
Now in previous episodes we covered what
the Cloud Adoption Framework is and how
it can accelerate your cloud adoption journey.
In today's episode, we're actually going to be
walking through how to you think about
your operations when you're in the cloud
according to some of the guidance
within the Cloud Adoption Framework.
To have that conversation with me,
I'm welcoming back Brian to the show.
Welcome to the show Brain.
>> Thank Sarah, thanks for having me back.
>> Awesome. Now, thinking about operations in the cloud Brain,
is there much difference from that
traditional IT operations that our customers are used to?
>> Like most things in the cloud, that depends.
You can replicate operations from on-prem to the cloud.
But a lot of customers look at the shift in this effort
to transform digitally as
an opportunity to transform operations as well.
Actually, it was slide that might
share a little bit about what that looks like.
Let's just switch over to the slide here
and what we see today is
that there is a bit of a paradigm shift that we see happening.
In traditional IT operations,
it's all about enforcement and control,
the central controlled responsibility.
But just like with cars,
IT has gotten smarter.
Cars now have GPS that help them navigate a little bit better.
Some of them are self-driving.
The role of IT shifts a little bit when
that happens and we focus more on
enable and support and really
creating freedom and delegated responsibility.
Now IT operations focuses more on how
do we put in the right infrastructure, the right guardrails,
the right controls so that people can drive about as they need and
really scale how much you can take
through those systems and those operations.
>> Now when I have heard people
talking about operations management,
I've heard them talk about the Cloud Center of Excellence, Brian.
Is that alluding to
the operating model that we talked about in previous episodes.
Where does that fit in this jigsaw puzzle?
>> Yeah, that's definitely a big part of
enabling this paradigm shift.
The paradigm shift in operations really equates
to a paradigm shift in organization.
In the classic IT world,
you would have your central IT standing between
the various different workload teams
and the data-center environment that want to deploy to.
What we see when we shift to
a Cloud Center of Excellence model is a little bit
less of that central control to where Cloud Adoption efforts,
or specifically over on the left, your workload teams,
they focus on really deploying to the cloud,
building out new innovations,
getting them out to the Cloud.
But to do that, you still need some of that central IT support.
Cloud Center of Excellence is a new way of
thinking of providing cloud governance,
really building out the cloud platform,
putting an automation and security controls so that
those workload teams can really
approach the adoption of different cloud solutions.
This comes in conjunction with making
sure that you are fulfilling your strategy.
But the biggest shift in all this,
and the reason why central IT can back out
a little bit is because there's a shift
in where cloud operations happens.
A lot of organizations that are taking
this Cloud Center of Excellence approach actually move
cloud operations out of IT and make
it more of its own standalone organization.
Or maybe it's still on inside of IT,
but it behaves a little bit differently and gets a lot more of
its funding from the line of business and workload teams.
What this causes is
a little bit of distinction in cloud operations works.
In a traditional world,
cloud operations would be shifted
way to the right and they're focused on
managing every workload inside
of a consistent platform using a baseline.
Now, there's a little bit more flexibility
and you may see that some parts of
cloud operations are more baseline platform operations focused.
Others are very workload focused and so that shift,
that flexibility is what enables
the paradigm shift that we're seeing in IT-Ops.
>> Now, I know in the past, Brian I've asked you about
some customer real scenarios that you can share along
the story line have you got
any stories that you could maybe share with
us in terms of how
other customers have dealt with operations in the cloud?
>> Yeah, absolutely. Just like with your strategy,
your motivations of what you want to do
is really important how you want to operate.
I was working with a very large bank,
I can't talk about publicly,
but they went through a number of
really visible security breaches like a lot of companies have.
For them, their strategy was all about keeping things safe.
They were more concerned with the security of
their customers than maintaining pace of innovation.
For them, this type of model didn't make a lot of sense.
They couldn't really quickly go to a Cloud Center of Excellence.
So for them Cloud operations were
shifted way to the right on the spectrum
and it was really
a central IT function and they still had those barriers in place.
Separate customer in the retail space,
they've had security issues in the past,
but they weren't as important anymore
because we've established good security parameters,
good governance guardrails, and now they start
looking to the future of saying how can we innovate quickly?
For this with this customer,
they decided to move more of their operations
way over to the left and become more of
a workload centric operations team and
focus on enabling innovation over protection and control.
Now, the reality is most of the customers I work
with aren't on either of these two extremes.
There's somewhere in the middle where they
have some parts of operations that are central,
some parts of operations that are
decentralized and that really helps them find the balance.
But we can share more of those stories
as we go through the conversation today.
>> Awesome. Thank you, Brian.
If an organization is actually looking to
get started with their operations in the Cloud,
where do they actually begin,
is that a set pattern for them to start with?
>> Yeah, just like
any transformation operations transformations takes time.
But we like to try to keep it as simple as we can and start
with a very easy step of just get a management baseline in place.
This makes sure that you have the minimum protections
that you need across all of the assets you have in the cloud.
But then from there, really building out
the right business commitments
and using those business commitments to expand
the management baseline and start to get into more of
those advanced operations and richer design principles.
This four step process gives you
a controllable path or plan that you can
follow to really evolve your IT operations in the cloud.
>> In terms of those business commitments,
is there any criteria
an organization can use to define them, that may help them?
>> For sure. When we look at
the Cloud Adoption Frameworks Manage Methodology,
that's actually what we start with is
the business commitments on the top here.
We'll oftentimes deploy that management baseline first.
But when we get into really using it,
we start to look at all of the workloads in
the portfolio as a holistic collection.
What we're doing is comparing those for
criticality to find out which ones are deemed
more critical by the business and this gives us
a relative value of where should we
prioritize investments and operations management.
Then we validate that with impact,
understanding what's the real time value metric
of any disruption to performance or downtime.
What that means is we're looking
at if this application is down for a few minutes,
does it cause a lot of money?
That banking scenario, for instance,
if they lost their core banking application,
money stops flowing and it costs millions of dollars.
If they lose the application that manages
their turnstiles in front of their doors,
maybe that's not as important.
So it doesn't need as much of an investment.
We use those type of metrics to really get fine-grained
on where do you want to make investments or
the returns which leads to the commitments?
This helps IT figure out,
are we paying for these operations?
Or are you paying for them
for anything that goes above and beyond the baseline?
>> Thinking about that baseline,
what is the actual goal of setting the baseline,
what's the purpose of that Brain.
>> Great question. When we look at the operations baseline,
we have to look at the holistic view of the portfolio.
Inside your portfolio, you probably have some of
those really important workloads that we talked
about up here on the upper right that need a lot.
They're going to have high SLAs.
They're going to have a lot of support.
Maybe you've got a dedicated operations teams,
but other things that you have may not need as much.
The operations baseline is designed to create a stable frame
for all of the things that you
have and find out what that's enough for.
In this operations baseline,
what we're really looking for is a couple of
key characteristics that we can
provide to all of those different assets.
>> Thinking about the baseline,
there's obviously a lot through that.
Could you maybe tell us a bit more what that actually looks like?
>> Yeah, definitely. When we look at the baseline,
it focuses on three primary areas.
For every single asset you have in the cloud,
we want to give you an inventory visibility
so that you can see what's going on and monitor.
We want to make sure that things are patched, tuned,
and optimized, so operational compliance.
We want to make sure that you've got
basic protections in place so that
everything can be recovered through some sort of BCDR plan.
Making sure that you have these three disciplines
really well-baked for every single asset that you own,
that's the principle of an operations baseline.
>> Thinking back to something you mentioned here a little,
and that's the SLA,
and I think we've probably all worked
in environments where there's
always a workload that maybe needs more than the minimum SLA,
rightly or wrongly, Brian.
What do you have to do if there's something that needs more
than the normal kind of SLA that you might have?
>> Yes. There's a couple of different options.
It really depends on what you really need from that,
and what you're trying to improve.
Like we talked about before, you could improve
those high profile workloads,
or you could see that maybe it's not
the end of the workloads that need the SLA.
Maybe it's that a collection of workloads with
a common tech platform dependency are what need the improved SLA.
Or maybe it's your operational requirements
are higher in a particular region.
Depending on where you need that improvement,
you've got a couple of different options there.
>> Awesome. Now, going back into the operations part of it.
If you need to improve operations for every workload,
what's the option for the customer?
>> Great question. That's what we refer
to as an enhanced baseline.
Those three pieces we talked about give you the foundation,
but what we commonly see in customer bases,
is that they need a little bit more
because that's just a generic baseline,
the way we've defined it today.
This enhanced baseline, commonly it's used to cover
a particular Azure region or subscription that needs more.
We'll also see people apply it to all of
their operations and enhance the entire baseline.
There's your both options there.
When you're doing something that impacts all assets evenly,
that's the enhanced baseline.
Things that we see there are
improvements like turning on service change tracking,
so you can see if there's changes to a service you've deployed.
Or things like ITSM integrations.
Maybe you've got an existing Ops management tool
that you use on-prem,
and you want to make sure that anything that
happens in this environment is reported back to that.
Or other things are things like
automating some degree of operations,
like if you have common behaviors that you see across everything.
Like if the server goes down,
I want to turn it back on,
or if this dev environment isn't
used for so long, I want to shut it off.
Those types of behaviors are things that you can generally
enhance and apply throughout your environment.
We call that an enhanced baseline.
>> Thinking to the Connect platform area,
what happens if you have to
improve operations for the same platform?
Thinking about, if SQL was the platform,
how do you improve all of that, Brian?
>> If we're looking at just this
upper quadrant platform operations,
that's another option for expanding the baseline where we
get really specialized in the platform itself.
What we'll see there are a number of different improvements that
you can make like improving
the general deployment or
the general environmental configuration for
that technology platform or following
best practices for deployment of the platform itself,
as well as a number of
operational practices specific to that platform.
The key thing to note here is we look at
platform specialization when we're centralizing that solution and
we're making it available to multiple workloads
to use a rising tide to float all those boats up.
But it's really just focusing on
that one critical dependency they all share,
the technology platform like SQL,
WVD, AKS, those sort of things.
>> In terms of the baseline,
are there any scenarios where you may have to
go above that baseline,
that minimum viable product, Brian?
>> Totally. Yeah, we see that all the time.
It could be that you're enhancing
the whole thing and that's how you go above.
It could be the platform or it could be that it
is more of that workload specialization that you need.
When we're in this quadrant over here,
this is when you have to get really close to the architecture.
You need people that know the workload
and can re-architect how the workload itself operates.
We have a complementary framework that works in
conjunction with this methodology
called the Well-Architected Framework.
When we make that scope shift from all of
the things we own to this one thing that's really important,
that's when we switch over to
the Well-Architected Framework as a central source of guidance.
You'll see the same principles,
the same type of things that we talk about,
but at a different scope, different elevation,
and then that allows you to go
deeper on the needs of a specific workload,
including a Well-Architected Review that you can
use to really evaluate that workload and
find different ways that you can improve that SLA,
and provide operational excellence for that workload itself.
>> Just going back to some of the customer scenarios I've had.
There's often been a workload that's super specialized, Brian,
and probably goes beyond even that extended baseline that
you mentioned earlier on and start right in the Cloud.
Is there scenarios there where we have to
go even beyond that baseline?
>> There always are.
The scenarios we see are ones like we mentioned earlier,
like inside of a bank, your banking application
is one that you can't make mistakes on.
You've got to do it right,
and you've got to get that workload level to really have
the right degree of operations to support those workloads.
That doesn't change in the Cloud.
Now, we have more automated tools to handle
the other things like the basic workloads that you have out there.
But any of these special workloads that are
mission-critical, they're extremely costly.
Maybe they have more sensitive information
than other workloads do.
Any of those type of workloads,
those are the ones that we want to use
that Well-Architected Framework for.
Whether you are on-prem or in the Cloud,
those are always there and you can't get away from them.
>> That's awesome, Brian. One last question.
Where would our customers go to get more information?
Where can they go to get started?
>> The key starting point for this is inside of
the Cloud Adoption Framework and the manage methodology.
We have an overview there that'll walk you through
these four steps and help make them actionable.
Starting with one that gives you a best practice
for implementing your own operations baseline.
>> Awesome. Thank you so much for your time today,
Brian, in walking me through this.
Thank you to everybody that's tuned in to the show.
We'll be sharing more information
and links in the description box.
Be sure to check that out and stay tuned for
future episodes of the Azure Enablement show.
[MUSIC]