►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Linkerd Deep Dive – George Miranda & Thomas Rampelberg (Intermediate Skill Level)
This session covers the more advanced use of Linkerd. You'll learn about real production use cases through customer lightning talks. We'll also cover how contributions in these open-source development projects work with updated looks at what's happening with both Linkerd and Conduit.
About George
George is head of marketing at Buoyant.io.
About Thomas
Thomas is a software engineer at Buoyant.io.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Hello,
everyone
we're
gonna,
go
ahead
and
get
started
so
hi.
Everyone
welcome
to
one
of
the
last
sessions
at
Q,
Khan,
so
stretch
power
up,
we're
gonna
have
a
good
time.
We
have
a
lot
to
get
through
in
this
SIG,
so
I'm
just
gonna
go
ahead
and
jump
in
and
get
started
so
hi.
My
name
is
Jorge
I
helped
run
community
a
buoyant
and
we're
gonna
have
a
lot
of
presenters.
A
This
is
the
the
deep
dive
for
link
Rd
and
if
you
look
at
the
rest
of
the
content
that
we've
had
throughout
the
conference,
I
think
you'll
get
a
pretty
good
idea
of
where
the
link
or
D
project
is
how
people
are
using
it
in
production.
We've
done
a
lot
of
demos.
I
think
we,
when
you
kind
of
look
at
all
of
the
talks
which
should
get
posted.
A
Usually
within
about
a
week
or
so
after
the
conference
you'll
start
seeing
these
talks,
if
you
haven't
caught
them,
I
think
there
were
a
couple
of
great
customer
talks,
both
from
Edward
wild
at
forum
3
and
Israel
from
Moulton
Oliver
beedis
talked
the
anatomy
of
a
production
outage.
Did
anybody
catch
that
keynote
few
folks,
yeah
really
great
story
on
just
transparency,
chaos,
engineering
and
sort
of
you
know
where
link
or
D
fit
into
the
production
stack
and
troubleshooting
I
was
like
a
real-life
production
outage.
A
If
you
didn't
catch,
William
Morgan's
talk
getting
a
service
mission
in
a
production
without
getting
fired.
It's
both
not
just
an
amusing
talk,
but
I
think
it
was
also
very
helpful
from
both
the
cultural
and
a
technology
perspective,
and
then
we
did
a
couple
of
things
right.
Francie
did
a
great
talk,
looking
at
conduit
and
linker
D
and
how
you
use
a
service
mesh
to
do
troubleshooting
and
then
in
the
intro
cig.
A
Yesterday's
thing
he
did
a
really
good
job
going
through
line
by
line
and
looking
at
config
files
in
linker
D,
explaining
everything,
that's
happening,
doing
custom
routing
with
details
on
the
fly.
So
if
you
didn't
catch
any
of
those
sessions,
they
were
all
recorded
and
I
think
they
show
you
different
parts
of
linker
D
where
the
service
mesh
is
going,
how
its
operating
in
production
and
then,
where
it's
going
with
conduit.
A
A
Thomas
is
gonna,
walk
us
through
a
guide
into
participating
in
the
community,
looking
at
the
different
resources
that
we
have
and
if
you
want
to
get
involved,
how
to
make
contributions
how
to
plug
in
and
how
to
really
jumpstart
your
linker
D
experience
and
then
we're
gonna
end
with
an
AMA
session.
We're
gonna
bring
William
Morgan
up
here,
our
CEO
and
co-founder.
So
you
can
ask
anything:
that's
on
your
mind
about
link
or
D
or
the
service
measure
or
anything
at
all.
B
Thank
you
very
much
hello,
everybody.
My
name
is
Dario
quick
intro
about
me,
head
of
core
engineering
can
attest.
I
lead
a
team
of
about
seven
developers
going
up
to
1058
I'm
growing,
very
quickly
and
I
focus
on
making
sure
that
the
developers
can
stay
focused
and
be
as
efficient
as
possible.
Malinka,
Deere
enthusiasts
otherwise,
I
wouldn't
be
here
really,
and
a
minor
contributor
more
like
I
speak
about
it
and
I
have
done
some
minor
contributions,
but
I'm
more
like
helping
spreading
a
voice.
A
quick
word
about
a
test.
B
We
provide
a
platform
that
allows
any
company
to
ask
any
question
to
anyone
and
receive
the
results
in
real
time.
Allows
you
to
have
insights
on
what
your
target
audience
or
what
your
actual
customers
think
to
make.
Decisions
based
on
data
is
sort
of
gut
feeling,
so
we
have
two
interfaces.
One
is
for
the
customers
to
create
a
service
and
see
the
results
and
the
other
one
is
for
the
respondents
to
answer
the
questions.
B
They're
paid
get
reports
get
some
nice
and
data,
so
this
is
kind
of
our
backends
I'm,
not
gonna
drill
into
the
fronton,
but
we
have
two
different
separate
api's.
One
is
for
the
maker,
which
is
where
customers
make
service
wanted
to
take
her,
where
respondents
take
the
surveys
and
they
talk
to
different
services.
Those
are
private
services
in
a
private
vbc.
Some
of
them
talk
to
a
third-party
systems
on
and
talk
to
a
database,
and
it's
a
pretty
standard
architecture.
We
don't
use
kubernetes
will
use
this,
yes,
but
the
way
the
API.
B
One
of
the
problems
that
we
have
is
that
if
we
drill,
if
we
kind
of
dissect
each
of
those
ups,
we
will
see
that
there
is
a
lot
of
boilerplate
in
there
that
you
have
to
repeat
for
each
of
those
services
and
we
use
different
programming
languages.
So
sometimes
we
can't
forget
to
do
that.
Sometimes
we
do
it,
but
we
end
up
having
a
lot
of
code
that
is
repeated
across
different
services.
B
Second
problem
is
okay
call,
so
we
want
to
DG.
Our
PC
now
turns
out.
We
can't
because
EWS
doesn't
support.
Http
origins
and
GRC
speaks
uses,
HTTP
T
as
a
protocol,
so
it's
just
not
possible
to
do
yes,
I
think.
The
answer
to
that
is
no,
it's
been
a
while
and
then
just
not
doing
any
work
on
that.
So
yeah,
that's
grating.
B
So
this
is
where
link
ad
comes
in.
That's
a
great
title
up
there
and
I
should
say
something
about
Inca
tea.
The
thing
that
I
really
like
about
link
it
is
that
a
focus
on
doing
one
thing
really
well
and
that's
being
a
service
mesh
data
plane,
and
it
doesn't
try
to
do
too
many
things,
and
your
recognizes
that
there
are
other
tools
that
can
do
that
thing.
Well,
so
it
would
rather
integrate
with
those
services
rather
than
do
itself
not
gonna
drill
too
much
into
this.
B
B
Right,
so
this
is
kind
of
the
way
works
at
the
moment,
and
so
we
have
introduced
a
new
API
that
is
just
internal
and
the
fun
thing
about
building
internal
stuff
is
that
you
can
break
things.
You
can
try
new
technologies.
If
things
go
down,
I,
don't
care,
it
doesn't
really
matter,
it's
just
internal.
So
there
is
a
new
API
there's
a
new
service,
the
which
uses
you
RPC,
and
this
is
kind
of
highways.
This
is
just
an
illustration.
Obviously,
the
cluster
is
a
lot
bigger
than
that.
B
We
have
a
bunch
of
other
containers
and
this
is
a
link
at
a
linker
configuration.
So
in
order
for
two
containers
to
talk
to
each
other,
the
container
goes
on
a
link
at
the
end,
the
host
machine,
which
talks
to
the
Rinka
D
on
the
other
host
machine
which
talks
to
the
actual
container.
So
we
have
service
discovery
this
way,
as
as
I
said
linker,
he
doesn't
do
it
itself.
We
used
console
for
that.
So
whenever
I've
been
API
wants
to
speak
to
service,
they
will
just
say:
hey
linker,
can
you
send
this
request
service?
B
The
linker
will
go
to
console
to
see
why
we're
so
busy
is,
and
maybe
it's
got
a
cache,
so
it
doesn't
actually
have
to
go
to
console
all
the
time.
So
how
that's?
How
that
works?
You
can
configure
linkage.
You
have
circuit
breakers,
so
you
don't
have
to
have
that
in
your
application.
Logically,
just
you
just
have
link.
B
Do
it
for
you
same
for
trial
and
deadlines,
a
connection
pooling
so
after
the
first
request,
the
connection
is
kept
open
so
that
the
following
requests
would
be
a
lot
quicker
I,
because
every
single
request
goes
through
a
link
ad.
You
cannot
distribute
the
tracing
to
have
a
better
implementation
of
distributed
tracing.
You
actually
have
to
change
some
of
the
code
on
your
application.
B
B
B
Right
crying
sorry,
load,
balancing
I'm,
so
sorry,
I
thought
that
was
actually
a
really
important
point.
Whenever
me,
an
API
nice
thought
service
d-link.
It
is
actually
aware
of
where
service
D
is
because
it
will
probably
live
in
more
than
one
instance,
and
so
it's
clever
enough
to
send
a
request
to
the
service
D
that
has
the
lowest
latency.
So,
for
example,
if
service
Li
was
in
the
same
instance
as
admin
API,
the
request
would
probably
go
to
that
container,
because
the
latency
is
very
low
because
it's
on
the
same
host.
B
So
it
does
clever
things
like
that.
It
also
means
that
you
don't
need
to
use
a
native
load
balancer,
which
means
you
can
you
can
talk
to
load
to
GRC
services,
but
also
means
that
you
don't
have
to
pay
for
a
load
balancer
which
is
pretty
expensive
these
days
so
yeah.
We
can
now
speak
the
GRC
services.
We
have
lower
latency
because
we
are
client-side
load
balancers.
We
have
connection
poles
by
default
and
we
use
your
PC,
which
is
a
more
efficient
protocol
because
it
uses
a
pilot
protocol.
B
We
have
high
resiliency
because
circuit
breakers
because
of
trials
and
also
staff,
we
have
lower
costs
because
we
don't
have
to
pay
for
load
balancers.
We
have
easier
troubleshooting
because
we
have
distributed
distributed
tracing,
so
we
can
use
Zipkin
or
Jaeger
to
actually
see
what's
going
on
and
where
the
problem
is,
when
there
is
a
some
sort
of
slowness
or
exceptions
are
expected,
but
the
main
point
that
I
want
to
make
I'm
running
a
bit
late,
I
think,
is
that
we
have
all
of
this
stuff
for
free.
B
So
when
we
now
look
at
our
applications,
what
we
have
in
there
is
your
business
logic.
You
don't
have
anything
else
in
there
speaking
specifically
about
the
RPC
services,
the
client
and
the
server
generated
automatically.
You
don't
have
to
our
circuit
breakers
or
anything
like
that
in
your
application.
You
can
focus
on
delivering
value
and
you
have
fun
doing
so,
because
you
don't
have
to
worry
about
or
wonder.
B
C
Hey
thanks
so
I'm
Christina
I
work
in
search
team
at
SoundCloud
and
I
want
to
talk
a
little
bit
about
how
we
do
search,
how
we
integrated
ink
a
deal
with
that
and
what
the
benefits
for
me
personally
were
so
quick
show
of
hands.
How
many
of
you
are
familiar
with?
Soundcloud?
Oh
wow,
that's
quite
a
lot,
so
you
don't
have
to
spend
a
ton
of
time
talking
about
who
we
are
basically
we're,
probably
the
world's
largest
catalogue
of
of
modern
music,
but
definitely
the
world's
coolest
catalog,
in
my
opinion.
C
So
what
a
search,
what
a
search
a
SoundCloud
look
like!
We
allow
users
to
search
across
roughly
three-quarters
of
a
billion
of
documents
and
peek
we
get
about
1500
QPS
and
we
try
to
serve
stuff
like
under
100
milliseconds,
p95
latency,
what
it
search
looked
like
until
about
half
a
year
so
SoundCloud
we
views
elasticsearch
a
whole
bunch
of
clusters
and
they're
fronted
daily.
They
were
fronted
by
an
API
and
we
have
H
elasticsearch
cluster.
We
had
a
configuration
of
that
API
in
like
multiple
replicas.
C
Everything,
like
all
the
stateless
bits,
are
running
in
coordinators,
and
then
these
different
configurations
of
the
api's
were
registered
in
in
services
gallery
under
the
same
name,
so
that
request
could
load
balanced
across
them
as
they
come
in
through
the
API
gave
way.
The
reason
we
have
multiple
clusters
serving
traffic
is
for
well
we'll
get
them.
C
So
we
wanted
to
fix
hats
previously.
The
way
we
got
around
this
was
somebody
gets
paged
in
the
middle
of
night
and
then
they
shut
down
the
configuration
of
the
API
that
was
serving
those
50%
of
the
requests
and
scared
out
the
other
configuration
to
to
handle
the
load,
and
then
traffic
went
the
other
way
and
everything
was
fine,
except
for
the
person
who
got
paged.
So
we
wanted
to
fix
this.
C
That's
most
of
the
content
for
the
talk,
one
learning
that
we
did
have
while
deploying
this
was
how
many
of
you
attended
the
link
of
the
intro
talk
yesterday
about
the
tabs
and
everything?
Okay.
So
you
might,
you
might
have
I
I
didn't
see
myself,
I
have
to
admit,
but
basically
details
offer
you
the
possibility
to
specifying
the
source
and
then
targets
for
these
evaluation
rules,
and
then
there's
this
and
operator
and
present
operator
that
lets
you
spread
traffic
across
multiple
services.
C
When
we
try
to
do
this,
it
didn't
work
out
the
way
we
expected,
because
this
operator
doesn't
load
balanced
across
all
incident
union,
all
the
instances
together
and
then
distribute
the
traffic.
Instead,
it
divides
the
traffic
and
then
load
balances
within
each
of
those
groups,
so
that
was
a
sort
of
unexpected
effect
for
us.
The
workaround
for
that
for
us
was
that
we
basically
indeed
that
approach
here,
so
we
registered
all
the
research
clusters
and
at
the
same
service
discovery
name.
D
C
E
Thanks
George,
hello,
everyone,
my
name
is
Zach
Angelo
I'm
on
the
platform
engineering
team
at
big
commerce.
Bigcommerce
is
a
sassy
e-commerce
platform,
so
we
help
other
businesses
sell
successfully
online.
Here's
a
couple
of
stats
to
sort
of
hopefully
prove
that
we're
not
that
we
are
big
commerce
and
not
small
commerce.
We
we
help
power
quite
a
lot
of
transactions.
Every
year
we
have
60,000
stores
on
the
platform,
17
billion
and
GMB
so
far,
so
a
lot
of
volume.
E
E
You're,
usually,
you've
got
one
variable
for
the
hosts
one
variable
for
the
port,
if
you're
using
something
like
console
that
has
like
DNS
built
in
maybe
you're,
just
using
consoles
your
DNS
using
the
console
host
name
to
help.
You
find
the
service
one
of
the
problems
that
we
notice
with
this
or
one
of
the
things
I
wouldn't
say
problems.
One
things
that
we
really
wanted
to
make
better
was
using
environment
variables,
couples
your
service
to
the
environment
itself.
E
So
we
wanted
to
sort
of
like
break
that
apart
a
little
bit,
we
thought
that
there
was
sort
of
a
better
way
and
so
I'm
gonna
walk
you
guys
through
some
steps
on
how
we
accomplish
that
yeah.
So,
basically
the
goal
was:
is
we
just
wanted
to
be
able
to
spin
up
a
client
in
our
service,
send
the
traffic
out
of
the
service
and
have
something
else
in
the
infrastructure
figure
out
where
the
traffic
needed
to
go.
E
So
the
step
one
at
least
for
us
in
achieving
this-
was
we
needed
some
consistency
and
the
short
story
is:
is
we
basically
use
G
RPC
to
achieve
that
consistency,
G,
RPC
uses
generated
clients
and
those
generated
clients
have
G
RPC
service
names
baked
into
those
clients.
So
when
the
request
lands
on
the
wire
here,
it's
always
gonna.
Look
the
same,
no
matter.
If
the
client
is
no
js'
or
whether
it's
Scala
or
there
it's
Java
or
whether
it's
C++,
it's
always
gonna.
Look
the
same.
Excuse
me
step
two
to
achieving.
E
This
is
you've
got
to
publish
G
RPC,
these
G
RPC
service
names
that
are
baked
into
the
client
into
your
service
discovery
mechanism.
So
for
us,
that's
console,
and
you
can
see
right
here.
I
know
this
is
like
really
small
text,
but
basically
what
we've
done
is
we've
taken
containers,
so
we've
got
sort
of
a
list
of
containers
that
are
running
an
air
infrastructure
on
the
left
and
then
the
tags
that
are
associated
with
those
containers
on
the
right.
E
We've
basically
created
a
tag
on
each
container
to
associate
G
RPC
services
with
console
services
or
console
containers,
step.
3
the
traffic's
got
to
go
somewhere,
so
you
have
to
submit
that
traffic
into
some
sort
of
intelligent
layer
that
knows
how
to
consume
those
tags.
It
knows
how
to
consume
that
information
that
you've
provided
for
it.
In
our
case,
it's
linker,
D,
linker
D
allows
you
to
send
traffic
to
it
and
if
you
have
it
configured
correctly,
it'll
reach
into
your
G
RPC
requests
and
figure
out.
E
Ok,
you're
trying
to
reach
this
service
or
this
method
on
this
service.
But
that's
not
enough.
We
had
to
sort
of
take
an
additional
step.
There's
still
a
gap
you
have
to
cross
linker
D
will
receive
the
traffic
and
it
can
identify
what
the
destination
G
RPC
service
is.
But
how
does
it
there's
still?
It
still
doesn't
have
enough
information
to
know
to
look
at
a
tag
or
nota.
It
can't
convert
that
to
an
IP
and
a
port
which
is
ultimately
what
it
needs
to
actually
know
where
to
send
the
traffic
on
your
network.
E
So
what
we're
basically
doing
is
crawling
the
console
service
catalog,
looking
for
any
tags
on
each
service
and
then
writing
the
DTaP
out
and
those
d
tabs
look
a
little
bit
like
this,
so
you
can
see
on
the
Left.
We've
got
G
RPC
services
and
on
the
right,
we've
got
console
services,
and
then
we
take
this
D
tab
when
we
load
it
into
linker
D
and
that
basically
allows
link.
We
need
to
associate
the
services
that
it
sees
coming
in
on
the
wire
on
the
left
and
associate
it
with
console
services
on
the
right.
E
Then
it
can
then
reach
out
to
console
and
say:
hey
I
need
you
to
give
me
an
IP
import
for
these
console
services
and
that
basically
completes
the
chain.
So
once
it
has
all
of
this
information,
it
can
then
take
the
take.
The
gr,
PC
request
off
the
wire
and
automatically
convert
them
into
ip's
imports
and
then
you're
at
service
discovery.
Nirvana.
E
C
A
Thanks,
those
were
awesome,
talk,
Thank,
You,
Zack,
Chris
and
Dario
I.
Think
my
favorite
part
of
that
was
that
if
you
just
sell
your
soul
to
the
service
mesh
you'll
reach
a
Nirvana,
oh
cool
today,
we're
gonna
ask
ramas
to
come
up
and
talk
to
us
a
little
bit
about
how
to
plug
in
and
get
started
with.
The
linker
D
community.
F
Hey
there
so
I
think
this
is
the
hazing
ritual
for
buoyant
I'm,
the
newbie
and
so
I
get
to
talk
about
the
community
community
participation
I'm
an
engineer.
I've
got
my
github
and
Twitter
up
there,
but
why
don't
I
jump
in
a
little
bit
to
where
I'm
gonna
go
I'm
going
to
be
throwing
links
at
everyone
at
50
miles
an
hour
I
put
it
up
in
bitly?
Don't
try
and
write
it
down,
just
use
the
bitly
link,
but
let
me
get
started
first
off.
Let's
talk
a
little
bit
about
the
first
steps.
F
The
linker
D
Doc's
are
great,
but
they're
a
little
bit
spread
out
the
two
most
important
places
to
go.
Look
are
the
docs
getting
started
will
get
you
installed
the
for
me,
I
actually
like
to
play
around
with
demo
apps,
though
so
I've
shown
you
the
linker,
DS
examples.
In
fact
that
is
the
coolest
demo
that
I've
seen
up
there
right
now.
F
This
is
one
where
it
takes
a
slow
application
and
shows
you
how
link
ridi
can
make
it
faster
by
using
the
intelligent
load
balancing
by
seeing
what
request
times
are
highly
recommended
to
go
see
how
that
works
out
next
up
once
you've
gotten
started.
Obviously
you
want
to
get
and
hopefully
give
some
help.
We've
got
discourse
slack
Twitter,
I'm
personally,
in
slack
helping
everyone
as
much
as
I
can
giving
them
big
bear
hugs.
Even
in
this
time
zone.
F
So
once
we've
gotten
through
all
of
that
I
hope
everyone
is
ready
to
do
some
contributions.
The
first
and
maybe
best
place
to
start
doing.
Contributions
is
plugins.
Everyone
talked
a
little
bit,
those
of
us
that
were
in
production
about
some
of
the
little
changes
they
needed
to
make.
So
there
are
four
different
types
of
plugins
that
you
can
do.
They
are
identifiers,
namers,
interpreters
and
routers.
I
will
restrain
myself
from
saying
what
all
of
those
do
outside
of
potentially
going
back
here
and
showing
that
identifiers
tell
you
where
to
go.
F
D
tab
binds
namers,
resolve
it
and
then
routers,
which
maybe
is
the
coolest
thing
lets
you
actually
go
and
write
your
own
protocol
routing,
so
you
don't
have
to
just
stick
with
HTTP
and
g
RPC.
You
actually
can
do
your
own
protocols
as
a
plugin
and,
in
fact,
there's
a
awesome
write-up
on
making
your
own
plugin.
These
are
all
Java
or
Scala
using
SBT,
so
once
you've
written
a
plug-in,
the
next
and
best
step
is
to
go,
do
and
contribute
some
changes.
Unfortunately,
our
repo
is
not
tagged
for
new
first
issues.
F
F
Next
up
is
the
contribution
guidelines,
pretty
standard
I,
basically
laid
them
out
here,
which
is
please
create
an
issue
before
you
go
and
write
some
code,
we'd
love
to
help.
You
make
the
issue
as
awesome
as
possible
or
make
the
PR
as
awesome
as
possible
and
getting
to
talk
to
us
early
is
the
right
way
to
do.
F
It
then
fork
the
repo
and
obviously
create
a
PR
as
always,
try
and
make
sure
that
you
create
the
PR
early
and
label
it
as
a
whip,
so
that
you
can
get
some
feelings
for
code
style
and
the
rest
of
that
I
would
strongly
recommend
that.
So
that's
pretty
much
it
again.
Here's
a
link
to
the
links,
those
are
up
in
github.
Is
it
just
and
take
a
look
at
all
of
that
wonderful
documentation?
Thank
you.
A
Thanks
Thomas
I'm
gonna
share
the
slides
for
this
presentation.
Afterwards,
you
can
follow
me
on
twitter
g,
moran,
223
you'll
see
him
posted
there.
One
of
the
things
that
I
didn't
mention
at
the
beginning
of
the
slides
we've
been
doing
a
lot
of
hands-on
demos
in
psy
or
at
the
link.
Rd
booth
on
the
exhibitor
floor.
I
think
it's.
The
exhibitor
floor
is
about
to
shut
down
just
after
this
session.
A
So
if
you
didn't
get
a
chance
to
do
one
of
those
hands-on
demos
there
like
five
to
ten
minute
scenarios
that
shows
you
how
to
use
linker
D
or
how
to
use
conduit
and
there's
some
really
handy
exercises
in
there
there's
a
link
to
those
at
the
first
slide
that
I
had
in
the
beginning
of
the
presentation,
and
next
I
want
to
ask
William
up
here.
So
we
can
ask
any
questions
that
are
on
our
mind
and
William.
A
G
All
right,
thank
you,
George
everyone.
So,
for
those
of
you
who
haven't
already
seen
me,
give
a
talk,
my
name
is
William
Morgan
I'm,
the
CEO
of
buoyant
the
first
thing
I'll
say,
is
I
feel
a
little
weird
standing
up
here,
because
I
I'm
not
kind
of
I,
don't
want
to
be
the
representative
of
the
link
or
D
project
like
we.
G
This
is
a
project
that
started
with
buoyant,
obviously,
and
that
buoyant
spends
a
lot
of
time
and
energy
on,
but
the
goal
is
to
kind
of
make
this
a
little
less
dependent
on
us
and
to
turn
it
into
a
real
community
project.
So
I'll
stand
up
here
and
I'll
I'll
give
you
my
opinions,
but
this
is
not
a
buoyant
project.
This
is
a
community
project
and
it
has
to
be
a
community
project.
In
order
for
it
to
be
successful.
G
The
thing
that's
really
gonna
make
link
Rd
successful
in
the
long
run
is
going
to
be
the
size
of
the
community
around
it.
How
many
not
only
adopters,
but
how
many
contribute,
how
many
contributors
we
have
around
it
so
I
want
you
all
to
feel
like
you
own
this
project.
Just
as
much
as
I
do-
and
you
can
be
up
here
just
as
easily
as
I
and
also
I-
haven't
written
a
line
of
code-
you
know
in
linker
D
since
2000
I,
don't
know
a
long
time
ago.
G
Okay,
so
George
answer
your
question:
how
can
we
have
conduit
and
linker
D?
So
the
goal
for
us-
and
we
haven't
really
talked
too
much
about
this-
is
to
take
all
of
the
lessons
that
we've
learned
from
linker
D
and
make
them
in
a
very
kubernetes
specific
way
and
turn
them
and
wrap
those
up
into
conduit.
And
the
goal
is
eventually,
we
haven't
talked
a
lot
about
this,
but
to
turn
conduit
into
what's
effectively
linker
D
2.0,
so
that
you
know
how
that
happens
and
what
those
details
are
are
still
very
much
TBD.
G
But
we
did
learn
and
we
continue
to
learn
a
whole
lot
of
stuff
with
linker
D,
as
the
service
mesh
expands
slowly
to
take
over
the
entire
world.
And
you
know
we
are
all
as
part
of
the
linker
D
community,
on
the
edge
of
that
transformation
and
and
we
need
a
process
by
which
we
can.
We
can
turn
all
those
lessons
into
a
better
product
at
every
point,
so
that's
kind
of
a
long-winded
answer
with
that.
Let's
actually
do
an
AMA
go
ahead.
G
G
G
It's
very
production
tested.
So
if
your
time
frame
is
basicly
immediate,
then
link
or
D
is
clearly
answer.
If
your
time
frame
is
kind
of
later
on
and
you're
willing
to
spend
some
time
and
going
going
through
kind
of
a
beta
process,
and
you
are
kubernetes
like
you're,
really
developing
stuff
on
kubernetes,
and
you
don't
care
too
much
and
then
in
the
near
term
about
all
the
things
that
linker
D
is
very
good
at
and
in
terms
of
talking
to
e
CS
and
talking
nomads
and
console,
then
condo
would
what
is
where
I
would
start.
G
G
Also
say
along
those
lines
that
we're
making
a
really
concerted
effort
to
move
the
development
process
into
the
open
with
linker
D
we've
started
to
do
this.
We
weren't
very
good
about
this
early
on
with
conduit,
we're
really
making
a
very
concerted
effort
to
do
that.
Development.
Have
the
issues
up
in
github?
Have
the
roadmap
out
in
the
public
to
have
the
design
discussions
on
the
conduit
dev
mailing
list?
So,
if
you're
interested
in
participating
like
we
would
like
that
to
happen,
we
have
mailing
lists.
We
have
a
slack
channel.