►
From YouTube: Governing the Cloud Native Event Bus: Applying ServiceMesh to Knative E... Michael Costello (Part 1)
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Governing the Cloud Native Event Bus: Applying ServiceMesh to Knative Eventing Workshop - Michael Costello, Red Hat (Part 1)
In the cloud we expect our resources to be able to come and go and react to the environment around them in a way that meets our business needs. While we take on event streaming and serverless architectures to accomplish this need in the cloud, our new architectural constructs can be unwieldy and grow past our traditional attempts to apply authorization, authentication, rate limitation, policy, and other traditional enterprise requirements around our service interactions. In this workshop, we discuss the implications of event streaming and serverless architectures, and how we might re-inject governance models, mutual authentication, all the wonderful guardrails as well as observability a Service Mesh gives us (in our case, Istio) to cloud native event streaming serverless models (in our case, Knative Eventing with Apache Kafka). At the end of this presentation, participants should be able to assert viable architectural patterns to governing these service interactions and will be exposed to the technology behind an implementation of these approaches (via a demo!).
A
A
This
is
a
talk
about
k-native,
eventing
and,
more
specifically,
what
I'd
like
to
refer
to
as
a
cloud
native
event,
bus
think,
old-school
esbs,
but
it's
2021
and
we're
going
to
present
us
something
a
little
bit
different
than
a
monolithic
esp
we're
going
to
inject
issio
into
this.
To
attempt
to
get
give
ourselves
some
notion
of
governance,
which
k-native
eventing
may
kind
of
lack
about
me.
I'm
a
senior
architect
of
red
hat.
I
work
in
an
emerging
technologies
practice
in
services.
A
A
We
need
to
kind
of
go
figure
out
how
k
native
works
with
issio
k,
native
eventing
doesn't
work
right
out
of
the
box
with
istio,
so
we'll
definitely
want
to
do
a
little
bit
of
a
deep
dive,
because
we've
got
some
things
to
do,
which
you
guys
will
see
in
the
repo
I'll
point
you
towards
speaking
of
which,
if
you
guys
go
to
github.com
my
coslo,
okay
native
event,
examples.
This
is
where
everything's
going
to
happen.
A
Why
we're
doing
this
to
begin
with
for
a
while
and
then
we'll
check
back
in
what
we're
using
we're
using
a
kubernetes
system.
In
my
case,
I'm
using
openshift48,
you
don't
need
to
use
openshift.
In
fact,
you
could
really
use
any
kubernetes
cicero
as
long
as
we're
talking
about
a
version
past
119
or
something
like
that
and
seo
2x
just
around
in
my
case,
I'm
using
maestra.
It's
the
red
hat
operator.
A
However,
generally
speaking,
what
you'll
find
is
the
primitives
we're
using
are
issue
primitives,
there's
nothing,
mostly,
nothing
specific,
that's
going
to
happen!
That
is
meister
specific,
so
you
can
probably
get
away
with
just
about
any
seo
distro
as
long
as
it's
a
2x
disarm,
we're
gonna
use,
k
native
in
my
case
again,
I'm
using
openshift
serverless.
However,
you
don't
need
to
use
openshift
serverless
we're
only
using
k-native
serving
and
k-native
eventing
primitives.
Really,
you
could
use
most
recent
distros
of
k-natives.
A
So
if
you
guys
don't
have
a
if
you
don't
have
a
open
shift
available
with
all
the
openshift
fun,
you
can
really
just
use
like
I
said
any
kubernetes
cistro,
most
issio
operators,
most
k
native
operators,
so
on
and
so
forth.
Right
and
then
I'm
going
to
use
something
to
demonstrate
k
native
services
and
how
we
kind
of
get
on
the
cloud
native
event
bus
I'm
going
to
use
something
called
camel
k
totally
immaterial
to
what
we're
doing
here.
A
A
So
real
quick.
Let's
talk
about
the
rise
of
cloud
native
architecture,
let's,
and
why
it's
important
more
specifically,
let's
take
a
little
trip
through
history,
we'll
kind
of
find
how
we
got
here.
So
initially
we
had
main
we
had
mainframe
computing
kind
of
give
way
to
client
server
approaches.
That
was
pretty
cool.
If
you
guys
will
remember
vividly
the
late
90s
mid
90s.
So
this
was
really
cool
because
it
democratized
compute,
you
didn't
need
to
go,
buy
a
million
dollar
mainframe.
A
You
could
go,
buy
something
much
smaller
one
small
problem.
These
things
tended
to
be
at
least
our
initial
client
server.
Implementations
tended
to
be
a
little
heavy
weight.
We
started
moving
to
things
that,
and
you
know
what
we're
talking
about.
Are
things
like
you
know
fat
clients
stuff
like
this.
A
It
was
really
quite
difficult
to
go
out
and
distribute
software
like
this,
and
so
what
we
started
doing
is
moving
this
more
distributed
software
techniques,
this
beca,
as
mentioned
this
became
unwieldy
right
and
some
of
the
distributed
techniques
we
moved
to
like
rpc,
corba,
so
on
and
so
forth,
they're
a
little
ugly.
I
think
many
of
us
have
stubbed
our
knees
and
toes
and
got
quite
bloody
because
of
corba,
really
really
painful
stuff.
A
If
you
were
doing
rmi
in
the
late
90s
and
early
odd
years,
so
we
started
publishing
a
variety
of
tool
sets
to
kind
of
accommodate
this
right.
We
started
thinking
about
things
like
asynchronous
messaging,
which
fit
quite
nicely
with
some
of
the
mainframe
concepts
we'd
had
in
the
past.
We
we
started
coming
up
with
these
things
that
were
patterns
that
we
noticed
emerging
everywhere
so
right.
You
know
10
years
ago,
15
years
ago,
very
buzzy.
A
We
we
started
coming
up
with
a
survey,
a
service,
oriented
architecture.
We
started
coming
up
with
things
like
enterprise
integration
patterns,
where
we
would
say,
hey.
We
notice
some
of
these
behaviors
that
happen
quite
a
bit
and
we
we
actually
want
to
encode
this
in
a
practice
and
advocate
usage
of
the
pattern,
so
that
was
really
cool
right.
We
got
there
but
oh
yeah,
and
before
we
talk
about
that,
so
initially
we
kind
of
have
these
point-to-point
remote
invocations.
A
A
This
was
hot
hot
hot
in
the
mid
odd
years,
and
we
we
found-
you
know,
as
you
guys,
probably
well
know
over
the
next
decade
or
so
those
types
of
monolithic,
implementations
where
everything
is
coupled
to
a
central
bus
are
great
and
all
until
we
need
to
change.
So
we
started
looking
at
things
like
microservices
and
starting
and
started
advancing
our
paradigm
a
little
bit
more
right.
A
Where
we
got
independent,
pipe
independent
deployment
pipelines,
we
could
change
a
little
quicker,
a
little
faster
without
necessarily
causing
ourselves
a
ton
of
heartache,
but
over
the
last
few
years
we
all
had
this
ginormous
edict,
whether
it
came
on
high
from
our
ceos
or
it
was
just
something
that
we
thought
sounded
like
a
good
idea.
We
began
to
move
to
the
cloud
that
caused
us
a
whole
new
list
of
concerns.
A
What
in
the
cloud?
Of
course,
we
can't
have
point-to-point
communication
per
se.
We
have
to
expect
our
infrastructure
to
fail.
There
needs
to
be
something
to
accommodate
ephemeral,
compute,
ephemeral,
storage,
so
on
and
so
forth.
We
had
multi
and
hybrid
cloud
designers.
Remember,
we've
still
got
all
this
stuff
right
from
all
from
the
little
scroll
through
history
we
just
took.
We
still
got
all
this
stuff
stuck
in
a
data
center.
A
We
didn't
want
to
go
to
the
cloud
and
not
be
able
to
exploit
those
things,
so
we
had
to
start
coming
up
with
ways
where
we
would
say
hey.
I
want
to
be
hybrid
cloud.
We
also
probably
had
some
edict
from
again
somebody
on
high
saying:
thou
shalt
be
multi-cloud
right.
They
didn't
want
to
get
stuck
in
aws,
they
wanted,
they
had
dreams
of
being
able
to
go
off
to
azure
and
all
of
the
rest
of
the
cloud
providers
we
needed
to
distribute.
We,
our
compute
density
and
efficiency,
are
front
and
center
right.
A
When
this
edict
was
made,
thou
shalt
go
to
the
cloud.
Nobody
thought
we
were
going
to
be
actually
more
expensive
right.
We
as
we
decompose
things
into
micro
services,
we
started
to
notice
a
big
explosion
of
compute
and
all
of
a
sudden,
we
were
getting
aws
bills
that
were
quite
high.
I
remember
about
10
years
ago
having
a
discussion
with
our
cfo
and
he
was
like
hey
man.
A
I
could
have
bought
a
new
data
center
for
the
run
rate
that
we
were
doing
in
a
quarter
right,
painful
stuff,
and
it
became
front
end
this
that
becomes
front
and
center
in
this
move
to
the
cloud.
So
we
also
want
to
distribute
our
architecture
across
availability
zones.
What
we
really
mean
by
that
is,
we
don't
want
to
be
stuck
in
a
single.
We
don't
want
to
be
stuck
in
a
single
location.
That
was
one
of
the
problems
that
we
always
had
in
the
past
right.
Our
dc
goes
down.
A
A
There
goes
most
of
our
use
cases
the
business
stops,
so
we
started
to
take
on
container
platforms
as
a
means
to
abstract
this
move
to
the
cloud
so
that
we
could
deploy
things
to
the
cloud
that
weren't
necessarily
specific
to
a
particular
cloud
provider
right,
if
I
am
only
using
aws
managed
services,
perhaps
I
might
like
to
call
myself
cloud
native,
but
I'm
not
really
cloud
native,
I'm
an
aws
native
right.
If
I
go
take
these
things
off
to
another
cloud,
and
I
go.
A
Do
the
multi-cloud
thing
that
I'm
being
asked
or
even
hybrid
cloud
thing
that
I'm
being
asked
to
do
I've
gotta,
I
don't
quite
have
a
lift
and
shift.
I
have
something
far
bigger
than
that
right.
It's
quite
likely
that
it'll
be
quite
difficult
to
replicate
what
I
was
doing
there
in
another
in
a
another
cloud,
all
right.
So
what
does
that
mean?
A
We
decomposed
that
part
of
the
pun
and
we
found
ourselves
with
microservices
right
and
now
that
we've
gone
to
the
cloud
we
are
attempting
to
take
on
these
cloud
native
architectures
and
some
of
the
things
that
we
want
to
take
on
with
cloud
native
architectures
are
things
like
we
want
to
be
able
to
scale
to
zero.
Remember
that
resource
and
compute
efficiency
thing
right
became
front
and
center.
A
If
I
go
say:
hey,
I'm
going
to
go,
take
the
monolith
and
I'm
going
to
break
it
into
40
parts
right,
it's
very
difficult
to
go
say
to
my
boss
or
or
my
checkbook
hey.
You
know,
that's
I've
added
in
tremendous
amounts
of
overhead.
My
bills
are
quite
high.
It's
not
a
great
look.
We
want
to
optimize
resource
usage
and
we
also
want
to
avoid
random
arbitrary
workload
problems
so,
for
instance,
what
we
really
mean
by
that
is,
if
I'm
dealing
with
ephemeral
compute.
A
A
So
what
does
cloud
native
mean
right
if
this
is
the
architectural
jump
or
leap
we're?
Making
we've
actually
spent
quite
a
bit
of
time,
defining
this,
it's
rather
laborious.
If
you
have,
if
you
need
to
go
to
sleep
tonight,
I
would
read
from
this
earl:
we
get
really
really
really
into
why
we're
suggesting
there
are
these
cloud
native
characteristics,
but
some
of
the
cloud
native
characteristics
that
we
need
to
take
on
to
have
a
cloud-native
architecture.
A
A
Sorry,
slas
can't
do
anything
about
that.
We
need
to
be
observable
and
manageable
right.
It's
easy
enough
to
say:
hey,
I'm
going
to
go
decompose
things,
I'm
going
to
go,
put
them
in
the
cloud,
but
if
I
lose
visibility
and
I
lose
observability
the
same
sorts
of
observability
that
I
had
in
my
my
more
traditional
legacy-
data
centers.
Well,
that's
not
really
a
good
place
to
be.
We
also
need
to
be
location,
agnostic.
Remember
our
computers,
ephemeral
things
are
moving
around.
A
We
can't
necessarily
say:
hey,
I'm
gonna
go
send
this
http
request
at
ten
dot
so
on
and
so
forth.
That's
not
really
a
viable
promise.
We
need
to
be
able
to
invoke
invoke
an
http
request.
It's
completely
agnostic
of
the
physical
place
that
this
thing
lives.
We
want
to
be
api
centric.
One
of
the
reasons
we
want
to
be
api.
Centric
is
one
again
in
the
cloud
native
integration,
github
earl,
that's
there.
A
We
we
we're
in
a
container
platform
we're
in
something
that
is
api,
driven
and
api
and
event
driven
for
our
things
to
come
and
go.
They
exist
in
this
api
driven
api
centric
world
right,
so
we
need
our
things
to
do
something
fairly
similar
and
we
also
because
things
are
coming
and
going
and
because
this
can
be
sometimes
happening
quite
fast.
We
want
well-defined
apis
and
we
need
to
be
able
to
handle
event-driven
premises
such
as
asynchronicification,
so
on
and
so
forth.
A
A
We
want
to
abstract
that
some
way,
the
way
that
we
would
recommend.
Generally
speaking,
abstracting
it
again,
we
get
really
into
this
in
that
url.
The
way
we
would
want
to
abstract
that
is
via
a
container
platform
or
some
notion
of
abstraction,
whether
that
is
mesos
kubernetes
so
on
and
so
forth.
It's
really
a
material
right.
It's
the
abstraction
itself!
That's
important!
I
would
argue
that
kubernetes
seems
to
have
won
the
day
in
this
regard.
However,
let's
not
get
too
hung
up
on
kubernetes
as
much
as
we
get
recognize.
A
We
need
this
abstraction
and
kubernetes
and
containers
alone
aren't
enough.
We
we
need
a
couple
of
things
right.
We
need
things
to
care
and
feed
for
our
deployments.
I
don't
want
to
spend
one
of
the
things
we
I
used
to
spend
quite
a
bit
of
my
time.
Doing
once
upon
a
time
was
configuration
in
fact,
generally
speaking,
we'll
find
developers
who
are
shipping
microservices
right
now
that
don't
rely
on
some
cloud
native
abstractions
and
cloud
native
architectures
spend
quite
a
bit
of
time
figuring
out.
A
So
what
does
that
mean
right
as
we're
on
this
kind
of
stroll
through
history,
and
we
come
to
the
present
where
everything
is
moving
to
the
cloud,
so
you
know
the
net
that
next
logical,
iteration
isn't
just
cloud
native
or
this
cloud
native
term
isn't
meaningless
right.
We
actually
are
after
something
and
one
of
the
things
we
would
we
or
I
the
royal.
A
We
or
the
royal
eye
would
argue
for
is
that
serverless
fits
this
paradigm
quite
well,
in
fact,
serverless
this
serverless
conceptually
promises
us
things
like
scaling
to
zero
resource.
Optimization
and
again,
we
want
to
avoid
arbitrary
workload
prediction.
By
that
I
mean
I
don't
again,
I
don't
want
to
say
hey,
I
feel
like
we
need
three
pods.
I
want
something
that
actually
scales
to
bursts
the
skills,
ideally
algorithmically
right,
based
on
some
common
constructs
cool.
A
So
there's
a
lot
of
obviously
service
implementations
out
there,
as
you
guys,
probably
guessed
from
the
title
of
the
talk,
we're
going
to
talk
about
k
native
the
native,
so
k
native
is
two
kind
of
just
separate
things,
one
of
which
relies
on
the
other.
So
the
the
main
thing
that
key
native
is
is
something
called
pardon
me,
k
native
survey
and
that
provides
us
some
components
that
enable
rapid
deployment
of
serverless
containers
auto
scaling,
including
scaling
pods
down
to
zero.
A
This
is
based
on
sampling,
either
from
a
kpa
or
hba
perspective
and
will
actually
sit
there
and
say:
hey
every
so
often
right,
I'm
going
to
determine
based
on
the
samplings
that
I
have
whether
or
not
we've
passed
some
threshold
and
I
need
to
scale
up
down
so
on
and
so
forth
or
potentially
even
scale
to
zero.
It
has
support
for
multiple
networking
layers
such
as
ambassador
contour
courier.
A
That's
what
openshift
serverless
ships
with,
but
we
don't
want
to
use
that
as
we'll
explain
later
glue
and
seo
for
integration
into
existing
environments.
We
also
have
point
in
time
snapshots
of
deployed
coding
configurations
you
get
re.
In
fact,
I
can
spend
the
rest
of
the
day
talking
about
k
native
serving
we
can
get
really
really
into
what
that
last
thing
means
and
why
it's
important.
A
But
if
we
look
at
the
schematic
on
the
my
right-hand
side,
I
think
your
right-hand
side,
too,
we'll
notice
that,
as
we
take
in
revisions
or
things
that
are
running,
one
of
the
things
we'll
do
is
we'll
actually
spin.
Those
revisions
up
see
if
they're
viable,
the
cont
k
native
will
actually
inspect
them,
go
see.
A
So
what
is
key
native
eventing-
and
this
is
what
this
talk
is
actually
about
all
right.
So
canadian
inventing
is
something
that
enables
developers
to
use
event
driven
architecture
with
serverless
applications.
So,
as
we
take
on
our
cloud-native
architectures,
what
we
one
of
the
things
we
notice
is,
we
need
to
be
event
driven.
We
need
to
be.
We
need
to
be
location,
agnostic,
so
on
and
so
forth,
right
event,
driven
architecture.
A
Specifically
this
the
sorts
of
pub
sub
behavior
that
you
see
on
the
right-hand
side
are
actually
quite
good
at
this,
the
event-driven
architecture,
the
k-native
offending
espouses.
We
have
event,
producers
and
consumers
that
can
come
and
go.
They
are,
of
course,
location
agnostic.
They
will
see
that
coming
up
and
we
essentially
have
a
sort
of
we.
A
Our
dichotomy,
if
you
will
is
neatly,
put
as
source
and
sync
right,
something
is
a
source
we'll
talk
about
the
things
that
can
be
a
source
in
a
second,
and
something
is
the
same.
Some
of
the
things
that
can
be
a
source.
Our
event
sources
are
primarily
event.
Producers.
An
event
producer,
however,
may
be
something
like
kafka
right.
So
what
we'll
do
is
we
create
a
an
event
source
that
actually
interrogates
in
k
native
eventing,
that
it
interrogates
our
source
and
then
emits
http?
A
If
we
look
here
on
the
schematic,
on
the
right
hand,
what
we'll
see
is
source
one
and
source
two?
We
have
a
logical
abstraction
we
refer
to
as
a
channel,
and
then
we
have
a
logical
abstraction
that
we
refer
to
as
a
subscription
the
our
syncs
subscribe
to
channels.
The
channels
are
a
logical
representation
of
our
event
sources.
Some
of
these
event
sources
could
be
any
number
of
things.
A
What
the
cloud
event
specification
is
is
a
a
type
of
message,
payload
that
we
always
have
over
our
over
our
event:
bus
implementation.
That
means
that
we
have
a
canonical
payload.
Normally,
generally
speaking,
I
would
say
stay
away
from
canonical
payloads
bad
sauce
change
is
really
difficult.
However,
what
we'll
notice
with
the
cloud
event
specification?
Is
it's
really
just
something
that
holds
any
number
of
different
other
types?
In
fact,
it
has
a
an
event
registry
so
on
and
so
forth,
and
I
think
it's
a
really
critical
part
of
knowing
what's
happening.
A
What
can
happen
and
what
can
flow
across
our
hybrid
and
multi-cloud
implementations
cool.
So
there's
a
big
word
at
the
beginning
of
the
title
of
this
talk
called
governing
and
it
implies
governance
right.
So,
let's
and
generally
speaking
in
software,
this
is
a
dirty
word
right.
We
all
hate
the
governance,
guys
to
come
down
and
say:
thou
shalt
not
do
everything
you're
doing
because
there's
some
magical
governance
theory
that
we've
offended
so
mit
took
this
on,
and
I
think
these
are
actually.
A
This
is
actually
a
pretty
good
definition
of
what
governance
is.
We
want
to
centralize
information
about
our
digital
initiative,
so
instead
of
having
n
bespoke
systems
all
over
the
place
right,
I
actually
want
to
give
myself
some
way
to
cobble
these
things
all
together
in
a
centralized
fashion.
I
want
to
move
from
from
centralized
to
decentralized
governance
of
digital
initiatives,
meaning
I
can't
necessarily
run
everything
in
the
same
place.
I
have
to
allow
people
to
be
able
to
go
out
and
do
the
things
that
they
need
to
do.
A
These
could
be
any
different
run
times
different
languages
so
on
and
so
forth.
However,
I
still
want
that
centralized
information
piece
and
I
still
want
some
means
of
exercising
control
in
a
centralized
way,
while
handing
over
power
to
my
developers
and
let
them
do
their
thing,
I
want
to
decentralize
ideation,
but
centralize
idea,
evaluation
and
prioritization.
A
I
want
to
make
sure
my
kpis
are
meaningful.
I
want
to
make
sure
my
I
want
to
avoid
kind
of
siloed
solutions,
or
these
bespoke
things
that
we
see
all
over
everybody's
enterprise
right
now,
where
we
have
7000
things
providing
off
oz.
We
have
just
about
every
sort
of
way
to
go
about
this.
We
need
some
notions
of
technical
consistency
across
how
we
do
these
things
most
noticeably,
notably
in
a
distributed
computing
context.
A
I
have
service
accounts,
those
things
that
were
run
my
ultimate
or
pods
or
runtimes.
We
we
certainly
don't
hand
out
anything
service
accounts
generally
speaking
willy-nilly
right.
We
also
have
some
notion
of
our
back
there.
There
are.
We
have
cluster
admin,
we
have
developer
roles
so
on
and
so
forth.
We
have
oauth
proxies
right,
so
we
go
likely
in
our
kubernetes
destroyer,
depending
on
which
one
you're
using
we
may
go
out
to
an
external
oauth
provider
right.
A
We
may
construct
our
own
oauth
provider
inside
of
the
cluster.
This
gives
us
a
common
way
of
authenticating
our
runtimes,
ensuring
that
they
can
actually
do
the
things
that
they
want
to
do.
In
kubernetes
we
have
some
ingress
governance
right:
we've
gone
beyond
the
node
port.
At
this
point,
we're
not
just
saying
hey,
go
find
a
port
on
one
of
your
nodes
and
hook
up
to
it.
We
have
meaningful
ways
of
ingress.
A
We
have
mtls
capabilities,
tls
capabilities
so
on
and
so
forth.
We
have
centralized
monitoring
and
logging
capabilities
and
most
distributions
right
remember
some
of
the
things
we
were
just
after
that
white
paper
suggested.
We
should
be
after
it's
kind
of
mostly
taken
care
of
there
and
we
have
an
event
driven
api
control,
plane
right
all
over
http
and,
generally
speaking,
we
have
some
technical
consistency
here
between
our
our
back
approaches.
A
How
we
do
things
over
the
wire
who
gets
to
do
what,
how
they
authenticate
and
authorize
with
each
other,
but
this
provides
a
pretty
basic
level
of
governance
and
rudimentary
notions
of
auth
odds
from
a
runtime
perspective
right
so
for
ins.
A
classic
example
of
this
is
well
yeah.
My
service
account
presents
a
shot
to
the
next
guy,
and
the
next
guy
may
have
be
hooked
up
to
an
external
oauth
provider,
and
I
may
have
been
pretty
good
and
got
my
service
accounts
in
there.
A
So
yeah
I'm
authorized
and
we
had
something
do
that
in
a
meaningful
way,
but
the
thing
that
I'm
actually
doing
in
my
pod
or
my
runtime
is
hooking
up
to
nats
or
kafka,
or
I'm
hooking
up
to
a
database
right
that
level
of
authorization
and
authentication
is
not
addressed
by
kubernetes
alone.
We
need
something
more
than
that.
We
have
communications,
protocol,
schemas
and
standards.
There's
nothing
per
se.
Saying
the
things
that
are
traveling
over
the
wire
will
necessarily
do
anything
but
adhere
to
the
kubernetes
api
if
they
want
to
do
kubernetes
stuff.
A
But
as
I
go
speak
from
one
as
I
go,
let's
say
from
one
system
to
the
next
there's
nothing
saying
that
I
will
be
carrying
a
certain
particular
payload.
There's
nothing
saying
that
I
will
adhere
to
any
particular
standards
other
than
maybe
some
basic
tls
type
stuff,
so
on
and
so
forth.
I
generally
speaking,
have
bespoke
runtime
visibility
right.
A
I
see
this
non-stop
almost
everywhere
I
go
and
talk
to
people
I'll
notice
that
they've
got
some
other
means
of
monitoring
just
about
every
system
in
that
they
have
right
their
services.
Generally
speaking,
may
one
one
group
may
be
using
prime
prometheus
one
group,
maybe
using
app
dynamics
so
on
and
so
forth.
A
The
what
we'll
notice
in
many
kubernetes
clusters
is
that
this
notion
of
runtime
visibility
is
all
over
the
shop
and
then
we
also
have
bespoke
carrying
and
feeding
we'll
notice
that
some
people
are
just
doing
a
plain
old
kubernetes
deployment.
Some
people
are
using
an
operator,
and
maybe
that
has
some
level
of
maturity
in
how
it
cares
and
fees
for
things
right,
but
it
lacks
total
consistency.
A
There's
no
one
way
that
we
go
about
this,
so
we
know
that
kubernetes
in
and
of
itself,
isn't
enough
to
go
after
those
governance
characteristics
that
our
white
people
are
stated
well.
Another
question:
you
know
I
probably
didn't
prime
the
pump
enough
for
you
guys
to
answer
this
question,
but
another
question
that
we
have
we
probably
have
at
this
point
is
well
is
k
native
enough
well,
k
native
kind
of
is
right,
like
we
probably
have
a
good
deal
of
governance,
just
from
k
native,
we
have
service
routing.
We
have
revision
visibility
right.
A
We
have
load
balancing
blue
green,
a
b
out
of
the
box.
This
is
all
happening
in
a
centralized
way
in
a
technically
consistent
way.
Many
of
the
features
that
we'd
even
get
out
of
issue
we're
sitting
there
in
k
native.
We
have
auto
scaling
via
common
means
in
hba
and
a
kpa
scaler.
I
can
definitely
allow
people
to
instrument
hpa
or
kpa
in
ways
that
they
want
right.
But
you
know,
generally
speaking,
I've
at
least
said:
hey
here
are
two
constructs
that
we'll
allow
into
our
organization.
A
I
have
central
ingress
into
services.
I
have
we'll
get
into
this
in
a
second,
but
I
have
an
activator
and
auto
scaler.
These
things
are
actually
going
to
talk
to
my
services,
and
that
is
how
traffic
is
getting
directed
there
at
least
some
of
the
time
right
so,
and
I
also
have
the
cloud
event
specification
we'll
get
into
more
on
that
in
a
second,
like
I
promised
you
guys,
I
was
gonna
bang
that
drum,
but
we
don't.
We
just
don't
have
enough
to
complete
the
governance
picture
here
either.
A
Something
else
is
needed
to
guarantee
mtls
between
components.
It
may
happen
to
be
the
case
that
your
canadian
operator
distribution
is
using,
has
some
means
of
wiring
up
mtls,
but
you've
probably
got
something
else
for
the
next
thing,
you're
doing
and
something
else
for
the
next
thing,
you're
doing
so
on
and
so
forth.
We
don't
really
have
a
consistent
means
of
doing
this.
We
certainly
don't
have
a
centralized
way
of
doing
this.
This
just
becomes
another
bolted
on
appendix
frankenstein
style
appendage.
A
We,
the
service
notification
between
our
components,
does
not
apply
off
oz,
so
we're
kind
of
left
up
to
ourselves
to
handle
whether
or
not
something
can
or
should
call
us.
So
we
need
something
else
for
visibility
into
the
performance
of
our
components.
Right.
We
could
hook
up
something
like
prometheus,
so
on
and
so
forth,
but
we
just
simply
in
and
of
itself
don't
have
enough.
A
There,
oh
yeah
and
canadian
in
and
of
itself
does
not
provide
a
set
of
rules
for
who
gets
to
do
what
per
se
right
k
native
in
and
of
itself
will
say:
hey
you
get
to
hook
up
to
the
event
bus.
You
can
send
as
a
result,
things
can
go
over
here,
but
there's
nothing
to
say,
hey.
I
laid
down
a
particular
channel
implementation
and
I'm
per
I'm
authorized
to
do
that
out
of
the
box.
A
A
What
cloud
with
a
cloud
event
specification
is,
I
think
I
described
this
a
little
bit
previously,
but
we
described
data
event
data
in
common
formats
to
provide
interoperability
across
services,
platforms
and
systems.
We
know
what's
going
to
come
in
our
cloud
event
specification,
even
though
we
may
have
avro,
we
may
have
protobuf
so
on
and
so
forth.
We
may
just
have
jason
where
heck.
A
In
some
cases
we
may
just
have
a
an
encoded
string.
We
we
have
something
around
that
a
payload,
an
envelo,
a
not
to
use
a
soap
term,
but
an
envelope
that
describes
the
payload.
That's
coming,
that's
being
shipped
in
between
these
services.
This
is
the
canonical
payload
of
k-node
k-native
eventing.
Everything
is
a
cloud
event.
We
could
have
as
we'll
notice
previous
we
could.
This
could
be
amqp.
This
could
be
avro
jason
kafka,
mktt,
nats,
websockets
protobuf.
A
The
picture
keeps
emerging.
What
this
allows
us
to
do
because
of
the
event
registry
of
k-native,
offending
is
say:
hey
we
have
a
particular
payload
types
that
are
associated
to
particular
channels.
For
instance,
if
I
have
a
nats
channel
right,
I'm
going
to
have
a
cloud
event,
specific
cloud
event,
spec
type
type
of
gnats
right,
and
what
this
allows
us
to
do
is
to
move
away
from
these
bespoke
incongruous
means
of
communication
over
the
wire
right
and
to
say
hey
at
minimum.
A
I
have
governance
and
I
know
what
is
what
is
going
over
the
wire
and
I
can
say:
hey
or
I
shouldn't
be
able
to
say
hey.
Why
are
you
guys
doing
oh
like?
Why
are
you
guys
doing
this
really
strange
thing
over
http
as
it's
not
possible
because
of
rk
native
eventing
constructs
specifically
the
event
registry.
A
A
For
instance,
there
is
no
concept
of
destination
rules
so
on
and
so
forth,
yeah
we
could
probably
ship
an
envoy
filter
there,
but
there's
a
whole
lot
of
constructs
and
primitives
from
issio
that
we
just
simply
don't
have
we're
not
wiring
up
mtls
out
of
the
box.
We
remember
something
else
needs
to
handle
this
issue
all
depending
on
how
we
go
about
things
we'll
handle
this
out
of
the
box.
A
For
us,
canadian
eventing
also
leaves
some
governance
pieces
wanting,
while
many
of
the
canadian
vetting
sources
provide
means
of
authentication
and
authorization.
That's
bespoke
by
component
by
that,
what
I
mean
is
hey.
Are
you
sure
I
can
go
talk
to
my
kafka
brokers?
If
I
lay
down
a
kafka
channel-
and
I
can
figure
myself
with
some
sort
of
auth
right
and
all
depending
I
may,
if
I've
wired
up
kafka
correctly
to
handle
the
thing-
that's
calling
it
right.
A
A
What
we'll
notice
is
we
have
an
explosion
of
these
bespoke
activities
over
our
enterprise
without
using
something
like
seo
all
right,
and
I
think
I've
covered
oh
yeah-
and
you
know
some
of
the
things
that
we
have
in
seo
and
it's
an
advanced
concept
that
we
won't
show
here,
but
we
will
make
a
recommendation
later.
There's
no
advanced
authorization
such
as
opa
right.
We
can.
A
A
Well,
again,
that's
going
to
be
the
same
shot
every
time,
because
it's
coming
from
the
same
k
native
component.
I
can't
really
do
much
with
that
right.
I
certainly
can't
give
myself
the
acls
that
I
would
like
to
give
myself
in
something
like
kafka
right.
I
again
a
topic
I
could
go
on
and
on
and
on
about.
A
A
A
If
we
want
to
expose
ourselves
to
the
outside
world,
we're
probably
creating
a
virtual
service
initiative,
the
things
that
are
really
really
really
important
in
k-natives-
and
this
is
a
look
at
k-native
serving
pretty
much
exclusively,
but
it
you'll
see
quickly
why
this
applies
to
canadian
vetting.
We
have
an
activator
so
when
a
an
http
call
comes
into
my
ingress
gateway,
for
instance,
here
via
istio,
one
of
the
first
things
it's
going
to
do.
Is
it's
going
to
hit
the
activator
assuming
I'm
scaled
to
zero?
A
That
means
it's
going
to
start
bringing
instances
up
the
our
controller
and
dispatcher
will
actually
continue
talking
to
to
our
auto
scaler
as
well,
so
the
activator
is
going
to
bring
stuff
up.
It
may
say:
hey
by
the
buy
auto
scaler
I'm
at
zero,
I'm
at
one
so
on
and
so
forth,
we'll
notice
that
we
also
have
here
we
represent
a
kpa.
What
that
would
mean
is
I've
got
some
metrics
like
concurrency
or
something
like
that?
That
actually
does
this
scaling.
A
For
me,
we
we're
we're
constantly
referencing
this
deployment,
while
our
auto
scaler
is
running
and,
as
you
can
notice
here,
we're
gonna
push
metrics
to
the
auto
scaler
and
the
autoscaler
will
actually
bring
these
guys
up
and
down
all
based
on
those
things
right.
Inevitably,
what
will
continue
happening?
Is
these
http
requests
as
the
activator
and
auto
scaler
are
kind
of
doing
their
thing?
Hey.
Do
you
need
to
come
up
hey?
A
Maybe
something
as
simple
as
hello:
world,
hey,
I'm
I'm
a
rest
service
could
be
something
a
little
bit
more
complex
that
we'll
show
later
so
the
k
native
serving
components
we
have
our
activator
again,
that's
what's
responsible
for
receiving
and
buffering
requests
for
inactive
revisions,
we've
got
it
reports
to
the
auto
scaler.
As
we
mentioned,
we
have
the
auto
scaler
that
is
going
to
take
in
our
metrics
and
adjust
the
number
of
pods
required
to
handle
the
load
of
traffic
right.
We
could
go
up
and
down.
A
A
The
surface
controller
is
going
to
be
the
thing
that
says:
okay,
cool.
I
know
what
to
do
with
that
and
I'm
going
to
go
ahead
and
k
native
serving
I'm
going
to
go
ahead
and
create
some
revisions,
I'm
going
to
test
them
out,
I'm
going
to
mark
them
viable
or
not,
viable,
so
on
and
so
forth.
By
that
I
mean
in
k-native,
serving
if
I
roll
change
out
to
k-native
surveying
and
that
exchange
does
not
work.
A
He
native
serving
isn't
going
to
stop
answering
it's
just
going
to
maintain
the
current
revision
right,
which
is
kind
of
gives
us
some
a
notion
of
a
canary
release
out
of
the
box.
We
also
have
our.
We
also
have
a
dynamic
admissions
webhook.
What
this
is
going
to
do
is
it
takes
in
that
that
initial
cr
right
and
says
hey,
you
know,
I,
you
gave
me
a
kubernetes
service
thing
and
that's
cool
like
you're
able
to
I'll
admit
you,
but
it's
I'm
sorry.
A
I
just
go
back.
There's
two
flavors
there's
two
parts
to
our
web
hook.
We
have
an
admissions
configuration
and
we
also
have
a
validation
configuration.
The
admissions
configuration
will
say:
hey,
okay,
cool,
like
I
got
the
cr
from
the
cube
api
yeah.
You
know
you're
allowed
to
do
this.
Your
particular
jot
from
your
particular
service
account.
That's
cool.
A
The
validation.
Configuration
will
then
say:
hey
wait!
A
second
yeah,
you
kind
of
screwed
up
your
configuration
of
your
k-native
service,
I'm
actually
going
to
reject
you.
You
want
the
cr
will
not
be
successful
in
the
cube.
Api
server
will
not
get
a
admissions
response
that
is
meaningful
and
tells
it
hey.
I
need
to
launch
this
pod
we're
going
to
start
going
a
little
faster
because
we're
running
out
of
time-
and
I
want
to
get
to
the
demo
before
such
at
least
part
of
the
demo
before
session
two.
A
This
will
help,
though
so
key
native,
serving
integrates
with
issio
out
of
the
box.
What
we'll
see
here
is
right
under
our
right
under
the
spec
part
of
our
yaml,
we'll
notice
that
we
have
issio
enabled
right.
However,
if
we
just
remembered
what
we
were
looking
at
a
couple
of
slides
ago,
there's
a
few
things
that
have
to
happen
be
after
ingress
right,
I
have
to
go
to
the
activator.
A
I've
got
the
auto
scaler
likely
also
involved
right,
so
we're
going
to
have
to
for
those
who
participate
in
in
a
service
mesh.
We
actually
need
to
inject
a
proxy
there
as
well.
I'm
I,
like,
I
said,
using
maestra.
Generally
speaking,
this
is
a
good
approach,
but
we
want
to
opt
into
sidecar
injection.
We
don't
just
want
to
label
a
namespace
and
have
sidecars
injected
all
over
the
place.
There's
a
reason
for
that.
There's
a
bunch
of
other
things
in
k,
native
serving
that
don't
actually
need
to
say
car
injected.
A
Logically
speaking,
anyways
is
going
to
be
something
might
just
be
an
in-memory
broker,
or
it
could
be
something
like
kafka,
nats,
so
on
and
so
forth.
The
trigger
is
what
is
actually
making
our
subscription
to
this
particular
this
particular
broker.
The
broker
will
define
what
the
backing
with
the
backing
channels
are,
that
we'll
be
looking
at
you'll,
see
a
better
example
of
that
in
a
second
on
the
next
slide
right
and
we
have
a
filter
here.
A
We
may
not
want
all
the
events
that
are
being
emitted
out
of
this
broker
and
then
that's
where
our
last
few
slides
come
in
once
we
say
hey,
you
know
I
I've
got
a
subscription
here
going
to
your
broker.
I'm
filtering,
maybe
I'm
not.
Maybe
I
just
want
you
to
give
me
all
events
either
way
that
is
actually
going
to
call
our
k-native
service
right,
and
that
is
what
we've
just
put
of
that
particular
k-native
service
should
be
injected
with
a
side
car
remember
it's
also.
A
We've
also
got
a
few
other
things,
that's
interacting
with
it
that
are
also
injected
with
a
sidecar
and
are
performing
mtls
and
potentially
authorization
policies.
All
the
goodness
we've
got
out
of
all
the
goodness
we
get
out
of
istio.
So
in
our
most
simple
sense,
what
that
really
implies
is
this
kind
of
source
of
service,
simple
delivery?
What
we're
going
to
see
in
our
demo
is
something
a
little
bit
more.
A
It's
we're
not
going
to
get
too
complex,
sorry,
but
it's
something
a
little
bit
more
complex
so
that
that
source
is
that
broker
is
actually
be.
What
it
really
is
is
a
event
source
where
it's
I
shouldn't
say
that
the
broker
is
defining.
What
this
channel
implementation
is
an
event
source
is
the
thing
that
it's
emitting
things
into
the
broker
or
into
our
channels.
What
we'll
notice
here
is.
We
have
a
subscription
that
we
talked
about
previously,
logically
and
physically.
A
This
is
a
trigger
resource,
but
we
also
have
the
logical
construct
of
a
subscription.
Unfortunately,
you
can't
wire
one
up
without
a
trigger,
but
the
two
things
aren't
necessarily
the
same
thing.
What
that
will
do
as
a
result
as
we're
as
our
offense
source
is
emitting
these
things.
Our
broker
has
wired
up
our
particular
channel
for
in
a
namespace
to
handle
things
in
a
certain
way.
For
instance,
this
could
be
again
an
in-memory
channel.
It
could
be
a
gnats
channel,
it
could
be
a
kafka
channel.
A
The
subscription
is
going
to
say,
hey
you're,
my
sync
service,
and
I
actually
want
to
I'm
going
to
subs
I'm
going
to
subscribe
to
the
thing,
that's
publishing
events,
and
inevitably
I
I
have
my
source
sync
dichotomy
or
my
pub
sub
dichotomy
as
well.
Again,
it's
really
really
important
to
note
that
this
guy
here
is
in
our
mesh
and
needs
to
be
injected.
A
That
means
that
some
of
these
other
things
are
probably
need
to
be
in
our
mesh
and
probably
need
to
be
injected,
as
they
can't
talk
to
each
other
or
complete
the
handshake
without
being
injected.
That's
a
pretty
important
thing,
because
we
don't
necessarily
want
anybody
being
able
to
admit
anything
to
any
particular
service.
We
also
don't
want
it
to
be.
If
you
guys
will
remember
our
governance
talk,
we
really
really
really
don't
want
to
have
10
000
bespoke
ways
of
doing
this.
A
It
would
be
great
if
we
had
one
technically
consistent
approach,
cool,
and
this
is
again.
Another
kind
of
this
is
a
physical
view
of
what's
happening
in
canada
vetting.
Hopefully,
this
is
big
enough
for
you
guys
to
see,
but
again
we
have
our
event
source.
We
have
something
in
here's
we
have
k
native
serving,
and
here
we
have
k
native
eventing
in
canada
vetting
I'm
going
to
wire
up
a
dispatcher.
A
That's
going
to
talk
to
my
that's
going
to
talk
to
my
event
source
the
that's
going
to
create
my
logical
broker
construct
that
exists
in
a
particular
application,
namespace
right
when
we
lay
in
a
channel
into
our
application
name
space,
that's
actually
going
to
call
our
that
dynamic
admissions
web
hook
that
I
talked
about.
That
is
then
going
to
say:
hey,
yay
or
nay,
you're
good
to
go
it'll
let
this
guy
in
and
our
controller
is
going
to
start
doing
some
stuff.
A
We
our
subscription
is
based
on
the
things
that
the
controllers
decided
to
do
and
again
our
dispatcher
is
going
to
do
a
little
bit
more
or
then
just
talk
to
our
event
source.
It's
actually
going
to
come
over
here
into
our
k
native,
serving
ingress,
the
ingress
controller.
Then
at
that
point
decides
to
activate
or
potentially
this
is
drawn
a
little
bit
incorrectly.
It
should
be
like
this
is
going
to
activate
or
potentially
just
send
on
the
traffic
to
the
service
right
and
auto.
A
A
A
A
We
need
to
have.
We
need
to
inject
our
vending
controller,
we
need
to
inject
our
vetting
web
hook
so
on
and
so
forth.
We
have
a
couple
of
different
flavors
here
of
controller
and
dispatcher,
specifically
the
in
this
particular
cr,
our
in-memory
con
broker
is
being
injected,
so
this
all
comes.
I
think,
I'm
going
to
have
enough
time
for
this.
A
This
all
comes
down
to
our
our
demo,
and
so
our
what
our
demo
is
attempting
to
do
is
take
really
fully
take
on
those
cloud
native
constructs
that
we
saw
previously.
This
is
a
I'm
sure.
Everybody
here
is
familiar
with
aleister
cockburn.
If
you're,
not
google,
it
immediately
and
read
everything
he's
ever
written,
but
this
is
something
that
we
refer
to
as
hexagonal
architecture
and
that's
why
it's
depicted
in
this
fashion.
What
hexagonal
architecture
is
also
called.
A
Is
ports
and
adapters,
meaning
that
the
way
we
would
like
to
construct
our
software
architectures
according
to
aleister
cockburn,
is
that
we
want
to
have
adapters
out
here
on
on
the
outside
and
ports
into
our
actual
of
the
things
that
actually
happen
in
our
business.
So
here
we'll
notice,
we
have
event
stream
processors,
we
have
an
event
sync,
and
inevitably
we
have
an
event
store
in
the
middle
there.
That
is
where
our
business
is
happening
right.
A
A
A
A
Cool
here
is
my
seo
system.
Namespace,
you'll
notice-
I
have
a
few
things
wired
up
we're
using
is
we're
using
a
seo
2x
with
maestra,
so
you'll
notice
seod
there.
In
my
particular
case,
I
call
the
k
native
governance
we
have
in.
There
are
a
couple
of
differences
with
maestra
versus
other
versus
other
issue
distributions.
A
And
you'll
notice
this
is
a
meister
specific,
but
you
could
easily
get
there
with
issio
cuddle.
What
this
does
is
a
few
different
things.
It
wires
up.
The
things
that
we
see
here
are
ingress
gateway,
jager,
kiali,
so
on
and
so
forth.
Right
prometheus
as
well
grafana
as
well
as
we
have
a
few
other
things
going
on
in
the
background.
Meister
will
also
go
out
and
lay
network
policies
down
for
us.
A
A
Service
mesh
member
roles
and
again
this
is
a
meister
specific
concept,
but
we
don't
need
maestro
to
get
there
right.
We
could
easily
get
there
with
istio
cuddle
and
network
policies
so
on
and
so
forth.
But
what
essentially
this
does?
Is
our
service
match?
Member
roles
will
be
things
that
we've
said:
hey.
You
are
a
part
of
our
mesh
and
in
our
case
we
have
a
few
different
things.
A
A
Canadian
survey
well,
as
we
talked
about
previously,
we
have
an
activator.
We
have
an
auto
scaler,
there's
a
few
other
interesting
things
that
are
going
on
here,
we'll
notice
that
we
also
have
an
istio
webhook
right
because
remember
we
didn't
just
take
full-on
k-native
serving
out
of
the
box
with
courier,
we
said:
hey,
we
want
you
to
use
something
else
for
ingress.
We
want
you
to
use
issio.
What
we'll
notice
here
is.
A
We
have
an
istio
web
hook,
that's
going
to
also
be
providing
these
sorts
of
admissions
and
validation
control
over
the
things
that
are
allowed
to
come
in
right.
We've
got
some
networking,
that's
being
done
as
well
as
our
standard
k
native
web
hook
as
well.
Noticeably
our
standard
k
native
web
hook
is
not
injected.
That
doesn't
mean
everything
can
get
to
it.
A
This
is
one
of
the
drums
we
bang
in
the
this
is
one
of
the
drums
we
bang
in
our
actual
instructions,
but
what
sorry,
what
you
may
need
to
do,
if
you're
using
another
seo
operator,
so
you
may
need
to
go,
lay
down
some
network
policies.
What
we'll
notice
here
is.
We
have
a
bunch
of
different
network
policies.
These
are
all
laid
out
by
our
particular
seo
operator,
and
what
this
is
going
to
say
is
hey.
Some
things
can
come
here.
A
Some
things
can't,
generally
speaking,
that
service
mesh
member
roles
object.
We
just
looked
at
that's
going
to
define
the
things
that
can
talk
to
each
other.
We've
actually
blocked
all
traffic
from
outside
of
this
namespace,
unless
you're
labeled
in
a
particular
way
right
we'll
depend
on
the
cube.
Our
kubernetes
are
back
to
enforce
some
notion
of
governance.
There,
not
everybody,
hopefully
in
your
org-
can
label
a
namespace
if
they
can
you've
got
problems,
however,
all
right
so
we're
up
on.
That's
we're
up.
A
A
Cool
and
real,
quick
in
our
last
minute,
we'll
notice
that
we
have
a
bunch
of
stuff
in
canada,
vetting
that's
wired
up
with
issue
as
well
inside
it
right.
If
we'll
remember
the
schematics,
we
were
looking
at
when
we
get
an
invocation
via
an
event
source.
It's
going
to
hit
these
guys
first
right
because
we've
injected
these
guys
we'll
be
able
to
and
because
we're
both
members
of
the
service
mesh
we'll
be
actually
able
to
call
each
other.
So
what
we'll
see
inevitably.
A
Cool
that
took
way
too
long,
so
those
two
integration
things
that
I
just
spoke
about.
As
I
said,
I'm
using
camel
k,
it's
just
making
my
life
a
little
bit
easier,
but
we
have
these
2k
native
services.
These
are
going
to
be
sitting
in
our
service
mesh
con
event
in
our
service
mesh
con
namespace.
What
we'll
notice
right
now
is
which
we
just
saw
up
here.
One
of
them
is
scale
to
zero.
The
other
one
is
scaled
to
one.
A
What
we'll
do
I'm
over
by
a
minute,
so
I
got,
I
probably
should
stop,
but
what
we'll
do
when
we
come
back
is
we'll
actually
get
rid
of
that
event.
Sync
integration,
we'll
start
it
up.
That'll
start
spraying
messages
to
our
channels
and
that
then,
we'll
notice
that
event,
bus
transformation,
integration
scale
from
zero
up
up
right
all,
depending
on
how
much
traffic
we're
bringing
in
so
we'll
all
and
then
we'll
go
and
look
in
kiali,
a
notice
or
we'll
actually
scratch
out
we'll
go
into
jaeger
and
notice.