Welcome to another episode of Azure
Mythbusters. My name is Chris Reddington,
and I'm from the fast track for Azure team. My name is Will Eastbury, and I'm also from the
fast track for Azure team. So, Will
today we're going to be busting the myth
of cloud as expensive; talk me through it.
Okay so expensive being in inverted
commas but the question is when you're
going to migrate a workload to the cloud
or build a new cloud native workload
it's largely around this confusion
around how people would want to cost
something how you can estimate things
against on-premise and actually the fact
that a lot of people begin to oversize
or mis-provision resources. It leads to a common perception that actually
let's keep it premise because actually
we've already paid for this.
So the fact we're building in cloud there's this kind of new dimension and potentially new rules
and different way of thinking. Yeah it's
it's kind of like the scenario if you
just to give a quick preamble of leasing
a car right if you already own the car
then leasing the car is going to
seem expensive to you immediately right
not when you factor in maintenance costs
and you factor in taxes and etc actually
sometimes it can work out cheaper to go
and buy a smaller car on the lease deal
and sell your existing one. So do you want
to kind of look through what kind of
things we might have? So the
first thing that gets blown out the
water when we start to look at these
myths is around actually a lot of people
are unsure what they're architecting for
and if you look at so what we've got up
on the screen here is simply our five
pillars of software quality and you'll
find that all over our documentation and
all over the things that we do day in day out.
What you won't see in this
current list of five aspects of
scalability, your availability etc is
cost yes so actually cost is a
consideration around your requirements
absolutely and we've done we've done a
previous episode on requirements as well
and I think all of this is on the Azure
architecture centre as well, so
definitely a good resource to go into
absolutely and one of the things
when we look at requirements for cost
design you know where do you start
actually what what is a cost design
process so the first thing is you
must have an idea of what you
intend to spend on a solution or what cost
profile it needs to sit in and it
comes in a couple of ways and we've got
the three of them illustrated here so
you know do I have a fixed budget of a
thousand pounds or dollars, or not
do I want to spend X, do I have a fixed
budget of, I want to spend X per visitor
or per impression, or per banner ad that
I've surfed, you know it could be a micro
charging scenario, or is cost not you
know or not a number if you're a Java dev
but that that one at the
bottom is the really important one to
get to the bottom of when somebody says
that they have no idea what the solution
should cost. A dangerous place. That's
normally a big red flag.
It's quite interesting because you know you've got there having that fixed layer but also
that you know per user per call per
whatever and that's an interesting way
of thinking as well and I guess would
have quite an impact on how you operate
and what options you choose in the cloud
right yeah absolutely and more often
than not when you actually design a
system to operate on a given cost
envelope you actually have to factor in
both so there are both fixed cost
and variable costs if you ever see
anybody writing a business plan when
they estimate cost they'll have both of
those in there, designing systems
whether it's in the cloud or on-premise
is no different. I guess one of the
main differences between something like
on-premises in the cloud is that
on-premise it's a little harder to
switch things off right whereas in cloud
you can probably go ahead and turn
things off when you don't need them, maybe
scale down when you don't need them. Totally, so that's the first
challenge is on-premises I've paid for
some hardware I'm depreciating it x y&z
it's happening I've paid for it
whether it's on/off or indifferent apart
from power and cooling. You don't
tend to see people spin down their
server estates overnight in on-premise. It's common in cloud like why
would you want to pay for something
which is just not being used you know
aside from the environmental aspect of
it generating heat and requiring cooling
and taking power actually are you really
running this stuff 24 by 7 by 365 or
actually do you only have maximum of
five percent of your users accessing the
service overnight. And this is a really
interesting idea because again it really
comes back to those requirements you
know; are you an application
where you focus in one region and you
work
9 to 5 let's say or you in this global
system where maybe you need to have
different deployments across the world
and some of those are online at certain
times some of those are offline in certain times. Exactly or maybe they're
spun down to a minimum capacity right
before, we've talked about auto scaling,
auto scaling to the peak of a workload
but scale down to a minimal bare-bones
the one guy might be up at 3 o'clock in
the morning happening to work on
something because it's just you're
pulling a late all-nighter but that
person is the only person working in
that region on the system at that time
don't keep an entire estate of
servers up for that just keep the one available.
And this is where that
holistic picture from operational
perspective things like metrics and
being able to start bringing that whole
system together you know if you start
seeing an influx of scale
you've got auto scale there it can react
to that it's not like you need to have
that you know top level there as you say
so a great example of that is there are
certain circumstances where you'll also
know in advance the system needs to scale
you know we've worked with certain
customers who are potentially running
online services which have a large
amount of traffic driven from TV
advertising, so you know when your
advert comes on, they know their adverts
coming on at this period of time and
they can prescale a service up in advance to know
they're going to hit it and so they can make sure that they
don't waste the resources when they know
the services is not going to be required.
Another great example I guess
would be those scenarios where there's this
kind of big event coming up so something
like Black Friday for example,
it's predictable, retailers over here they can
have a huge following of load coming in
but they don't want to operate at that
level every day because that's gonna be
a lot of cost wasted. I have to be
honest a little piece of me dies inside
every single time I hear of some of the
issues that customers experience on
Black Friday where they're throttling
people coming on to the site you know
they haven't just scaled of the services
in advance and added some auto scale
capacity to take the strain. In a modern
cloud world there is no real reason to
not have that availability and
performance headroom on demand
it's there that's what cloud's all about.
Which actually brings us neatly to that
point right so using auto scaling is
critical I mean I don't understand why
when you've got the I can just drag this
to the right and give myself more server
headroom why you would not choose to use that. There are probably 1% of apps we
see that can't. I guess there's a
there's an element there at that upfront
planning in terms of you know is our
application workload spiky is it quite
flat and whether you actually need to
have that because that kind of decision
really then determines which Azure
services you can pick and how it
influences their overall solution.
Absolutely, so this is where we kind of
loop back to the architecture and design
discussion that we were talking about in
the first episode, you know so choosing
that right abstraction is absolutely
critical, if you pick the wrong abstraction you're
going to get the wrong scaling envelope
you're probably going to get the wrong
cost envelope, if your cost envelope
is fixed and you'd rather that the
service degrades and slows down instead
of actually servicing more users because
you've got a fixed budget then you're
probably going to be choosing bare metal
IaaS/ fixed PaaS options but
you've got a fixed box you know it's
going to cost that and exactly that
regardless of what happens if you want
it to be more scalable than auto-scale
PaaS and serverless and SaaS options that
charge per transaction potentially you
know if you're a big online retailer on
Black Friday and you want to make
your service just scale limitlessly so
you can take as many transactions as you
possibly can, serverless is perfect
because it will just scale out
limitlessly and eventually your
warehouse, you'll need a bigger warehouse
to ship it, not a bigger service.
That's a good problem to have! Absolutely and that's what we're starting to see with
some of the more modern cloud
architectures that retailers begin to
put in place and some of the etailers.
But it's interesting you know all the
way through this discussion we started
off with cost being that extra pillar of
the requirement and you can see that
shining through what we just talked
about. It's a key consideration in
your architecture and this is one of the
reasons why you end up with that
perception
okay well it's expensive right it really
isn't, we could design architectures
for you if they're not being used cost
near zero.
You know with with serverless
platform features but people don't tend
to think about it like that because
they're coming in and they're not used
to that scenario they're not used to the
architectural constraints and design
choices that you can make to
cost and that's one of the things where
you have to just choose that correct
service and lock it into the solution
that you actually want to try and build
as though as a sixth pillar really.
So what else do we have here
you've got also got
understanding those hidden costs, you
know there's a ton of cost which we just don't see.
So the things we've
talked about in one of the prior
episodes of maintenance which gets
hidden away. Choosing an IaaS
infrastructure is, it adds some
maintenance costs. That halo
effect because of the impact of the
decision they've made you suddenly get
all these other things you need to start
thinking about from a management
perspective and now you take those on.
Absolutely, and going after a cloud
versus not cloud decision rather than
necessarily IaaS versus PaaS also
brings another understanding costs are
things like hardware maintenance, air
conditioning, power, access control,
security, all of those kind of aspects
network bandwidth, connectivity, you know
routers, double connectivity
circuits all that kind of stuff is
actually factored into the cost already
in Azure you know you just don't have to
deal with that and it's there.
And I guess that's one of those things where upfront you're gonna be starting to
think about those costs in a different
way right, you know if you're used to
this scenario and the on-premise this
world where to spend that you probably
do every five years or every number of
years whereas now you're translating it
into this more operational kind of cost
and you need to start think about in
subtle different ways. Totally so
and it's an interesting one right
because if you take an IT manager's
kind of persona or you've
got the dev team and building the
solution right they're very concerned
about the architecture of the service
and they're not particularly concerned
about how much it costs to power the
things sitting in their server rack sure
yeah the IT manager is very concerned
about it cause it's his budget
whereas the dev team aren't necessarily
concerned about it and that's when all
of a sudden when you move across the
cloud those costs move from one bucket
to the other and they become visible but
actually understanding the true cost of
operating a service on-premise is really
important
to make an apples-to-apples comparison.
So on the subject of calculations, these
things here, so PaaS services actually
are easier to predict, again it
comes down to that linear aspect we
talked about earlier on when we've got serverless. I know the costs, it's got a number of
instances and you do the multiplier
effectively. And what you do is you
budget for the peak cost, and
then use auto scaling to take that cost
down rather than using it to take it up
right so you've got your kind of this is
the most damage we could potentially do
to the to the budget you know thinking
back to that scenario and then anything
below that is better, and you can
then give a hard business line that says,
hey here's my, if I could spend five
thousand dollars or five thousand pounds
on app service then actually we've had a
great year; the service has
performed really really well we've
actually driven a ton of a benefit or
you can just say look we're gonna charge
you a penny per transaction or a
millionth of a penny per X and actually
have it scale up and down with load and
then your cost will follow the actual
workload profile as well. Gotcha,
excellent I think we've learned a lot
there in terms of cost and you know done
some myth-busting on that as well so  that's our session
on Azure Mythbusters and thinking about their cost estimations and thinking about cost overall.
