►
From YouTube: Slaying Monoliths with Docker and Node.js, a Netflix Original by Yunong Xiao, Netflix.com
Description
Slaying Monoliths with Docker and Node.js, a Netflix Original - Yunong Xiao, Netflix.com
At Netflix, our data access platform is at the heart of nearly every request from our subscribers. It enables our innovative UIs to communicate efficiently with our bevvy of backend services while growing our subscriber base to 75 million members. As a result of this scale, this monolithic platform requires ever increasing resources to run and maintain, both regarding hardware (32 vCPUs per instance) and developer productivity (try running that on your laptop!). As we continue to grow and expand our subscriber base globally (#netflixeverywhere), we need fundamentally to change the monolithic design of our platform.
In this talk, I will discuss the new container-based data access platform that’s replacing the monolith. See how the architecture of this cross-cutting project allows us to build isolated microservices with Node.js and Docker. Examine the tools and infrastructure we’re building across our stack that enable engineers to effortlessly build, debug, test and their code on this platform anywhere -- whether it’s locally on your laptop, or remotely in the cloud -- all made possible thanks to Node and Docker.
About Yunong Xiao
I’m a software engineer at Netflix. I also maintain the open source Node.js framework restify. I have spent stints of my career at AWS and Joyent, respectively, where I worked on distributed systems and helped launch several cloud computing products. I’m especially proud of AWS IAM and Manta, two projects that I helped shape and build. These days I’m leading the Node.js platform at Netflix.
A
Thank
you
for
that
warm
introduction.
This
is
a
really
good-looking
crowd.
Wow
how's
everyone
doing
enjoying
those
guys
in
action.
Yeah
like
like
I
mention
my
name
is
you
know,
I
work
in
Netflix.
Is
anyone
heard
of
us
no
anyway?
So
we
start
with
this
simple
idea
right,
which
is
you
know
we
want
you
to
be
to
watch
your
favorite
content,
sort
of
anywhere
anytime,
whether
that's
dramas,
comedies
or
or
award-winning
original
series,
and
here's
just
a
few
selection
of
some
of
my
favorites
I'm
sure.
A
A
So
it's
not
a
bait-and-switch
time
only
thing
like
that.
So
you
want
to
watch
Netflix
right.
How
does
everything
work?
Well,
as
mostly,
you
probably
know,
we're
sort
of
the
poster
child
for
going
to
the
cloud
we've
long
abandoned
the
data
set,
our
own
data
centers
for
infrastructure
hosted
on
top
of
AWS,
and
so
once
our
engineers
had
poured
it
all
over
stuff
into
the
cloud
we
were
done
right.
We
sat
around
all
day
and
just
watch
TV
shows
turns
out.
That's
not
the
case.
A
There's
no
cloud
as
everyone's
well
aware
of
it's
just
someone
else's
computer,
but
more
than
that,
actually,
just
because
we
migrated
abstracted
away
the
infrastructure.
You
know
we
still
have
to
scale
out
the
platform
platforms
and
the
services
that
running
on
top
of
our
infrastructure
today,
and
so
let's
talk
about
that
right,
you
know.
Our
premise
is
you
know
today
we're
known
for
letting
you
watch
netflix
on
any
platform
and
you
plug
your
phone
or
your
laptop's
on
your
game
consoles
even
on
the
nintendo
or
payment
system.
A
I
was
like
a
hack
day
project,
but
in
the
very
beginning
it
turns
out
right,
mostly
you
probably
don't
remember
this.
Maybe
some
of
you
do
the
early
hardcore
subscribers.
We
were
only
available
on
the
browsers,
and
so
what
did
that?
You
know?
Architecture
and
API
infrastructure
look
like
well,
we
had
a
java-based
web
server
and
that's
web
server
did
everything
right.
It
rendered
the
UI.
So
you
know
all
the
markup
that
gets
them
back
to
the
browser
did
all
that,
but
also
did
all
the
data
access
and
we're
known
for
this
micro-services
based
architecture.
A
So
the
mid-tier
on
the
backend,
every
single
team
really
owns
their
own
independent
micro
servers
and
they
provide
a
client
for
for
the
java
web
server
to
use.
So
there's
a
ton
of
coordination
here
right
and
this
is
sort
of
our
first
evolution.
It
was
responsible
for
doing
everything
like
I
said
before.
So,
let's
play
a
game
called
spot.
The
monolith
right.
A
Can
anyone
spot
the
monolith?
It's
pretty
obvious
to
hear
right.
We,
this
is
the
monolith,
and
so
where
were
some
of
the
issues?
Some
of
these
are
pretty
obvious.
You
know
I
think
the
biggest
thing
is
it
was
really
really
slow
to
push
and
to
innovate,
because
imagine,
hey
a
new
show
just
launched
stayed
the
crown,
which
is
one
of
our
really
amazing.
The
original
series
and
I
want
to
add
a
new
original
roll
title
to
the
UI
right.
That
means
I
have
to
push
this
web
service.
A
What,
if
you
know
I
want
to
one
of
the
back-end
team
says:
hey
I'm,
a
client
update
that
has
a
security,
vulnerability
or
performance
fix
I
want
you
to
integrate
again
after
personal
service.
Maybe
I
want
to
add
a
new
new
micro
service
from
from
a
stack,
you
have
to
push
the
service
so
basically
any
time
you
make
any
changes
up
and
down
the
entire
network
stack.
You
have
to
push
this
service
and
because
it
was
complicated
and
encapsulated
sort
of
all
this
different
functionality
was.
A
It
was
painful
and
a
painful
exercise
to
do
every
time
and
at
the
same
time
you
know
we
wanted
to
move
beyond
just
just
browsers
right.
We
wanted
to
add
a
bunch
of
all
the
other
devices
in
the
ecosystem.
So
how
could
we
move
from
this
sort
of
monolithic,
API,
this
infrastructure
to
something
that
would
support
multiple
devices?
A
Well,
let's
take
a
look
at
the
next
journey
in
our
API
evolution
right,
so
we
start
with
the
shadow
biz
web
server,
which
is
a
monolith,
and
we
moved
in
order
to
support
multiple
clients
to
what
everyone
else
does
right,
which
is
the
REST
API,
and
this
is
the
industry
standard.
We
expose
the
REST
API
and
this
really
unlock
the
ability
for
us
to
support
more
than
one
device
right.
So
we
could
support
now.
You
know
our
TV
and
the
Android's
of
the
world
and
it
broke
apart.
A
The
monolith
and
what's
really
critical
here,
is
that
we're
no
longer
rendering
the
UI
and
accessing
data
in
the
same
process-
and
this
is
good
and
and
so,
but
where
some
of
the
sort
of
the
unfortunate
aspects
of
having
to
use
the
REST
API
well,
the
REST
API
still
turns
out,
was
initially
designed
for
just
one
device
right.
This
meant
that,
as
we
brought
more
and
more
devices
online,
you
know
you
can
imagine.
Every
single
device
has
a
different
experience.
A
A
He
imagined
every
little
element
on
the
Netflix
UI
as
a
resource,
so
in
order,
like
fetch
an
entire
page
of
all
your
movies,
that's
multiple
round
trips
to
the
back
end
to
the
data
center
to
be
able
to
fetch
and
grab
all
those
assets
back
and
as
time
had
elapsed,
you
know
the
API
continued
to
get
the
question
below
and
we
were
retrofitting
it
with
lots
of
different
unique
API
is
for
different
clients.
It
became
hard
to
maintain.
A
There
was
really
there's
tug-of-war
now
between
all
the
client
teams,
but
who
really
wanted
to
bespoke
API
for
their
only
user
experience,
but
had
to
wrestle
with
a
single
REST
API.
So
what
do
we
do
right?
What
is
the
next
sort
of
step
in
our
API
revolution?
Look
like
well
I
thought.
I'd,
take
a
step
and
sort
of
talk
about
our
ethos
and
Netflix,
which
is
really
the
design
for
innovation.
I
mean
one
of
the
places
where
we
really
differentiate
ourselves.
A
In
addition
to
the
amazing
content
and
the
great
algorithms
is
our
innovative
UIs
right
so
things
the
works
were
optimizing
for
from
an
engineering
perspective
is
rapid
innovation
right.
We
want
even
more
a/b
tests
to
look
holistically
test,
the
user
experience.
We
want
to
make
sure
that
we're
available
on
every
single
device.
That's
out
there
performance,
really
matters
right:
the
faster
you're
able
to
load
that
stuff
the
easier
it
is
for
you
to
consume
the
content
and
for
customers
to
be
to
enjoy
the
great
content.
So
what
this
really
meant
is
we?
A
You
know
these
teams
really
wanted
to
customize
the
APR.
They
wanted
to
be
able
to
change
that
REST
API
on-the-fly
whenever
they
like
to
store
new
features
and
you
a/b
test.
That's
specifically
crafted
for
their
own
clients
and
they
don't
have
to
share
with
any
other
clients
right,
because
you
know
you're
the
you're,
the
web
team
and-
and
you
want
a
specific
API
and
maybe
the
TV
team
wants
something
completely
different
cuz
the
UI
looks
different
when
you
know
are
different,
so
they
want.
We
wanted
to
derive
these
tailor-made
api's
and
the
existing
rest.
A
Api
didn't
really
scale
right.
It
was
being
flexible
again,
multiple
requests
around
trips
to
load
a
page,
and
we
want
to
be
able
to
move
from
one
API
to
custom
API,
as
the
team
can
craft
themselves
and
be
able
to
change.
So
what
did
the
next
version
of
our
API
infrastructure
look
like?
Well,
we
named
the
API
dot
next,
and
it
was
something
like
this
right.
So
we
have
this
API
server,
that's
owned
by
our
edge
services
team
and
instead
of
have
a
one,
rigid,
strict,
REST
API.
A
We
now
let
these
teams
upload
their
own
custom
API
to
the
service.
So
you
can
upload.
You
know
any
number
of
these
custom
ApS
that
you
you
crafting
in
a
groovy
script
form
and
these
scripts
are
unique
and
sort
of
specific
for
yourself,
so
you
can
change
them.
However,
you
like
the
team
ache
and
you
know,
change
50
different
versions
of
their
scripts
without
affecting
team,
B
and
they're.
Integrating
these
little.
These
little
data
access
ap
is
against
the
Netflix
back
in
with
with
the
clients,
libraries
that
edge
services
provides.
A
So
you
know,
there's
no
more
new
deployments,
that's
needed
whenever
you
need
to
upgrade
your
API
s
or
change
your
APS
or
add
a
new
API,
so
you
just
simply
add
upload
them
to
the
to
the
API
dot
next
service
and
the
API
server
itself
can
be
updated
independently
of
all
of
these
different
ApS
that
you're
writing-
and
this
was
in
for
infrastructure
list
as
well.
So
these
client
teams
now
get
the
flexibility
of
authoring
their
own
API
without
having
to
run
in
the
infrastructure.
A
But
let's
play
that
game
again,
which
is
spot
the
model
with
write
worse
tomorrow.
That's
this
time.
It's
there
right
still
back
there
and
that's
because
and
we're
actually
we're
actually
running
into
some
scaling
problems
now
with
a
small
of
across
so
this
is
they
actually
API
infrastructure?
That's
available.
Today,
that's
running
all
of
the
Netflix
and
let's
take
a
moment
talk
about
some
of
the
scaling
challenges
that
we
have
right.
A
We've
got
about
forty
three
billion
hours
and
we're
watching
that
was
watching
2015
and
we
have
billions
of
RPS
per
day
through
the
system,
and
so
we
have
thousands
of
these
custom
API
scripts
of
what
activate
active
active
in
product
any
one
time
even
more
in
test.
Tens
of
thousands
and
all
of
these
go
through
hundreds
of
changes
a
day,
and
we
have
hundreds
of
a/b
tests
with
lots
of
variants
per
test.
So
there's
a
lot
of
skill
happening
within
this
one
single
model
ethic
system
and
because
all
these
scripts
living's
have
one
process.
A
There
are
some
scaling
issues
right.
We're
quickly
running
some
vertical
scaling
issues.
You
can
imagine
all
these
scripts
have
to
live
inside
one
process
so
running
out
of
headroom,
whether
that's
memory,
CPU
or
I/o
right
and
there's
a
cost
associated
to
this
as
well
right,
because
each
of
these
really
really
large
instances
are
really
expensive
and
in
addition
to
that,
all
these
scripts
living
together
inside
one
process
is
in
the
best
scenario
right.
A
You
know:
we've
had
some
outages
in
the
past
due
to
the
fact
that,
like
one
script,
had
a
memory
leak
or
had
a
problem
and
that
ended
up
taking
down
the
entire
process,
which
meant
that
every
single
client
was
unavailable
right.
Just
because
say
you
know
the
I'm,
just
picking
at
the
TV
UI
team
pushed
the
bad
build
of
their
own,
their
access
api's.
They
ended
up
taking
down
the
entire
netflix
stack.
So
when
best
we
can
take
out
every
one.
That's
not
good
right
and
there's
also,
you
know
in
Java,
conflicting
dependencies.
A
A
Additionally,
Deval
core
developer
ergonomics
wasn't
that
great
either,
because
there's
this
natural
separation
down
the
middle
right
on
the
left
is
everything
that
a
UI
engineering
team
would
own,
which
is
both
the
client
code,
which
you
know
90%
of
our
clients,
are
written
in
JavaScript
and
then
the
data
access
API
switch
with
their
writing
groovy
script,
which
does
anyone.
People
have
heard
of
groovy,
I
hope
right
at
least
a
couple
hands
couple
hands,
but
it's
not
ideal
and
then
on.
A
The
right-hand
side
of
the
big
box
is
where
everything
that
systems
engineering
owns
right,
all
the
backend
sort
of
traditional.
You
know:
service
service
ownership,
service
teams
that
you
would
imagine
and
deploying
this
monolithic
process
takes
hours
right,
and
so
it's
it's
a
huge
amount
of
the
process.
You
can't
run
this
stuff
locally
so
for
engineers
who
are
writing
these
data
access
api's
instead
of
evil
to
run
and
debug
everything
locally,
they
actually
have
to
upload
these
scripts
to
a
test.
A
A
set
of
tests,
instances
right
and
then
hit
them
with
curl,
whatever
to
see
if
they
work
and
if
they
don't
work
out
print
line,
statements
and
repeat
the
process,
it's
very,
very
painful
and
it
slows
down
our
innovation,
which
is
something
we
talked
about
right.
So
with
all
these
things
in
mind,
what
have
we
learned
from
all
these
previous
incantations
right
and
let's
talk
about
sort
of
what
our
future
sort
of
facing
API
will
look
like
wait.
How
do
we
get
more
and
more
devices
and
get
faster
velocity
of
change?
A
So
what
would
our
goals
be
for
to
create
the
next
generation
of
API?
My
platform
right
I
think
it
comes
down
to
three
things,
which
is
scalability
availability
and
developer
productivity
and
we'll
go
through
these
in
detail.
So
let's
talk
about
scalability
availability
right.
The
biggest
thing
here
is
process
isolation,
because
again
we
don't
want
to
take
an
outage
because
one
data
access
script
has
blown
up,
so
we
want
to
be
able
to
horizontally
isolate
all
these
data
access
codes
from
each
other.
This
also
helps
us
reduce
infrastructure
costs.
A
A
We
also
want
faster
startup
times
right
and-
and
we
want
an
immutable
deployment
artifact
so
that
we
can
easily
reproduce
the
different
builds
that
we
have
it's
available.
What
about
developer
quality
productivity
right?
And
we
often
don't
really
think
about
this,
but
this
is
actually
one
of
the
really
important
tasks
from
all
of
our
engineering
teams,
which
is
that
one
they
want
to
code
in
JavaScript
on
the
server
on
and
on
the
client
right.
They
don't.
A
Nobody
wants
to
run
googly
scripts,
but
it
even
more
important
than
that
they
never
ever
want
to
have
to
wait
like
ten
minutes
between
turnarounds
I've
developed
debugging
their
scripts.
They
want
to
be
the
run
and
debug
everything
locally
step
breakpoints.
You
know
they
want
fast
incremental
builds
and
they
want
an
environment
that
closely
mirrors
production
as
possible,
right
I.
A
A
So
let's
look
at
the
API
evolution
right,
so
we
start
with
the
monolithic
API
to
our
next
server,
where
you
upload
your
data,
access
scripts
and
everything
lives
together,
and
we
talked
about
the
fact
that
there's
this
natural
separation
right
down
the
middle
right
where
we
have
these
data
access
API,
is
on
one
side
and
these
other
servers
to
integrate
against
the
back-end
services
on
the
other
side.
So
what
could
the
next
generation
data
access?
Api?
Look
like
well,
it'll.
A
Look
something
like
this
right:
we've
taken
all
those
data
access,
api's
and
move
them
out
in
through
separate
apps
as
pond
that
they're
now
running
no
Jess,
which
is
great
and
these
these
scripts
that
used
to
be
grew.
We
are
now
running
note
and
they're,
also
horizontally,
isolating
running
inside
of
a
dark
container,
we'll
get
into
the
details
of
that
platforming
a
little
bit
in
the
next
couple
of
slides,
and
we
also
migrated
the
other
side
of
that.
A
Mold
platform
into
something
we're
calling
the
remote
service
layer,
so
that's
the
Java
based
and
it's
still
inner.
It's
still
doing
all
the
integration,
the
heavy
lifting
that
integrates
against
the
back-end
services,
but
it's
just
one
consistent
API
and
whenever
our
developers
on
the
front
I
want
to
craft
new
API,
they
simply
just
have
to
push
new
JavaScript
on
the
server
in
the
form
of
a
node.js
container.
So
that's
this.
This
talk,
we're
gonna,
focus
more
on
the
front-end
part
cuz.
A
It's
a
we're
at
an
O
conference,
so
we're
gonna
talk
about
the
node
API
platform
itself.
So
what
is
that
right?
It's
the
new
API
platform.
It's
literally
a
set
of
JavaScript
data
access
scripts.
That's
when
a
node
and
our
HD
framework
we
use
that
and
that
folks
called
Resta
Phi
and
it's
all
running
instead
of
a
docker
container.
A
So
if
you
remember
those
groovy
scripts
that
were
that
were
being
injected
into
the
single
model,
if
now
they're
injected
into
their
own
isolated,
docker
containers
right,
that's
really
powerful,
because
that
means
that
you
know
we're
getting
a
horizontal
isolation
and
a
bunch
of
the
other
goes
that
we
talked
about
or
what
walks
out
in
the
next
few
slides.
So
how
do
we
go
from
that
design
on
paper
to
a
new
API
running
in
the
cloud
at
our
scale?
A
Right
we
have
the
investig--
investing
a
bunch
of
things,
so
the
things
that
we've
been
investing
in
is
the
runtime
platform.
Application
management
is
just
how
do
we
manage
now?
These
potentially
hundreds
of
these
different
API
applications,
that's
owned
by
UI
engineering
teams?
What
about
the
container
infrastructure,
because
we've
traditionally
only
run
on
VMs
that
Netflix,
the
hobby
marriage,
this
new
sort
of
paradigm,
shifting
deploying
deploying
infrastructure
and
what
about
developer
tools
right?
We've
had
some
developer
productivity
gains
that
we
wanted
to
hit
as
well.
A
So
let's
talk
about
the
runtime
platform,
I
was
I
was
trying
to
write
this
out
the
slide
I
just
done
there's
this
talk.
I
came
upon
this
kind
of
funny
quote
on
Twitter,
which
was
that
a
full
stack
developer
is
one
who
can
add
technical
debt
to
any
player
the
application
right
and
and
I
know
this
is
this
is
kind
of
joking,
but
there's
some
truth
in
this
and
the
truth
in
this
isn't
really
it's
more
like:
hey
we've
hired
these
really
great
world-class
UI
engineers
right.
Why
would
we
have
them?
Go
run
servers
right?
A
It
doesn't
really
make
sense
where
that's
not
where
their
expertise
is.
Their
passion
is
right,
so
they
don't
care
about
that
either
that
we
want
to
do
what
the
we
want
them
to
do,
what
they're
good
at,
which
is
right
and
really
awesome
reactive.
You
use
their
interfaces,
so
our
aim
here
was
to
provide
a
paved
path
for
these
data
access.
Apps
right.
A
We
have
a
great
set
of
sub
systems
and
Netflix
and
let
you
run
reliably
and
availablee
any
services
at
scale
right
and
our
job
is
to
provide
a
platform
on
no
that
provides
integration,
full
integration
with
all
of
a
sudden,
Netflix
subsystems,
so
that
things
like
metrics
alerts,
you
know
all
scaling
low,
balancing
service
discovery
analytics
all
the
stuff
that
you
know.
We
already
have
a
Netflix.
We
just
want
to
be
able
to
provide
this
for
free
tuning
engineers,
who
are
writing
an
O
based
data
access,
API
right
and
yeah.
A
We've
hired
some
really
great
UI
engineers,
so
you
know,
let's,
let's
have
them
do
what
they're
great
at
right.
If
you
ask
me
to
write
you
eyes,
it'd
probably
just
be
tables
so
I
mean
you
know:
you're
gonna,
you
know
make
sure
you're
you
were
investing
in
the
right
places.
So
what
is
the
no
runtime
right?
Well,
the
no
runtime
we've
provided
some
very
platform
as
a
service
model.
A
So
again,
we're
maintaining
same
contracted
that
these
writers
had
before
with
the
API
down
max
infrastructure,
which
is
that
they
don't
only
any
the
infrastructure
right
and
so
we're
providing
a
production
ready,
no
platform
and
all
they
have
to
bring
is
just
functional,
JavaScript
business
logic,
so
they're
implementing
like
a
middleware
expressed
type,
ratify
type
Handler
and
age
they're,
just
building
that
into
their
application,
and
everything
else
is
free
right.
All
the
sort
of
integrations
with
a
Netflix
ecosystem
service
discovery.
Metrics
logging
analytics
all
that
stuff,
alerting
all
that
stuff
you
just
get
for
free.
A
Of
course,
we
give
you
the
flexibility
if
you
want
to
sort
of
peel
that
back
and
play
around
and
make
make
changes
to
that.
But
ideally
you
know
when
you
just
bootstrapping
your
application,
like
that,
like
this,
everything
already
just
exists
right
yeah,
our
focus
here
is
for
it
to
be
infrastructure
list.
For
these.
Do
our
engineers
do
not
have
to
worry
about
running
for
structures
that
scale
but
really
to
craft,
really
great
unique
experiences
for
our
customers,
so
about
application
management
right
here
again
with
this.
A
This
is
something
complete
to
the
staff,
because
now
we're
taking
one
model
with
I'm
breaking
it
apart
into
multiple
discrete
applications,
the
three
things
that
we
were
thinking
about,
which
is
versioning
deployment
and
operational
insights
right.
So
in
terms
of
versioning,
these
you
have
to
realize
that
these
API
is
they
change
all
the
time
right.
So
there's
literally
hundreds
and
thousands
of
different
versions,
because
you
can
make
changes
to
these
ApS
anytime.
You
like
in
the
past,
we
have
sort
of
an
inconsistent
bursting
issue
which
is
like
every
team.
A
Just
came
up
with
their
own
sort
of
version
schemes
like
TV
would
use
the
timestamp
and
maybe
web
users
a
gift
shot.
Some
other
team
will
use
an
integer,
and
this
is
wildly
inconsistent
and
really
hard
to
manage,
and
so
our
goal
here
was
to
get
consistent
versions
of
reproducible
build.
Is
there
something
from
the
node
ecosystem?
Okay,
to
use
the
manage
versions?
Of
course
right
we
could
just
use
somewhere,
so
we
decided
to
actually.
A
Not
only
do
you
know
the
weeds
we
all
use
summer
for
packages
we're
actually
we're
actually
now
using
somewhere
to
manage
all
of
our
services.
As
well
so
we
build
sort
of
an
NPM
for
services,
a
Netflix
called
the
node
API
index
and
that
actually
immutably
tracks
all
the
versions
of
all
of
your
applications
that
you've
published
cement
with
the
semantic
version.
A
What
about
routing
right
back
in
the
in
the
old
system?
You
know
we
we
would
have
to
route
based
on
the
actual
path
of
the
of
the
API
itself.
Well,
this
was
a
problem
right
because
we
have
applications
out
there,
our
clients
out
there.
There
are
long
live
clients,
and
so
these
are
baked
into
the
apps
themselves
and
so
I'd
say
I've
shipped
an
iOS
client
and
it's
out
version
1.3
point
two
and
that's
baked
into
my
app.
A
Just
like
how
npm
is
resolving
your
dependencies
and
gets
gives
you
the
latest
version
of
that.
Whatever
thing
that
you're
matching
in
this
case,
it's
the
same
thing
right.
We're
able
to
upload
update
the
versions
underneath
the
hood
and
even
though,
and
because
we're
floating
were
able
to
just
resolve
to
the
latest
version
of
that
application
and
with
the
operational
insights
we
build
in
this
rich
set
of
operational
insights
into
the
application
that
you
list
and
view
all
your
deploy,
apps
and
their
routes,
the
development
deployment
history
and
our
X
metrics.
A
Good
example
of
this
is
like
no
generator
dashboards
that
you're
able
to
get
whenever
you
deploy
an
application
again,
like
you
as
a
UI
engineer,
for
example,
don't
have
to
do
any
of
this.
All
this
stuff
just
shows
up
shows
up
what
about
the
third
section,
which
is
container
infrastructure
right.
As
you
all
know,
we
need
this
sort
of
sort
of
our
first
foray
into
containers.
We
built
something
called
titus,
which
is
our
own
sort
of
homegrown
container
management
scheduling
system.
A
This
is
his
own
talk,
so
I'm
not
gonna,
go
too
much
into
it,
but
if
you're
curious
go
check
it
out,
but
it's
it's
a
it's,
the
it's
an
infrastructure
with
which
were
able
to
reliably
deployment
containers
in
the
cloud
and
the
last
section
is
really
undeveloped.
Err
tools-
and
you
recall,
our
aim
here-
is
developer
productivity
right.
The
biggest
thing
is
hey:
I
want
to
be
able
to
develop
and
test
and
do
everything
locally.
A
I
never
want
to
have
to
upload
and
wait
to
test
my
service,
and
the
problem
here
is
even
if
we're
using
docker
I'm
able
to
drop
these
docker
containers
locally
onto
my
desktop
if
I
make
changes
and
I
build
a
new
docker
image
that
build
all
the
doctored
stuff
and
building
the
dollar
dependencies
and
then,
ultimately,
the
docker
image
still
takes
tens
of
minutes
right
and
so
I
got
four
slides
left
just
so
I'm
almost
done
so
so
that's
that's
an
issue
right.
So
how
do
we
solve
that
problem?
A
Well,
we
create
this
really
unique
set
of
tooling.
That
lets
you
rapidly
develop
locally.
So
we've
done
is
mapped,
mapped
your
workspace
from
your
local
host
into
the
docker
guess,
that's
running
locally
and
whenever
you
make
changes
on
your
laptop
I
guess
map
into
a
docker
container,
that's
running
inside,
of
you're
inside
your
development
environment,
and
so
these
changes
are
reflected
back
and
forth
and
so
they're
basically
automatically
picked
W.
So
the
dart-
and
we
have
tooling
that
rebuilds
your
dependencies
or
restarts
the
application.
A
So
as
a
quick
recap
right,
the
reason
we
went
with
containers
is
like
if
they
give
you
process
isolation
and
a
layer,
dependency
management
and
portability
request
environments
right
so
I
can
take
a
image
that
deployed
the
pradhan
brilliant
test
and
test
that
it
gives
me
fast
deployments
and
a
single
deployment
artifact,
and
this
lets
me
test
my
build
artifacts
anywhere
in
the
cloud
or
locally.
Even
I
would
note,
as
you
all
know
here,
on
the
reason
we
chose
notice
them.
A
We
could
use
JavaScript
everywhere,
write
client
and
the
server,
so
it's
really
easy
for
engineers
when
they're
writing
their
their
apps
to
both
Mike
JavaScript
on
the
client
server,
its
performant.
It's
lightweight,
you
know,
there's
a
probe
ecosystem
and
all
the
NPM
modules
it's
built
for
the
web.
A
So,
as
a
recap,
you
know
the
three
themes
that
we
really
focused
on
for
the
new
no
platform:
one
developer
productivity
right,
really,
let
you
run
debug
and
test
things
locally,
fast,
incremental
builds
and
scalability
availability
right
breaking
that
model
with
into
micro
services
running
instead
of
a
target
and
tanner
running
node
with
process
isolation,
so
we're
getting
better
availability.
Everything
is
horizontally
scalable
and
we
have
immutable
diploma
artifacts,
and
so
today,
I
walk
you
guys
through
sort
of
our
you
know
our
sort
of
our
journey
in
the
Netflix
API
and
we've.