►
Description
Hitchhiker's Guide to"'Serverless" Javascript - Steven Faulkner, Bustle
Tools like AWS’s Lambda, Google's Cloud Functions, and many others are allowing us to create “serverless” applications.
At Bustle (a top 30 website in the US) we are taking full advantage of this new infrastructure. APIs, databases, searching, indexing, server side rendered javascript, are all being handled without deploying any of our own servers. And the best part? It costs orders of magnitude less than our old VM based deployments.
I’ll walk attendees through our entire serverless stack. I'll talk about the good, the bad, and the ugly. I'll share real numbers from production systems.
The goal is that attendees will leave with concrete knowledge of what going serverless really means and be able to decide if it makes sense for their own infrastructure.
A
All
right
thanks,
everybody
for
coming
I,
really
appreciate
it,
like
you,
said:
I'm
Steve,
Faulkner,
I'm
at
South,
Pole
Steve,
on
Twitter
or
on
github
or
on
any
other
part
of
the
Internet.
So
if
you
ever
looking
for
me,
that's
how
do
you
find
me?
I
did
go
to
the
South
Pole
once
a
long
time
ago
in
a
different
career.
So
that's
the
story
for
later
I.
A
Came
here
all
the
way
from
Philly
land
of
cheesesteaks
and
rocky
and
all
kinds
of
stuff
like
that,
so
if
you're
in
Philly
or
in
your
bike,
stop
and
say
I,
as
you
said,
it
work
for
bustle.
So
for
those
who
are
not
familiar,
bustle
is
one
of
the
largest
women's
media
properties
online.
So
depending
whose
numbers
you
believe,
we're
somewhere
in
the
top
30
websites
in
the
US,
a
lot
of
editorial
content.
A
I
am
the
director
of
platform
engineering,
which
is
just
the
fancy
way
of
saying
I'm
kind
of
in
charge
of
all
things
back-end.
But
we
have
kind
of
a
lot
of
a
very
cross-disciplinary
team,
so
touch
a
lot
of
different
things
in
the
front
end
to
occasionally
so
this
talk
is
broken
down
into
six
different
sections.
A
First,
I'm
going
to
talk
about
the
hype
of
surrealists,
so
I
mean
there's
a
lot
of
people
here,
so
hopefully
you're
all
hyped
on
it,
but
maybe
not
maybe
you've
seen
just
some
of
the
the
hashtags
out
there
and
the
tweet
storms
and
whatnot
so
you're
here
to
figure
out
what
what's
actually
going
on
I'm
gonna
talk
about
service
101.
Why
why
it
exists?
Why
we're
talking
about
what
the
word
actually
means?
Why
you
may
want
to
use
it?
A
Why
you
might
want
when
you
use
it
and
then
I'll
talk
about
what
we
actually
do
with
it,
a
bustle
and
some
of
the
tooling?
Lastly
so
hype
first,
this
is
a
medium
post
called
your
buzz
word
for
2016
serverless.
It
was
written
in
March
of
2016,
so
didn't
even
get
like
one
of
the
few
months
in
and
it
was
already
proclaim
the
the
buzz
word
of
the
year.
A
There's
all
kinds
of
great
tweets
I've
collected
about
serverless
I,
don't
have
time
to
go
over
all
of
them.
This
is
probably
my
favorite
comment
ever
that
I've
ever
read,
I
also
hated
when
people
put
walls
of
text
on
slides,
but
I'm
gonna.
Do
it
because
it's
my
talk,
do
what
I
want,
but
I'm
gonna
read
it
the
people
who
are
serving
websites
on
lambda
or
something
are
not
only
doing
it
wrong.
They
are
wasting
money
while
locking
themselves
in
to
an
architecture
that
doesn't
fit
their
app.
A
This
is
on
Hacker
News,
so
my
first
reaction
to
this
is
I
should
probably
hire
this
person
because
they
know
more
about
my
app
and
I
do
so
commonly
I.
Give
this
talk
a
few
times
before
talk
a
lot
of
people
lost,
herbalist
I
hear
it
doesn't
scale,
it's
not
production-ready.
It's
too
slow,
it's
too
expensive,
so
I'm
here
to
tell
you
that
all
of
these
things
are
completely
false
at
bustled.
A
To
give
you
kind
of
a
preview
of
the
later
part
of
the
talk,
we
use
serverless
technologies
for
99%
of
our
user
requests
that
results
into
AWS
lambda,
specifically
10
to
20
million,
calls
per
day
less
than
200
milliseconds
average
latency,
and
it
costs
us
less
than
our
ec2
base
setup.
So
I'm
here
to
tell
you
it
actually
does
work
in
production
for
us.
So
I'm
going
to
tell
you
about
all
that,
and
maybe
it
will
work
for
you,
too
surveillance,
101
I'm,
going
to
talk
about
kind
of
how
we
got
to
where
we
are.
A
First
off
there
are
still
servers.
This
is
like
the
first
thing
everybody
says:
oh,
my
god,
there's
still
servers
all
right.
Yes,
I
get
it
I
know
that's
a
terrible
word.
I
did
not
come
up
with
the
word
service.
I,
don't
know
what
market
agency
did,
but,
unfortunately,
for
better
for
worse,
it's
kind
of
what
has
been
used
as
the
buzzword
around
a
certain
set
of
practices
and
those
practices
are
basically
what,
if
we
abstracted
all
the
servers
away-
and
this
is
not
really
like
a
very
new
concept.
A
Stuff
like
this
has
been
happening
for
a
long
time.
It's
usually
called
whatever
as
a
service.
There's
lots
of
things
that
claim
to
do
this
or
claim
to
be
this.
There's
this
one
critical
missing
part,
though
every
time
somebody
has
blank
as
a
service,
they
never
really
addressed
the
question
of
ok.
Where
does
my
business
logic
go?
Where
does
the
stuff
that
actually
matters
to
my
specific
application
live
and
there's
been
a
lot
of
different
approaches
to
try
to
fix
this?
A
Yes,
something
like
firebase
or
parse,
was
kind
of
like
well
put
all
the
logic
on
the
client
right
and
we're
not
going
to
you
know
let
you
do
anything
there.
Heroku
is
kind
of
in
this
vein,
although
they're
they
still
make
it
very
aware
that
you
have
a
server.
You
have
to
scale
up
manually,
all
your
processes,
so
this
talks
really
not
about
those
things.
Those
are
interesting
things
and
interesting
tools,
but
maybe
the
fact
that
one
of
them
doesn't
exist
can
tell
you
why
we're
not
really
talking
about
those
in
2016.
A
What
we're
really
talking
about
in
2016
when
we
talk
about
server
lists,
is
we're
really
talking
about
functions
as
a
service?
People
are
trying
to
kind
of
go
online
to
service
service
and,
you
know,
say
Oh.
Our
app
is
also
service.
Our
service
is
also
service,
but
really
this
is
like
the
core
thing.
This
is
business
logic,
going
into
functions
as
a
service,
a
few
core
tenets
of
functions
as
a
service,
so
run
my
code
only
when
I
need
it.
A
I
only
want
to
pay
when
it's
actually
running
I,
don't
have
stuff
sitting
around
waiting
and
just
don't
bother
with
the
details
I'm
at
a
node
conference.
So
this
is
I,
think
not
a
hard
sell
to
say
that
you
know
your
app
is
basically
a
function
that
sits
between
the
requests
and
the
response
of
the
user,
especially
you
know
in
the
case
of
web
programming,
we're
all
programming
and
basically
an
invented
language
I,
so
who's
actually
kind
of
doing
this
stuff
offering
functions
as
a
service.
A
Well,
there's
a
zoo,
er
has
a
thing
called
I
think
that's
called
the
zoo,
er
functions.
Google
has
Google
Cloud
functions.
Ibm
has
this
very
interesting
thing
called
open
Wisc
that
is
actually
open
source?
So
if
you
kind
of
want
to
see
how
maybe
this
is
works,
underneath
the
hood
highly
encourage
you
to
check
those
things
out,
stock
is
not
about
any
of
those
things
talking
about
Amazon,
Web,
Services
and
I'm
very
excited
with
some
of
the
progress
that's
being
made
by
everybody
else
in
this
arena.
A
But
honestly,
Amazon
is
pretty
far
out
of
everybody
else,
and
the
reason
that
everybody's,
so
hyped
on
server
list
I
think
has
a
lot
to
do
with
Amazon
specific
offering
and
it's
what
we
use
a
puzzle
so
being
the
Hitchhiker's
Guide
I'm,
going
to
kind
of
like
get
into
some
specific
details
and
talk
about
what
that
actually
looks
like
sidenote
reinvents
is
literally
happening
right
now,
like
people
at
Amazon
or
announcing
things
as
I'm
talking.
So
something
in
this
talk
may
be
completely
wrong
by
the
time
I
get
out
of
here.
A
So
we'll
see
what
happens
all
right,
let's
look
at
some
code,
so
this
is
sort
of
a
pseudo
Express
app.
The
simplest
thing.
I
could
possibly
come
up
with
and
there's
actually
two
different
things
happening
here.
There
is
routing
and
there
is
functions
right.
This
is
your
business
logic,
then
there's
something
that
says:
hey
here's,
the
proper
function.
You
actually
need
to
call
so
it
turns
out.
We
actually
need
two
things.
We
need
functions
as
a
service.
We
also
need
routing
as
a
service
and
Amazon
provides
both
of
those
for
us.
A
This
is
what
it
looks
like
I
put
this
slide
up
here,
because
people
I
don't
find
Amazon's
UI
to
be
incredibly
confusing,
and
so,
if
you're
in
here
you're
in
the
right
place,
lemon
is
actually
really
simple.
You
write
code,
you
zip
it
you
upload
it
and
then
they
will
run
like
it's.
Not
the
model
around
lambda
is
not
super
complicated
on
tear.
You
can
actually
run
them
in
multiple
languages.
First-Class
support
for
node
Java,
Python,
plus
with
a
node
shim.
It's
pretty
easy
to
run
any
binary
compiled
language.
A
So
it's
a
lot
of
options
there.
Everybody
always
freaks
out
when
I
talk
about
lambda
for
the
first
time
because
they're
like
oh,
my
gosh,
it's
going
to
be
some
super
specific
Amazon
thing.
No,
it's
not
it's
totally!
Okay,
you're
going
to
survive.
It
is
basically
just
like
normal
node
functions.
It's
a
callback
based
model.
You
call
back
to
the
caller,
which
happens
to
be
Amazon
or
some
end-user
request,
and
you
give
them
some
data
either
an
error
or
a
success.
A
Result
on
top
of
this
Amazon
gives
you
all
this
stuff
that
you're
going
to
want.
So
when
you
first
start
out
deploy
a
function
pretty
easy.
This
is
really
cool,
but
at
some
point,
when
you're
doing
this
in
production
you're
going
to
need
versioning,
you
want
to
have
multiple
versions
of
these
functions,
you're
going
to
want
to
a
lien.
So
you
want
to
say
version:
45
is
the
beta
version
version.
46
is
the
production
version,
maybe
switch
those
around
when
you're
ready
to
promote
things
to
production.
They
give
you
some
controls
over
RAM
and
CPU.
A
They
give
you
a
bunch
of
logging
stuff
with
any
kind
of
distributed
system
or
microservices
style
architecture.
This
is
a
often
the
biggest
problem
is.
How
do
we
aggregate
all
these
logs
in
one
place
as
frustrating,
sometimes
as
Amazon's
Cloud
Watch
UI?
Is?
It
is
nice
to
have
everything
all
in
one
place
and
then
also
non-http
events,
so
lambda
actually
used
to
be
that
you
couldn't
really
respond
to
HTTP
events
with
it.
A
It
was
only
for
kind
of
back-end
processing
requests
like
an
s3
bucket
got
updated
or
a
dynamo
T
DynamoDB
table
got
updated
things
like
that,
API
gateway.
So
it's
actually
my
pretty
firm
belief
that
the
reason
serverless
has
seen
such
big
rise
is.
We
cause
Amazon
released,
API
gateway,
they
released
it,
maybe
a
little
over
a
year
and
a
half
ago
before
that
lambda
had
been
around
it
wasn't,
you
know,
used
a
ton,
but
it
was
definitely
something
that
already
existed,
and
this
is
really
the
key
that
unlocked
lambda
lemon
is
the
interesting
part.
A
A
This
has
gotten
a
little
bit
better
recently
installed
touch
on
some
of
that
later,
but
mostly
it's
it's
a
lot
of
UI
work.
On
top
of
that,
on
top
of
just
routing
to
your
functions,
you're
going
to
get
all
this
stuff
that
you
wanted,
anyways,
caching,
throttling
authorization.
You
can
do
bunch
of
things
there.
You
can
bring
your
own
custom
off,
you
can
do.
A
So
those
are
kind
of
the
tooth.
The
two
main
components
of
server
list
I
think
that
when
I
go
around
and
talk
to
people
at
server
lists
and
talk
to
other
people
who
are
doing
this
stuff,
I
would
say
that
95
percent
of
the
time
they're
talking
about
AWS,
lambda,
API
gateway,
so
I
think
that's
a
fair
assumption,
I'm
very
excited
where
everybody
else
is
going
to
catch
up,
but
they
are
definitely
leading
the
pack.
A
So
why
serverless?
Somebody,
my
favorite
tweets
of
all
time,
I,
really
I,
really
like
and
very
skeptical
of
new
things
and
I'm
like
okay
I,
want
to
really
know
how
this
particular
set
of
technology
is
going
to
help
me.
Do
my
job
better
help
me
meet
the
needs
of
my
business
better,
that's
how
I'm
always
looking
at
things.
So
with
that
in
mind,
I
have
a
bunch
of
you
know
kind
of
points
about
why
you
might
want
to
do
serverless.
The
first
is
UPS,
so
everybody
always
I
may
be
not
at
this
conference.
A
But
when
I
go
to
DevOps
conferences
to
talk
about
serverless
everybody
freaks
out-
and
it's
like
this
means
ops
going
away,
it's
not
going
to
go
away.
Little
history
I
in
2011
I,
was
working
at
a
very
small
startup,
and
this
was
like
our
ops
right.
Hip.
Roku
was
down.
We
just
went
to
lunch
because,
like
what
else
are
we
going
to
do
now?
I,
don't
we're
going
to
startup,
and
we
have
to
have
a
plan.
I
mean
that's.
A
There's
been
a
lot
of
progress
in
the
area
of
making
ops
better
in
last,
like
five
years
very
excited
by
a
lot
of
the
stuff,
that's
happening
there,
and
then
everybody
thinks
that
this
is
now
what
serverless
people
think
right:
service
ops,
like
whatever
there's
those
servers
doesn't
matter,
but
this
is
not
true
at
all.
So
it's
not
no
ops,
I
hate.
This
hashtag
don't
use
this
hashtag,
it
might
be
less
ops,
but
a
service
ops
is
still
have
a
plan
when
it
comes
to
AWS
lambda.
A
We
were
very
early
kind
of
in
the
game
and
so
we'd
spent
a
lot
of
time
doing
these
things
we
did
benchmarking.
We
spent
trying
time
trying
to
do
all
kinds
of
crazy
hacks
to
do
fall,
backs
to
different
regions
or
different
lambda
functions,
or
even
some
of
our
old
ec2
stuff.
We
do
a
bunch
of
load
testing
we're
trying
to
improve
on
monitoring,
there's
a
bunch
of
new
tools
that
have
since
kind
of
come
out
in
the
last
year
that
have
made
this
a
lot
easier.
Like
I
said,
maybe
a
hash
tag.
A
Les
ops,
let's
talk
about
scale,
so
scaling
is
always
one
of
those
things.
You
know
everybody
says:
does
it
scale
which
I
don't
really
know
what
that
means,
but
I'll
use
a
analogy
that
I
like
to
use
for
lots
of
different
programming
things
and
that's.
If
I
give
you
a
pen
and
tell
you
to
write
down
your
name
on
a
piece
of
paper
you're
like
that's,
not
too
bad.
If
I
tell
you
to
do
it
a
hundred
times?
A
A
A
How
are
we
conceptualized
in
all
this
stuff,
so
I
think
and
I'm
really
trying
to
come
up
with
a
way
to
actually
quantify
this,
but
qualitatively
I
think
that
serverless
results
in
less
stuff
changing
between
one
request
per
second
and
a
thousand
requests
per?
Second,
that's
the
benefit
to
me
and
to
scale
as
I
see
it
within
our
organization.
We
have
to
do
less
in
and
change
less
about
how
we
operate.
That
doesn't
mean
that
we
can
just
turn
things
on
instantly
and
all
sudden
we
have
you
know
bazillions
of
requests
and
nothing
falls
down.
A
We
still
have
to
be
very
careful
about
stuff
we're
doing,
but
it
means
we
get
to
do
less
and
those
changes
come
easier
nobody's
really
talking
about
this
yet,
but
I'm
excited
about
this
part.
Does
anybody
here
have
that,
like
one
ec2
box,
that's
still
on
that,
you
think
you
might
be
able
to
turn
off,
but
you're
not
really
sure.
So
it's
still
running
in
the
background,
maybe
like
yeah,
the
great
part
about
service.
Is
you
only
pay
for
it
when
you're
using
it?
So
if
nobody's
using
it,
you
don't
pay
for
it.
I.
A
Don't
worry
about
the
functions
that
are
still
sitting
around
that
we
deployed
a
year
ago
right
like
at
some
point,
I'm
I
need
to
clean
up,
so
the
UI
looks
better,
but
in
general,
like
that
cost
me
money.
It's
not
costing
my
team
time.
It's
great
excited
about
iteration
I
think
that
it's
really
nice
to
be
able
to
kind
of
iterate
on
a
function
based
level
rather
than
your
entire
application.
A
Single
function
deployments
allow
us
to
deploy
things
very
quickly.
They
also
allow
us
to
experiment.
If
you
want
to
rewrite
some
function,
one
little
part
of
our
app
and
rust
like
we
can
do
that,
go
for
it.
We've
kind
of
done
things
like
that,
where
we've
experimented
on
very
small
parts,
very
quick
deploys.
A
Basically
I
talked
about
aliasing
and
versioning
before,
but
you
can
deploy
a
bunch
of
functions.
You
could
deploy
50
functions
and
then
you
can
alias
them
all
at
once,
which
means
going.
You
know
your
entire
app
going
from
beta
per
to
production
kind
of
doing
blue
green
style
deployments
becomes
very
easy
to
do.
Let's
talk
about
money,
so
I
mentioned
before
it's
cheaper
I
have
one
really
good
example
of
this
I
hate
when
people
give
examples
where
they're
like?
A
Oh,
we
it's
cheaper,
but
we
rewrote
it
and
we
move
through
features
and
it's
in
a
new
language
and
that
kind
of
stuff.
But
we
have
this
one
API,
it's
actually
probably
one
of
our
most
trafficked
API.
Is
it
travels
all
of
our
kind
of
user
tracking
and
event
tracking
on
the
website.
It's
very
simple:
it's
just
one
node
endpoint
that
kind
of
collects
all
this
data
and
puts
into
the
various
places
needs
to
go
on.
Ec2
was
costing
us
about
twenty
five
hundred
dollars
a
month.
A
It
was
already
a
node
application
was
one
of
the
very
first
things
we
know
it
wrote
a
node.
We
were
in
order
lambda
an
API
gateway
and
went
down
to
$400
a
month.
So
awesome
right,
I
think
honestly
we're
seeing
even
higher
cost
savings
in
other
places
but,
like
I,
said
a
little
hesitant
to
to
make
those
comparisons
directly.
But
this
is
the
best
example
that
I
have
all
right.
So
why
not
I'm
not
going
to
sit
up
here
and
tell
you
that
serverless
is
like
the
most
amazing
thing.
A
You
have
to
rewrite
everything
tomorrow
in
service
I.
Think
it's
great
I
think
it's
going
to
be
a
game-changer
moving
forward
with
how
we
build
applications,
but
there's
definitely
reasons
not
to
use
it.
Lock-In
is
one
our
organization
is
not.
This
is
not
a
business
scene
for
us.
We
don't
really
care
that
much
about
lock-in.
We
love
Amazon
and
they
do
lots
of
great
things
for
us
and
I'm
happy
to
keep
using
their
stuff
I
get
that
this
is
not
the
case
for
everybody
if
you're
ever
locked
into
lambda.
A
This
is
all
you
need
to
get
out.
It's
an
express
server
that
calls
lambda
functions.
If
you,
if
you
ever
get
stuck
just
email
me
I'll,
send
you
this
code,
I'll
charge
you
for
it
all
right,
cold
functions
all
right.
This
is
actually
a
big
one
that
we
worry
a
lot
about
and
you
definitely
should
be
worried
about.
A
You
know
I
mentioned
before
that
you
could
also
write
lambda
functions
in
Java
and
in
Python
the
Java
people
particularly
freaked
out
about
this,
because
they
have
big
cold
start
issues
because
obviously
the
first
time
you
call
a
function
if
you're
doing
something
outside
the
handler
like
this
like
load,
a
bunch
of
data,
then
you
need
to
actually
process
that
data.
If
this
happens
outside
the
main
part
of
your
function,
you
need
to
be
worried
about
how
long
that
takes
and
how
that
affects
end
users.
A
The
data
the
best
data
we
have
on
this
is
your
functions,
actually
get
cold
started,
guaranteed
within
three
and
a
half
just
something
about
how
laminas
Amazon
does
their
container
management
behind-the-scenes
long
running
tasks
5minutemax?
So
everybody
should
just
be
aware
of
that.
The
best
example
I
have
a
vast.
This
is
we
have
a
thing
we
load
from
s3
every
night
goes
into
lambda,
and
then
it
gets
in
DES
indexed
and
elects
elasticsearch
I
thought
this
was
going
to
be
our
like.
The
one
thing
we
couldn't
use
lambda
for
comes
in
at
like
four
minutes.
A
So
totally
good
testing
test
scene
is
definitely
an
issue.
Unit
tested
individual
functions
is
not
too
difficult,
but
when
you
do
one
of
these,
you
want
to
integration
testing
across
all
of
your
functions
or
functions,
calling
functions.
That's
a
little
bit
of
a
pain
point
still
so
right.
Now
we
do
a
lot
of
testing
the
cloud
we
spin
up
new
environments,
specifically
for
testing,
so
how
we
do
serverless
app
bustled.
It's
actually
really
simple.
This
is
probably
like.
A
Maybe
this
is
why
you
showed
up,
but
it's
probably
the
most
uninteresting
part
of
the
talk
on
the
front
end.
This
is
what
the
bus
of
website
looks
like
all
we're
doing
is
we're
setting
up
HTML
and
JavaScript
through
API
gateway.
We
read
some
static
assets
out
of
s3
and
we
use
lambda
to
do
server-side
rendering,
so
we
use
both
ember
and
fastboot
and
pre-act,
because
we
have
a
couple
different
properties
and,
like
I
said,
I
comes
in
it's
plenty
performant
for
our
needs
on
the
backend.
A
Basically,
the
same
deal
we
use
now
I've
kind
of
moved
over
to
graph
QL
for
pretty
much
everything
on
the
back
end.
That's
what
our
graph
killer
looks
like
and
same
thing:
JSON
API
gateway,
all
done
through
lambda,
usually
talking
to
Madinah,
Moe,
DB
or
Redis,
some
elasticsearch,
and
there
some
Postgres,
oh,
my
gosh
I
have
one
minute
left
to
lean
all
right.
So
to
lean,
there
is
a
bunch
of
great
stuff
out
there
that
will
help
you
do
serverless
help
you
do
api
gateway
and
lambda.
A
You
need
to
use
one
of
these
things
if
you're
using
more
than
like
two
functions.
This
is
incredibly
painful
to
deploy
the
stuff
yourself
and
honestly.
This
is
the
place
that
we've
seen
the
most
improvement
in
the
last
year
and
I.
Think
we'll
continue
to
improve
a
lot.
Serverless
framework
is
the
oldest
thing.
They
changed
their
name
to
this,
these
to
be
called
jaws
and
not
really
a
fan
of
the
new
name,
because
I
think
it
confuses
a
lot
of
people.
There's
thing
called
node
lambda.
A
That
does
a
lot
of
this
for
you,
which
is
written
and
go
but
supports
all
the
runtimes
written
by
TJ
hallo
Chuck,
if
you're
familiar
with
his
work,
also
Claudia
Jas,
which
is
another
very
interesting
thing
kind
of
how
they
architect
it
or
you
can
use
the
one
I
wrote
so
Shep
check
it
out.
Shep
is
bustles
open-source
lambda
and
api
gateway
deployment
framework,
the
it's
very
easy
to
get
npm
install',
G
Shep
the
pitch
for
Shep.
A
B
B
A
A
It's
it's,
not
a
big
business
concern
of
us.
We
have
a
pretty
robust,
caching
and
CDN
stuff
in
front
of
out
of
our
content.
We
don't
do
payments,
you
know
we
I
get
that
our
meet
are
the
needs
of
a
media
company
are
very
specific.
We
just
don't
have
a
lot
of
cases
where
like
if
something
fails
on
lambda
that
we
can't
just
run
it
again,
so
not
to
say
that
that's
always
true,
but
it's
not
something.
We
worry
a
ton
about.
Oh.