►
From YouTube: Intro: Telepresence - Richard Li, Datawire
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Telepresence - Richard Li, Datawire
We'll talk about development workflows for Kubernetes. We'll discuss the differences between traditional development, and different approaches people take to building Kubernetes services. We'll then introduce Telepresence and discuss how it integrates with different organizational development workflows. Finally, we'll talk about the evolution of Telepresence and how we are actively moving Telepresence forward from its heritage as a VPN-type approach into a more sophisticated L7 routing layer for developers.
https://sched.co/MPie
A
Okay,
thank
you.
Everyone
for
coming
I'm,
Richard,
Lee
I'm,
one
of
the
founders
of
data
wire,
and
we
actually
started
the
telepresence
project
back
in
the
day
really
born
out
of
just
challenges
of
coding
on
kubernetes
and
over
the
past
few
years,
we've
learned
a
lot
about
how
you
develop
on
kubernetes.
A
A
This
guy
from
Microsoft
did
an
excellent
blog
post
around
the
inner
development
loop,
but
essentially,
if
you're
coding,
micro
services
or
any
sort
of
program
it
doesn't
new
micro
services,
you
have
an
inner
loop
as
a
developer.
You
write
some
code,
you
might
build
your
code,
then
you
test
it
a
little
bit
right
and
then
once
you
convince
yourself
that
it
works
right,
that's
good
enough!
A
But
it's
really
optimized
around
sharing,
typically
characterized
by
integration
tests,
continuous
integration
system
right
but,
generally
speaking,
that's
the
outer
loop
and
one
of
the
key
things
to
recognize
about
the
inner
loop
versus
the
outer
loop
is
that
in
the
inner
loop
latency
is
a
really
really
big
deal
right.
So
if
you
add
an
extra
five
seconds
to
your
inner
loop,
that
really
gets
your
developer
mind
to
kind
of
wander
little
bit
and
maybe
and
the
longer
it
takes.
A
If
it
takes
an
extra
five
hours,
then
you
might
want
to
click
that
REE
retry
button
and
Travis
a
lot
more
often,
but
but
generally
speaking,
it's
really
about
reducing
latency
in
that
inner
loop
right,
so
in
kubernetes
initially,
and
this
has
evolved
a
little
bit
but
the
inner
and
outer
loop
for
kubernetes
it
typically
is
the
same
right.
So
you
write
some
code,
but
instead
of
just
building
your
your
service,
you
build
a
container
that
contains
your
code.
Then
you
push
to
a
registry.
A
Then
you
deploy
to
a
cluster
and
then
you
test
right
and
this
actually
can
be
a
little
slow
and
and
so
the
classic
engineering
answer
to
this
has
been.
How
do
we
do
automation,
and
so
there
have
been
a
proliferation
of
tools
of
the
past
few
years.
Microsoft
introduced
draft
right.
Google
then
said:
oh,
we
don't
like
helm,
so
we're
gonna
do
scaffold
right,
which
is
not
helm,
but
it's
kind
of
like
draft,
but
not
really
right
and
then
various
startups,
like
garden
and
windmill,
has
tilt
and
get
cube
and
I'm.
A
You
tend
to
want
to
use
your
own
tools,
and
so
Microsoft
has
done
a
great
job
of
integrating
draft
with
vs
code,
and
the
S
code
is
great.
But
what,
if
you
want
to
use
a
different
code,
editor
right
or
what?
If
you
want
to
use
a
debugger,
a
profiler,
and
so
each
of
these
tools
needs
to
be
integrated
with
you,
your
particular
deployment
tool,
workflow
on
a
case-by-case
basis
and
and
frequently,
unless
you're
using
the
most
common
tooling.
A
It
doesn't
actually
work
super
well,
so
then
there
came
another
school
of
thought
and
this
is
not
super
linear,
but
so
the
alternative
to
this
historically
has
been
to
do
everything
locally.
So
it's
really
fast
and
you
can
use
your
tools
and
that's
where
tools
like
mini
cube
and
docker
4
kubernetes
and
before
that
it
was
docker
compose.
A
Could
work
really
well
and
these
are-
and
this
actually
lets
you
be
fairly
productive
around
this.
The
challenge,
of
course,
is
that
your
laptop
only
has
16
gigs
of
ram.
My
laptop
I
bought
last
year
still
only
has
16
gigs
of
ram
and
you're
asking
to
run
kubernetes
and
a
JVM
and
a
database,
and
all
your
other
micro
services
and
by
the
way,
because
you're
on
kubernetes
and
your
VP
of
engineering
loves
micro
services.
A
They
keep
on
spinning
up
these
new
teams
and
suddenly
you
have
a
hundred
micro
services
and
they
only
need
a
little
bit
of
RAM.
But
then
you
have
a
hundred
times
a
little
bit
and
that
turns
into
a
lot,
and
so
you
can't
actually
run
all
your
stuff
locally
anymore
right,
and
so
that's
where
telepresence
comes
into
play
right.
So
so
what
is
telepresence
and
I've
been
trying
to
explain
telepresence
for
a
long
time
and
I've
tried
to
explain
in
different
ways
so
I
think
about
it.
A
As
I've
I've
tried
different
things,
I'm
going
to
try
everything
with
everyone
here.
So
it's
a
fancy
kubernetes
VPN
for
development,
not
for
production,
because
when
we
explain
how
it
actually
works,
people
get
scared
and
I
say:
oh,
don't
worry!
You
don't
need
to
run
this
in
production.
It
scoop
cuddle
port
forward
on
steroids
and
we're.
Generally
speaking,
it's
just
a
network
bridge
between
your
laptop
and
your
kubernetes
cluster
right,
so
it
makes
your
laptop
a
virtual,
node
and
I
use
this
term
super
loosely.
A
It's
not
really
a
virtual
note
on
your
kubernetes
cluster
right
and
what
it
does
is
you
run
a
client
on
your
laptop
and
that
and
then
you
run
a
service
locally
in
your
laptop,
a
prime,
and
what
we
do
is
there's
a
you
have
service
a
running
your
cluster
and
what
we
do
is
we
cunningly
SWAT
or
scarily.
Depending
on
your
point
of
view,
we
swap
out
that
deployment
in
your
cluster
of
service
a
for
a
proxy
right
and
that
proxy
will
then
proxy
those
requests
from
the
cluster
all
the
way
to
your
laptop
right.
A
So
the
net
effect
is
when
service
C
wants
to
talk
to
service.
A
service
C
sends
requests
to
our
proxy,
which
is
masquerading
through
the
magic
of
kubernetes
labels
and
all
that
sort
of
stuff.
It
takes
that
request
and
it
forwards
it
onto
the
laptop
right
service,
a
prime
on
the
laptop
and
when
a
prime
on
your
laptop
wants
to
talk
to
service,
B
or
service,
see
we
proxy
that
request
to
your
cluster
right
and
telepresence
is
doing
a
whole
bunch
of
things
behind
the
scenes.
A
It
actually
invokes
a
bunch
of
IP
tables
rules
on
your
local
laptop
to
intercept
dns,
to
delegate
that
dns
to
your
cluster.
This
is
not
recommended
for
the
faint
of
heart.
We've
actually
discovered
how
on
different
flavors
of
Mac
OS.
There
are
all
these
different
ways.
You
can
intercept
DNS.
We
also
proxy
your
environment,
variables
and
secrets
from
your
cluster
to
your
laptop,
we
proxy
volumes
and,
of
course,
we
approximate
your
tcp
right.
So
the
net
effect
is
a
prime
thinks
or
for
all
practical
intents
and
purposes.
A
It
feels
like
to
a
prime
that
it's
running
on
kubernetes,
but
it's
not
right
and
all
your
other
services
are
still
running
in
kubernetes
right,
so
the
benefit
is
you
can
use
any
tool
that
runs
on
your
laptop
right,
whether
it's
an
IDE
profile
or
debugger.
It
doesn't
matter
you
get
effectively
unlimited
compute,
because
most
of
your
stuff
is
running
in
the
cloud
you
get
the
same
network
namespace,
so
your
local
server
or
local
application
is
running
the
same
network.
Namespaces
everything
your
cluster.
A
You
get
a
very
fast
inner
loop,
because
we've
eliminated
this
docker
billdocker
push
step
right,
but
it's
not
there's
no
free
lunch
right
because
it
does
require
a
network
connection
for
larger
organizations.
You
need
coop
control
access
to
the
cluster
and
because
at
least
at
our
company
no
one
runs
Windows.
We
only
were
on
a
Mac
and
Linux
there's
no
intrinsic
reason
not
to
run
on
Windows
I'm
told
that
if
you
use
Windows
subsystem
for
Linux,
there
are
ways
to
get
it
to
work,
but
none
of
us
actually
run
Windows
subsystem
for
Linux.
A
A
Usually
the
challenge
is:
how
do
I
integrate
it
into
my
development
workflow
and
that's
what
I
think
is
some
of
the
more
interesting
questions,
and
so
just
to
reiterate,
you
really
don't
want
to
try
this
at
home
right
so
capturing
the
DNS
and
routing
only
part
of
it
to
the
cluster.
It's
tricky.
We've
discovered
that
no
two
laptops
are
the
same.
A
So
we
started
data
where's,
really
more
of
a
server
infrastructure
software
company,
where
everything
runs
in
kubernetes
and
there's
some
amazing
things
about
the
fact
that
if
everyone
runs
kubernetes,
it's
pretty
much
the
same
thing
kind
of,
but
no
two
laptops
are
actually
alike
and
it
makes
debugging
and
troubleshooting
telepresence
very
tricky.
We
do
all
sorts
of
Kirby
Denny's
magic
around
swapping
out
your
real
deployment
for
this
proxy
deployment.
It
turns
out,
that's
actually
complicated.
So
anyway,
so
I'm
going
to
do
a
super,
quick
demo
and
I'm
going
to
go
here.
A
A
And
so
it's
going
to
create
this
VPN
type
connection
to
the
cluster
and
and
one
of
the
things
it's
one
of
the
reasons
why
and
we're
addressing
this
and
I'll
talk
about
this
in
a
little
bit.
It
takes
a
few
minutes
or
few
seconds
minutes
whatever
to
start
up
is
because
it's
actually
deploying
this
proxy
in
the
cluster.
A
Every
time
you
invoke
the
the
command,
which
is
turns
out
not
to
be
totally
necessary,
so
see
here
we
go,
and
so
now
so
I'm
still
my
local
file
system.
So
this
is
my
Mac
file
system,
so
I
can
get
pods
right.
So
you
see
a
bunch
of
stuff
running
so
I
have
a
service
called
the
tour
backend
service,
so
I
can
do
something:
a
curl,
2
or
back
end
and
I
get
this
JSON
blob
back
right.
A
B
Basically,
I'm
chris
raja
software
developer
for
angle
and
focus
which,
which
is
a
real
estate
company.
We
have
11,000
employees
and
millions
of
customers
worldwide,
and
recently
we
started
to
undergo
the
process
of
transferring
all
the
data
from
the
legacy
systems
to
the
new
micro
services
inside
the
cloud.
B
So,
in
order
to
achieve
this,
we
need
a
song
sort
of
synchronization
service
right
because
we
cannot
let
the
data
in
the
new
services
go
out
of
sync
with
services
that
are
still
running
the
legacy
wants
and
with
this
many
customers
we
cannot
just
shut
down
the
old
systems
without
having
previously
really
tested
the
new
systems,
and
we
encountered
a
big
issue
which
was
that
well,
our
architecture
grew
really
fast.
We
have
right
now
seven
micro
services
that
are
handling
our
singles.
B
Also
true-
and
we
are,
we
have
multiple
protocols
for
the
legacy
systems
we
have
at
the
directory.
We
have
SQL,
we
have
api's,
so
this
is
not.
This
was
not
really
easy
to
maintain,
and
the
problem
was
that
at
some
point
we
just
decided
to
start
to
push
and
deploy
before
testing
the
code,
because
on
our
machine
it
was
not
possible
to
actually
test
the
code.
Docker
compose
is
just
too
heavy
when
you
have
this
many
services
mocking
the
service
in
themselves.
B
When
you
have
so
many
protocols,
it
start
to
be
tricky
to
you,
have
enough
test
data
to
actually
be
sure
that
you're
testing
in
the
right
way.
So
we
just
thought
that
you
build
on
the
machine
and
then
just
push
and
deploy
and
let
the
pipeline
run
if
something
goes
wrong,
you
have
to
make
the
changes
and
you
have
to
deploy
again.
This
takes
five
minutes
ten
minutes
every
single
time
you
have
to
deploy.
So
last
year
we
met
telepresence
at
the
last
cubicle
and
we
immediately
loved
this
kind
of
product.
B
We
immediately
saw
the
potential
that
he
had
inside
our
workflow,
so
we
started
to
experiment
with
it
and
we
started
to
integrate
it.
So
our
workflow
right
now
works
in
such
a
way
that
engineers,
when
they
have
to
change
a
micro
service,
not
just
a
synchronization
one
that
responds
over
the
synchronization,
but
any
micro
service.
They
can
check
out
the
repository.
They
can
build
the
image
locally
and
then
use
telepresence
in
container
mode.
So
this
way
it
doesn't
matter
how
complex
is
the
architecture.
B
We
can
always
run
the
service
on
our
machine
and
debug
on
our
machine,
and
this
allows
us
to
be
really
fast
to
make
adjustment
changes
locally
very
very
quickly,
and
this
enabled
us
to
be
able
again
to
quickly
deploy
and
efficiently
deploy
on
our
clusters.
So
yes,
this!
This
is
our
workflow
today's
and
it's
much
much
faster
and
efficient
than
the
one
we
were
using
before.
Telepresence
came
in.
A
All
right,
Thank,
You,
Christian,
so
I'm
gonna
talk
a
little
bit
about
what's
next
and
then
we'll
take
questions.
So
if
you
think
about
the
telepresence
architecture,
there's
basically
two
components
to
it.
There's
the
client,
which
runs
on
your
laptop,
which
does
the
work
of
capturing
your
DNS
requests
for
your
kubernetes
resources
and
I
should
actually
talk
about
a
little
bit
that
one
of
the
complexities
of
this
is.
We
don't
want
to
intercept
every
single
one
of
your
DNS
requests.
A
We
want
to
figure
out
which
DNS
requests
actually
are
really
request
for
stuff
in
the
cluster
versus.
If
you
want
to
go
to
say
google.com,
we
don't
necessarily
want
to
intercept
that
DNS
request
right.
We
want
to
do
dns
resolution
for
kubernetes
resources
that
happens
on
the
client
and
then
it's
that
proxy
from
we
proxy
the
TCP
connections
from
your
laptop
to
the
cluster
and
then
in
the
cluster.
A
We
have
a
proxy
server
rate
so
which
does
which
proxies
your
TCP
connections
back
to
your
laptop
and
also
is
the
canonical
DNS
for
all
your
kubernetes
resources.
So
those
are
the
two
components
so
on
the
client
side,
the
way
it
works
today
is
we
use
coop
cuddle
port
forward
to
bootstrap
an
S
shuttle
to
bootstrap
a
shell
which
is
an
SSH
based
VPN.
A
We
tried
a
bunch
of
different
VPN
type
solutions
and
turned
out.
A
shuttle
was
seem
to
be
the
most
reliable.
The
challenge
is
S.
Shuttle
actually
has
a
bunch
of
functionality
that
is
not
used
by
telepresence
I
mean
it's
a
VPN
after
all,
and
we're
not
really
building
a
full
VPN.
So
what
we
actually
have
started
doing
is
we've
written.
This
thing
called
tell
approxi,
which
is
written
and
go
designed
for
kubernetes,
and
it
just
does
some
very
simple
things
on
the
client
right,
which
is
all
we
need
to
do
it.
A
Does
that
DNS
local
capture,
a
DNS
resolution
and
it
redirects
TCP
connections
to
the
right
destination.
It
doesn't
do
anything
else
and
so
we've
actually
embedded
tell
approxi
into
telepresence.
So
you
probably
don't
know
this,
but
we
were
because
the
sense
the
telepresence
is
written
in
Python
and
we
figured
out
how
to
embed
this
go
library
essentially
into
telepresence
and
will
be
exposing
that
to
as
a
replacement
for
the
VPN
TCP
method,
and
it
also
will
let
us
do
multiple
simultaneous
sessions,
which
has
been
a
popular
request
to
do
the
cluster.
A
A
So
so
it
actually
turns
out
to
be
something
that
we
think
is
reasonably
reliable
and
gives
us
more
control
than
as
shuttle.
So
that's
what
we're
happening,
what
we're
doing
on
the
client
side
and
on
the
practice
server
doesn't
really
need
change.
It's
not
really
the
world's
most
sophisticated
piece
of
software,
but
one
of
the
things
is
every
time
you
swap
out
that
deployment.
We
redeploy
that
proxy
server,
which
is
silly
right,
so
we're
actually
planning
on
switching
to
mode
where
your
proxy
server
is
actually
persistent.
A
So
you
deploy
a
persistent
proxy
and
because
I
mean
after
all,
kubernetes
is
designed
to
run
persistent
services,
and
there
are
two
real
benefits
that
one
is
startup
is
much
faster
because,
as
you
saw,
a
startup
is
a
little
slow
and
one
of
the
reasons
for
that
is
because
we're
downloading
this
docker
image
and
deploying
this
proxy
server
and
then
the
other
thing
is,
it
will
support
reconnect.
So
there
are
people
who
work
on
trains
with
spotty
internet,
and
so
they
can
do
a
little
bit
of
coding
and
then
they
can
reconnect.
A
So
so
the
answer
we
use
today
and
that
folks
tend
to
do
is
we
recommend
either
each
developer
gets
his
or
her
own
cluster
or
his
or
her
own
namespace.
But
it
is
more
expensive
because
there's
more
Hardware
in
the
setup
and
also
the
other
thing
is
it
delays
integration
testing
until
after
commit
right,
because
you're
not
constantly
updating
every
single
service
in
your
cluster.
You
basically
are
writing
some
code,
your
snapshotting
everything
and
then
you're,
letting
your
outer
loop
actually
do
that
integration
testing.
A
So
the
thing
that
we're
working
on-
and
this
is
part
of
our
commercial
product
but
we're
experimenting
with
different
versions
and
iterations-
is
what
we
call
intercepts.
So
the
user
actually
goes
through
an
API
gateway
and
we
actually
deploy
a
sidecar,
which
is
the
yellow
thing
in
front
of
the
actual
service
right.
So
there's
a
psycho
in
front
of
a
in
their
psyche
or
in
front
of
B
and
basically
sidecar
actually
can
do
a
request.
A
Inspection
looks
at
the
headers
and
if
the
header
actually
belongs
to
me,
for
example,
instead
of
routing
it
to
B,
it
will
actually
route
it
to
B
Prime
right.
So
if
it's
a
developer
request
and
but
if
it's
a
user
request
right,
then
it
will
just
route
to
B.
So
essentially
you
get
the
essence
of
multi
user
development
in
in
sort
of
a
nice
sort
of
encapsulated
model,
so
I'm
gonna
be
slightly
daring
and
I'm
gonna
try
to
show
this
oops.
That
was
not
the
right
thing
to
show.
A
So
so,
essentially,
what
I
have
here
is
I.
Have
this
application
running
this
note
application
running
on?
Let's
see
if
this
is
a
look
see
the
demo
gods
are
not
friending
me
see
here
so
I
have
this
known
app
running
on
localhost,
3000
and
I.
Don't
see
it's
not
running
anymore?
Is
there
something
funny?
Okay,
I
can't
show
the
demo
I
haven't
actually
done
anything,
but
it's
a
shared
cluster,
so
I
think
okay,
anyway,
you'll
have
to
see.
A
This
is
why
we
haven't
actually
released
it
or
anything
so,
but
the
general
principle
is
you
be
able
to
look
at
set
a
host
header
and
say
going
to
Jane
dot?
You
know
whatever
that's
my
sort
of
personal
development
site,
so
I
can
actually
preview
changes,
while,
if
I
go
to
production
dot,
whatever
then
I
can
actually
see
the
production
instance
and
based
on
the
host
header,
we
can
actually
do
that
dynamic
routing
so
just
to
wrap
it
up.
We
are
looking
for
folks
to
help
contribute
to
telepresence
I.
A
Think
that
from
we're
not
we
don't
plan
on
doing
most
of
the
work
around
telepresence,
really
around
reliability
and
working
in
different
environments,
and
so
that's
really
a
challenge
that
can
really
only
help
happen.
If
we
have
more
folks
who
actually
try
it
out
and
give
us
feedback,
so
we
built
in
automatic
bug
reporting
around
this
so
and
it's
a
pretty
low-level
engineering
problem,
but
we
actually
find
it
really
valuable
or
a
lot
of
people
ask
questions
around.
How
can
you
improve
the
documentation?
I
know
something.
A
A
A
It
only
so
the
question
is
for
authentication:
how
frequently
does
it
happen
and
the
answer
is:
it
only
have
authentication
basically
is
built
around
coop
control.
So
so,
essentially
we
use
coop
control
to
bootstrap
and
do
the
port
forward.
So
if
you
have
rights
at
that
point
in
time,
then
you
can
do
whatever
you
want
and
there's
a
list
of
our
back
rolls
that
you
need.
So
you
don't
need
full
Auerbach
access,
but
that's
the
only
point
we
do
authentication.
We
don't
do
what
the
negation
and
any
other
point
in
time.
A
Do
I
happen
to
know
if
telepresence
works
with
sto
with
a
sidecar?
Yes,
so
I
know
it
works.
There
is
a
company
out
of
New
York
City
called,
namely
that
gave
a
great
talk.
What
they
do
is
they.
They
have
this
monolithic
rails
app
and,
and
they
run
sto,
and
what
essentially
they
can
do
is
they
can
actually
take
a
request
based
on
the
developer,
header
and
sto.
Does
all
this
fancy
routing
stuff,
and
so
they
could
say
you
know
you
know.
A
Jane's
request
gets
routed
all
the
way
to
Jane
slap,
though
so
similar
just
some
of
the
things
that
I
was
trying
to
demo
earlier
and
and
so
they
were
able
to
do
that.
I
do
know
that
there
was
some
amount
of
engineering
they
had
to
do
and
we
haven't
had
a
chance
to
actually
sit
down
with
them
to
understand
so
so
I
know
it's
definitely
possible.
I
also
know
they
are
a
very
tech-savvy
team,
so
I
don't
know,
I,
don't
know
how
much
work
it
was
for
them
to
do
that.
Integration,
yeah.
A
Got
it
yes,
so
the
question
was
a
little
bit
more
about
the
telepresence
architecture,
with
respect
to
what
it
does
in
the
kubernetes
cluster
and
essentially
it
creates
a
kubernetes
deployment.
So
and
so
we
create
a
crew
Benes
deployment
with
the
same
labels
as
your
existing
kubernetes
deployments
and
there's
a
way
you
don't
have
to
always
do
it
this
way,
but
that's
the
most
common
way
so
and
so
that
way,
and
then
we
we
basically
do
a
coop
cuddle
scale
to
zero
of
your
existing
deployment
and
we
scale
up
the
the
deployment
containing
our
proxy.
A
A
Well,
the
multi-user
be
available
in
open
source
telepresence
and
not
a
commercial
product.
I
think
the
answer
is
we'd
like
to
make
that
possible,
but
right
now
we're
trying
to
make
sure
that
we
have
enough
resources
to
invest
in
both
the
open
source
and
the
commercial.
So
right
now
we're
going
to
start
with
a
commercial
and
kind
of
see
how
that
goes
and
then,
but
we're
basically
open
sourcing
most
of
the
stuff
into
the
the
core
product
yeah.
So.
A
Yes,
so
the
question
is
it:
can
it
can
sometimes
be
tricky
getting
TelePresence
to
work
with
a
VPN
and
will
tell
approximately
a
difference,
and
the
answer
is
yes,
so
one
of
the
reasons
is
a
shuttle
doesn't
is
a
full
base,
full-blown
VPN,
so
it
is
really
not
super
compatible
with
other
VPNs,
so
tell
approxi.
We
actually
have
gotten
it
to
work
with
one
of
our
customers
VPNs,
so
we
know
it's
possible,
it
doesn't
require
it
requires.
Every
single
VPN
tries
to
intercept
your
packets
in
some
way,
and
so
it's
there's.
A
We
can't
figure
out
a
super
scalable
way
to
do
it
other
than
hey,
install
a
VPN
and
then
try
and
see
what
happens
at
the
client
level,
but
but
tell
approxi
makes
it
much
easier
for
us
to
support
other
VPNs
yeah.
So
I
think
that
the
if
it's
a
proprietary
VPN
it's
much
harder
for
us
to
support,
because
we
obviously
don't
we're
not
going
to
purchase
every
single
proprietary
VPN
and
try
it
on
our
laptop.
So.
A
A
Registering
the
machine
as
an
own
cluster,
oh
I,
see
I,
don't
think
we
I
don't
know
if
we've
actively
explored
that
option,
so
I
don't
know
if
it's
any
better
or
worse.
In
our
experience
like
there's
some
intrinsic
complexities
to
this
to
the
space,
and
we
we
feel
like
at
this
point
with
tell
approxi,
we
actually
have
a
reasonable
mental
model
around
how
to
make
this
work
reliably
and
we
actually
have
a
bunch
of,
and
also
just
through
brute
force
engineering,
because
we
have
a
lot
of
users.