►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Serverless Experiences -- On Your Own Servers? - Evan Anderson, GoogleSDCC -
The term "Serverless" was coined to suggest that "in the future, developers won't think so much about servers". Since then, many have equated serverless with Functions-as-a-Service as offered by AWS Lambda (and competing services). Unfortunately, defining a movement by the absence of a concept is as absurd as "don't think of a white bear".
In this talk, Evan Anderson will provide an overview of a number of hosted and OSS serverless efforts including services like CircleCI and BigQuery and projects like Knative and Tekton to develop a useful test and theory of serverless. After examining signature design features of existing serverless solutions, he will discuss the applicability of Serverless to organizations with large on-premises installations.
The talk will close with suggestions about how and when to apply serverless design principles to software projects, as well as signs that your problem might not be a good fit for serverless.
A
So
some
of
some
people
have
heard
me
rant
about
this
already,
but
serverless
is
a
terrible
name
because
it
talks
a
lot
about
what
it
isn't
and
not
about
what
it
is,
and
it's
not
true,
because
there
really
are
servers
and
so
everyone
that
ever
the
first
argument
every
wants
to
have
is,
but
but
there's
really
servers
there
and
that
completely
misses
the
point.
Yes,
there
are
servers
there.
Yes,
your
code
runs
on
servers
most
of
your
code.
You
know
some
of
you.
Some
of
you
are
working
on
client-side
things
too,
and
there
isn't.
B
A
So
there
are
a
couple
different
ways
that
people
choose
to
define
server
lists
platforms,
the
one
that
I
like-
and
this
is
the
one
that
I'm
going
to
focus
on-
is
that
you
have
a
development
model
where
developers
focus
on
doing
a
single
unit
of
work.
Well,
so
they
don't
think
about
connection
pooling
and
instance
counts
and
auto
scaling
and
how
things
get
cloned.
They
think
run
this
function.
A
So
these
aren't
the
same
thing
they're
related,
though,
if
developers
are
focusing
on
a
single
unit
of
work,
someone's
still
got
to
be
doing
that
scaling
and
either
you
have
an
Operations
team
running
around
in
the
background
frantically
trying
to
keep
up
with
what
the
developers
are
doing
and
the
developers
aren't
communicating
with
the
Ops
people
and
that
kind
of
sounds
like
where
we
were
20
years
ago.
Before
this
whole
DevOps
thing:
let's
not
go
back
there.
A
So
if
the
developers
aren't
going
to
be
doing
the
scaling
and
operators
are
going
to
be
doing
the
scaling,
the
platform
has
to
do
the
scaling
and
then
the
last
definition
that
lots
of
people
like
to
harp
on,
particularly
if
they
are
hyper
scalars
trying
to
sell
you
a
particular
product
is
that
you
pay
for
what
you
use.
So
if
you
use
10
seconds
of
compute,
you
pay
for
10
seconds
of
compute,
you
don't
pay
for
you
know
the
time
it
takes
to
boot
your
instance
and
the
time
that
it
takes.
A
You
know
to
shut
things
down
and
some
minimum
increments
and
things
like
that,
but
I'm
most
interested
in
the
first
one,
because
focusing
on
a
developer
model
with
developers
focus
on
a
single
unit
of
work.
Lets
you
build
that
second
one,
because
the
developers
aren't
thinking
about
scaling
and
so
forth,
and
if
you've
built
your
platform
right,
they
don't
have
to
think
about
it
because
you're
doing
it
for
them.
A
So
what
is
that
single
unit
of
work?
Well?
I
talked
about
function
as
a
service
of
it
before
so
that's
run
this
function
once
you
know
it
could
be
lambda,
it
could
be
cloud
functions,
it
could
be
open
whisk,
you
know,
but
you
basically
say
here's
a
function.
You
can
run
it
as
many
times
as
you
want
they're
all
independent
of
each
other.
It
doesn't
keep
any
state.
This
is
awesome
for
infrastructure
builders
because
it
doesn't
keep
any
state
and
it
lives
for
60
seconds
is
basically
easy
mode.
A
You
can
be
like
hey
I
I
made
this
thing,
I
ran
it
and
now
I
could
just
throw
it
away.
I
don't
have
to
worry
about
it.
I
can
reuse
it.
You
know
nobody
cares,
but
basically
I've
made
the
developers
figure
out
all
the
hard
like
state,
stuff,
elsewhere
and
I've
said:
I'll
take
care
of
the
easy
stuff.
Let
me
do
the
easy
stuff
really.
Well.
You
focus
on
the
hard
stuff
that
may
be
too
hard
for
me
to
understand
generally,
but
it's
a
great
place
to
start.
Obviously
this
is
the
hot
space.
A
If
you're
at
you're,
here
at
the
service
practitioner
summit,
you've
probably
heard
of
lambda,
you
probably
know
that
lambda
is
you
know
this
crazy
gangbusters
thing
in
the
service
world
build
a
lot
of
people
use
Travis,
you
circle
its
serverless,
you
don't
know
well,
okay,
it
it
should
be
service.
There
may
be
cases
where
you
discover
where
abstractions
leak
through
we're
gonna
talk
about
that
later.
A
But,
ideally
you
say
you
know,
hey
build
this
thing,
here's
my
instructions
for
building
it.
You
do
it.
You
figure
out
how
to
pipeline
builds
when
to
run
them
and
so
forth.
I
just
think
about
how
do
I
build
my
software
and
then
I
write
a
description
and
I
hand
it
to
you
and
then
you
take
care
of
doing
the
building.
Maybe
all
the
building
happens
on
a
single
machine.
Maybe
you
paralyze
it.
A
The
point
is
as
a
developer:
I,
don't
care
I
care,
maybe
how
fast
my
builds,
get
done
and
I
choose
between
services
based
on
that
or
maybe
how
much
it
costs
I
can
choose
between,
but
mostly
I'm
choosing
on
the
features.
Does
it
do?
What
I
need
and
there's
lots
of
examples
of
this
a
fun
one
that
I
like
to
talk
about
because
I
work
at
Google
and
it's
the
bee's
knees
is
Google
bigquery.
A
So
if
you
haven't
used
bigquery
before
it's
kind
of
an
amazing
fire-breathing
thing
who
here
would
run
a
reg,
X
expression
on
your
sequel
database,
you
know
just
select
where
reg
X
match.
You
know
this
string.
It
turns
out.
Bigquery
eats
this
stuff
up.
You
know
you
can
have
like
10
terabytes,
50
terabytes,
a
petabyte
of
data,
and
it's
organized.
You
know
in
in
sort
of
a
protocol
buffer
inspired
model,
and
you
can
just
feed
it.
A
These
queries
and
it
will
figure
out
how
to
parallelize
it
and
make
it
go
fast
and
it
even
has
stuff
like
user-defined
functions
and
the
way
it
works
behind
the
scenes.
Is
it
breaks
out
the
work
to
a
bunch
of
individual
workers,
but
your
interfaces
run
this
sequel
query
and
give
me
the
answers
and
it'll
come
back.
You
know
in
five
or
six
seconds
you
know
and
tell
you
hey,
I
searched.
You
know
three
terabytes
of
data
and
here's
your
answer.
A
So
it's
probably
clear
why
my
sequel
and
Postgres
don't
quite
meet
up
to
that
right
now,
even
with
something
like
the
test,
you
have
to
think
about
the
sharding
in
your
shard
keys
and
so
forth.
If
you
can
show
me
a
database
that
can
do
that
charting
automatically
for
transactional
stuff
I
am
super.
Interested
bigquery
is
mostly
import.
Your
data
and
then
run
read
queries.
So
I
don't
have
a
great
answer
for
you
for
a
server
list.
You
know
write
database
with
a
sequel,
interface.
A
Google
spanner
gets
kind
of
close,
but
you
still
have
to
you
still
see
the
instances
underneath
and
how
many
you
provision
and
stuff
like
that
object,
storage,
probably
actually
one
of
the
original
serverless
services
and
nobody
thinks
about
a
service.
Nobody
talks
about
os3
is
service,
but
hey
I've
got
a
back-end
ooh,
okay,
no
yelling!
Even
if
I
get
excited,
hey
I
want
a
full
folder.
You
know
a
remote
filer
and
I
can
just
throw
as
much
stuff
into
it
as
I
want
and
it
just
gets
bigger
and
bigger
and
bigger.
A
A
Why,
though,
well
which
do
we
care
more
about
for
most
projects,
the
cost
to
the
developers
or
the
cost
of
the
hardware
for
most
projects?
It's
going
to
be
the
cost
of
developers,
and
you
know
if,
if
you,
if
you
do
end
up
with
one
of
those
wildly
successful
projects
where
your
hardware
costs
start
to
eclipse
the
cost
of
your
developers,
the
models
that
you've
built
up
from
using
serverless
will
actually
help
you
scale
it
because
it
scales
horizontally,
really
wide,
and
then
you
pay,
you
know
one
or
two
people.
A
You
know
to
dig
down
in
and
figure
out
how
to
make
a
single
function
run
faster
and
look.
Your
hardware
costs
get
reduced,
it's
like
magic,
so
serverless
is
great
for
this
kind
of
thing,
for
both
your
costs
and
your
developer
productivity.
But
the
key
thing
is
the
developer
productivity,
and
this
applies
to
your
operators
too.
So
this
is
a
I
can't
show
you
numbers
from
Google
sorry.
A
A
So
saying
here's
a
unit
of
work
helps
you
when
you're
really
big,
keep
your
ops
costs
low,
because
you're
no
longer
saying
oh
here-
are
70
different
things,
each
of
which
needs
a
team
of
20
engineers,
because
they're
big
enough
to
do
the
thousand
servers.
You
say:
oh
I
need
a
hundred
thousand
servers
and
they
all
work.
Basically
the
same.
So
instead
of
you
know,
50
teams
of
five
ops
people,
I'm
gonna
hire
you
know,
80,
you
know
60
or
80
people
and
they'll
manage
all
of
that
stuff.
A
The
same
way
and
serverless
gives
you
that
power,
because
you
tell
your
developers,
are
focused
on
all
using
the
same
two
model.
The
same
you
know
released
model
and
so
forth.
Kubernetes
gives
you
this
to
kubernetes
is
basically
a
cluster
operating
system
for
your
operators.
So
it's
not
really
a
surprise.
When
you
get
big,
did
you
start
caring
about
this
stuff?
A
But
the
real
reason
for
focusing
on
a
single
unit
of
work
is
that
it
cuts
down
on
your
distractions
and
it
lets
the
platform
take
care
of
a
lot
of
these
things.
So
you
know
right
off
the
bat.
If
you're
using
a
surrealist
solution,
you
don't
have
to
think
about
capacity
and
replication
in
charting
on
an
individual
service
basis.
You
can
have
a
stamped
out
pattern.
That
does
that
you
probably
get
the
same
thing
for
OS
and
library
patching
because
you're
running
on
standardized,
OS
images.
A
You
may
have
to
come
up
with
a
docker
patching
solution
if
you're
building
on
kubernetes,
but
it
should
be
a
consistent
one
across
all
the
different
containers
that
you
run,
and
so
you
know,
hey,
look,
there's
a
new
vulnerability
in
open
SSL.
Well,
that
sounds
really
bad.
What
containers
to
have
that
uses
that
have
that
contain
open
SSL?
Oh
it's
all
of
them
surprise,
but
at
least
now
I
know
what
I
need
to
rebuild,
and
it's
not
like.
A
Oh
so
these
50
servers
I
need
to
run
a
yum
update
and
these
20,
you
know
I
need
to
get
do
an
apt-get
update,
and
these
seven
over
here
I
have
to
wait
for
the
upstream.
Like
you
know,
vendor
patches
or
whatever
you've
got
a
consistent
way
of
building
these
things
focus
on
one
thing:
when
you've
got
individual
units
of
work,
you're
testing
can
become
easier.
A
You
know
test
one
thing
to
find
its
interface
and
then
you
can
just
test
that
one
thing
and
yes,
you
still
sometimes
need
to
integration
testing,
depending
on
your
rollout
controls.
Rollback
may
be
faster
than
a
complicated
integration
test
suite
and
that
may
be
the
right
choice.
In
some
cases,
I
read
an
interesting
article
recently
from
someone
who's
at
Facebook
in
2013
and
said
you
know
they
wrote
a
bunch
of
unit
tests
and
they
promptly
got
deleted
when
they
broke,
because
the
solution
was
just
roll
back
to
the
previous
working
version
on
the
site.
A
Flag
guard
everything,
and
if
you
do
that,
then
you
know
if
anything
breaks
you
Metrix
tell
you
you
roll
back
immediately,
and
then
you
figure
out
what
went
wrong
after
that.
So
having
a
standardized
solution
lets
you
do
things
like
that
which
you
can
build
outside
of
the
unit
of
work,
and
you
can
say:
hey
here's.
A
The
old
unit
work,
here's
the
new
unit
of
work,
we're
gonna
canary
it,
we're
gonna,
see
what
happens
and
then
we're
going
to
roll
back
if
needed,
can
help
a
lot
and
then
there's
always
going
to
be
overhead
stuff
of
things
like
outages
and
bug
triage
and
things
like
that
that
people
won't
be
able
to
get
out
of.
But
at
least
you
can
take
a
bunch
of
the
daily
grind
out.
A
A
You
want
to
do
exactly
one
invocation,
there's
other
models
that
work
so
I've
got
on
the
first
drill
for
general-purpose
computing,
open,
faz,
Apache
Beam
might
not
think
of
it
as
service
solution,
but
it's
hey
write
one
description
of
how
you
want
to
process
your
data
and
then
you
can
do
that.
Someone
else
could
potentially
do
the
tuning
I.
Don't
know
that
beam
is
great
where
it
is
right
now,
but
I
think
that's
where
it's
going
and
that's
where
it
should
be
going
is
just
write
the
description
of
how
you
want
to
process
your
data.
A
Someone
else
will
figure
out
how
to
fit
that
on
to
the
machines
and
do
the
planning.
It's
like
a
sequel,
query,
planner
for
your
big
data
and
then
Google's
cloud
run.
If
you're
storing
data,
it
depends
on
what
you're
using
it
for
if
it's
mostly
for
human
beings,
doing
reports
or
asking
questions
if
you're
doing
observability,
if
you're
doing
business
analytics
or
something
like
that,
then
your
API
should
be
something
that's
friendly
and
approachable
to
humans,
like
sequel.
A
If
it's
mostly
intended
for
machines
to
read
it,
maybe
pick
something
really
simple:
you
know:
I'm
not
gonna
hold
Redis
out.
There
is
the
you
know
hey.
This
is
a
perfect
thing,
but
if
you
look
at
their
their
tools
and
their
language
and
so
forth
for
connecting
to
things
it's
all
based
on
the
idea
that
machines
are
going
to
be
doing
this
querying,
not
people
and
you
know
object,
stores-
are
kind
of
a
mix
of
both.
A
C
A
But
you
know
if
it's
for
computers,
then
you
know
that's
a
perfectly
good
interface
and
I've
got
Kafka
in
there
as
another
interface,
which
is
basically
you
know
on
one
side.
On
the
producer
side,
it's
pushed
things
on
to
a
queue
and
on
the
consumer
side,
it's
take
things
up
to
here
off
of
the
queue
and
then
there's
other
times,
sometimes
you're,
building
a
platform
where
your
goal
is
to
be
glue.
Your
goal
is
to
stick
things
together.
If
that's
the
case,
your
goal
is
for
users
not
to
think
about
you.
A
When
was
the
last
time
you
heard
someone
say:
oh
man,
I
love,
that
pipe
thing
in
your
goal
is
to
get
out
of
the
way
people
shouldn't
be
thinking
about
you.
They
should
be
thinking
about
the
stuff
they
want
to
glue
together,
and
so
you
know,
I'm
not
sure
that
we're
doing
a
great
job
there
I've
got
circle
and
Emmas
and
AWS
step
functions
as
some
examples
of
places
where
maybe
we're
moving
in
the
right
direction.
I
think
circle
and
some
of
these
other
build
things
are
actually
further
along
than
we
are
elsewhere.
A
If
a
lot
of
you
are
using
terraform
I,
don't
know
how
much
time
you
spend
thinking
about
terraform
and
how
terraform
is
going
to
work
as
opposed
to
the
pieces.
You
want
to
stick
together,
but
you
know
if
you're
building
one
of
these
blue
tools,
think
about
how
you
get
out
of
the
way.
How
do
you
make
it
so
that
people
can
just
do
things
elsewhere?
A
That's
really
helpful
for
a
surrealist
solution,
because
things
will
start
out
small
and
then
they
should
just
be
able
to
grow
without
people
having
to
you
know,
go
and
file
a
ticket
or
something
like
that.
Just
start,
taking
up
the
remaining
space
and
being
able
to
scale
those
back-end
resources
without
needing
to
tell
the
clients,
oh
hey,
guess
what
that
partition
you
were
talking
to
now.
It
has
seven
servers,
not
six.
You
wrote
a
bunch
of
data
now
you
need
to
keep
track
of
more
servers.
A
A
You've
got
nothing
there,
tabula
rasa,
you
had
something,
and
now
you
need
to
move
to
a
new
state,
so
there's
a
transition
and
you
need
to
update
coming
from
essary
this
next
one
was
very
important
to
me:
there's
a
problem
or
an
outage,
and
you
need
to
rollback.
How
do
you
make
that
quick
and
reliable
and
your
first
reaction
when
there's
a
problem?
A
A
Your
your
options
are
push
and
pop
off
of
this
persistent
queue.
Your
partitions
don't
map
one-to-one
to
server.
So
you
can
say:
hey
I've
got
this
topic.
It's
got
a
thousand
partitions,
that's
way
more
than
I,
think
I'll
need,
but
if
it
gets,
big
I
won't
have
to
repartition,
that's
awesome
and
so
that
micro
partitioning
lets
people.
A
You
know,
ok
assign
something
to
a
thousand
partitions
or
5,000
partitions
and
then,
as
it
grows,
the
partitions
get
fuller,
but
they
never
get
so
full
that
they
cause
a
problem,
and
you
just
add
more
servers
to
back
things
up
on
different
topics.
It
enabled
that
multi-tenancy
we
talked
about
you
could
have
10
different
topics,
backed
by
the
same
set
of
three
servers,
and
so,
as
you
add,
more
servers
things
you
know
balance
out
on
to
them.
A
So
what's
not
so
serverless
about
Kafka
right
now,
there's
some
pretty
solid
limits.
If
you
start
doing
micro
partitioning,
you
discover
that
that
n,
the
number
of
brokers
and
the
replication
starts
to
actually
put
a
damper
on
how
many
topics
you
could
have.
If
you
were
like.
Oh
we're,
gonna
do
10,000
partitions
for
every
topic,
so
we
don't
have
to
ever
think
about
restarting
other
numbers.
I
saw
where
you'd
get
maybe
20
topics
or
so
per
Kafka
cluster,
which
might
be
smaller
than
you'd,
like
the
failover
semantics
make.
You
think
a
lot
about
individual
nodes.
A
There's
a
coordinator
and
if
the
coordinator
fails
your
recovery
time
is
based
on
all
of
these
partitions
and
so
forth
that
you
made
and
how
the
coordinator
works.
And
ideally,
that
would
be
something
where
you
had
a
master
master
or
a
primary
primary
or
some
sort
of
leader
election
that
had
a
quick
failover
and
someone
else
knew
the
state
right
away.
But
they're
working
on
stuff
like
that
and
the
cluster
address
is
a
little
weird.
A
You
need
to
know
somebody
who's
participating
as
one
of
the
servers
and
then
they'll
tell
you
the
other
ones,
and
it
would
be
nice
if
you
could
just
give
a
network
name
but
I
think
the
last
I
checked.
If
you
give
multiple
a
records,
it
doesn't
actually
figure
out.
Oh,
you
know
try
one
of
these
if
it
doesn't
work,
try
another,
but
obviously
these
are
things
you
can
fix
so
I'm,
getting
close
to
wrapping
up
in
case
you're.
A
Getting
tired
of
this,
but
not
everything
is
serverless,
it's
hard
to
make
some
things
serverless
and
it
only
works
building
a
platform
if
you
understand
how
to
break
things
down
into
those
separable
units.
So
a
great
example
that
I
don't
know
how
to
make
server
lists
is,
if
you
like,
to
play
action
games
in
multiplayer,
something
like
fortnight
and
everybody's,
interacting
with
each
other.
A
That's
usually
going
to
a
single
server
where
it's
doing
a
bunch
of
you
know
a
bunch
of
operations
in
memory
and
it
might
be
working
on
a
60,
Hertz
tick,
which
means
they've
got
16
milliseconds
to
manage
where
everyone's
moving
and
figure
it
and
send
it
all
back
out.
I,
don't
know
how
to
make
that
something
where
it's
just
like.
Oh
you
stretch
it
horizontally
and
all
of
a
sudden,
you
don't
have
to
think
about
memory
access
times.
No,
that's
not
going
to
work
so
there's
some
places
where
service
doesn't
fit.
That's
okay!
A
But
if
you
understand
your
problem-
and
you
can
say-
and
if
you
go
over
and
talk
to
some
of
the
agonized
folks
at
Google,
they
have
a
mechanism
for
at
least
making
it
easy
to
run
many
of
those
game
servers
and
assign
users
to
a
particular
game
server.
So
it's
moving
in
a
service
direction,
just
not
quite
as
completely
serverless
as
you
might
like,
and
there's
actually
a
whole
bunch
of
different
things
in
that
game's
game
server.
Example
that
tick
off.
Basically,
all
these
boxes,
scales
out
and
server
units.
A
A
So
this
is
the
part
at
the
end,
where
I
give
you
a
call
to
action.
I,
don't
know
how
many
people
here
are
application
developers
versus
platform
operations,
teams
and
who's.
Here.
Writing
infrastructure
software
I
wear
that
last
hat
so
I'm
thinking
about
how
do
I
make
the
stuff
I
interact
with
more
serverless
from
a
build
point
of
view,
if
you're
an
application,
developer,
you're
giving
me
that
demand,
you're,
saying
hey
I
want
something:
that's
more
service,
tell
the
people
who
are
buying
your
infrastructure.
A
Hey
I,
want
something
that
looks
more
like
this
service,
where
I
only
do
one
unit
of
work
and
I
don't
get
distracted
by
all
the
other
things
that
need
to
happen
in
the
business.
Let
the
platform
sort
that
out,
if
necessary,
let
operations
sort
that
out,
but
I
want
to
be
able
to
just
focus
on
my
code
and
if
you're,
on
a
platform
team.
A
Look
for
the
software
that
you
can
give
to
your
application
developers
that
will
do
that
without
costing
you
an
arm
and
a
leg.
In
terms
of
you
know:
staff
and
ticket
volume
and
burnout,
and
things
like
that,
if
you're
on
one
of
those
platforms
seems
you're
really
the
glue
between
those
of
us
writing
infrastructure
and
those
of
us
consuming
infrastructure,
that's
all
I've
got.
C
Hi,
yes,
so,
with
the
with
the
move
from
a
monolith
to
micro-services,
things
were
pretty
much
easier
for
developers
to
figure
out
how
do
I
make
my
solution.
Look
like,
however,
with
several
eyes
it's
more
or
less
black
magic,
that's
sitting
somewhere,
and
there
is
no
much
there's
no
much
prior
art
about
it
or
yeah.
So
how
do
you
see
that
developing
actually
how
to
do
old-style
use
cases
like
mine,
X,
ERP
system,
in
a
surrealist
fashion,.
A
Well,
I
think
so:
I
don't
understand
a
full
ERP
system,
but
I
think
server
list
and
micro
services
actually
fit
together
pretty
well
micro
services.
A
monolith
is
basically
oh
I've
got
one
thing
and
by
the
way
it
does
these
50
different
things.
Oh
and
they're
all
complicated
they're,
not
just
like
a
one-line
description,
they're
like
two
pages
of
text
describing
what
this
you
know,
what
the
one
of
these
50
things
is.
A
Not
because
you
know
we
hate
people
or
something
like
that,
but
because
you
know
you
know,
let's
say
you're
doing
insurance,
for
example,
there's
a
bunch
of
rules
about
what
you
can
insure
and
how-
and
maybe
it
varies
by
city
or
by
state-
maybe
there's
taxes
that
need
to
be
built
in,
like
that's
a
thing
that,
like
that
complications
not
going
to
go
away,
we
live
in
a
complicated
world
and
the
thing
that
kind
of
annoys
me
when
people
show
the
serval
stuff
is
they'll.
Look
you
can
do
this.
A
Ten
line
function,
it's
like
yes,
but
people's
problems
are
bigger
than
that,
but
micro-services
lets
you
at
least
break
that
monolith
into
50,
separate
things
and
hopefully
have
some
sort
of
interface
between
them
and
then
for
the
things
that
make
sense.
You
can
run
them
on
some
sort
of
serverless
platform.
You
can
say
hey,
you
know
this
microservice
has
a
backing
database
and
then
all
of
the
application
logic
can
be
stateless
or
hey.
This
entire
service
looks
like
an
enriched
key
value
store.
A
So
if
you
had
a
key
value
store
where
you
can
run
some
compute
alongside
the
data
storage,
so
whenever
you
say
store
you
get
to
run
a
little
bit
of
code.
That
would
be
a
serverless
thing.
I
don't
have
a
great
example
of
a
thing
that
is
alive
and
other
than
the
mill
wheel
paper
from
Google,
which
nobody
else
can
use.
So
I
can
reference
it.
A
You
can
read
it
it's
interesting,
but
the
idea
is
basically,
you
can
run
a
little
compute
alongside
each
storage,
node
and
react
to
stuff,
and
that
might
be
the
right
serverless
thing,
and
maybe
someone
should
build
it.
It's
on
my
list.
I've
got
a
long
list,
but
yeah
each
micro-service
should
make
its
own
choice
on
service.
I
would
encourage
them
to
choose
something
server
less,
but
maybe
there's
something
more
that
doesn't
work.
A
D
A
B
B
D
B
If
you
do
back
of
the
envelope
calculation
of
something
like
scale
to
zero
and
the
reason
I
say,
this
is
because
I
keep
hearing
from
folks
for
my
DM
that
the
cost
of
running
these
massive
data
centers
is
electricity.
Initially,
you
have
set
cost
to
buy
the
hardware
right
okay.
So
if
that's,
if
that's
true
and
you
think,
okay
well,
what
burns
the
most
electricity
on
the
machine?
It's
exactly
CPU
and
why?
Because
it
just
generates
energy-
and
if
you
are,
you
know,
assuming,
like
50%
of
your
workloads,
could
go
down
to
zero
I'm.
B
D
B
A
I
can
do
a
quick
ballpark
based
on
GCE
compute
costs.
So
the
question
you
know
the
question
is
okay.
How
much
were
you
saving?
Let's
say,
you've
got
an
application
version
and
you
keep
two
or
three
versions
around
and
you
don't
scale
to
zero.
You
only
scale
to
one
and
you
size
things,
so
it
only
takes
half
a
CPU
and
it
takes
only
like
one
and
a
half
gigs
of
RAM
when
it's
sitting
around
resident
each
one
of
those
things
over
the
course
of
a
month
on
GCE
is
going
to
cost
you
about
$15.
A
A
non
negligible
amount
of
electricity
there's
also
you
know,
cooling
and
other
things
like
that,
going
on
as
well,
there's
actual
like
staff
like
that
for
hundred
dollars
a
year
per
server,
you
know
yeah,
that's
getting
split
out
across
32
or
40
cores
or
something
like
that,
but
that
still
ends
up
being
like
a
dollar
a
month.
So
there's
a
lot
of
different
costs
that
go
in
electricity
is
one
part
of
it.
If
you
can
scale
down
to
zero,
that's
nice,
you
know
across
a
fleet
of,
say
a
thousand
applications.
That's
$15,000
a
month.
A
A
I
think
that's
a
bit
of
a
stretch
to
say
that
serverless
is
on
its
own
good
for
the
environment.
I,
don't
think
it's
bad!
It
helps
you
push
up
that
hardware
usage
number,
but
in
most
cases,
if
you
get
to
virtualization
and
oversubscription,
your
hardware
costs
are
probably
not
going
to
change
by
more
than
maybe
50
percent.
When
you
put
in
service
to
scale
to
zero
would
be
my
intuition,
I'd
love
it.
If
somebody
actually
had
studied
that-
and
it
wasn't
just
me
pulling
numbers
out
of
wherever.