►
From YouTube: Linkerd End User Panel: Case Studies from Production
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Linkerd End User Panel: Case Studies from Production - Catherine Paganini, Buoyant; Kasper Nissen, Lunar; Fredrik Klingenberg, Aurum AS; Eli Goldberg, Salt Security; Christian Hüning, Finleap Connect
Paganini, Eli Goldberg
In this panel, you'll hear from end users across a variety of industries on how they use the Linkerd service mesh in real-world production scenarios. Use cases range from applying mutual TLS to encrypt and secure all service-to-service communication, load balancing gRPC requests, and troubleshooting services before they're pushed to production. Panelists represent a variety of companies with very different environments, goals, and priorities, and discussion will be focused on real-world outcomes.
A
Okay,
I
think
we're
live
well
welcome
everyone
to
today's
linker,
the
end
user
panels
on
case
studies
on
production
and
I'm
catherine
paganini
with
buoyant
the
creator
of
linkerd,
where
I
work
very
closely
with
our
end
user
community,
including
our
panelists
today,
we'll
hear
from
four
panelists
today
from
a
variety
of
industries.
All
of
them
have
lots
of
linker
d
production
experience
and
so
yeah.
B
Yeah
so
my
name
is
ellie
goldberg,
I'm
with
the
platform
team
and
solid
security
sold
as
a
as
an
api
security
company.
So
we
protect
apis
for
our
customers,
we're
running
link
rd
on
multiple
production
clusters
and
we
came
to
found
link
rd
because
we
were
actually
looking
for
a
grpc
load
balancing
solution
and
that
was
a
perfect
fit
for
us.
So
happy
to
be
here.
C
D
Yeah,
my
name
is
christian
hooning,
I'm
the
tech
lead
or
the
the
cloud
lead
for
at
findlay
connect.
We
are
using
linkedin
since
2019
in
production,
so
we
were
quite
early
adopters
and
finite
connect
is
a
financial
services
provider
from
germany.
That's
why
we
care
deeply
about
the
mutual
tls
features,
and
these
kind
of
things.
E
A
B
So
grpc
was
kind
of
the
perfect
solution
for
us
being
based
on
protobuf,
vertical
buffers
and
and
http
2..
So
it
came
with
amazing
backwards
compatibility
guarantees.
So
that
was
a
real
great
choice
and
well.
Jvc
is
also
based
on
http
2,
so
as
opposed
to
http
one,
you
don't
really
get
actual
low
balancing
for
that.
So
that's
what
we
went
for
linker
d.
C
Yeah
we
had,
we
had
the
same
use
case.
We
also
using
grpc
a
lot
internally
to
communicate
synchronous
synchronously
between
our
services
and
with
the
scale
that
we
sort
of
get
right
now
and
the
jpg
load
balancing
is
definitely
becoming
a
problem
internally
at
our
clusters.
So
having
you
know
a
service
mess
that
can
help,
you
actually
load
balance
between
all
this
those
parts.
That's
yeah,
really
valuable.
C
A
B
Yeah
so
I
mean
at
first
we
didn't
really
know
what
a
service
mesh
is
and
we
were
looking
for
the
like
the
simplest
solution
for
gfc
low
balancing,
but
as
we
were
kind
of
meshing,
our
services
and
adding
them
adding
them
to
the
service
mesh.
So
we
realized
we
have
something
far
more
powerful
than
a
sophisticated
load
balancer.
So
first,
our
inner
pod
communication
was
now
encrypted
and
that's
super
important
when
you're
aiming
for
zero
trust.
But
more
than
that,
we
we
just
started
seeing
all
failures.
B
Like
all
requests
on
the
network
level,
we
saw
those
failures
and
we
were
able
to
monitor
it
and
trigger
alerts
for
specific
teams
owning
the
the
services.
So
that's
pretty
amazing
and
finally,
like
in
terms
of
reliability,
you
can
actually
add
retry
policies
so
that
errors
are
start
looking
like
small
delays
and
and
yeah.
It
was
pretty
awesome
for
us.
That's
really
what
got
us
into
the
journey
of
reliability
going
yeah.
B
C
D
A
D
Can
so
that
was
when
the
team
and
I
basically
the
team's
over
there
somewhere
hey
team
when
we
joined
the
company
in
2018.
That
was
basically
the
beginning
of
a
cloud
native
transformation
and
as
part
of
that,
we
had
roughly
nine
months
to
do
everything
stand
up.
Kubernetes,
introduce
help,
charts,
get
ops,
all
the
things
prometheus
monitoring
and
at
some
point
we
realized.
Okay,
we
also
need
mtls
between
everything.
D
D
There
was
no
mtls
back
then,
but
they
said
like
novemberish
december-ish,
so
we
were
like
in
october.
I
said:
okay,
let's
give
it
a
try
and
they
delivered.
So
that
was
good,
so
trust
was
set
up
and
by
I
think
april,
1st
we
went
live
with.
I
think
the
first
really
released
version
of
linkadi
2
with
actually
mpls
enabled
yeah,
and
that
was
possible
because
it
was
really
easy
to
install
it
and
not
provide
any
additional
specs
to
get
it
working
with
the
services.
So
this
is.
C
B
C
Yeah
definitely
yeah.
We
tried
out
actually
the
old,
lincoln
d1
back
in
2017.
I
guess
actually,
my
colleague
juan
is
just
sitting
down
here.
Who
was
the
one
who
who
tried
it
out?
We
had
a
lot
of
issues
back
then,
and
I
think
both
the
issues
that
we
saw,
but
also
at
that
time
he
wasn't
really
mature
enough.
C
We
were
me
as
a
platform
team,
basically
and
then
bjorn
came
in
and
then
sort
of
tried
things
out
and
yeah
for
at
that
time,
in
service
space
was
just
wasn't
there
for
us,
and
I
think
there
was
some
issues
with
the
the
old
model
as
well.
So
but
yeah
really
wanted
all
of
those
features.
But
I
guess
it's
about
maturity
as
well,
and
and
when
are
you
ready
to
adopt.
A
E
Airship-
nordic
is
somewhat
of
the
kind
of
best
buy
of
nordics
selling
electronic
cups
large
online
present
as
well.
They
have
moved
more
of
their
application
development
in-house
instead
of
buying
off-the-shelf
products
and
was
then
building
up
the
microservice
architecture
on
on
azure
app
services,
which
are
great
up
until
a
point.
We
have
a
lot
of
those
microservices
and
it
become
quite
costly
and
then
henry
hognos
the
cloud
solution.
E
So
that's
where
we
started
looking
at
linkedin,
easy
to
get
started,
create
two
operations,
documentation
and
community,
and
we
will
get
that
insights,
especially
on
the
networking
part
that
that
saved
us
a
couple
of
days
before
black
week.
We
found
some
some
bugs
in
some
applications
where
they
were
not
reusing,
sockets
correctly,
for
example,
and
that
would
have
been
difficult
to
troubleshoot
without
getting
that
delinquency,
insights.
D
Yeah,
I
think
especially
this
out
of
the
box
for
golden
signals,
was
also
back
then,
in
this
early
adoption
phase.
Really
what
helped
us
also
to
understand
this
deck,
as
we've
also
knew
in
the
company.
We
didn't
really
notice
that
completely,
so
we
were
also
then
able
to
to
look
at
things
and
see.
Okay.
This
is
working.
This
is
maybe
not
working
all
that
well,
so
this
is
an
out
of
the
box
thing
that
if
you
do
not
have
custom
metrics
yet,
but
that
that
really
helped
us
also
yeah.
C
B
A
Awesome-
and
of
course
I
mentioned,
you-
are
a
service
provider,
so
you're
not
only
working
with
elk.
You
work
with
a
variety
of
different
companies
on
helping
them
in
their
client
qualitative
journey.
Can
you
tell
us
about
another
example:
you're
currently
working
on
where
you
implemented
linkedin
yeah,.
E
The
the
the
project
I
worked
on
after
lsap
is,
if
the
insurance
company
nordics
as
well
again,
they
have
already
chosen
linkedin
whenever,
whenever
starting
the
project,
so
job
job
done
there
somewhat
similar
problems
at
the
encryption
and
the
insights,
we
try
to
go
gear,
ups,
everything
as
well
and
that
that
align
perfectly
with
how
we
can
install
an
nkd
and
use
that
as
well
we're
going
to
have
a
talk
at
four
o'clock.
I
don't
know
that
one
check
that
out
yeah.
A
C
Yeah,
so
maybe
you
should
just
you
know,
work
like
a
little
bit
in
time
and
so
we've
we
especially
been
evaluating
cherishment
for
a
long
time,
and
we
belong
that
in
that
period
you
know.
Looking
at
all
the
nice
features
we
sort
of
could
get
if
we
adopted,
but
wasn't
ready
to
take
on
the
complexity
that
we
actually
thought
came
with
a
service
miss
and
then
at
some
point
we
we
figured
out
that
yeah.
C
So,
though,
that
fluent
bit
which
we
use
to
collect
all
the
logs
can
just
transparently
send
all
the
data
through
that
kubernetes
service,
that
is
being
mirrored
to
the
opposite
side
and
directly
into
a
log
management
solution.
So
that's
sort
of
why
we
started
to
look
at
service
mesh,
because
slinger
d
came
out
with
this
in
2.8.
I
think
and
yeah
that
was
sort
of
this
is
this
is
what
we
really
need.
So
that's
what
really
tipped
it
for
us
and
then
we
got
all
of
these
other
nice
features
as
well.
A
C
It's
kind
of,
I
guess
opposite
of
at
least
maybe
your
stories
at
least,
that
you
sort
of
want
something
in
cluster,
and
that
is
why
you
adopt,
but
we
russian,
we
were
really
not
ready
at
that
point
to
take
on
that
until
we
were
like
two
free
people
and
running
a
lot
of
stuff
everything
ourselves
replicated.
You
know,
environments
and
stuff
like
that,
so
we
wasn't
just
ready
to
do
that
so,
but
then
we
escaped,
we
scaled
a
lot,
and
in
the
past
year
we've
added
for
500
new
people.
C
We
went
from
200
to
700
in
a
year,
so
that's
just
been
a
lot
of
growth,
and
now
we
also
start
maturing
in
our
platform
organization
to
have
enough
people
to
actually
take
on
this
and
and
yeah.
So
multi-cluster
just
makes
a
lot
of
sense
for
us,
and
it
just
gives
this
transparent
communication
that
works
really
well.
B
C
Yeah
and
for
for
us
we
so
we
we
basically
sat
down
two
two
people
actually
going
again,
I'm
pointing
to
him
again
me
and
him.
We
just
wanted
to
try
out
the
different
options
there.
So
we
tried
out
this
year.
We
tried
out
link
d.
I
tried
setting
up
this
multi-cluster
feature
in
linkedin
and
it
took
like
an
hour
and
our
clusters
were
just
connected
and
I'm
not
sure
if
it's
beyond
the
skills
or
sdo,
but
we
couldn't
get
that
up
and
running
it
took
like
forever.
C
E
B
C
Yeah
and
it's
just
nice,
it's
not
like
everything
can
can
talk
to
everything
you
you
can
really
control
which
service
do
you
want
to
expose,
and
now,
with
several
authorizations
and
stuff
like
that
in
integrity
as
well,
you
can
actually
put
on
some
you
know,
policies
of
who
can
actually
talk
to
who
and
get
that
validation
and
security
in
place
as
well.
It's
pretty
awesome.
A
Okay,
so
let's
talk
a
little
bit
about
business
impact,
particularly
with
infrastructure
investment.
It's
often
difficult
to
justify
because
it's
kind
of
invisible,
so
were
you
able
to
frame
it
from
your
adoption
in
terms
of
tangible
results
to
the
business?
This
is
a
question
for
anyone,
so
just
jump
in.
D
Well,
yeah,
I
mean
we
were
able
to
go
live
on
april
1st,
while
hitting
the
compliance
goal.
That
was
the
thing
here
and
I
think
now
we
really
struggled
a
bit
with
implementing,
for
instance,
network
policies
on
the
cni
level,
because
we
wanted
to
do
that
in
a
way
to
expose
it
to
the
developers
that
they
can
self-service
themselves
and
that's
a
bit
hard
on
that
layer.
D
So
with
link
id
policies,
also
known
as
the
new
212
release,
I
think
it
becomes
a
lot
better
to
do
that
to
to
allow
the
teams
that
are
doing
that
in
a
devops
way
to
to
say
I
I'm
talking
to
these
services,
so
that
will
also
enhance
the
security
and
allow
to
to
hopefully
very
quickly,
spin
up
this.
This
whole
policy
nash,
if
you
want-
and
so
that's
that's-
also
a
good
business
impact,
because
you
can
then
take
another
box.
E
We
did
a
back
of
an
envelope
estimation
on
on
the
cost,
saving
of
just
hosting
the
the
application
at
lship.
I
think
we
were
80
85
percent,
cheaper,
moving
on
to
the
kubernetes
and
stuff
like
that
and
yeah,
and
also
the
policies
becomes
quicker
and
easier
to
implement
instead
of
going
subnets
and
and
udr's
and
all
that
stuff,
and
you
can,
you
can
quickly
iterate
and
try
it
out.
B
E
B
C
Yeah
for
us
also
the
the
cost
management
aspect
or
the
cost
aspect
of
of
adopting
linkedin,
especially
in
the
case
of
where
we
are
sort
of
centralizing.
Our
entire
monitoring
stack,
logging
stack,
and
all
of
that
is
at
some
point
also
becoming
we're
not
completely
die.
Yet
we
haven't
like
migrated
everything,
but
but
just
removing
some
of
the
yeah,
the
replicated
dedicated
resources
that
just
runs
and
costs
some
a
lot
of
money.
If
you
can
centralize
those
into
a
you
know,
extrudable
cluster
and
only
one
run,
one
of
them
and
yeah.
C
C
You
know
on
board
these
new
acquisitions
and
and
make
everything
work
and
come
into
the
same
sort
of
environments
that
we
run
so
that
we
can,
you
know,
so
we
are
in
the
financial
service
industry
and
some
a
lot
of
policies,
and
we
built
a
lot
of
tooling
around
the
platform
we
run
in
aws
today
that
we
really
want
to
extend
and
provide
to
all
the
different
providers
we
might
be
on
at
some
point.
But.
E
Yeah,
one
of
the
things
we
saw
at
that
set
was
to
maybe
not
go
all
in
on
search
measures
and
we're
quite
relieved
to
see
that
linkedin
made
it
possible
quite
easily
to
just
add
some
application
to
the
service
mesh
and
still
be
able
to
communicate
to
the
applications
that
weren't
meshed.
Then
we
can
opt
in
the
other
ones
and
gradually
move
everything
over
to
the
mesh
yeah.
C
That's
a
really
good
point:
that's
also
how
we
sort
of
started
because,
as
mentioned,
we
started
with
you
know,
connecting
clusters
and
only
mesh
putting
the
services
that
are
sort
of
on
the
edge
into
the
service
mesh
and
not
all
the
the
rest.
So
you
can
really
you
know,
adopt
as
you
want
to
and
just
take
it
as
slow
as
you
want
to,
which
is
really
a
really
good
point.
Yeah.
B
Right
right
and
I
mean
because
it's
so
easy-
I
mean
we
found
out-
we
had
we
had
like
certain
bugs
in
certain
places
that
we
were
just
weren't,
aware
of
because
it
didn't
show
up
in
logs,
but
we
could
see
like
excessive
calls
from
one
service
to
another.
You
can
see
like
you
know,
it's
being
hit
really
hard,
and
I
mean
we
wouldn't
know
that
if
we
wouldn't,
you
know,
introduce
the
surface
mesh,
so
you
might
find
that
hopefully
not,
but
you
might
find
out.
You
have
like
things
like
that.
D
I
think,
what's
to
add,
is
also
that
you
shouldn't
get
engaged
with
the
community
like
for
anything.
If
you
have
any
question
like,
can
this
technology
be
injected
with
link
id
or
something
you
could
hit
the
slack
and
there's
people
who
already
did
that
or
tried
that
or
have
a
tip
on
how
to
do
it
like
stuff,
like
rabbitmq
and
other
things
that
might
be
a
bit
special
and
network-wise,
depending
on
how
you
integrate
them?.
C
Yeah
yeah
check
out
the
documentation
and
I
I
really
love
the
documentation
in
the
community
around
lingard.
It's
very
welcoming
and
easy
to
to
yeah
get
in
touch
with
everybody.
The
ceo,
william
always
said
when
you
ask
questions
in
the
chat,
you
also
have
the
class,
so
it's
very
like
a
little
family,
so
to
speak.
It's.
E
Really
yeah
the
biggest
cost
in
system
and
the
system's
lifetime.
In
my
experience,
is
the
maintenance
part,
not
the
development
part.
So
if
day,
two
operation
is
horrible,
but
it's
easy
to
get
started.
You
should
be
out
the
other
way
around.
If
anything,
and
we
saw
that
linkedin
and
not
only
the
community
but,
like
you,
you
said
also,
the
documentation
is
next
to
yeah.
Second,
to
none
really
good.
C
E
Hello,
we
had
some
principles,
starting
at
the
different
projects.
I'm
working
on
one
of
them
is
that
it
should
have.
You
should
actually
have
a
problem
that
you're
trying
to
solve
and
then
introducing
something
like
a
service
mesh
and
the
good
thing
about
linkedin.
That's
very
focused
on
solving
particular
problems,
so
you
can
opt
in
to
having
more
it's
not
like.
E
D
D
I
guess
so,
when
you
really
run
this
for
over
a
year,
at
least
in
the
beginning,
you
at
some
point
you
had
to
rotate
these
certificates
and
there's
many
intermediate
cas
and
it
was
a
challenge
in
the
beginning,
so
we
managed
it
kind
of.
But
after
that
we
decided
that
we
should
contribute,
and
then
just
edit
this,
this
search
manager
integration,
but
that
was
certainly
a
challenge
we
had
to
overcome
at
the
beginning.
D
C
C
E
Cool
we
started
testing
out
the
the
scalability
as
well
and
quickly
realized
that
the
the
proxy
for
linkedin
is
it's
not
a
problem.
It's
it's
too
efficient.
It's
usually
two
less
obsidian
memories,
so
we
have
to
tune
that
a
little
bit
to
to
be
able
to
to
kick
off
the
scaling
part.
That's
really
not
an
issue,
but
I
gotcha.
C
Maybe
just
like,
maybe
just
a
small
comment
on
one
of
the
things
that
we
sort
of
didn't
knew
we
would
get,
but
we
are
really
sort
of
you
know
really
happy
that
we
have
right
now
with
the
content
of
traffic
splits
from
the
smi
the
service
mesh
interface,
which
is
also
implemented
in
liga
d.
This
is
really
really
interesting
to
have
that
feature
where
you
can
so
what
we
used
it
for
was
actually
verifying
that
fluent
bit
was
able
to
buffer
logs.
C
If
the
connection
between
the
cluster
between
the
clusters
were
down,
so
we
just
basically
you
know
inserted
a
traffic
split
that
you
know
at
some
point.
We
just
forwarded
all
the
locks
going
through
to
a
black
hole
and
we
saw
the
fluent
beat
buffering
up
as
expected,
and
then
we
could
just
flip
the
traffic
back
on
and
see
how
it
sort
of
backfilled
the
the
locks,
so
getting
that
sort
of
hook
in
the
network
is
also
something
that
can
help
you
a
lot
in
terms
of
chaos.
B
D
I
think
young
over
there.
He
really
picked
it
up
very
early,
so
we
we
enabled
it
very
early.
It
took
a
while
for
the
teams
to
actually
use
it
to
pick
it
up,
but
by
now
we
have
one
product.
That's
completely
deployed
in
a
canary
way
through
link
id
and
it's
yeah.
That's
I
mean
that's.
That's
just
good
to
have
and
yeah.
B
C
B
I
mean
circuit
breakers
are
something
we're
really
looking
forward
to.
I
think
I'm
not
sure
liberty
supports
that
yet,
but
that's
something
we
really
want
to
want
to
do,
because
you
know
when
things
start
to
fail
and
then
services
start
calling
the
failing
service,
they
start
getting
warmed
up,
and
sometimes
it
doesn't
allow
the
service
to
kind
of
recover
from
from
those
errors,
that's
really
something
we're
looking
forward.
B
D
C
You
know:
life
cycle
management
in
kubernetes,
around
side
cars
that
are
not
really
fully
there
in
terms
of
you
know,
don't
shut
the
proxy
down
before
my
application
is,
you
know,
finish
offloading
whatever
it
needs
to
do
so,
having
sort
of
that
life
cycle.
I
know
it's
something
that's
being
worked
on
the
community,
but
it
would
be
nice
to
have
that
because
it's
not
really
fully
supported.
So
we
just
right
now,
you
know
rely
on
timeouts
or
grace
periods,
but
yeah
and
another
thing
in
the
future
of
the
service
miss.
C
I
really
hope
to
see
a
lot
more.
You
know
automation
around
the
multicluster
setup
and
unlinking
clusters.
You
can
link
them
in
one
direction
or
more
bi-directional
if
you
want
to,
but
it's
kind
of
like
you
need
to
go
into
this
cluster,
you
need
to
run
this
command.
You
need
to
go
to
the
other
cluster
and
apply
this
yaml,
that
the
other
command
outputted.
So
having
a
way
to
sort
of
you
know
an
operator
or
something
that
you
know
generates
these
things
and
put
them
somewhere.
C
E
We
we
saw
also
the
side
card
pattern
and
and
the
support
for
cron
jobs
were
a
little
bit
challenging
because
the
archive
wouldn't
stop
and
then
their
jobs
wouldn't
stop
either.
Also
another
question
we
we
got
once
we
saw
the
the
good
overview
and
insights
that
we
got
from
all
of
the
applications
on
one
cluster.
E
C
F
C
Well,
for
for
us,
I
think
the
the
way
we
see
multi-cloud
as
it
is
right
now.
So,
if
you're
not
familiar
with
the
failure,
I
think
it.
What
it
can
do
is
that,
if
that
service
in
your
cluster
and
yeah
are
sort
of
responding
with
some
some
bad
things
or
whatever
it
can,
you
know
fail
over
to
so
the
same
service
running
another
in
another
cluster
somewhere,
so
that
you
get
that
capability
for
us.
C
It's
our
goal
is
not
really
to
to
come
to
a
point
of
you
know:
federating
services
and
running
free
in
this
cloud
and
three
minutes
down
this
cloud.
It's
more
like
we
want
to
locate
and
put
services
where
it
makes
sense
close
to
the
to
the
business
integrations
or
the
critical
integrations
that
this
particular
service
needs
to
communicate
with.
So
it's
not
really
something
that
having
that
failover
thing
is
not
really
something
for
us
at
least
not
across
clusters,
but
could
be
maybe
interesting
to
explore
more
in
cluster.
D
D
B
E
We're
looking
looking
into
that
that
that
area
or
that
that
direction
for
for
the
current
client
I'm
working
with
now,
is
the
bank
id
bank
accept,
which
is
the
identity
and
payment
provider,
norway,
and
it's
it's
not
good.
If
those
are
down
so
and
to
having
to
fail
over
to
another
region,
not
only
be
yeah
another
region
in
the
cloud
brother
as
well
having
multiple
clusters
doing
the
github
setup,
definitely
something
you
make
looking
into
yeah.
B
The
one
thing
we're
toying
around
with
is
we
actually
mesh
in
our
api
gateway.
So
if
we,
you
know
if
we
like
enable
failover
for
that
for
that
purpose,
so
you'd
have
requests
coming
into
one
cluster
in
the
api
gateway,
but
it
would
like
redirect
you
to
another
cluster.
So
all
the
rest
of
the
services
are
actually
serving
it
from
the
other
cluster.
B
G
All
right,
you
mentioned
a
couple
of
times
that
the
reason
to
choose
lingard
d
was
that
it
was
more
simple
to
run
or
work
with
than
istio.
So
I
was
wondering,
could
you
mention,
or
are
there
any
places
in
lingerie
where
you
currently
find
it
too
complicated
like?
Where
are
the
parts
of
lingerie
themselves
where
we
could
improve
in
the
community
to
make
something
even
more
simple,
so
any
places
we
can
do
something
better.
A
B
Like
one
example
is,
I
think,
the
whole
thing
with
auth
policies
or
like
service
profiles
like
for
me.
It
was
simpler.
There
are
certain
features
in
let's
say
istio,
for
example,
jwt
authorization
which
we
might
want
to
see
in
linkerid,
but
I
don't
know
I
just
felt
like
it
was
a
little
bit
abstracted
away
and
liquidy.
It
was
a
bit
simpler
in
terms
of
like
you
know,
deployment
was
you
can't
deploy
with
a
with
a
link
or
dcli,
but
also,
I
think
it's
just
like.