►
From YouTube: To Serve or not to Serve Serverless, Microservices & ServiceMesh OpenShift Commons Gathering KubeCon
Description
To Serve or not to Serve: Serverless, Microservices, and Service Mesh
Moderator: Jamie Longmuir (Red Hat)
Panelists: Paul Morie (Red Hat) , Daniel Berg (IBM) ,Lin Sun (IBM) ,Brenda Chan (VMware) and Nick Young (VMware)
OpenShift Commons Gathering KubeCon NA
November 17 2020
To Be Of Service or Not: Serverless, Microservices, and Service Mesh: In this panel, moderated by Jamie Longmuir (Red Hat), Brenda Chan (VMWare), Paul Morie (Red Hat), Lin Sun (IBM), Dan Berg (IBM) and Nick Young (VMWare) discuss the year that was, what's to come and other tails of fun from the KNative, Istio and Contour communities.
466762 To Serve or not to Serve Serverless, Microservices, and Service Mesh
B
C
E
F
A
Thanks
paul
thanks
thanks
everyone,
so,
let's,
let's
just
jump
straight
into
our
first
question-
to
help
us
get
a
little
bit
of
pr
of
context
around
these
pro
projects,
I'd
like
to
understand
where
they
fit
into
the
ecosystem
at
large.
So
assuming
we're
starting
with
kubernetes,
which
I
think
most
people
have
some
familiar
familiarity
with.
Where
does
your
project
fit
in
I'll
start
with
nick
on
and
contour.
B
It's
that
means
that
you
can
use
any
of
the
resources
we
support,
which
are
currently
ingress,
our
own
cid
http
proxy
and
soon
the
new
service
apis
to
get
the
traffic
to
your
to
the
pods
that
are
running
you.
We
will
do
that,
regardless
of
what
those
pods
are.
If
they're
running
you
know,
vanilla,
old
style,
pods,
serverless,
pods
or
in
a
service
mesh.
If
we
could,
as
long
as
we
can
do
whatever
mtls
you
have
then
we'll
fit
in
there.
So
we
aim
to
do
a
very
wide
range
of
ingress.
C
C
They
will
encounter
a
lot
of
challenges
how
they
are
going
to
connect
the
micro
services,
how
they
are
going
to
do
traffic
shifting
how
they
are
going
to
handle
timeouts
and
retries.
So
as
people
developers
break
their
monolithic
to
microservices,
a
set
of
new
challenges
arise
and
kubernetes
doesn't
really
help
to
solve
these
challenges.
To
help
the
microservice
to
connect
to
each
other
to
help
the
micro
service
to
secure
is
that
establish.
Secure
communication
doesn't
help
the
owners
to
observe
what
might
be
going
on
within
different
microservices.
D
It
actually
extends
the
control
plane
of
istio
that
manages
all
of
the
programming
of
that
network
service
mesh
is
built
as
an
extension
to
kubernetes.
So
it's
api
capabilities
are
extending
the
kubernetes
environment.
The
benefit,
though,
is
that
it
works
natively
with
kubernetes.
It
also
works.
Istio
works
with
native
vms
as
well,
but
kubernetes
is
central
to
the
management
of
the
istio
control
plane
and
the
sdo
ecosystem
itself.
E
Sure
so
what
caney
means
to
provide
is
a
higher
level
sort
of
developer
abstraction
on
top
of
kubernetes,
so
k-native
serving
focuses
on
allowing
app
developers
to
be
able
to
roll
out
different
revisions.
Make
changes
easily
handles
things
like
auto
scaling
and
traffic
rollout
for
you
and
then
there's
k-native
eventing,
who
handles
sort
of
event
triggered
applications,
and
essentially
what
k-nato
provides
is
tying
all
of
that
experience
together,
because
if
he
were
to
do
it
manually,
it's
actually
quite
challenging
right
now,
maybe
I'll.
Let
paul
chime
in
here.
F
Yeah,
I
would
say:
that's
that's
a
good
summary.
One
thing
that
that
maybe
we'll
talk
a
little
bit
about
later
on
is
that
when
we
say
serverless,
we
a
lot
of
folks
tend
to
conflate
serverless
and
functions
as
a
service,
and
we
we
do
not
currently
have
functions
in
k-nib,
more
of
serverless
building
blocks
for
event,
activation
and
scale
to
and
from
zero.
A
A
F
Oh
yeah,
I
think
the
the
misconception
I
probably
spent
the
most
wall
clock
time
talking
with
people
about
is
that
you
do
not
need
a
service
mesh
to
use
k
native.
You
really
just
need
an
ingress,
and
I
think
this.
This
misconception
is
probably
rooted
in
like
a
historical
fact
that
in
the
very
early
days
of
the
project
it
was
there
was
a
dependency
on
istio,
but
we've
since
removed
that
a
fairly
long
time
ago,
and
so
you
can
use
any
any
of
the
supported
ingress.
F
A
D
Yeah
sure,
one
of
the
ones
that
we
hear
and
we've
heard
this
from
day
one
is
istio-
is
too
complex
to
get
started
with,
and
a
lot
has
changed
in
the
project
over
the
over
the
years
to
simplify
the
getting
started
experience.
But
I
think
a
misconception
here
is
that
if
you
adopt
a
service
mesh
like
istio,
you
have
to
adopt
everything
about
that
istio
about
the
service
mesh
and
all
the
capabilities
which
isn't
true.
We
have
many
people
that
adopt
very
much
to
what
paul
was
saying.
D
Many
people
adopt
istio
simply
for
the
ingress
capabilities
and
they
do
not
enable
and
take
advantage
of
the
other
features
from
day
one.
They
gradually
work
their
way
into
it
and
going
down
a
path
such
as
that.
The
install
simple
the
adoption
of
simple
ingress
through
the
istio
gateway
is
incredibly
simple,
so
it
it
doesn't
have
to
be
complex.
It
gets
more
complex
as
your
application
is
more
complex
and
takes
advantage
of
more
complex
features.
A
B
Ironically
enough,
we
often
get
the
question
or
the
statement
so
you're
using
envoy.
Does
that
mean
you're
a
service
mesh
to
which
I
say
well?
No
condor
is
not
a
service
mesh,
it's
using
envoy
as
a
like,
as
a
reverse
proxy
for
for
ingress.
Only
so
that's
probably
the
biggest
misconception
that
again
to
use
pulse
phrasing.
I've
used
spent
the
most
war
clock
time
talking
to
people
about.
B
B
Yeah
sure,
well,
I
think
you
know.
Obviously
our
major
dependency
is
envoy.
We
work
as
close
as
we
can
with
with
the
envoy
team.
You
know:
we've
done
all
the
usual
stuff
to
get
signed
up
to
the
security
announcements
so
that
we
can
make
sure
we're
keeping
up
with
those
things.
But
you
know
we
we've
been
doing
the
envoys
xds
for
a
long
time,
the
same
as
ustfx
have,
and
so
we've
you
had
start
out
with.
We
didn't
have
when
we
started
using
it.
A
C
C
A
E
I
think
for
for
k
native
it's
interesting.
So
as
nick
mentioned,
there's
contour
support,
there's
istio
support
and
I
think
the
worker
blades
and
the
toc
and
the
community
have
done
a
really
good
job,
making
sure
that
they're
developing
the
right
interfaces
to
connect
with
these
different
implementations.
E
I
think
the
the
community
really
wants
to
make
k-native
as
portable
as
possible
and
in
order
to
do
that,
they
understand
that
they
need
to
make
that
experience
with
contour
contouring,
istio
and
upstream
kubernetes
be
successful
as
possible.
So
a
lot
of
them
do
end
up
going
to
the
various
community
meetups
or
the
sig
meetings
or
the
work
group
meetings.
That's
applicable
for
the
different
work
group
leads.
F
Yeah
one
one
other
challenge
that
we've
had
is
that
is,
and-
and
this
was
a
bit
of
an
eye-opener
for
me-
having
been
historically
focused
on
openshift,
where
we
we
in
the
upstream
k-native-
want
to
support
a
variety
of
different
cubes
and
it
was
sort
of
eye-opening
to
see
that
they
they
really
move
at
different
rates.
If
you
look
at
the
cube
as
a
service
products
from
different
cloud
providers,
so
we
we
kind
of
have
this.
F
This
sort
of
sliding,
like
highest
version
of
cube,
that
we
can
get
away
away
with,
and
it's
frequently
behind
the
the
cube,
that's
under
development,
or
that
was
just
released.
So
a
balancing
act.
There
has
been
doing
things
like
before
conversion
web
web
hooks
were
pervasively
available,
doing
sort
of
what
we
could
until
we
were
able
to
rely
on
that
feature,
and
then
the
other
end
of
it
is.
F
That
is
that,
if,
if
folks
that
are
watching
aren't
aware
the
tecton
project,
which
you'll
probably
hear
more
about
in
commons
and
I'm
sure,
you're
you'll
hear
more
about
at
cubecon,
is
it
actually
started
out
as
part
of
the
k-native
project
and
they
have
a
dependency
on
some
of
our
internal
libraries
and
k-native?
So
there's
a
need
for
really
good
communication
around
that,
like
we
call
it.
The
pkg
package
that
techton
uses
too.
A
Cool
thanks,
okay,
I
think
now
we're
going
to
jump
into
more
of
what's
what's
what
what's
been
happening
in
the
products
and
what's
what's
coming,
so
I'd
like
to
hear
a
little
bit
about
what's
what's
been
happening
in
the
previous
year,
so
I'll
ask
the
question:
what,
from
your
perspective
is
the
most
important
thing?
That's
happened
in
the
project
and
if
it's,
if
it's
different,
what's
what's
the
best
thing,
that's
happened
in
your
project,
so
I'll
start
with
nick
for
contour.
B
Yeah,
I
guess
the
the
most
important
one
is
probably
similar
to
the
best
one
for
us.
We
joined
the
cncf
as
an
incubating
project
in
the
last
year.
That
is,
has
been
a
really
exciting
process
to
go
through,
and
it's
really
great
that
now
we're
officially
part
of
the
cncf
I've
when
talking
to
a
bunch
of
users
of
contour
they've,
definitely
found
it
very
reassuring
that
that
that
we
are
now
a
cncf
open
source
project
and
to
know
that
we're
not
going
anywhere
yeah.
B
B
D
We
created
a
new
and
voted
in
a
new
charter
for
steering
and
held
elections
and
changed
the
the
actual
structure
of
our
committee
itself
and
the
the
outcome
of
that
has
been
a
much
a
much
more
diverse
steering
committee
and
beyond.
Just
adding
more
diverse
set
of
members
to
the
committee.
We've
also
reduced
individual
power
of
any
one
organization
within
the
committee,
so
that
no
one
has
a
majority
on
unto
themselves,
so
it's
actually
made
a
big
difference.
D
We've
we've
noticed
it
now
now
that
we've
had
the
new
members
new
ideas,
new
dynamics
have
been
added
to
the
project
and
it's
it's
actually
been
a
really
nice
change
to
to
the
project,
to
have
other
voices
beyond
just
the
initial
founders
in
in
the
project.
So
I
would
say,
that's
probably
one
of
the
most
important
things
that
has
happened
to
the
project.
D
Obviously
there's
the
looming.
We
did
not
go
to
the
cncf
as
we
as
we
were
hoping,
but
what
we
have
found
is
that
the
chain
and
the
management
of
the
trademark,
which
was
also
an
a
pretty
large
event
in
the
community,
hasn't
really
changed
the
dynamics
on
a
day-to-day
basis
of
how
the
community
and
the
seo
project
runs.
C
I
definitely
agree
you
know
what
dan
said.
I
would
say
on
the
technical
side,
I
think
the
most
there's
so
many
accomplishments
we
did
certainly
but
the
most
impactful
one
is.
The
istio
control
plan
actually
went
from
microservices
to
monolithic
to
really
help
our
user
to
our
operators,
who
manages
istio
to
simplify
their
installation
management
experience
and,
honestly,
I
would
say
it
actually
helped
us
for
the
maintainers
on
the
project.
A
E
E
I
think
that
the
highlights
for
me
personally
are
getting
an
elected
toc
in
back
in
march,
and
just
recently
in
september,
we
defined
a
new
process
for
how
we
might
have
an
elected
steering
committee
that
can
focus
on
community
health
and
community
growth,
and
also
a
trademark
committee,
where
vendors
who
are
actively
contributing
to
k-native,
can
have
a
veto
or
a
say
in
how
the
trademark
is
used.
So
that,
for
me,
is
really
exciting.
A
I
know
that
makes
a
lot
of
sense.
I
know
a
lot.
A
lot
of
customers
are
not
confident
to
use
something
until
it
has
that
that
big
1.0
steel
seal,
so
that
was
look
at
looking
looking
behind
now.
Looking
looking
ahead
this
year,
I
want
to
go
back
back
to
you
guys
and
basically
ask
what's
what's
exciting
about,
what's
what's
coming
next,
what's
what's
interesting
there
so
again,
I'll
start
with
nick
again
on.
B
Contour
well,
we've
got
a
bunch
of
stuff
on
our
roadmap
for
the
next
year,
you
around,
adding
in
a
bunch
of
things
into
contour
that
basically
catching
up
is
the
real
story
there.
But
you
know
things
like
rate
limiting
we've
recently
added
external
authentication,
which
has
been
a
hole
for
us
for
a
while.
But
I
think
that
the
biggest
thing
that
I'm
looking
forward
to
adding
in
the
next
year
is
support
for
the
new
service
apis
that
are
being
built
in
the
kubernetes
working
at
the
moment.
B
We've
been
involved
in
that
project
since
since
its
inception,
and
I
think
that
it's
really
great
chance
to
remedy
some
of
the
deficiencies
of
the
thing
that
I
mean,
which
were
things
that
we
just
missed
that
were
just
missed
when
people
started
building
ingress,
because
no
one
had
done
it
before
and
no
one
knew
what
we
needed.
But
now
everyone's
been
using
ingress
for
some
time,
and
now
we
kind
of
know
know
what
it
is,
that
we
need
and
so
we're
able
to
design
a
much
better
api.
B
A
C
Yeah,
so
I
I
think
we,
our
users,
are
getting
comfortable
using
issue,
at
least
on
the
common
scenarios
in
single
map,
a
single
cluster,
so
a
lot
of
focus
of
the
project
has
been
shift
to.
How
do
we
improve
users
experience
beyond
a
single
cluster?
How
do
we
onboarding
users
services
on
a
vms
securely
and
easily?
How
do
we,
how
do
we
allow
users
to
run
services
on
different
cluster?
C
How
do
we
federate
different
meshes
together,
so
I've
seen
community
has
been
kind
of
a
shifting
this
notion
of
beyond
single
cluster
experience,
where
we
really
want
to
expand
the
service
mesh.
You
know
beyond
a
single
kubernetes
cluster
so,
for
instance,
we're
being
consolidate
our
multi-cluster
model
into
one
single
model,
which
I
really
like
so
before
the
longest
time.
You
know
there
was
like
two
models
and
we
got
tons
of
questions
from
our
user.
C
Why
would
you
use
this
or
that
we've
also
introduced
external
control
play
which
allows
user
and
mesh
admin
to
work
with
single
cluster,
where
their
control
plane
runs
outside
of
the
cluster
and
provide
opportunity
for
vendors
who
runs
istio
as
a
service
for
for
the
user?
So
these
are
exciting
things
we
are
introducing
in
the
community
to
improve
users
experience,
whether
it's
single
cluster
or
whether
they
want
to
grow
the
mesh
beyond
the
single
cluster
to
include
vms
and
multiple
clusters.
A
D
D
Also
a
big
a
big
deal,
the
new
kubernetes
multi-cluster
services
support
is
a
is
a
big
area,
obviously
aligned
with
that
same
notion
of
the
multi-uh
multi-cluster
multi-mesh
scenarios.
These
these
keep
coming
up
with
our
with
our
customer
sets
continuing
to
expand
on
support
for
hybrid
workloads,
because
not
everything
is
containers,
so
you
do
have
legacy
so
being
able
to
tie
into
those
legacy.
A
F
A
F
Of
the
things
that
that
to
to
to
go
back
to
what
I
previously
said
around,
hitting
that
v1
api
version
is,
we
have
not
actually
released
1.0
yet
so
the
api
and
api
version
and
the
actual,
like
version
number
of
the
software
two
different
things.
One
of
the
things
that
I
think
related
to
the
trademark
committee
that
brenda
mentioned
earlier.
That
became
a
lot
more
clear
during
our
like
community
process
for
working
through
the
governance.
E
Maybe
one
thing
I'll
add
is
we've
seen
a
lot
of
excitement
around
forming
a
functions
working
group
within
the
community,
and
I
think
that
will
be
pretty
exciting.
Coming
up,
we've
seen
a
lot
of
excitement,
a
lot
of
people
passionate
about
this
topic,
so
I
think
that's
probably
something
that
people
can
look
forward
to.
A
Sounds
good,
so
a
lot
lots
to
come
final
question
that
I'm
gonna
go
around
with
you
guys
on
is
so
open
source
can
have
many
interesting
moments
and
there's
a
lot
of
benefit.
So
I'd
like
to
hear
about
what
what's,
what's
your
favorite
open
source
moment
that
you've
seen
in
your
project
and
I'm
actually
gonna
go
back
to
paul
first
on
this,
because
I
know
that
he,
this
is
one
that
he
was
interested
to
talk
about.
So.
F
And-
and
I
brenda
you'll
have
to
correct
me
if
I
misremember
the
number
of
people
but
like
I'm
pretty
sure
in
that
first
public
meeting-
that
we
had
we
had
about
55
or
60
people
dialed
in,
and
that
was
that
was
just
a
great
feeling
to
to
see
that
people
were
that
interested
in
working
through
these
things
and
just
just
energizing
to
know
that
that
other
people
cared
about
it
as
much
as
you
know.
I
do,
and
I
know
that
brenda
does.
E
That
that's
exactly
the
moment
that
came
to
mind
for
me
as
well.
I
believe
it
was
like
65
people
on
a
zoom
call
or
a
hangout,
and
it
was
just
so
good
to
know
so
many
people
cared
about
the
success
of
this
project
and
everyone
was
open
for
discussion.
There
was
no
pointing
fingers.
Everyone
just
wanted
to
make
the
community
better.
That
was
a
really
nice
feeling.
A
D
Yeah,
I
was
gonna,
I
was
gonna,
say
and
I'm
gonna
go
beyond
just
this
year.
I'm
gonna
go
back
to
2019
was
one
one
event
that
I
thought
was
incredibly
interesting.
It
was
kubecon
in
san
diego,
and
this
was
pre-covered.
Obviously,
so
we
could
actually
get
together,
but
the
problem
was
there:
we
we
wanted
to
do
a
meet-up
for
istio,
but
we
kind
of
organized
it
late
and
we're
we're
not
the
best
at
some
of
these
organizational
skills.
D
If
you
will
so,
we
tried
to
organize
one,
but
we
ran
out
of
space.
There
was
no
available
locations
that
we
could
use,
but
someone
came
up
with
a
pretty
novel
idea
and
an
approach
and
come
to
find
out.
Our
meetup
was
later
in
the
evening
on
a
boat
which
I've
never
had
a
meet-up
on
a
boat
before
it
is
kind
of
odd
when
you're
walking
up
and
you're
you're.
D
D
B
C
Remember
the
name
either,
but
that
was
like
a
really
special
evening.
Gosh,
it's
so
interesting.
I
remember
somebody
I
think
it
was
christian
was
trying
to
show
a
live
demo
on
that
boat
where
there
was
no
projector,
so
everybody
had
to
stare
at
his
tiny
monitor
for
his
demo,
but
it
was.
It
was
a
really
cool
event
I
actually
saw.
B
Yeah
because
we're
such
a
we're
so
much
a
younger
project
and
a
smaller
project
than
the
others.
My
stories
are
kind
of
different.
I
guess
you're,
one
of
one
of
the
great
open
source
moments
for
me
has
been
being
accepted
into
the
cncf
and
being
able
to
say.
Okay,
now
we're
really
open
source
and
one
of
the
things
that's
come
with.
That
is
greater
visibility
and
more
comfort
from
people
to
come
and
talk
to
us
about
what
they've
been
doing.
B
One
of
the
things
that
I
found
when
I
became
the
tech
lead
for
contour,
which
is
about
the
same
time
as
we
we
were
accepted,
was
that
you
know
a
number
of
people
had.
We
were
a
small
team,
then,
and
a
number
of
people
had
because
they
wanted
features
that
we
just
couldn't
build
for
them
fast
enough.
B
You
know,
even
though
we
weren't
so
great
at
getting
it
started,
but
but
they
stuck
with
it
and
helped
us
out
and-
and
everyone
has
won
in
the
end,
because
the
people
who
needed
the
feature
got
it
and
we
got
to
good
got
them
to
build
it
for
us.
I
guess
I
said,
and
this
and
the
other
thing
is
just
all
of
the
times
you
know
again.
B
I
really
want
to
thank
okay
native
team
for
they've
they've
discovered
two
pretty
critical
performance
issues
for
us
because
of
the
scale
testing
that
they
run
on
contour
that
yeah,
we
probably
wouldn't
have
found
until
it
went
out
wider
and
so
yeah.
That
was
another
great
open
source
moment
where
people
who
are
not
part
of
the
core
main
maintenance
group
have
really
helped
us,
and
really,
you
know
been
able
to.
You
know,
drive
improvements
to
the
product,
even
though
it's
not
their
main
job.