>>Let's talk about scaling up
and scaling out with cloud.
Pierre, what do you see today with public cloud?
>>Well, there's different adoption patterns for the cloud.
There are some that are scaling out
to the cloud for resiliency
and there are some that are scaling out to the cloud
for availability and growth.
There are some that are moving to the cloud
because they're losing their on-prem data center,
maybe they've acquired a company,
and they don't want to use both data centers,
so they want to consolidate.
And there are some that are just going to cloud
because it's a new company, it's a new initiative,
and instead of building it on-prem and then moving
it to the cloud at a later date, they decided to just
move it to or build it on the cloud right away.
>>Do you see specific types of workloads
working better in the cloud vs. on-prem?
>>Yes, there are a number of segments
that work better in the cloud.
So anything that is stakeholder focused,
so if your audience is out in the wild, then doing cloud
because you can reach multi geography,
you can reach stakeholders wherever they are
and provide them the best experience in terms of latency.
So if they're in Europe, they're gonna hit a data center in
Europe. If they're in North America, they're going to hit
a data center in North America.
So if it's outward facing, then it's best in the cloud.
If it's internal facing, then you have to ask yourself
is it internal facing in one location,
is it internal facing in multiple location,
if you're moving applications into the cloud
and you want to take advantage of scaling and growth,
is the application you're moving into the cloud built
to support multi instance and dynamic growth
and dynamic scaling out then scaling in?
So, these are all discussions
that you really have to have
with your management and with your developer
and the owners of this application,
because you could really paint yourself into a corner
if you're taking the wrong approach
based on the application you're trying to move to the cloud.
>>Got it.
Do you happen to see verticals that are more inclined
to adopt cloud vs. others?
>>Our commercial, number one, is more inclined
to go to the cloud mostly
because they have less of a compliance issue with cloud.
So if you're looking at Government, or healthcare,
or financial now there's some added compliance issues
that they need to consult with their lawyers
and their legal departments in order to figure out
what they need to do in order to get to the cloud
because of course, the cloud
has got all the compliance requirements.
However, the tools are there, it's whether or not
you apply them to your own deployment.
So those ones are a little slower, but they are still,
they're very big so they are looking at it.
So anybody that wants to have competitive
advantage goes to the cloud.
New companies don't invest in on-prem as much
because they see the benefits of the economies of scales
that you can get by building directly on the cloud.
Commercial because of the fact that
you can reach your audience so much quicker
is adopting the cloud very, very quickly.
>>Okay, that makes sense and so you know,
if I go back many years, you know I think back to
when virtualization first came out when you had
VMware, Hyper-V, and you know, everybody was like
oh no I'm not gonna give up my physical servers--
>>It's working just fine, I'm never gonna move that up.
>>Exactly, and so, you know, give it a few years and
you have most workloads are virtualized
and I think we've seen kind of the similar type
of behavior in trend with cloud.
You know initially it was typically
more of the larger enterprises
or like you said kind of the organizations
that were cloud first,
you know that were early adopters and the rest of the folks
were like, "well I've already got such an investment
in my data center" or "no I just prefer
because you know as an IT engineer,
is the cloud gonna take my job away?
Is that something I have to worry about?"
And I think as people got over those concerns and fears,
and saw all the greatness that cloud can provide
and bring to the table,
that more folks are starting to become much more open minded
to it and we're seeing it become much more mainstream.
>>Well if you're worried about "is the cloud
gonna take my job away,"
which is a completely separate discussion,
if your only job is to rack servers, then maybe.
Anything else you'll adapt because networking,
you still have to be able to manage your networking,
monitor it, scale it properly, your VM's, your IaaS,
your PaaS, your security, your identity,
all of that still needs to be managed
and still needs to be managed by IT professionals.
>>Exactly, and even though there's somebody
that's actually making sure that the equipment
is plugged in and racked and all that good stuff
in the data center, in the cloud's data center,
you still have to monitor it
and so there's still a lot of the similar challenges
and types of work that you do on-prem
that you still have to do in the cloud.
>>Absolutely.
>>So you talked about how every work load is not
truly prime for the cloud, some should remain on-prem.
So data centers aren't going away.
>>Not any time soon.
>>Yeah, exactly so maybe in the future
but not any time soon and so with that, the case,
as we talked about, cloud
is now becoming more main stream and more of the norm
and so with that being the case,
what type of challenges do you see typically
in working with customers as they start to kind of
the migration and transition to the cloud journey?
>>Well, in terms of migration
is picking the right application as we talked about already,
to move to the cloud.
Some companies are always gonna have their crown jewel
that is not gonna see the cloud
mostly because it's either sensitive, compliance,
or many other reasons where those applications
are not gonna go to the cloud.
So they still have to manage that.
So now they end up with, in a lot of cases,
dealing with deciding within, "do I have two separate
sets of tools to manage my growth, my scale,
one for the cloud and one for on-prem?"
How do you turn your mindset to start using,
even if sometimes you have to leave the tools
that your using on-prem, to adopt something
that will do both on-prem and in cloud so that you get
the benefits of, for example like Azure Monitor
where you can monitor all the VM's that are in your cloud,
but also you can monitor all of the telemetry
and performance metrics from your machines that are on-prem.
So there's a shift in how you're using the tools,
what tools you're using, how you build it in your mind
as to connecting those two environments together
so they actually work together well.
Are you connecting multiple data centers to the cloud
using express route, using site-to-site VPN,
or are you completely disconnected and just doing
point-to-site VPN when needed?
These are all questions that you need to answer
before you start scaling up to the cloud.
Once you get in the cloud,
again, not every application is going to be a good candidate
to scale out for growth.
If you have an application that doesn't work,
and you scale to multiple instances,
well maybe those instances are going to
conflict with each other
when they're talking to the back end.
Where do you want the back end?
Do you want the back end as a PaaS,
which is a little cheaper,
easier to manage because you don't have to worry
about the infrastructure underneath?
Do you want it on a VM in Azure or do you want it in a VM
or on a physical machine inside your own data center
because of threats or because of compliance?
There's all these questions.
So you need to understand very, very deeply
how your own line of business application,
commercial application, whatever they are, workloads,
all those workloads, how they work together,
how they're worked within each workload,
and how you can optimize it properly.
And then once you've got that inventory and you figure out
what are the low hanging fruit
that you can move to the cloud,
then you can start the migration of application.
On the other end, the cloud,
even though if you don't move any applications
which is possible in some environments.
Well there are some cloud services that will allow you to
have some benefits on-prem, back up, patching, monitoring,
all these things where you don't have to deploy
your own infrastructure to support that service
because that service is now being optimized for you.
>>Exactly.
>>So there's low hanging fruits,
there's applications that will move very easily,
there's applications that will move
a little bit more slowly.
It's all a matter of how well
you understand your own environment.
>>The infrastructure and the application and what are all
the pieces and components that make it up.
>>Absolutely and all of that works together,
it's like a giant puzzle with the squiggly edges,
you have to make sure that all the pieces fit well together.
>>Yeah it sounds like a lot of it has to deal with planning.
You know, understanding what you have in your environment,
and then like you said kind of targeting,
okay these are the workloads
that make the most sense to move over,
let's figure out how we're going to phase that
and actually make that a reality.
>>And moving a workload up to the cloud,
if you're moving something from VM to VM,
some VM to IaaS infrastructure as a service,
you may not see the financial benefits
that a lot of the marketing tells you.
>>Okay.
>>Because that's step one,
because at that point you're basically
hosting that application in a cloud service.
There are some availability benefits to it,
but you're really not using native cloud solutions.
So they won't automatically scale easily.
>>You can optimize it further then.
>>But then that's like step one,
move it because maybe you're losing your data center,
maybe something else.
There might be other drivers that are pushing you
to move that application there.
And then, once it's there, then you start modernizing it.
So go from Apache or IIS web server to a web app,
so now you don't have to worry about patching that machine,
monitoring that machine.
Now you just have to worry about the application.
Your data base can still be on the VM,
it can still be on-prem,
it's just a matter of switching the connection string.
>>Yeah.
>>So, you move one piece at a time.
If you try to move too much at the same time,
then you pinch yourself into a corner
and then you're all gonna have a hard time
getting to where you want to go.
>>Got it.
>>So, understanding what you're moving,
or what you want to move,
how it fits within the greater environment,
and what makes sense at the time,
and of course it always has to have a business value.
If you're just moving to the cloud
because you think it's cool and you want to be trendy,
great however, that's not gonna give you the ROI
that you're looking for.
>>Exactly, so you already talked about hybrid a little bit
and specific workloads that make sense to be in the cloud
and the back end for example being on-prem and so,
when you talk about hybrids specifically;
you know, what about in the scenario where,
let's say finance application
and it's at the end of the month
is when you need really the horsepower
in order to crunch all the numbers
and do all the aggregation but you don't need it
the rest of the month,
how do you handle that in that situation?
>>Well, scale or usage typically is in cycles.
The same scenario at the end of the month,
or at the end of the quarter where it used to be
well you're an accounting department,
you're not allowed to do any work for the next three days
because we need to be crunching numbers.
So you have this on-prem, this massive infrastructure
of hardware and software that is designed for that peak
but for most of the month is not being utilized,
so you're paying for something you're not using.
>>Yeah, you over invested.
>>Yeah, so if you move that to the cloud for example,
within a maintenance window before
that crunch happens, you can easily scale up that VM,
so take that VM, shut it down,
assign a larger family of VM, so more cores, more memory,
more horsepower to that VM, spin it back up,
run through your crunch, which instead of being
three days might end up being overnight,
and then the next morning, you shut it back down,
you bring it back down to a regular size VM,
and then you spin it back up so it's usable all month.
But then you can have access to the horsepower
when you need it.
That is if that application can't scale out,
so that's what we call scaling up, adding more resources
to an existing machine, that's scaling up.
Scaling out is if that application actually is
multi-instance aware. That's what I was talking about
earlier, was be very conscious of how your
application behaves and how it runs.
Now if it supports multi instance,
then you can dynamically grow it.
Meaning when it hits a certain level whether it's CPU,
whether it's memory, whether it's network,
there's all kinds of different metrics that you can monitor.
When you hit a certain threshold,
then increase it by two instance,
and if the threshold keeps going up
or the usage keeps going up, then you add two more instance.
So you can start with two instances,
so two is always a good number,
not one actually is the best number,
so you don't have a single point of failure.
And then you can grow to four or six, eight, 10, 20, 100
to take advantage of the load that you're doing
but when it's done, then those instances are being shed.
So you're only paying for the horsepower you need,
when you need it.
>>Got it.
>>So, that's what we call scaling out.
>>Okay.
>>It's a lot easier to scale out and scale in
when the application is built for it,
when it's in a PaaS situation for example,
if you're doing that in an IaaS situation infrastructure,
so if you're doing that with VM, that means you have to
install your application on a VM,
make sure that VM is now generalized
and you capture an image, and then you deploy it
in a scale set.
>>Yep.
>>So when you need a new instance, it'll copy the image,
spin up a new image, but it takes longer.
So it's longer to ramp up, it's longer to ramp back down.
But you end up with the same in the end results
but with a lot more management headaches.
>>Yeah it's not as elastic.
>>It's not as elastic, it's still possible
but with a lot more thought into it
and a lot more processes built in to it.
Plus, if you're scaling out VM's now you have to
start managing and monitoring more VM's.
>>Exactly.
>>So it all comes down to that life cycle,
application life cycle wheel where you deploy,
you monitor, you adapt, and then you redesign,
and then you deploy, you monitor, you adapt, and so on.
>>So we talked a little earlier about monitoring
and whether you have infrastructure on-premises
or it's in the cloud.
You know you can actually deploy a monitoring solution
for your on-prem and a monitoring solution
for your cloud, or look for one that does both.
But when you're actually moving workloads from on-prem
to the cloud, whether it's full or it's in a hybrid fashion,
you know you want to make sure
that you can actually measure it and prove to the business
and your users that it had the desired impact
whether it be better performance,
or better throughput in response time,
but how do you measure that effectively?
>>Well, first of all, I'm a huge fan of
a single pane of glass to measure everything.
So if your existing tool doesn't see the cloud
for example, then you gotta look at something
that will compliment that.
Because you don't wanna have any dark spots.
That's number one.
Number two is once you move an application
and it starts measuring,
you gotta start by knowing exactly
what you're gonna be measuring to make sure
that it actually meets your requirements.
So if you're measuring latency,
where are you measuring the latency?
Are you measuring it at the application gateway?
Are you measuring it at the server?
Are you measuring it at the database in terms
at the end of the transaction?
Are you measuring for the benefits of
the stakeholder that's connecting and using your service?
Or are you measuring for internal to make sure that the
inside of your application is working correctly?
So that's a decision that has to be made.
And then your monitoring solution will have to be designed
to meet what that expected threshold is.
That being said, your application
when you're looking at the cloud for example,
we have all telemetry for all of the resources
that you have in the cloud, it's all available to you,
it's how you consume it.
If you're scaling out then scaling in based
on the certain metrics that you're not measuring correctly
then your scale out and scale in is not gonna represent
what you want to actually happen.
If your tool has a blind spot and you don't see it,
again you're going to not have the performance,
or not have the end results that you're looking for.
So it's very important to pick a tool that measures
what's important to you and you have to decide
what's important to you with a clear vision as to
what you're measuring it for.
Is it for the stake holder at the other end,
or is it for internal usage of these resources
that you have?
So there are many, and is 80% CPU usage
what you were gunning for or is it 60?
Because if you're scaling in and out at 60,
then that means that at any given time
you're basically throwing away 40% of the compute power
you are using.
So that monitoring is very, very important
but it's only there to drive what your end results
want to be.
>>Got it.
So, one of the things that I kind of take away
from this conversation today is that
planning is critical to do upfront.
Understanding what applications you have first,
and then you know how those applications
are built and architected.
Are they something that is actually ripe
and prime to actually move to the cloud
and take advantage of those cloud services that are
available whether it's platform or infrastructure?
You know, having a clear understanding
and visibility into that is something that's important.
>>It's really key to understand what you have,
where you want it, and how you measure success.
That dictates the approach you're gonna take,
how you're gonna measure it,
what you're gonna measure, at which point
and it basically opens the door that once you're successful
on one workload it can start looking at the other workload.
What is the next low hanging fruit?
So, it's really, I'm really glad that point came across.
>>Yeah, so at the end of the day,
I mean the reality is that there's no silver bullet
when it comes to migrating to the cloud.
>>There really isn't.
>>So again, it's been enlightening and great
to have a cloud expert such as yourself,
Pierre here to kind of talk with folks about
the challenges and
what you take into consideration
as you start to scale up and scale out with the cloud.
>>Yeah and thank you for having me,
it's really great to work with partners
that ensure basically the success of all.