►
From YouTube: The True Costs of Running Cloud Native Infrastructure [B] - Dmytro Dyachuk, Pax Automa
Description
The True Costs of Running Cloud Native Infrastructure [B] - Dmytro Dyachuk, Pax Automa
Never before have organizations wrestled with as much choice in how they compute and where they compute. The public cloud offers freedom from lead times and elasticity to manage changing workloads, but once a workload reaches a certain size or can be forecasted over a longer period of time it may be much more expensive than building and operating the compute infrastructure in-house. In the following talk we estimate when this threshold is crossed. We then explore what a modern datacentre should look like, why running an efficient compute infrastructure requires a spirit of radical simplification, and finally how focusing on important abstractions enables workload portability in an era with an abundance of choice.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
Yeah
I
had
an
opportunity
to
check
one
of
them
yesterday
and
I
was
in
a
meat
coma
for
a
couple
hours,
so
I
apologize
ahead
of
time
for
the
quality
of
the
slides
because
they
definitely
suffered
because
of
that
anyway.
My
name
is
Dmytro
and
I'm.
Here
today
to
talk
about
the
costs,
the
true
costs
of
running
cloud
native
infrastructure
Before,
we
jump
into
the
subject,
I'd
like
to
introduce
myself
sorry.
A
So
I
spent
a
number
of
years
doing
research
in
the
area
of
performance,
modeling
and
provisioning
and
scheduling
after
that,
I
I
was
a
capacity
planning
engineer
at
a
major
video
game
company.
Where
was
responsible
for
capacity
planning
for
data
centers,
which
were
hosting
the
backend
for
major
video
game
titles.
A
Recently
I
started
a
company
with
a
former
colleagues
of
mine
called
pax
edema,
and
at
this
company
we
are
looking
at
a
easy
way
to
run
hyper
scale.
A
great
infrastructure
or
Forgan
is
a
shion's
of
all
sizes,
and
in
order
to
solve
that
problem,
we
decided
to
build
operas
operas
is
an
operating
system
which
actually
solves
all
of
those
problems.
So.
A
Why,
specifically,
this
topic
in
the
past
I
faced
this
question
myself
many
times
and
a
lot
of
colleagues
of
mine
and
friends
of
mine,
professional
friends
of
mine.
They
face
the
very
same
problem
like
how
much
it's
going
to
cost
us
to
run
a
specific
deployment
and
the
problem
with
the
existing
environment.
Is
that
a
where
is
a
big
shortage
of
information?
A
I
try
to
look
up
on
the
internet
number
of
times
to
find
in
a
you
know,
more
or
less
objective
study
about
the
cause
for
hosting
and
all
of
those
were
like
extremely
biased
white
papers
or
very
incomplete
discussions
on
Reddit
and
hacker
news,
and
that
didn't
really
paint
the
big
picture,
plus
the
pricing
model
offered
by
let's
say
Amazon
or
when
you
come
to
build
in
your
own
hardware.
It
does
get
pretty
complicated.
A
You
have
to
operate
in
this
pace
of,
let's
say
30
to
40
different
parameters
and
having
reasonable
estimates
for
those
is,
is
quite
difficult
and
challenging.
Not
everybody
has
the
good
apparatus
to
obtain,
in
those
estimates
and
estimating
and
and
and
calculating
the
the
future
cost
for
running
this.
So
I
decided
to
build
a
model
based
on
generalized
data
data.
A
From
my
past
experience,
I
spoke
to
a
number
of
people
running
their
own
deployments
in
different
environments,
so
they
provided
feedback
on
the
the
prices
and
caused
their
scene
and
I
decided
to
build
a
model
which
will
show
the
cost
of
run
in
infrastructure.
Specifically
since
it's
a
coupon,
we
are
focusing
on
the
cube
infrastructure
in
different
environments
and
I'll,
be
increasing
the
size
of
the
infrastructure
in
this
model
and
seeing
how
the
cost
is
gonna
change.
A
So
that,
basically,
is
the
means
to
understand
the
economics
and
on
and
the
economics
of
cloud
and
on-premise
team.
So,
as
you
might
guessed,
there
are
several
options
for
hosting
your
kubernetes
option
number
one,
and
this
is
very
popular
option,
as
we
heard
today
in
the
keynote
63%
of
of
cube
deployments,
actually
run
of
ec2
so
cloud.
A
That's
called
the
data
center.
You
probably
know
about
that.
So
I
will
focus
in
this
talk
on
the
first
two
options,
because
the
third
option
is
very
expensive
and
probably
a
little
bit
out
of
the
scope.
So,
as
a
gentle
reminder,
you
know
when
you
found
a
hammer,
not
everything
looks
like
a
nail,
so
don't
suffer
from
a
Thor
syndrome.
Please
I'm
not
here
to
start
a
holy
war.
There
are
true
believers
of
the
cloud.
There
are
true
believers
of
bare
metal.
A
We
are
not
here
to
you,
know,
engaged
in
a
I
would
say
heated
discussions
about
pros
and
cons
of
that's
I'm
here
to
talk
about
money
like
that
is
the
main
objective
of
this
talk
to
estimate
how
much
it's
gonna
cost
and
all
the
technical
advantages
and
disadvantages.
Well,
there
are
a
lot
of
other
talks
to
do
where
those
are
being
addressed.
So
please
focus
on
the
problem,
not
on
the
solution.
A
What
changed
is
that
your
application
is
effectively
decoupled
from
the
hardware
right
when
you
deploy
your
application,
it
doesn't
really
know
whether
it's
going
to
run.
All
you
have
to
do
is
to
say
how
much
memory
and
CPU
you
want
to
allocate
to
the
specific
pod
and
then
that
pod
effectively
becomes
a
Tetris
block
and
Cube
just
will
look
for
different
servers
and
we'll
try
to
find
where
this
Tetris
block
fits
the
best.
A
B
A
Years
yeah
we
got
the
winner,
I
thought:
I
was
the
winner
I
had
like
395
days,
so
that's
what's
cool
how
many
security
patches
were
missed
because
of
that
which
actually
required
the
restart
all
of
them.
We
got
an
absolute
winner,
so
guess
what
we
shouldn't
be
very
proud
of.
Well,
we
it's
kind
of
cool,
it's
a
cool
number
and
progress
should
be
a
special
competition
about
the
uptime,
but
we
don't
no
longer
have
to
maintain
that
at
any
cost.
Why?
A
Well,
because,
with
cube,
you
are
provided
with
a
self-healing
mechanism
which
can
help
you
to
deal
with
the
failed
server
or
if
they
need
to
restart
the
server,
it
can
simply
reschedule
your
pause,
rerun,
reroute,
the
traffic
somewhere
else
and
voila.
You
can
reboot
your
server
and
you
can
let
it
go
down
for
some
time.
A
Also,
you
don't
have
to
trouble
your
operations
team
with
the
tickets
and
server
is
down,
and
they
know
they
will
dispatch
remote
hands
who
were
probably
competing
in
the
Olympics
to
run
as
fast
as
they
can
and
to
replace
that
failed
SSD
or
build
the
raid
and
bring
the
database
back.
No,
you
don't
help
to
do
this
anymore.
So
what
has
changed
in
the
world
of
servers?
Well,
it's
still
a
big
gray
box
with
a
lot
of
blinking
lights
and
which
costs
a
lot
of
money.
So
that
part
didn't
change
much.
A
However,
the
density
of
the
compute
power
and
the
memory
and
storage
first
Ingle
unit
of
server
per
single
unit
has
changed
a
lot
and
has
dramatically
gone
out.
So
if
we
have
a
look
at
the
wide
box,
sorry
white
van
der,
like,
for
example,
this
is
the
Super
Micro
server
I,
just
basically
googled
the
first
site,
which
came
up
to
offer
Super
Micro
Services
and
looked
at
the
sticker
price
of
it.
It
costs
about
$25,000
per
chassis,
it
offers
hundred
twelve
cores
and
those
are
physical
cores.
A
Each
of
those
cores
has
two
CPU
threads
so
effectively.
It's
228
24
core
cores
which
are
visible
to
your
applications,
512
gigabytes
of
RAM,
and
if
you
split
it
over,
let's
say
three
year
amortization,
which
is
quite
how
to
say
aggressive
because
everybody
here
on
data
center.
They
know
that
very
often
you
can
keep
your
hardware
for
as
long
as
five
years
or
even
seven,
but
let's
say
three
years
for
the
sake
of
simplicity:
eight
thousand
dollars
a
year.
Okay,
that
was
cool.
A
So
then
we
asked
the
next
question:
how
much
would
cost
an
approximate
box
in
Amazon
and
I
asked
a
lot
of
people
who
actually
who
run
deployments
in
Amazon?
And
everybody
said
like
you
know,
we
usually
run
em,
for
instance,
as
I
said:
ok,
so
the
m4
10
extra
large
instances,
which
comes
as
on-demand
instance,
comes
with
4,
TV,
cores
and
outputs
burning.
Please
remember
that
we
core
and
physical
core
are
very
different.
Where
is
the
several
times
performance?
The
difference
between
those
and
160
gigs
of
RAM?
It
costs
about
$17,000
a
year.
A
The
graph
on
the
right
is
showing
how
much
CPU
memory
you
can
get
per
dollar.
If
you
buy
that
fat
twin
versus
again
on
demand
instance,
and
obviously
you
can
help
resort
instances,
we
should
require
a
longer
term
contract
and
cost
cheaper,
but
you
can
still
see
that
that
gap
is
huge.
Well,
let's
close
that
gap
a
little
bit
because
physical
servers
don't
run
in
vacuum.
A
You
need
power
and
you
need
to
place
them
somewhere
and
the
carriage
with
physical
servers
is
that
the
placement
of
the
physical
server
or
geographical
location
determines
the
costs
for
running
it
there.
Why?
Because
the
cost
for
power
differs
a
lot,
let's
say
if
you
want
to
run
your
data
certainty,
if
you
want
to
run
your
color
in
Nevada,
that's
probably
going
to
be
cheaper
than
running
that
in
Tokyo
or
in
downtown
New
York.
A
So
the
prices
I
used
in
this
model
are
shown
on
this
picture
and
they
represent
a
more
general
state,
a
more
general
case
and
apologize,
so
that
closes
the
gap
already
buddy
a
little
bit.
So
now,
let's
talk
about
network
and
that's
a
very
interesting
piece,
because
you
need
to
connect
those
servers
together
and
somehow
connect
to
the
outside
world.
The
network
architecture
has
done
a
major
leap
with
emergence
of
the
so
called
closed
network
design,
which
allows
to
run
more
scalable
Network
effectively.
A
Your
backbone
can
scale
out
if
needed
it
can
tolerate
component
failures
and
it
a
vibe,
provides
a
very,
very
substantial
east
to
west
bandwidth,
and
why
is
too
vast
bandwidth?
Matters
like
this
is
East,
and
this
would
be
West,
so
it's
2
s
is
bandwidth
between
these
two
guys.
Why
does
it
matter?
Well,
because
when
you
run
production
system
very
often
those
production
systems
have
calls
to
other
production
systems
and
other
production
systems,
and
it's
not
uncommon
to
have
about
40
requests
happening
inside
because
of
one
request.
We
should
write
from
the
outside.
A
Why?
Because
that's
the
micro
service
architecture,
everybody
is
trying
to
achieve
that's
why
it's
very
important
that
it's
not
only
the
bandwidth
forgetting
from
outside
the
perimeter,
is
also
getting
from
one
server
to
another.
Is
what
matters
a
lot?
So
if
you
decide
to
go
with
Cola,
make
sure
that
your
east
to
west
bandwidth
is
very,
very
well
thought
through
and
that
your
latency
is
is
bound
and
why
latency
a
lot
of
devices
offered
on
the
market
these
days,
they
have
really
really
big
buffers
which
can
store
a
lot
of
packets,
and
this
is
nice.
A
What?
What
happened
is
like
if
your
pack
is
getting
to
those
buffers?
Basically
they
stay
it
for
some
time
and
that
reflects
as
a
latency.
So
you
have
to
make
sure
that
the
capacities
you
have
are
actually
sufficient
to
accommodate
all
the
traffic
and
that
that
traffic
is
not
going
to
get
stuck
in
buffers
occasionally
and
have
latency
spikes
so
network
in
akola.
It's
the
closed
network
would
probably
come
and
come
at
the
cost
of
three
to
six
hundred
dollars
per
node
for
the
three
years
and
the
external
traffic
I
depends
on
the
ISP.
A
You
will
have
in
your
Colo,
but
the
general
conclusions
we
have
arrived
at
was
that
it
costs
about
one
megabit
megabit
per
month
in
the
cloud
the
situation
is
different
in
ec2
I
can
I
will
be
referring
to
the
cloud
to
ec2.
As
the
cloud
the
internal
traffic
is
free.
Traffic
within
one
availability
zone
is
free,
which
is
very
nice.
A
However,
the
external
traffic
is
a
little
bit
it's
more
expensive,
it's
about
twelve
cents
per
gigabyte,
so
the
difference
between
those
two
is
that
if,
in
the
first
case
you
pay
for
the
meter
traffic,
which
is
pretty
sweet
in
the
second
case,
you
have
to
pay
for
the
pipe
right.
So
the
saturation
of
your
pipe
and
the
size
of
the
pipe
basically
is
is
is
at
you.
However,
the
pipe
can
be
a
lot
cheaper,
now,
storage.
Well,
the
general
conclusion
was
that
most
of
the
people
run.
A
Storage
of
the
EBS
in
Amazon
and
EBS
is
is
amazing
because
it
can
be
mounted
to
any
physical
server
and
it
has
some
redundancies.
So
that's
that's
pretty
great.
However,
it
cost
about
769,
sorry
for
$1.
You
can
get
about
769
gigabytes
of
data
store,
it's
quite
generous
and
14
IRS.
That's
not
a
lot!
To
be
honest,
if
you
look
at
the
commodity
SSD
available
on
the
market,
you
can
probably
go
and
buy
a
nanny
store.
A
It
can
handle
60
80
and,
if
you're
looking
at
the
end
and
and
be
any
devices,
that
number
is
almost
four
times
higher
because
about
five
hundred
dollars
per
per
terabyte,
which
can
be
translated
into
20,
two
gigabytes
of
storage
per
dollar
per
month
and
hundreds
of
iOS.
But
you
cannot
just
like
BIOSes
decent,
like
you
know,
throw
in
your
Colo
and
wait
for
them
to
turn
into
storage,
because
that
doesn't
happen
like
that.
A
Unfortunately,
or
does
it
if
you
run
cell
on
every
of
your
kubernetes
nodes
on
the
background-
and
you
basically
expand
the
storage
of
your
compute
servers
with
those
additional
SSDs,
they
can
be.
Certainly
they
can
be
used
as
the
storage
servers
so
effectively.
You
are
shoveling
your
SSDs
just
in
your
data
center
in
your
Colo
and
they
turn
into
the
storage.
But
you
have
to
run
surf
on
that
and
that
doesn't
come
for
free
because.
A
Doesn't
come
for
free
period,
the
data
you
store
in
your
so
say,
active
storage
needs
to
be
snapshotted
and
backed
up
like
for
business
continuity
purposes
for
disaster,
recovery
purposes,
etc.
So
when
it
comes
to
ec2,
it's
pretty
straightforward,
you
got
s/3
s/3
is
amazing
and
fairly
cheap,
very
cheap
when
it
comes
to
the
physical
world.
A
Well,
you
gotta
buy
that
something
like
that
box,
which
is
a
nice
for
you,
server,
which
will
keep
your
color
nice
and
warm
and
that
heater
costs
about
seventy
thousand
dollars
and
can
accommodate
about
one
terabyte
of
raw
storage.
Usually
what
people
run
on
those
is
ZFS
and
they
have
about
half
of
that
storage
being
actually
usable
for
doing
the
backups,
because
you
have
to
enforce
some
redundancy.
A
So
so
what
we
have
figured
out
by
now
is
that
the
physical
world-
everything
is
a
lot
cheaper
compared
to
the
cloud,
however,
is
another
part
of
the
expanse,
which
is
very
often
overlooked,
and
it's
people
like
people,
unfortunately,
don't
like
to
count
to
talk
about
other
people.
I
know
that's
kind
of
weird.
A
The
people
cause
are
very
substantial
in
those
both
solutions.
So
when
it
comes
to
the
Colo
solution,
you
need
people
a
to
replace
foiled
parts.
You
don't
have
to
do
that
frequently
anymore,
because
you
don't
have
to
replace
your
downtime
is
not
determined
by
the
downtime
of
a
specific
part,
but
you
still
need
to
go
somebody
to
go
around
and
replace
failed
drives
or
memory
sticks.
You
need
contractors
for
doing
rack
and
stack.
You
can
help
people
on
staff
who
are
doing
this,
but
some
this
job
needs
to
be
done.
A
You
need
system
administrators
which
would
configure
that
storage,
which
will
configure
staff
which
will
configure
the
backup
script,
etc,
etc,
etc.
Also,
you
need
Network
administration,
you
need
somebody
who
will
look
after
your
network
who'll
make
sure
that
the
it's
a
flowing
nice
and
smoothly
that
there
is
no
clog
ups
and
configure
those
switches
correctly
when
it
comes
to
cost
it's
very
subjective,
because
different
markets
in
different
parts
of
the
world,
the
salaries
are
very
different.
A
A
There
is
also
other
option
where
you
can
help
people
inside
the
Colo
who
will
perform
those
tasks
for
you
so
yeah.
We
can
probably
look
into
that
in
a
different
model
in
this
model.
I
assume
that
you
have
to
have
your
own
staff
to
do
this.
To
be
honest,
my
experience
with
the
services
provided
in
Cola
was
that
the
pricing
for
those
is
can
be
very
substantial
in
some
places,
but
that
probably
is.
A
Okay,
so
if
you
look
at
the
breakdown
of
the
costs
like
basically,
if
you
remember
the
beginning
of
the
talk,
I
mentioned
that
there
will
be
about
50
different
moving
parts
around
that's,
roughly
speaking,
what
we
arrived
at.
So
when
it
comes
to
Amazon,
the
majority
of
your
cost
is
the
compute,
so
those
would
be
the
ec2
instances.
A
The
second
part,
which
comes
very
often
as
a
surprise
to
a
lot
of
people
is
storage
and
the
majority
of
that
storage
cost
is
due
to
the
aisles,
because
this
is
the
component
which
is
I've
seen
so
many
times
overlooked
your
in
the
cost
estimates.
So
if
you
happen
to
do
one,
please
remember
count
your
IEPs
and
count
them
very
wisely,
because
they
can
hurt
you
and
they
can
hurt.
You
apply
a
lot.
B
A
So
if
you
look
at
this
plate
of
costs
in
a
cola
situation,
it's
very
different.
The
biggest
expenses
people,
because
the
hardware
is
a
lot
cheaper,
the
second
biggest
expense
is
obviously
shot
sees.
That's
the
physical
servers
you
need
to
buy
and
racks
and
power,
because
power
is
not
as
expensive
and
if
you
compare
the
size
of
power
to
the
cost
of
chassis,
those
are
pretty
much
the
comparable
entities,
however,
the
backups
and
the
uplink
come
is
very
affordable.
A
A
A
You
don't
have
to
look
like
house
a
it's
a
lot
easier
to
estimate
the
demand
for
your
infrastructure.
Why?
Because,
with
the
traditional
deployment
model,
you
had
to
do
this
exercise
for
every
single
application
and
you
had
to
build
in
the
margin
for
error
in
every
single
variation
in
any
single
instance
of
your
application
and
then
combine
this
together
and
get
the
estimate
right.
It's
a
lot
simpler
because
you,
when
you
add
a
lot
of
entities
with
variation,
you
get
one
big
entity
with
a
much
smaller
relative
variation.
A
That's
called
the
law
of
large
numbers
and
that's
the
phenomenon.
Everybody's
reporting,
once
they
switch
from
one
to
one
deployment
to
the
container
orchestration
or
some
other
different
form
of
collocation,
is
that
your
workload
actually
fluctuates
a
lot
less.
The
workload
of
a
single
application
can
jump
up
and
down.
But
if
you
look
at
the
aggregate,
it
doesn't
jump
up
and
very
much
so.
A
The
most
typical
scenario
is
that
the
companies
are
facing
the
increase
in
workload
and
the
increase
can
change
a
lot,
but
would
say:
40
percent
is
a
fairly
typical
number
I've
seen
the
more
code
usually
has
some
seasonality.
For
example,
Christmas
period
can
be
a
little
bit
more
busy
than
let's
say
summer
period
or
the
other
way
around,
and
usually
it
can
be
predicted,
but
only
to
some
extent,
so
you
can
say
well.
This
will
be
my
demand,
maybe
in
this
range,
but
you
don't
know
exact
number
so
satisfy
that
demand
was
on
demand.
A
Instances
in
ec2
is
super
easy,
that's
basically
meat
and
bread
of
the
cloud
right.
That's
how
it
was
advertised
to
us
many
many
times
the
moment.
Your
domain
changes,
you
allocate
additional
instances
and
you
basically
can
reschedule
pods
on
to
those
the
moment
it
starts
going
down.
You
can
basically
decommission
instances
gracefully
without
causing
issues,
so
it
was
very
hard
to
do
with
the
traditional
one-to-one
deployments
because
you
had
to
do
this
exercise
for
every
single
application,
but
now
you
don't
have
to
do
it
for
every
single
application
right.
You
just
help
to
do
it.
A
For
your
run,
big
application
called
cube
deployment
usually
still
do
a
little
bit
of
a
small
over
provisioning
just
in
case,
because
we
all
feel
just
you
know
a
little
bit
scared
and
that's
good
usually
doesn't
hurt
the
cost
that
much
Oh
after
some
time.
It's
a
common
practice
to
switch
from
on-demand
instances
to
the
reserved
instances.
Why?
Because
they're
cheaper?
If
we
have
to
run
let's
say
150
instances
for
a
year-
and
we
know
that
this
will
no
one
go
below
hundred
instances.
Why
not
just
to
buy
one
year
worth
of
reserved
instances?
A
So
it's
very
typical
that
you
actually
switch
from
on-demand
to
reserve
once
the
workload
is
known
and
you
know
the
bounds
for
it.
So
for
those
who
really
like
to
play
with
the
you
know
different
with
statistics,
where
is
the
sweet
spot
between
the
ratio
of
reserved
verses
on
demand?
Because,
obviously,
if
everything
is
on
demand,
you
have
your
super
flexible
but
more
expansive.
If
everything
is
reserved,
it's
cheaper,
but
you
run
in
the
you
might
run
in
the
problem
of
over
allocating
resort
instances
which
also
can
contribute
to
the
cost.
A
So,
where
is
this
spot
of
the
ratio
between
on-demand
and
reserved,
which
is
the
most
optimal?
That's
a
little
bit
out
of
the
scope
of
this
presentation
in
akola.
The
situation
is
dramatically
different.
Provision
in
Cola
is
a
much
much
slower
process
like
if,
with
on
demand,
it
takes
like
literally
tens
of
minutes
worse-case
to
provision.
In
instance.
We
don't
demand.
It
can
take
several
months
because
you
have
to
communicate
with
the
vendors.
You
have
to
make
sure
they
ship
them
on
time
that
they
arrive
on
time.
A
You
help
drag
them
stag
them,
do
the
burning
test,
etc,
etc.
As
a
result
of
that,
the
over-provisioning
doesn't
happen,
let's
say
on
a
quarterly
basis
or
weekly
basis.
Most
of
the
time,
the
expansion
of
capacities
in
your
cola
happens
one
or
twice
a
year,
so
the
red
dots
they
show.
Your
demand,
which
is
going
up
and
down,
is-
and
it
is
a
little
bit
fuzzy
about
how
the
future
going
to
look
like,
and
you
still
have
this
delay
about
four
ad
in
the
capacities.
A
So
what
you
usually
do
you're
over
provision
and
you
over
provision
by
a
lot.
Why?
Because
you
need
to
compensate
for
growth
and
unpredictability
and
possible
delays
and
that
basically
downplays
the
costs
of
Colo
by
by
a
lot
like
two
point,
that
it
is
also
a
I
wouldn't
say
it's
a
typical
practice,
but
it's
it's
becoming
more
and
more
common
to
see
people
using
the
unused
capacities
in
color
for
running
the
bad
jobs.
What
difference
between
the
bad
jobs
and
the
online
jobs
that
the
online
jobs,
such
as
web
servers
and
etc,
etc.
A
They
have
to
satisfy
demand
right
away
the
bad
jobs
they
can
tolerate.
Some
delays
so
and
I
know
that
cube
resource
management
group
is
working
on
the
job
preemption,
which
would
probably
make
this
feature
even
better
in
the
common
future,
which
would
allow,
for
example,
fully
saturate
your
resources
and
if
new
online
jobs
comes
in,
it
can
just
kick
out
some
of
the
bad
jobs
which
were
running
on
the
background.
So
that's
what
this,
how
you
achieve
the
full
satisfaction
of
your
change
in
demand
and,
at
the
same
time,
you
run
the
bad
jobs.
A
A
Don't
use
the
numbers
but
produced
by
different
parts
of
the
body
use
some
analytics
if
you're,
if
you're,
just
starting
I,
would
highly
recommend
to
have
a
look
of
at
the
book
by
Yahoo.
This
book
is
fairly
old
in
the
tech
world,
but
all
the
principles
and
apparatus
for
establishing
so
for
for
building
linear
regression
models
and
curve
fitting
it
still
applies.
You
can
still
use
it
and
it
can
make
your
life
a
little
bit
easier
and
help
you
to
save
some
money.
A
So
when
we
put
them
side
to
side,
that's
the
picture,
we
see
that
when
we
use
cloud
we
actually
use
a
lot
fewer
resources
when
compared
to
the
amount
of
resources
you
would
have
to
use
in
in
Ecola.
So
all
of
that
beauty
of
the
color
which
which
we,
which
we've
seen
in
the
first
slide
and
the
cheapness
of
that
is
offset
by
quite
a
bit
by
the
fact
that
you
have
to
over
provision
by
several
factors
compared
to
ec2.
A
So
now,
let's
talk
about
dollars,
so
we
can
see
the
graph
is
showing
the
cost
of
the
structure
for
in
AWS
as
a
function
of
the
number
of
instances.
That
includes
all
those
components
from
the
pie
chart
and
obviously
it
scales
up
almost
linearly,
because
that's
how
Amazon
billing
works
with
the
call
of
the
situation
is
quite
different.
A
A
Because
the
cost
per
unit
of
resource
is
a
lot
lot
cheaper
and
if
you
step
back
and
kind
of
zoom
out
this
picture,
we
can
see
that
there
is
a
sweet
crossover
point
in
the
range
of
hundred
to
two
hundred
and
for
two
extra
large
instances
where
the
costs
of
running
that
in
Amazon
become
comparable
to
the
cost
of
running
the
same
infrastructure
in
in
akola
space.
How
does
that
translate
into
dollars?
That's
roughly
speaking
about
hundred
thousand
dollars
a
month.
A
Once
again,
this
is
built
using
the
model
which
was
built
using
the
generalized
data
in
the
context
of
a
specific
organization.
That
point
can
shift.
For
example,
if
you're
very
I
UPS
heavy,
then
probably
Amazon
is
gonna
cost
you
even
more.
If
you're,
just
your
demand
fluctuates
a
lot
and
it's
mostly
CPU
bound
demand,
then
probably
Amazon
will
be.
Amazon's
solution
will
look
more
attractive
and
the
other
way
around.
A
So
basically,
if
your
workload
is
smaller
than
that
number
in
terms
of
instances,
there
is
no
much
financial
sense
in
in
in
moving
to
a
Colo
space,
because
all
you're
gonna
get
is
just
additional
headache.
Who
is
provisioning
and
you're?
Not
gonna
save
money
from
that?
It's
actually
it's
the
opposite
and.
A
Yeah
and
the
other
way
around
if
the
the
larger
infrastructure
becomes
the
more
financial
sense,
it
becomes
to
think
about
running
that
in
akola.
So
I
cut
off
this
graph
at
500
instances.
So
what's
happening
once
you,
if
you
actually
want
to
go
further
with
the
column,
where
is
only
certain
scale
of
a
color
which
can
be
sustained
with
a
rather
simple
networking,
after
which
the
net
cost
of
networking
becomes
a
lot
more
expensive
and
it's
a
stepwise
function.
You
basically
have
to
implement
a
lot
more
sophisticated
networking
part
and
that
will
run
your
cost.
A
Because
if
you
remember,
people
are
the
major
component
when
it
comes
to
estimating
the
cost
of
running
in
a
Colo
and
what
happens
is
you
can
have?
People
of
you
know
different
qualification,
and
sometimes
the
team
of
three
people
won't
be
sufficient
to
run
the
solution
like
that,
you
might
run
into
the
issue
of
like
you
hire
three
people.
A
A
So
that
would
probably
shift
a
little
bit
the
numbers,
the
feature
parity,
that's
effectively.
What
are
you
talking
about
like
if
you
want
to
achieve
the
same
feature?
Parity?
In
order
to
answer
that
question,
you
have
to
do
like
more
rigorous
evaluation
of
the
quality
of
the
solutions,
because
you
make
sure
that
they're
they're
production
grade
that
the
quality
is
there
and
estimate.
How
much
would
it
say,
cost
to
migrate
to
a
different
standard.
A
We
focus
here
on
the
most
of
how
they
lock
in
friendly
solution,
so
the
ones
because
we
were
talking
about
this
curve.
The
whole
idea
was
that,
well,
you
can
jump
from
this
environment
to
another
one.
The
one
you're
talking
about
basically
will
introduce
a
hard
locking,
and
that
is
a
pretty
big
fear
in
a
lot
of
companies
like
you're,
stepping
into
very
politically
difficult
area,
because
my
experience.