►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Why the future of the cloud will be built on Rust - Oliver Gould, Buoyant
For consideration as a keynote. In this presentation, Oliver Gould, creator of Linkerd---the first CNCF project to incorporate Rust, and a major driver of the early Rust networking ecosystem---will present an argument that the future of cloud software and the cloud native ecosystem will be tied to the Rust programming language. Oliver will argue that, while Go is the lingua franca of the *current* cloud native ecosystem, Rust will be the lingua franca--or at least one lingua franca---of the *future* ecosystem. He will draw parallels between the constraints of cloud environments, the core principles of the cloud native ecosystem, and the principles of Rust itself, grounded in concrete examples from Linkerd's Rust proxy as well as other projects. Finally, he will present a roadmap for the future of Rust in the cloud native world, both as captured by the CNCF ecosystem and beyond.
A
Hi
thanks
for
coming,
this
talk
is
about
why
rust
is
going
to
be
a
foundational
technology
to
the
future
of
cloud
native
infrastructure.
Before
I
get
to
that,
let
me
introduce
myself.
My
name
is
oliver
gould.
These
are
my
dogs
and
I'm
the
creator
of
a
project
called
linkery,
a
service
mesh.
That's
been
part
of
cncf
since
2016.,
I'm
also
the
cto
of
a
company
called
buoyant
where
we
make
this
and
some
other
infrastructure
tools.
A
This
talks
basically
three
parts.
First,
I
want
to
take
you
through
a
brief
history
of
the
cloud
from
my
perspective.
Next,
I
want
to
get
into
the
details
of
why
I
think
russ
is
so
important
to
cloud
technology
and
then
we'll
wrap
this
up
with
a
quick
tour
of
the
rust
toolkit
that
we
use
in
linkery.
A
So
I
want
to
emphasize
this
is
when
we
talk
about
the
history.
This
is
the
history
from
my
perspective,
like
all
history
subjective,
and
so,
if
you
may
have
been
in
the
industry
through
this
whole
time,
you
may
have
a
slightly
different
perspective
of
things.
That's
fine,
but
I
I
think
it's
important
to
set
the
table
for
for
where,
where
we've
come
from
before
we
talk
about
where
we're
going
so
when
I
entered
the
industry
when
I
started
working
at
yahoo
in
2007,
yahoo
was
a
big
old
internet
company.
A
They
had
literally
millions
of
physical
hosts
that
were
managed
and
they
were
managed
by
dozens
of
hardware
teams,
people
and
data
centers
people,
provisioning
hardware,
and
also
dozens
of
system
and
teams.
So
our
team
in
production
operations
was
one
of
many
responsible
for
managing
these
hosts
these
fleet
of
hosts
across
the
world.
A
But
it's
really
a
different
way
of
requiring
for
getting
hardware
than
we
do
today
and
the
first
problem.
I
really
started
working
on
there.
The
problem
I
worked
on
through
most
of
my
time
at
yahoo
was
config
management.
So,
across
these
millions
of
hosts,
how
do
we
make
sure
that
they
get
security
patches?
How
do
we
make
sure
that
new
users
of
the
company
get
access
to
the
host
or
when
a
user
leaves
the
company
that
they
no
longer
have
access
to
the
host?
How
do
we
manage
the
proliferation
of
configuration?
A
This
is
a
hard
problem
and
we
worked
on
this
for
for
years,
and
this
wasn't
unique
to
yahoo
lots
of
companies
at
the
time
were
going
through
similar
problems.
They
all
had
to
manage
hosts
to
be
connected
to
the
internet
securely,
and
so
the
proliferation
of
projects
came
around
this
first
cf
engine
long
time
ago,
written
in
c,
and
then
you
know
in
the
mid
2000s
to
late
2000s.
A
We
saw
new
products
coming
on,
mostly
in
ruby
or
python
projects
like
puppet
chef,
ansible
and,
of
course,
others
and
the
job
of
a
config
management
system
is
kind
of
simple
a
little
bit.
They
mostly
have
to
run
commands
and
generate
templates.
These
scripting
languages
that
were
really
coming
to
popularity
at
the
time
were
good
fit
for
that.
A
They're
they're
system,
scripting
languages
and
the
real
job
of
config
management
systems
is
to
make
the
host
able
to
run
an
application
and
frequently
config
management
systems
were
responsible
for
actually
deploying
code
for
getting
application
software
ready
to
run.
This
meant
there's
a
pretty
tight
coupling
between
your
hostess
database
and
your
actual
application.
A
It's
not
really
where
we
are
today,
obviously
around
the
same
time
so
early
well,
really.
Throughout
the
early
2000s
we
saw
a
new
proliferation
of
virtualization
technology
come
online,
so
projects
like
freebsd
jails,
kind
of
in
the
earlier
side
and
then
zen
and
solaris,
and
building
up
to
linux
c
groups,
which
so
much
of
what
we're
talking
about
today
is
built
on
really
the
job
of
these
virtualization
technologies
made
systems
multi-tenant.
So
no
longer
do
I
have
to
have
a
single
host
with
a
single
application
or
even
a
single
user
or
customer.
A
Now
I
can
run
multiple
operating
systems
on
a
single
piece
of
hardware,
and
this
really
really
change
the
game.
Of
course,
all
this
stuff
is
very
low
level
operating
system-
that's
maybe
written
in
c
at
best,
but
also
lots
of
assembly
to
get
this
stuff
done,
because
you're
virtualizing
hardware
you're.
Actually
you
know
mimicking
what
a
machine
does.
A
A
And
I
remember
having
a
conversation
with
a
colleague
with
netflix
and
probably
2009
or
2010,
where
he
told
me
how
netflix
was
moving
from
their
aix
mainframe,
so
netflix
originally
was
on
ax
mainframes
and
how
they
were
moving
to
aws,
and
this
made
no
sense
to
me
again.
I
was
working
at
yahoo
with
these
massive
fleets
of
bespoke
systems
and
the
idea
that
a
growing
popular
internet
company
would
go
to
amazon's
infrastructure.
It
didn't
make
any
sense
to
me
boy
was
I
wrong.
A
So
the
great
thing
about
this,
as
we
all
know,
is
that
it
made
service
accessible,
there's,
no
longer
a
hardware
review
committee.
I
have
to
go
to
to
get
a
new
server,
there's
no
longer
some
of
the
data
center.
I
have
to
call
to
get
out
to
fix
a
server,
and
I
now
just
have
an
api
and
a
credit
card
and
I
get
access
to
a
server.
I
get
an
internet
connected
server.
A
This
means,
as
students
we
actually
can
just
get
online
and
get
server
technology
easily
and
as
startups
and
businesses,
we
get
access
to
these
things
without
having
to
get
data
center
contracts
or
any
of
the
kind
of
overhead
that's
really
associated
with
the
time
before
this.
The
other
interesting
thing
here
is
that
linux
is
really
tied
to
this
right.
Linux
does
not
generally
require
licenses
to
operate,
and
so
this
was
a
great
fit.
I
no
longer
have
to
get
a
microsoft
or
whatever
license
to
get
into
prod.
A
I
now
just
get
a
free
operating
system,
and
I
also
no
longer
have
to
worry
about
the
vast
array
of
driver
compatibility
issues
which
were
kind
of
a
headache
before
this.
So
now
I
can
just
make
an
api
call,
click
a
button,
and
I
get
a
server
that's
ready
to
operate
on
the
internet,
which
is
great,
really
reduces
the
barriers
to
getting
involved
in
server
technology.
A
We
also
have
no
control
over
the
hardware
using
very
little
control
of
the
hardware
we're
using,
which
means
we
have
kind
of
less
reliability
there.
We
don't
no
longer
are
we
trying
to
have
one
super
power
machine
stay
online,
all
the
time
now
we're
kind
of
dealing
in
a
world
where
systems
might
fail
and
we
can't
call
any
data
or
deal
with
them.
We
really
have
to
consider
variable
variable
performance.
A
No
longer
do
I
have
exclusive
access
to
a
machine
I
might
have
other.
You
know
other
businesses
running
on
this
machine
that
are
dealing
with
lots
of
traffic,
and
so
these
concerns
end
up
changing
how
we
actually
think
about
operating
services.
We
have
a
whole
new
set
of
failures,
soft
failures,
more
frequent
failures
and
this
kind
of
gives
birth
to
a
new
way
of
testing
a
new
methodology
called
chaos.
Testing
also
coming
out
of
netflix,
probably
in
2011
or
so.
A
So
no
longer
do
we,
as
as
someone
who's
operating
a
service,
do
I
have
to
think
about
config
management
or
ssh
into
a
host
or
kind
of
all
the
overhead
of
that.
Now.
What
we're
thinking
of
through
projects
like
mesos
and
aurora
are-
I
just
want
to
ship
my
workload?
I
want
to
write
software,
build
an
artifact,
get
it
running,
and
this
was
really
great
for
twitter
and
other.
You
know
growing
scaling
companies,
uber,
lyft,
etc.
A
Where
you
now
now
need
to
focus
on
developer
productivity,
we
have
hundreds
of
engineers.
How
do
we
get
them
to
write
software
ship
under
prod
quickly
without
having
to
think
about
all
the
operational
overhead?
How
do
we
stratify
that
separate
that
the
downsides
of
these
projects
were
that
they
were
really
operationally
complex?
A
It
was
pretty
hard
or,
if
not
impossible,
to
run
a
full
mesos
cluster
on
your
laptop.
You
actually
need
quite
a
bit
of
hardware
to
get
started
or
you
need
some
pretty
beefy
cloud
boxes
to
get
started,
and
so
there
is
some
overhead
here.
This
is
not
a
broadly
accessible
technology
that
didn't
get
started
with.
A
Also
we're
dealing
with
a
lot
of
you
know:
jvm
runtime,
which
comes
with
runtime
costs,
overhead
memory,
cpu
and
operational
costs
in
terms
of
debugging
gc,
and
things
like
that
and
in
this
world.
We're
dealing
with
you
know
highly
just
highly
dynamic
systems
where,
where
mesos
may
reschedule
pods
or
instances
without
there
being
any
kind
of
user
involvement,
and
so
we
have
to
deal
with
things
like
service
discovery
and
load,
balancing
and
retries
and
timeouts,
and
all
the
things
that
kind
of
are
necessary
to
manage
services
of
the
scale
and
so
twitter.
A
We
were
working
on
a
library
called
finagle
and
that's
really
what
came
to
be
the
core
of
the
first
version
of
linkedin,
and
so
you
know,
as
we
dealt
with
all
of
these
production
issues
and
dealt
with
making
communication
more
reliable
in
this
library
called
finagle
the
idea
with
linker
to
you
as
well.
How
do
we
package
that
up
into
a
proxy
and
make
that
accessible
to
folks
who
are
not
writing
software
with
finagle.
A
Following
that
or
kind
of
around
the
same
time,
there's
what
the
you
know,
a
new
set
of
technologies
coming
on
that
what
we
call
cloud
native,
so
it
really
kind
of
starts
with
docker
in
a
lot
of
ways.
So
docker
is
building
on
linux
c
groups.
The
technology
we're
talking
about
a
little
bit
ago
and
docker
makes
it
possible,
as
many
of
you
know,
I'm
sure,
to
package
up
an
application
and
ship
it
somewhere
and
get
it
running
with
resource
constraints,
and
so
it
kind
of
avoid.
A
A
So
we
deal
with
fault
tolerance.
We
deal
with
the
fact
that
we
have
to
load
balance
and
a
lot
of
these
things.
Kubernetes
and
linker
d,
especially
docker
as
well
focus
on
user
experience
on
reducing
the
costs
of
managing
it,
getting
started
of
understanding
it
to
make
it
accessible
for
application
owners
to
get
running,
and
so
we
focus
on
applications
and
not
hosts
we're
finally
broken
that
those
barriers
down.
A
A
This
is
really
in
in
linguity,
there's
kind
of
two
halves
of
this.
We
have
a
control
plane
which
talks
to
the
kubernetes
api,
which
deals
with
a
lot
of
the
configuration
and
discovery
and
the
fact
that
things
are
dynamic
and
feeding
them
to
proxies,
and
the
proxies
are
supposed
to
be
very
lightweight
small
instances
that
can
fit.
A
We
don't
want
to
have
to
write
a
kubernetes
client
from
scratch
and
think
about
all
the
complexity
of
what's
in
a
kubernetes
client-
and
this
is
again
three
plus
years
ago,
when
we
were
starting,
we
wanted
linker,
d's
control
plane
to
be,
you
know,
feel
like
part
of
the
kubernetes
ecosystem.
So
we
chose
go
for
that,
but
when
we
start
went
to
write
the
proxy,
the
sidecar
proxy,
we
chose
rust
and
that
has
been
a
great
experience.
But
when
we
were
starting,
it
was
really
rough.
Around
the
edges
we
had
to
bootstrap
ourselves.
A
A
Right,
though,
I
as
an
engineer
can
write
a
data
plane
proxy,
a
you
know,
a
micro
service
proxy,
and
I
can
do
that
with
high
confidence
that
it's
not
going
to
have
memory
leaks
or
memory
safety
issues,
and
that
will
do
the
job
well
and
we
want
to
use
this
to
build
cloud
native
technology,
and
so
the
cloud
native
systems
are
again
dynamic,
network
fault,
tolerant
and
loosely
coupled,
and
so
these
things
end
up
actually
aligning
pretty
closely
and
I'm
going
to
get
into.
Why?
A
Every
talk
I
do
has
this,
but
we
look
at
the
application
stack
or
the
networking
stack
and
we
see
all
these
layers,
but
really
what
we're
talking
about
for
for
applications
for
the
people,
building,
websites
and
and
user-facing
applications.
This
is
how
the
world
looks.
They
should
only
really
care
about
their
application
logic,
whether
it's
tweets
or
pictures
or
payments
or
whatever,
and
maybe
the
presentation,
whether
that's
jason
or
protobuf,
or
you
know
the
details
of
how
it's
rendered
and
then
shared,
but
everything
beneath
that
is
infrastructure.
A
It's
the
cloud,
but
somebody
has
to
build
that
stuff,
and
that
stuff
is
us,
and
so
you
know
down
at
the
bottom.
We
have
physical
layers
and
link
layers
which
are
really
you
know,
part
of
the
cloud
providers
or
or
data
center
or
hardware
right
and
in
this
middle
glue.
Layer
is
where
we
spend
all
our
time
as
infrastructure
developers.
A
A
This
so
what
we're
all
becoming
is
system
programmers.
Anyone
working
in
the
cloud
native
space
is
really
not
an
application.
Developer
applications
are
end
user
facing
system,
programmers
build
software
that
supports
applications
and
generally
these
things
have
to
be
highly
trustworthy,
meaning
that
they're
going
to
work
safely
and
correctly
and
they're
generally
have
you
know
pretty
tight
performance
requirements,
and
this
is
really
where
rust
fits
in.
A
Rust
is
a
native
language,
meaning
reaction
compiled
a
native
code,
we're
not
running
in
a
you
know
a
jit
or
a
runtime,
a
vm,
and
so
we
have
access
to
low-level
memory
primitives
and
things
like
that.
But
we
also
need
to
do
that
safely
and
that's
where
I
think
rust
really
shines,
and
so
I'm
going
to
walk
through
some
comparisons.
A
I'm
going
to
compare
it
to
go
because
go
is
what
I
know
well
and
really
what
is
the
kind
of
state
of
the
art
in
the
cloud
native
and
we'll
talk
about
where
rust
really
makes
improvements
over
the
current,
the
current
state
of
things?
So
here's
a
really
simple
example,
a
function
that
fails,
and
I
call
it
and
I
ignore
the
error.
A
A
Let
us
express
constraints
in
a
much
richer
way
and
really
the
goal
of
all
of
what
we're
doing
here
is
taking
things
that
might
fail
one
at
runtime
when
the
application's
running
and
trying
to
make
them
fail
before
we
even
build
the
thing
before
we
test
it
as
early
as
possible
during
the
compilation,
phase
and
rust
really
excels
at
this,
so
here
same
function
that
just
fails.
If
we
ignore
the
error,
russ
will
actually
emit
a
compiler
warning
in
linkerity.
A
This
will
prevent
linker
d
from
building
and
we'll
have
to
fix
this
before
we
go
on
another
example,
pretty
similar
here
is
a
place
where
I
access
an
initialized
value
and
we've
had
this
type
of
bug
in
the
linkedin
control,
plane
or
cli
countless
times
more
times
than
I
can
character
that
I
than
I
wish
right
this.
This
is
a
a
big
pain
in
my
neck
and
russ
again
makes
this
simple
with
a
type
system.
So
no
longer
can
I
access
something
that
hasn't
been
initialized.
A
A
A
Similarly,
concurrency
becomes
a
big
issue,
especially
in
a
proxy
like
linker
d's.
We
have
multiple
connections
and
requests
going
at
once.
We're
talking
the
control
plane,
there's
lots
of
concurrent
access
and
in
go.
This
can
be
quite
dangerous
by
default,
so
here
I've
written
just
this
actually
from
the
the
go
by
example,
website
where
they
demonstrate
how
to
use
mutexes-
and
here
I've
just
left
the
mutex
out
and
go
will
happily
compile
and
it'll
even
run.
A
So
if
I
run
this
thing
for
a
second
go
works,
just
fine,
which
is
great
right
unless
I
run
it
for
longer,
so
I
increase
the
runtime
here
to
10
seconds
and
all
of
a
sudden,
I
hit
an
error.
So
this
is
completely
non-deterministic
right.
I
can
write
tests
that
pass
and
then,
when
I
ship
it
to
prod,
this
thing
can
fail
in
an
unexpected
way.
A
Somebody
has
to
own
this
thing,
and
so
this
idea
of
a
borrower
checker,
is
really
an
ownership
model
for
who
owns
memory,
who
is
responsible
for
this
or
what
code
is
responsible
for
this
means
that
I
can't
even
compile
this
code
in
rest
because
I
it's
unsafe,
the
axis
patterns
aren't
safe
and
so
to
fix
this
I
actually
have
to
go
and
put
a
mutex
in.
This
is
the
same
fix
effectively
that
should
exist
in
the
go
code,
but
the
compiler
enforces
in
rest.
A
And
then
I
have
another
task
that
continually
reads
from
that
channel
and
if
I
run
this,
it
runs
until
that
error
happens
and
we
hit
a
deadlock
and
go
exits,
which
is
great,
I
mean
go,
should
fail
in
this
case
because
that's
the
best
it
can
do,
but
we
can
do
better
in
rust
and
rust.
I
have
this
type
system
again
and
what
the
type
system
tells
lets
me
do.
Is
I
get
an
optional
value
back
and
so
there's
no
more
runtime
failure
here.
A
A
So
this
is
an
example
of
the
type
of
safety
net
that
we
get
from
rust
and
why
you
know
we
haven't
even
gotten
to
any
of
the
details
around
memory,
access
or
you
know,
russ
kind
of
provable
safety,
but
these
are
all
sorts
of
ways
that
we
take
failures
that
could
happen
at
runtime
after
I've
shipped
my
software
to
production.
When
I
hit
a
weird
corner
case,
where
things
can
crash
and
break
the
whole
up,
you
know
the
rest
of
the
system.
A
A
The
tokyo
is
a
rust
library,
that's
kind
of
similar
to
neti
if
you're
familiar
with
the
jbm,
it
gives
us
asynchronous,
I
o,
and
so
when
I,
when
I
start
a
program,
I
stood
up
to
tokyo
runtime,
and
this
lets
us
run
io
concurrently
without
having
to
have
a
thread
per
connection
or
you
know
it
gives
us
something.
You
can
basically
think
of
similar
to
goes
runtime.
Where
go.
Has
these
green
threads
that
let
you
run
things
concurrently
and
just
block
rust
in
tokyo?
A
A
The
first
one,
which
we've
invested
heavily
in
linkedin,
a
lot
of
the
towers
primitives
come
out
of
linkerity.
Is
this
system
called
tower
which
is
really
similar
to
finagle's
services,
and
so
it's
a
service
abstraction?
Where
there's
a
request
and
a
response
and
a
set
of
you
know
layers
or
middlewares
that'll.
Let
us
layer
stack
these
things
together,
so
they
can
be
used
and
I
can
write
loosely
coupled
components
and
then
bind
them
together.
A
So
here's
an
example
from
the
linker
d
proxy:
this
is
an
http
client,
and
so
what
this
is
for
every
endpoint
we're
talking
to.
We
build
one
of
these
services,
and
this
has
an
http
client.
It
has
a
reconnect
layer,
it
lets
us,
do
linkers
tap
feature
and
adds
metrics
and
all
of
these
compo.
All
of
these
features
are,
are
you
know,
orthogonal?
They
have
no
dependencies
on
each
other
really,
and
so
I
can
write
all
of
these
separate
modules
that
are
easily
tested
or
easily
shared
and
reused
without
having
to
couple
them
together.
A
I
also
should
emphasize
that
a
lot
of
the
primitives
we've
developed
for
lingerie
are
freely
available
in
the
tower
library
and
framework
that
so
you
can
use,
for
instance,
linkedin's
load
balancer
without
having
to
pull
and
link
you.
That's
that's
a
you
know.
The
tower
balance
project
or
crate
is
something
we've
contributed
back
upstream.
A
The
tonic
is
a
grpc
binding
for
rust,
again
cup
really
bound
up
with
tower
and
tokyo's
async
runtime
async
networking
tonic
lets
me
write
little
grpc
services,
so
here
on
the
right.
This
is
a
load
testing
service
that
I
wrote
and
we
just
have
to
implement.
You
know
we
take
a
a
grpc
protobuf
and
we
write
the
function
that
generated
by
that
api,
and
now
we
have
a
network
server,
and
so
this
makes
it
really
easy
to
build
microservices
or
little
pieces
of
services
in
rust
again
with
tokyo's
async
runtime.
A
A
Now
we
have
kubernetes
apis
and
we
have
lots
of
glue
beneath
the
application
and
we
need
that
to
work.
Well,
we've
all
become
system.
Programmers.
Anyone
who
would
have
been
in
operations
a
decade
ago
is
basically
a
systems
programmer
now,
but
scaling
that
out
having
to
have
you
know
an
industry
of
people.
Writing
c
would
not
be
great,
it
hasn't
been
great.
A
We
have
security
vulnerabilities,
we
have
safety
issues
and
we
actually
have
you
know
c
has
a
pretty
steep
learning
and
development
curve
and
rust
makes
this
way
more
accessible
and
one
of
the
things
I'm
most
excited
about
in
the
rust
ecosystem
is
the
number
of
young
engineers
getting
involved
here.
People
in
school
or
just
out
of
school
are
really
gravitating
towards
rust,
and
I
think
that
the
industry
is
going
to
be
transformed
by
this
we're
going
to
have
a
much
richer,
more
reliable
systems
ecosystem,
that's
built
on
rust.