>> Hey everybody, stay tuned today when I'm talking to Brian and
Jeff about the technical considerations
that you need to think about,
within your cloud adoption strategy.
[MUSIC].
>> Welcome to the Azure Enablement Show.
Where we're having technical conversations with Microsoft experts,
about some of the questions or concerns that you might
have with your cloud adoption journey.
Now in previous episodes,
we talked about how the Cloud Adoption Framework can
really help you accelerate that cloud adoption journey.
Today's episode is focusing on the strategy piece,
and the technical considerations that you need to
think about when executing your strategy.
Now I have two guests with me today.
I have Brian and a half Jeff with me.
However, my first question is for Brian and thank you,
for being on the show again with me, Brian.
What I want to ask you is about the technical considerations
that organizations have to think about
when they're embarking on their strategy journey.
>> When we think about the Cloud Adoption strategy as a whole,
there's a lot of different things
that you might want to accomplish.
All of those different objectives
they have come with different learning curves.
Most of those learning curves by themselves are small.
But when you're trying to accomplish
a large digital transformation,
those learning curves add up and they take time.
They also require proper timing for
stakeholder alignment to analyze data,
really validate the decisions you're making,
and get the people the processes and
the technology aligned to really drive that transformation.
Even when you are doing really well with your
adoption efforts planning takes a little bit of time,
and it runs in parallel to what you're doing.
It's important to notice that there's a big difference between
your Cloud adoption plan and your Cloud adoption strategy.
If you have that well-defined strategy,
it's going to help really figure out
how to guide the implementation,
and really guide the things you need to learn as you go.
It all starts with
a good understanding of technical considerations.
>> Are there any benefits of running
your first adoption process in
parallel with the development of your plan at all?
>> Definitely. There's quite a few benefits actually.
When we approach Cloud Adoption with a growth mindset,
one of the biggest things we think about
is learning and exploration.
With each of those,
what we're trying to do is create situations where the team
can go and do things that will contribute to your end goal.
But knowing that they're going to have to build skills,
and by taking a first adoption project approach,
we set them up to really get those skills to collaborate,
identifying gaps in our plan,
and really build the right degrees of partnerships that they
need to really validate the plan and be successful longer-term.
>> That seems great.
In terms of practical examples,
they're great for first projects and
the expectations to have of those first projects easily defined?
>> Yeah, and this is where the strategy
and the plans start to co-mingle a little bit.
You have to understand what your motivations
are to pick the right first project.
An example of that is let's say
that your overall plan as long-term,
you want to get into really deep digital innovation and big data.
You probably don't need to focus as much
on infrastructure for your first project,
is probably more about how do I move my data.
But if your real objective is you want to get
out of a datacenter and modernize IT operations,
well then you have to start with
a different set of first projects.
Maybe it's building a network and migrating
a workload or two so that you can
really see what migration looks like.
Or if you're just trying to add reliability,
and dependency, and the overall IT operations,
then maybe your first project is something simpler,
like using Azure Site Recovery to
recover some systems that you have on-prem into the Cloud.
It really depends on what you want to get out of it,
and knowing your objectives helps you really define that strategy,
aligned to the motivations that you have,
and choose a project that's going to help you move forth
right direction and learn the skills that you really need.
>> That's great. Thank you Brian.
It's definitely making me think about that
different motivations have different first projects,
which leads me in circulation I want to ask Jeff if that's okay,
if we can bring Jeff on,
and Jeff, welcome to the show firstly.
Thank you for your time, the question is,
can you help me understand the differences between
the on-premises motivations versus
the Cloud motivations that we have?
>> Absolutely. A great question,
and first, just a quick.
Hi, my name is Jeff Amels,
I'm a Senior Business Planner on the Microsoft Corporate,
but I tend to classify myself as
a datacenter architect that likes to do his own taxes.
Now, your question, the basic differences between like
on-premise and how we think about Cloud Adoption.
It's a fundamental shift on how
we look at the workload modernization.
There's some very basic differences between
on-premise and how you think about the Cloud,
both from a technical and financial standpoint.
Like historically,
on-premise servers when we thought about like refreshing
our workloads and building out that
infrastructure to support what the business units are requesting.
We typically focused on buying servers for
the worst-case scenario within a term,
like a financial term or a business cycle, if you will.
We're buying gear for those peculization periods.
Now, the downside to that is your systems,
the book at the time are under-utilized.
These business cycles of utilization
fluctuate depending on like industry verticals.
For example, in the retail industry vertical,
you have four to six spikes per year of utilization where
your datacenter resources are at their max capacity.
While the rest of the time, they're completely underutilized,
sometimes at 30 percent or 20-30 percent of utilization,
and even with the core allocations,
now the Cloud shifts models towards dynamic allocation of
capacity versus static allocation of capacity.
When you think about that,
you start architecting your solutions a little bit differently,
and that really comes into three different categories.
One, infrastructure as a service. Second, platform as a service.
Third, software as a service.
Now, starting with that infrastructure as a service component,
that's where we're really catering
to the compute that we're used to,
that unit level compute of
resource allocation at the core and memory footprint level,
as well as how that maps to virtual machines,
and how they leverage those resources as well as storage.
When we think about that Platform as a Service level,
you're getting more value out of every dollar of investment,
because you're no longer concerned about
the underlying compute managing
the Operating System and those type of
resources and physical transports for example.
You're not dealing with those underlying components,
but you're really focused at a particular workload.
You're paying for specific services like,
database platforms or analytics
platforms that are delivered directly.
Without that overall operational overhead or
underlying resources that you have to manage.
Then you start thinking about a Software as a Service layers,
where you're getting the most value
out of every dollar of investment.
But it's somewhere managed experience,
and it's encapsulated experience
around common services like e-mail systems,
file-sharing teams, and communications types of services.
As you work through those layers,
you are getting more value out of
every dollar of investment over time,
and a lot of time they classify it as
modernizing your workloads through phases.
That's a great way to classify that.
>> Awesome. Thank you Jeff,
in terms of trying to translate the workloads that
our customers have when they're investing in environment,
and moving into the Cloud, how does that work?
How else can they do them?
>> Excellent question.
A great concept to keep in mind is how you
provision or spin up resources as well as equally important,
how you de-provision resources,
and how that influences
your overall budgetary allocation
and how you're using your budgets.
Then you know that cashflow to support those particular workloads.
The nice thing about the Cloud,
is that you're able to deploy resources very rapidly.
As well and equally important,
keeping in mind that you can
de-provision those resources very rapidly.
Your cash-flow to support those workloads, to support them.
In those particular scenarios can fluctuate depending on demand.
I call this concepts as like a fail-fast type of model.
For example, a business unit has
a request to IT to provision a resource.
It doesn't work out, so maybe they
de-provision those resources, hence,
concurrently the cashflow as well
that you can provision to a new type of deployment.
It's very dynamic versus the historic like
static resource allocation that we're used to, historically in IT.
So you're not stuck with
that budgetary allocation for a longer period of time,
you could shift as it's required.
Both based off at success and failure of the deployment,
or based off overall demand and utilization.
Now, another thing to keep in mind and
something that we're seeing more and more of,
is more modular components making up
an overall application that you're delivering to a business unit.
For example, you can have encapsulated
business logic within an Azure formula or function,
versus having multiple roles on one single compute unit or VM.
Because historically were used to deploying a VM,
it's run unlike sequence and
business logic and maybe a one web front end,
all in one instance.
But we're seeing more of a breakout
of those components so they could be
modularized and some pieces being at the highest level,
and some components being at those Platform as a Service levels.
When we're thinking about architecting
a solution that's hosted in a Cloud,
certainly start thinking about those modular pieces.
Because they also map to native Cloud billing models,
and those offering constructs
that are available from Cloud providers.
For example, you might have
a pre-existing investment in
your licensing infrastructure on-premise,
those Windows licensing, and SQL licensing.
You want to be able to leverage those to the fullest extent,
and you can use like the Azure Hybrid Benefit that gives you
that license portability to not just use that license on-premise,
but also in the Cloud both at the highest level and even
in through my Managed SQL instances at the pass level.
Certainly something to consider at the long term.
Then also for those compute instances that are
long running instances start thinking about longer-term commits,
like reserved instance pricing and whatnot that really
play into a lower price point per compute hour,
for those production level systems.
Then those systems that may have high resource allocation,
like a high number of cores and memory,
we can only need them for a short amount of time.
There's also offering constructs like spot level pricing,
that has a much lower price point per compute hour,
but really are leveraged in a short amount of time,
for those quick batch level processes
that are high resource utilization,
but you want to pay a low price point for.
>> Now earlier you talked
about the Cloud chase the model away from
the static allocation to like dynamic allocation of resources,
and that's a big driver for our customers choosing the Cloud.
How does that change the main setting and being able to
operate with that elasticity that they now have in the Cloud?
>> Great question.
As you're looking at moving those workloads of Cloud,
you might start classifying some of
the different behaviors of
those particular workloads or computing hour.
It's like, for example,
you may have a production systems that are
those long running instances that need to be up 24 hours a day,
seven days a week, 365 days a year.
When we're building out, like models and
projecting out cost and an architectural changes.
We may classify those particular production long-running instances
in a reserved instance scenario
where we're doing long-term commits,
we're getting like a lower price point.
That could be a subset of your overall footprint.
Now there are going to be
other particular nodes that are serving up
an application to the business unit that might
have spikiness in utilization throughout a term.
We'll start looking at those,
and looking at their behavioral up times,
and classifying those as page go scenarios.
Because you don't need those up 24-hours days,
seven days a week, 365 days a year.
They may have different percentage up times
within a monthly period or within a financial term.
You're not paying for the actual downtime of those units.
Then as we do datacenter analysis and map those to Cloud targets,
we always see additional nodes that are no longer required,
so we can actually deprecate those nodes.
You don't need to move those to Cloud, they're not utilized.
That's immediate savings, or within that same exercise,
we'll look at the actual utilization of the core assignment,
some memory footprint, and right-size
those depending on the overall utilization and that's discovered.
I classify the thinking and
approach that as a peeling the onion exercise,
we would start with those long-running computes which put them in
the best cost classification
as possible as you're moving them to the workload.
Then looking to the Cloud and then start
looking at the other workloads and the behaviors of them,
with respect to percentage up times,
and placement, and applying the right cost structures for those.
>> Awesome. Thank you so much, Jeff, for your team.
Actually, thank you both for your time today.
I really do appreciate the time that you've taken
to talk me through technical considerations,
for that Cloud Adoption Strategy.
Now, thank you to all our viewers
and please do check out the description
for more resources about what the boys have both talked about,
and we'll look forward to seeing you in
future episodes of the Azure Enablement Show.
[MUSIC].