►
From YouTube: Birds of a Feather: Knative - Jessie Zhu, Google
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
Birds of a Feather: Knative - Jessie Zhu, Google
Knative is an OSS project to build high-quality serverless components on Kubernetes with a "voltron effect": the pieces work separately, but come together to work even better. Jessie Zhu (Google) will facilitate a discussion on how we build and release Knative and the challenges of decoupled and pluggable interfaces.
To learn more: https://sched.co/GraF
A
A
That's
interesting,
but
I
feel
like
some
of
the
key
pieces
of
Kay
native
are
actually
a
step
or
two
back
from
that
in
the
philosophy.
So
when
we
were
starting
on
this
project,
one
of
the
things
that
we
thought
was
really
important
was
actually
that
we
were
going
to
improve
the
experience
for
developers
in
particular.
Operators
actually
seem
to
have
it
pretty
good
in
kubernetes.
You've
got
lots
of
controls.
It's
really
easy
to
extend.
Oh
look!
Here's
all
this
stuff!
A
So
for
those
of
you
who
haven't
raised
your
hands,
that's
totally
fine
I
hadn't
encountered
them
until
maybe
a
year
and
a
half
or
two
years
ago,
but
the
idea
is
that
you
define
some
particular
users
that
you
imagine
wanting
to
use
your
system
and
you
talk
about
what
their
needs
are
and
what
their
desires
are
rather
than
sort
of
abstract
system
capabilities,
and
so
oftentimes.
These
correlate
to
things
like
user
journeys.
Where
you
say
hey,
you
know,
I
am
a
developer.
I
write
code
that
solves
business
problems.
A
You
know
I
need
to
manage
inventory
at
this
store.
You
know
what
are
the
steps
I
need
to
do
in
order
to
ship
this
software
get
a
big
bonus
and
go
on
vacation
at
the
end
of
the
year.
You
know-
and
that's
you
know
that's
my
interest.
My
interest
is
not
necessarily
I
want
to
learn
a
bunch
of
new
technology
or
you
know,
hey
I
really
want
to
learn
a
lot
about
distributed
systems.
I
want
us
to
not
run
out
of
inventory
during
Christmas.
A
That's
my
job,
and
so
you
know
how
do
we
make
that
easy
for
them?
Operators
are
people
who
provide
the
infrastructure,
who
probably
enforced
corporate
policy.
You
know
hey,
maybe
you
shouldn't
be
pulling
random,
docker
images,
or
maybe
you
know
it's
awesome-
that
you're
using
node,
but
maybe
we
should
make
sure
that
you're
not
installing
more
than
one
cryptocurrency
miner
per
process-
and
you
know
so.
Operators
have
in
kubernetes
a
bunch
of
tools.
They
have
a
bunch
of
problems
too,
but
the
community
is
very
well
engaged
with
things
like
registry
scanning
and
policy.
A
If
you
saw
some
of
the
OPA
talks,
we're
even
getting
into
a
pretty
complicated
attribute
based
access
control,
their
developers,
it's
like
hey
checking
your
code,
learn
docker
check
in
a
bunch
of
llamó
figure
out
what
your
CI
CD
system
looks
like,
and
then
you
can
start
solving
your
problems.
Don't
worry.
I
only
told
you
about
five
or
six
things,
there's
actually
about
10
or
12,
nouns
you're
going
to
need
to
know
in
order
to
be
productive,
that's
ten
or
twelve
nouns
that
they
can't
use
thinking
about
their
business
problems.
A
So
the
goal
for
creative
was
to
make
it
hey.
Here's
two
or
three
things
you
need
to
know:
they're
the
bare
minimum
you
need
to
know
and
they'll
give
you
a
lot
of
power
and
leverage
the
third.
The
third
thing
which
over
here
is
this
lovely
yellow
that
is
kind
of
hard
to
read
on
the
screen,
is
contributors
and
those
are
the
folks.
You
know
here
in
the
front
and
scattered
through
the
audience
who
are
actually
writing
the
que
native
software,
and
you
know
we
want
to
make
things
good
for
them.
A
So
we
have
enough
contributors
that
we
can
keep
building
a
software
project,
they're
not
the
end
goal
but
they're
how
we
get
to
the
end
goal
and
our
thesis
is
that
if
we
make
developers
love
K
native
and
we
make
it
no
worse
for
operators
than
their
current
workload,
they'll
be
happy
to
add
it
into
their
clusters.
And
then
we'll
have
a
lot
of
people
running
K
native
and
a
lot
of
happy
developers.
A
And
you
know,
contributors
will
want
to
go
and
make
a
difference,
because
we
will
make
it
easy
and
rewarding
for
them,
and
so
sometimes
you'll
hear
me,
call
it
specific
people
for
functionality.
That's
because
I
want
to
say
thank
you
for
contributing,
and
we
think
that
our
audience
sizes
look
like
this,
except
that
the
scale
here
is
probably
more
logarithmic
than
linear.
A
So
there's
a
whole
bunch
of
people.
Most
people
really
who
are
developing
software
should
be
doing
it
in
a
stateless.
You
know
something
like
a
twelve
factor
case
unless
you're
working
on
databases,
for
example,
and
then
you
really
don't
get
to
be
stateless
and
I'm.
Sorry,
but
we're
not
solving
your
problems.
A
There's
going
to
be
a
bunch
of
you,
hybrid
on-prem
cloud,
I,
see
folks
from
you
know,
IBM
here
in
Red,
Hat
and
pivotal
I
think
I
saw
here
and
we've
been
working
with
a
bunch
of
smaller
companies
and
people
who
you
don't
necessarily
think
of
traditionally
as
like
cloud
or
operator
personas
and
then
of
course,
contributors.
We're
all
here
to
well
we're
here
to
encourage
you
to
get
involved.
A
That
changes
over
time,
hey
what
you
want
on
day.
One
is
not
the
same
thing
that
you
wanted
a
365.
In
fact,
some
of
the
things
you
want
on
day,
one
our
stuff
that
you'd
be
terrified
of
on
day
365
on
day
one
someone's
like
hey.
Did
you
hear
about
that
Cantina
project?
You
should
check
it
out.
You're
like
well
I've,
gotten
our.
Let's
see
what
I
can
learn.
Is
this
any
good?
A
A
365,
there's
money
in
this
system
and
you
have
to
keep
it
running
and
you
have
customers
and
if
you
made
a
mistake
on
day
seven
and
your
assessment
and
you
got
to
day
365.
Well,
you
get
to
own
that
mistake.
You
don't
you're,
not
gonna
change
that
without
a
lot
of
effort.
So
we
want
to
make
sure
that
if
you
choose
to
invest
in
us
on
day
one
or
day,
seven
then
on
day,
365
you're
still
happy
about
that
choice.
A
And
so
these
were
some
of
the
tools
you'll
note
that
the
stack
gets
bigger
as
you
go
along
in
terms
of
demands
and
requirements,
but
you're
also
getting
more
people
involved
and
you're
actually
changing
your
organization
in
some
sense
as
you
go
along,
so
you
know
day
one
in
day:
seven,
it's
probably
you
and
your
laptop,
maybe
day,
seven,
it's
your
your
personal
like
cubic
Rene's,
cluster
or
mini
cube,
or
something
like
that
day.
30,
maybe
you're
starting
to
have
like
everybody,
has
their
own
sandbox.
A
And
then
you
have
a
place
where
you
merge
and
integrate
and
on
day
365.
You've
got
you
know:
staging
pre,
prod,
prod,
controlled,
rollouts,
rollbacks,
post
mortems,
when
you,
when
you
screw
up
software
releases
and
stuff
like
that
and
to
be
clear,
you
know,
post
mortems
are
good
people
screw
up
software
releases.
A
So
you'll
see
on
day,
one
and
day,
seven
you're,
probably
mostly
interacting
with
service
you're,
probably
mostly
in
whren
latest
day
30
you're,
probably
figuring
out
how
to
do
your
releases
and
stuff
like
that
and
you're
starting
to
learn
about
the
lower
layers
of
the
system,
and
we
don't
want
to
hide
those
from
you
completely.
We
don't
want
to
say
no,
no,
you
don't
get
to
touch
sto
because
that's
too
complicated
for
you
don't
worry
about
that.
A
We
want
to
say,
don't
don't
get
into
sto
until
you
need
to
solve
these
kinds
of
problems
that
is
Tio's
good
at
and
then
you
know,
here's
sto
and
you've
like
unlock
to
power
up
basically,
and
we
should
work
well.
If
you
are
managing
sto
and
we
are
managing
sto,
it
should
be
really
clear
and
we're
not
as
good
at
this
today
is.
A
We
should
be
where
that
boundary
is,
you
know
and
as
you
go
on
towards
day,
365
you're,
probably
starting
to
take
advantage
of
stuff
like
career
days,
admission
controllers
and
you're
really
owning
that
whole
kubernetes
cluster,
rather
than
you
know,
oh
I'm,
in
a
small
sandbox
on
top
and
that's
your
organization,
you
as
a
developer,
you
may
still
be
actually
like
I.
Don't
want
root.
A
I
want
to
I
want
to
write
my
code,
but
somebody
else
is
making
sure
that
all
of
that
admission
control
and
everything
else
is
safe
and
protected,
and
every
time
I
build
an
image.
You
know
we're
scanning
it
for
vulnerabilities
and
we're
putting
it
we're,
making
sure
to
only
run
things
from
validated
repos
and
things
like
that,
and
so
with
that
everyone
likes
to
talk
about
the
different
components
that
we
have
and
so
here's
the
obligatory.
A
A
Most
of
these
are
interesting
topics
that
are
going
on
in
the
three
main
working
group
serving
build
and
eventing,
but
I
also
want
to
call
out
that
we
have
a
bunch
of
cross-cutting
concerns
and
we
have
working
groups
for
those
too.
So
if
you're
interested
in
documentation
or
how
do
you,
you
know,
how
do
you
actually
release
an
open
source
project?
A
We
don't
know
the
answer
yet,
but
if
you
have
good
ideas
right
now,
the
productivity
contributor
productivity
working
group
works
on
both
that
and
testing,
but
they
would
I'm
sure
they
would
appreciate
your
help
and
each
of
the
working
groups
for
serving
build
and
eventing
also
has
to
figure
out
pieces
of
that
puzzle.
So
you
I'd,
say:
there's
open
questions
in
all
of
these,
but
the
big
question
here
is:
what
do
people
want
to
talk
about.
A
C
I'm
so
happy
that
you
did
this
to
me
mad,
so
yeah
pipelines
is
a
new
project.
It's
building
on
some
of
the
cool
stuff
that
we
have
in
Canada
build
so
I.
Think
at
this
conference,
you've
seen
that
people
are
there's
a
camera.
That's
okay,
you've
seen
that
people
are
very
excited
about
Kane,
a
to
build
and
using
it
for
a
lot
of
things
and
then
there's
more
complicated
use
cases
that
people
have
been
coming
up
with
where
they
want
to
put
different,
builds
together
in
a
pipeline
or
maybe
have
like
a
graph
of
sorry.
A
You
I
think
that's
actually
a
great
example
of
some
of
the
ecosystem
benefit
we'd
hope
to
get
when
we
started
this
project.
If
there
was
an
existing
standard
for
a
for
doing
kubernetes
build
that,
actually,
you
know
was
kubernetes
as
opposed
to
go
somewhere
else
and
figure
out
some
other
system.
We
would
latch
on
to
that.
The
same
way
that
we
latched
on
to
sto.
We've
started
with
e
lk
for
observability
and
Prometheus
and
zip
gun
for
observability,
but
not
seeing
one.
E
C
Think
what
we're
hoping
to
do
is
build
an
interface
that
many
different
providers
of
CI
CD
could
implement
and
use
so
I
think
anyone
who
wants
to
be
providing
CI
CD
could
potentially
comply
with
this
interface.
So
the
interface
is
the
most
valuable
part
just
like
expressing
like
I
need.
These
things
to
occur.
I
need
them
to
occur
in
this
order.
A
D
A
A
It
was
the
cloud
events
deep
dive
and
if
you
get
a
chance
to
see
those
slides,
there's
some
good
insights,
but
the
I
think
the
key
piece
that,
if
is
intended
to
be,
is
a
pattern
where,
when
changes
happen,
there's
a
way
of
recording
that
they
happened
and
delivering
it
to
interested
parties.
The
talk
yesterday,
distinguished
venting
from
messaging
in
that
in
events,
things
happen
and
you
shout
about
what
you're
doing
and
maybe
somebody's
listening
and
maybe
nobody's
there
and
typically
in
messaging.
A
A
F
Then
messaging
could
be
something
like.
I
want
to
send
a
message
to
that
guy
and
that
guy
and
that
guy,
because
I
we
already
have
a
little
relationship
and
that
would
be
messaging,
but
at
the
end
of
the
day
you
as
a
developer,
you're
writing
code
to
handle
that
data.
So
it's
all
about
data,
so
data
could
be
communication.
It
could
be
weather,
it
could
be
click
events.
So
the
decoupling
allow
us
to
build
patterns
Enterprise
patterns,
where
we
can
create
ETL
process
data
from
machine
learning
process.
F
G
D
A
A
A
It's
a
little
bit
fuzzy
in
some
cases
and
eventing
typically
works
by
sending
messages
so,
but
rather
than
the
applications
knowing
intrinsically
like
hey
I'm,
going
to
send
this
over.
Here,
it's
a
little
bit
more
like
on
top
of
somebody
drawing
the
topology
rather
than
writing
it
into
the
code,
and
it
looks
like
Carlos
says
more.
So
if
he
wants
to
say.
F
Developers
they
should
not
care
right.
The
infrastructure,
the
kubernetes
infrastructure
or
whoever's
building
the
dis
chat
event
sources
are
the
ones
going
to
deliver
that
message
to
your
function
right,
your
function
didn't
know
if
there
was
a
micro
services
right
pooling
for
events
or
just
listening,
ideally
even
the
perfect
world,
every
open
source
should
be
pushing
notifications
because
nobody
wants
to
spend
time.
Just
like
are
you
there?
Are
you
there?
Alright,
you
there
right,
but
we
have
systems
of
Records.
F
We
have
legacy
systems
or
classic
systems
that
you
have
to
do
it
because
those
systems
are
already
installed
and
you're
not
going
to
have
have
those
systems
change
to
send
event.
So
one
example
is
work
with
CouchDB,
so
couchdb
doesn't
have
a
way
of
saying
hey
when
somebody
inserts
a
non-sequel
document
into
your
database
go
and
send
an
HTTP
request
to
this
URL.
So
we
have
to
create
a
a
micro
service
where
it
can
configure
that
and
it
will
pull
the
connect
to
the
database
and
it
will
start
listening
for
messages,
interesting
messages.
G
A
Been
talking
with
a
lot
of
people
with
both
messaging
and
eventing
backgrounds,
I
say
one
of
the
challenges
has
been
to
get
a
quorum
of
people
on
the
same
page
I'm,
not
even
going
to
say
a
substantial
majority,
because
there's
a
lot
of
different
use
cases
and
some
people
want
to
use
events
as
glue,
and
some
people
want
to
do
like
heavy
duty.
Thousands
of
requests
per
second
or
millions
of
events
per
second
type
processing
and.
A
It's
hard
to
design
a
system
that
will
meet
all
of
those
needs
and
we're
likely
to
end
up
in
a
place
where
a
lot
of
things
fit,
but
we
also
want
to
build
in
safety
valves
if
you
were
here
at
Joe's
last
talk
about
auto
scaling,
I
think
it's
related.
Therefore,
you
can
plug
in
different,
auto
scalars
2k
native
serving
stack.
So
if
you
discover
that
our
default
concurrency
based
autoscaler
is
no
good
for
you,
then
you
can
plug
in
something
else,
and
Joe
actually
showed
how
you
can
plug
in
your
own
custom
algorithm.
A
So,
ideally,
you
could
plug
in
some
of
these
opinions
like
akka
or
light
bend
either
at
the
beginning
or
at
the
end
of
pipe
lines
or
other
things
that
we're
doing
and
I
forgot
to
mention
pipe
lines
is
part
of
what
eventing
is
doing,
because
that
piece
is
currently
pretty
well-established
any
other
questions.
How
many
people
here
actually
have
had
a
chance
to
try?
K
native
that's
pretty
cool?
A
A
It's
a
little
bit
hard
to
resist
fixing
those
sometimes
because
you're
like
I,
could
fix
this
so
quickly
and
it's
like,
but
someone
else
could
learn
from
it.
I
shouldn't
take
this
issue.
I
should
write
it
up
instead
and
so
sometimes
we're
better
than
others
Docs.
We
have
a
I'd
say
we're
doing
okay
on
Docs,
but
there's
probably
lots
of
places
where
we
could
have
better
samples.
A
One
of
the
projects
that
someone
pointed
out
a
month
or
two
ago
is
we
have
a
bunch
of
pinpoint
docs
or
how
to
do
specific
thing,
but
there
isn't
something
that
does
the
overall
flow
that
puts
everything
together.
So
if
you
have
examples
that
put
together
multiple
components
into
one
big
arc,
it'd
be
very
interesting
to
see
those
and
see
what
the
install
and
stuff
like
for
that
stuff,
like
that
looks
like
and
yeah
we're
interested
in
talking
with
lots
of
people
who
are
solving
problems
in
this
space,
we'd
like
to
collaborate
in
some
cases.
A
A
Someone
can
correct
me
for
further
than
that,
so
you
could
replace
sto
with
contour
and
the
way
we
do,
that
is
with
a
internal
CRD
that
describes
what
we
wish
the
resources
look
like
and
then
we
take
our
external
things,
turn
them
into
what
we
wish
things
look
like,
and
then
we
have
something
that
takes
what
we
wish
things
looks
like
and
takes
it
to
sto
or
takes
it
to
contour.
The
autoscaler
works,
I'll
plug
them.
A
lot
of
scaler
works
in
the
same
way.
A
B
So
there's
actually
a
recording
of
the
demo
of
plugging
in
hep.
Do
you
someone
say
something
of
plugging
in
hep,
D
is
contour
to
the
networking
layer,
I
think
Demetri,
who
I
don't
know
if
he's
in
the
audience
didn't
need
to
tweak
it.
So
we
need
a
whole
number
of
features
in
it.
I
think
it
was
missing,
like
header
decoration
or
something
like
that,
so
it's
not
quite
ready
for
general
consumption,
but
it
helps
prove
the
concept
and
you
know
we
talked
to
folks
like
linker
de
and
whatnot
touring
the
booths.
G
G
A
Be
keyed,
X
or
something
I
think
that's
part
of
it.
So
I
have
a
really
good
answer
for
this
yesterday,
when
I
got
put
on
the
spot
and
then
talk
and
I,
don't
think
that
I
had
a
microphone,
so
no
one
will
ever
hear
it
again,
I'll
see
if
I
can
recreate
it.
So
at
Google
we've
built
a
few
serverless
platforms
and
every
time
we
do,
we
have
regrets
about
design
choices.
We
made
different
ways.
A
We
were
going
through
one
of
those
rounds
and
thought
you
know.
Well,
if
we're
gonna
do
it
again,
we
should
really
do
it
in
open
source
and
we
should
look
at
and
learn
from
the
other
offerings
out
there
and
having
done
it
a
number
of
times.
We
had
a
number
of
features.
We
knew
we
wanted
and
we
looked
at
a
lot
of
the
existing
offerings
and
what
it
would
take
to
bend
them
into
the
shape
we
imagined
and
by
the
time
we
looked
at
doing
that.
A
But
we
also
wanted
a
bunch
of
features,
some
of
which
you'll
recognize
from
things
like
App
Engine
about
tracking
revisions
and
percentage
based,
rollout
and
easy
rollback
I'm
coming
from
the
essary
side
of
the
organization.
Fast
rollback
is
particularly
important
to
me
as
a
way
to
solve
something
like
80%.
Probably
of
your
issues
is
you
know,
hey,
we
made
a
change
recently.
How
do
I,
how
do
I
go
back
either?
A
It
will
solve
the
problem
or
it
will
prove
that
it's
not
part
of
the
most
recent
change
I
made
and
it's
something
else,
and
so
we
knew
we
wanted
that,
and
we
knew
that
sto
provided
that
kind
of
fine-grained
percentage-based
rollout,
and
so
we
started
looking
ok.
What
do
we
need
to
make
a
good
service
platform?
What
can
we
reuse
what's
extensible
and
what
is
what
can
we
take
pieces
of
in
order
to
make
it
work?
A
Eventing
doesn't
do
this
as
well
as
we'd
like
today,
but
you
can
install
build
and
not
need
serving
or
venting
you
can
install
serving
and
not
need
builder
venting
today,
if
you
install
eventing,
you
need
serving,
but
only
for
certain
event
sources,
but
right
now
our
packaging
isn't
good
enough
to
make
that
fine
grained,
and
so
that's
one
of
the
things
that
want
to
fix
there,
but
ideally
job
a
to
describe.
This
is
the
Voltron
effect.
You
have
a
bunch
of
pieces
that
are
useful
and
someone.
A
You
know
who
wants
to
go
and
take
build
and
use
it
to
launch
deployments,
and
they
don't
care
about
serverless.
They
should
be
able
to
do
that,
but
if
you
put
them
all
together,
you
get
a
full-powered
platform
for
serverless.
That
looks
a
lot
like
the
other.
You
know
the
major
commercial
offerings
out
there.
You
know
lambda
or
GCF
or
Azure
cloud
or
Azure
functions
or
open
wisk,
and
it
takes
your
source.
You
hand
it
some
source
code.
It
takes
it
scales
it
handles.
A
A
lot
of
these
pieces
connects
events
to
it
and
you
can
get
all
that
functionality,
but
it's
all
built
on
open
source
components
and
those
open
source
components
are
each
on
their
own
feedback.
Loop,
that's
getting
better,
but
also
by
being
on
top
of
them.
We
give
them
incentive
to
get
better.
We
say:
hey,
you
know
our
cold
start.
Latency
is
at
four
seconds.
We
need
it
to
be
at
one
second,
you
know
this
is
the
work
that
is
tio
needs
to
do.
This
is
the
work
that
kubernetes
needs
to
do.
A
Maybe
htv-2
works
as
well,
we're
not
for
later
this
year,
we'll
start
thinking
about
how
do
you
do
upgrades
and
things
like
that?
But
right
now
we
have
enough
other
pieces
to
figure
out
including
stuff,
like
releases
and
observability
and
so
forth
that
we
only
solve
so
many
problems
at
one
time,
but
all
our
roadmaps
and
everything
else
are
public.
A
If
you're
curious,
it
should
be
easy
to
get
involved
with
any
of
these
things.
I
failed
to
actually
put
a
slide
that
has
all
of
the
links
on
it,
but
github.com
K,
Native
Docs
has
a
community
subsection
in
there.
That
tells
you
a
lot
about
how
to
get
involved
the
groups
to
join
the
slack
channel
to
join,
and
if
you,
you
know,
find
any
of
the
people
on
the
project.
A
B
I'm
gonna
give
that
back,
but
to
echo
one
one
thing
Evan
said
right
like
about
the
benefits
of
layering.
It
just
feels
endless
right
like
there
was
a
really
cool
demo
from
been
browning
earlier
today
about
Jiali
and
like
visualizing,
the
traffic
and
like
we,
he
was
doing
it
for
K
native
deployments,
and
you
know
you
you
were
able
to
do
that
just
by
virtue
of
the
fact
that
we
were
layered
on
top
of
sto
right
integration
with
the
mesh
right
like
we're
not
doing
any
special.
B
Anything
special
with
that
right,
like
ISTE,
is
injecting
things
into
pods
right
and
since
there's
pods
under
the
hood
investments
you
make
around
policy
that
effects
things
at
the
pod
level
right.
Those
should
just
work
with
things
like
K
native,
so
it's
ya
know
but
yeah.
So
all
of
the
benefits
we
get
to
read
from
this
massive
ecosystem,
we're
building
on
top
of
our
really
exciting,
and
so
seeing
all
the
talks
around
here
and
being
like.
Oh
cool
I,
want
to
I
want
to
try
using
that
with
K
native.