►
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.
Thinking Cloud Native, CloudEvents Future - Scott Nichols, Chainguard
Being a part of the CNCF brings huge opportunities for us as a community to define and embrace common ways of communicating between the projects with the ultimate goal of integrators selecting and connecting projects and products. We will pitch what this world looks like and how it will turn our collection of projects into an ecosystem of solutions. We then will provide a status of the CloudEvents project with the focus on where we are headed in the working group, including specifications helping with the interoperable discovery of event sinks and sources and the metadata description of events and their contents. We will also touch on the integration of CloudEvents with Open Telemetry.
A
A
A
And
so
we
started
looking
around
and
I'm
going
to
show
you
a
couple
examples
of
excellent
projects,
and
I
just
noticed
a
little
something
that
was
recurring
and
that's
that
they
almost
every
project
has
either
the
ability
to
consume
an
event
or
or
the
ability
to
produce
an
event.
So
prometheus
has
this
alert
manager
and
I'm
not
totally
sure
what's
in
that
box.
A
But
you
know
it
brings
questions
like
do
they
have
to
manage
that.
Can
I
bring
my
own?
Could
I
bring
a
different
version?
How
tightly
are
those
events
who
defines
the
schema
if
we
move
on
to
one
one
final,
one
falco
another
great
project,
part
of
the
cncf
the
and
I
happen
to
know
that
the
the
core
of
falco
is
written
in
c
plus,
plus
and
eppf,
and
they
have
various
outputs
that
they
support
in
that
structure.
A
But
they
wanted
to
support
more
things
like
slack
and
s3
and
in
fact,
cloud
events,
and
so
they
extended
it.
With
this
thing
called
falco
sidekick,
it
streams
data
from
the
grpc
server,
and
then
it
does
some
munching
in
a
more
friendly
language
and
this
one's
written
in
go
hence
the
gopher
and
but
they
have
the
same,
integrations
right,
slack
and
s3
and
email,
and
who
knows
what
so
eventing
is
everywhere
and
many
projects
either
produce
or
consume
events.
A
So
I'm
going
to
coin
the
term,
and
I
don't
know
if
this
is
a
real
term
or
not,
but
it
felt
good
when
I
wrote
this
slide,
but
I'm
calling
them
island
architectures
and
I'm
going
to
define
it
as
a
piece
of
technology.
That
brings
a
very
strong
opinion
about
all
of
the
underlying
technologies
that
it
wants
to
use
and
if
we're
doing
that,
a
la
carte
pic
projects
off
the
cncf
board
and
using
them
to
orchestrate
and
architect
our
applications.
A
A
A
A
The
real
problem
is
that
we
have
these
event,
producers
and
because
the
event
producers
come
from
different
selections
off
of
that
cncf
map.
Their
schemas
of
their
events
are
in
different
shapes,
potentially
even
in
different
formats
like
this
one
produces
xml
events
and
this
one
produces
json
events,
and
so
there's
no
there's
no
way
for
me
to
generically.
A
Ask
a
component
like
this
event
mediator
that
ingresses
the
event
and
then
I
write
some
custom
code
that
inspects
it,
maybe
decodes
it
halfway
and
then
decides
based
on
my
custom
logic,
to
send
it
to
some
individual
message,
bus
or
channel
or
queue
so
that
I
have
an
event
consumer.
That's
wanting
to
process
that
event
and
it
becomes
a
problem,
if
I,
if
I
add
a
new
producer
and
it
or
the
producer,
has
been
upgraded
and
it
adds
a
new
event
and
I
haven't
updated
the
event
mediator.
A
But
I
did
update
the
consumer
and
I
have
to
do
this
very
complicated
coordination
thing.
So
you
know
we
have
these
event
producers.
You
probably
have
many
of
them
in
your
your
systems
and
they're
glued
together.
With
this,
I'm
calling
it
the
event
mediator,
but
you
it's
it's
this
little
custom
piece
of
logic
that
is
trying
to
inspect
it,
and
it's
maybe
different
for
every
kind
of
producer
and
it's
this
custom
necessary
evil
to
be
able
to
route
things
the
right
way.
A
So
if
you,
if
you
can't
rely
on
some
sort
of
common
schema
against
all
of
your
events,
you
have
to
write
these
these
routing
configs
and
they
become
part
of
your
application
and
platform
and
they
have
to
be
developed
and
maintained
in
and
so
what?
If
we
could
define
the
event
but
define
it
independent
of
the
protocol.
A
If
we
did
that,
we
would
be
free
to
be
able
to
choose
the
particular
technology
we're
using
to
route
the
event
and
that
could
be
the
the
protocol.
That's
the
persistence
layer.
You
know
we
want
to
save
the
event,
so
we
we
make
sure
it
gets
delivered
or
it
could
be
the
language
that
we
are
processing
the
event
with.
A
But
often
what
happens
is
when
you
go
to
start
a
new
project
or
you
go
to
add
a
new
piece.
You
have
to
make
a
hard
choice
that
kind
of
sticks
with
the
project
forever.
Unless
you
do
a
big,
refactor
and
you're,
you
have
to
decide
which
of
those
persistent
technologies
we're
going
to
use
which
language
we're
going
to
use.
A
So
the
what
cloud
events
is
trying
to
do
is
accept
that
you
have
the
event
payload
the
occurrence.
The
the
weird
shaped
object
that
you're
trying
to
send
around
and
cloud
events
defines
you
an
envelope
to
put
that
in
right.
Just
like
the
mail
has
a
spot
for
the
address
and
where
it
goes
and
the
postal
you
you
adhere
to
that,
and
then
you
shove
your
letter
in
and
to
deliver
that
event.
A
The
post
person
doesn't
open
the
envelope
and
read
the
letter
and
say:
oh
this
one
is
for
grandma,
I'm
going
to
put
it
in
grandma's
box.
Now
they
just
look
at
the
outside
of
the
envelope
and
they
don't
have
to
look
right.
So
if
we
can
wrap
that
event,
we
can
treat
everything
as
this.
This
cloud
event
object
and
a
lot
of
the
the
event
mediator.
Type
objects
become
generic
and
and
off
the
shelf
replaceable.
A
So
I'm
going
to
take
a
pause,
and
so
that's
that's
that's
framing
the
technical
point
of
where
we
are
today
with
cloud
events.
We've
defined
this
envelope.
We
can,
we
can
find
other
cloud
event
compatible
components
and
just
kind
of
drop
them
in,
but
there's
there's
more
that
we
could
do,
and
so
I
have
a
call
to
action
to
everyone.
A
If
the
external
format
and
the
internal
format
are
the
same,
it's
this
cloud
event
thing
and
if
you're,
integrating
with
things,
ask
that
project
to
produce
cloud
events,
because
if
you're
not
asking
for
the
cloud
event,
support
no
one's
going
to
listen
and
we're
not
going
to
get
a
nice
world
where
we
can
do
fancy
things
like.
Maybe
the
prometheus
and
the
falcos
and
my
projects
all
produce
events,
but
they
ingress
it
into
some
of
these
off-the-shelf
common
components.
A
A
I
think
we
have
to
make
it,
but
it
starts
by
agreeing
that
the
cloud
events
format
is
the
the
right
direction
and
something
that's
worthwhile
so
that
we
can
have
nice
things
and
we
can
delegate
some
of
this
responsibility
where
you
know
a
new
cncf
project
comes
up
and
says
we
are
the
slack
and
email
and
alert
manager
and
etc.
Kind
of
we
know
how
to
manage
and
rotate
credentials
and
keep
that
stuff.
A
Safe
and
push
events,
and
all
you
need
to
do
is
tell
us
the
kinds
of
events
that
you
would
like
to
signal
on,
so
that
we
can
produce
those
results,
and
then
that
frees
the
the
prometheuses
and
the
falcos
and
the
your
project
and
all
like,
maybe
eighty
percent
of
the
cncf
landscape.
They
don't
have
to
do
those
integrations
in
their
project
and
they
don't
have
to
do
those
maintenances
because
they
can
decouple
themselves
from
those
integrations.
A
So
that's
that's!
My
wild
pitch
is
the
we're
going
to
move
to
abridged
island
architecture
because
at
scale
this
makes
sense.
And
yes,
it
is
very
simple
to
make
some
of
these
integrations
locally
and
test
it,
but
it
doesn't
scale
when
you
go
to
production,
because
there
are
other
concerns.
You
know
not
just
the
the
ease
that
it
is
to
do
that
integration,
but
you
have
to
maintain
it
and
you
have
to
do
the
cert
rotation
and
you
have
to
keep
up
with
the
patches
from
that
component
and
et
cetera,
et
cetera.
A
So,
okay,
we're
going
to
zoom
way
in
and
I'm
going
to
try
to
answer
the.
How
does
this
help
me?
It
sounds
like
you're
asking
me
to
do
more
work.
Well,
let's
say
you're
picking
kafka
as
a
delivery
mechanism
for
your
venting
systems.
You
have
your
business
logic,
that's
meant
to
you,
know
it.
It
creates
it.
Does
business
work
it
does.
You
know
it
creates
some
sort
of
object
and
then
that
object
is
the
occurrence
of
the
like.
A
So
you
don't
have
to
write
that
shim
anymore.
You
can,
if
you
want
to,
though,
because
you
know
the
first
artifact
of
the
this
working
group
has
been
specifications
that
define
the
the
bindings
between.
We
call
them
bindings
the
bindings
between
the
the
thing
that
you
know
your
event.
This
thing
and
the
the
weird
shape
that
kapha
expects,
which
is
different
than
what
nats
expects
and
which
is
different
than
what
the
http
wants,
and
so
the
point
of
the
cloud
events.
A
Library
is
we
got
you
whatever
you
configure
with
a
protocol,
you
pass
around
your
your
actual
object
and
we
will
help
you
create
that
protocol
specific
shape
and
and
back
out
is
the
important
part
and
your
business
logic
starts
to
just
depend
on
the
the
custom
code
and
yeah.
Okay,
fine
yeah.
It
is
the
same
picture
right,
but
the
difference
is
you
have
to
maintain
that
glue.
A
I
have
to
maintain
that
glue.
I
don't
want
to
help
you
and
there's
those
you
know
I
type
and
and
work
on
the
code,
our
colleagues
work
on
code
and
then
it
helps
everybody
and
so
that
there's
a
scale
factor.
If
you
find
a
bug
you
come
and
you
help
me
fix
it,
because
I
need
some
help
but
yeah.
So
you
know
you
get
to
really
focus
on
that
business
logic
of
producing
and
consuming,
and
this
this
applies
to.
A
You
know
those
that
selecting
those
cncf
projects
too.
You
know
they're
in
this
case
the
event
consumer
and
if
they
leveraged
cloudevents
sdk,
they
would
have
the
ability
to
kind
of
at
runtime
select
different
protocol
libraries.
And
how
neat
would
that
be
says?
You
know
I
okay,
let's
say
prometheus
uses
kafka
internally.
I
don't
know
I
don't
I'm
just
guessing.
Maybe
they
do,
but
I
don't
have
any
kafka
instances
in
my
cluster
and
I
want
to
use
prometheus.
A
So
if,
if
they
had
an
integration
like
this,
I
could
have
in
their
configuration
no
no,
not
kafka.
Today
I
want
to
use
nats
and
it
would
just
be
a
configuration
on
installation.
I
I
get
to
wire
in.
I
bring
my
own
persistence
layer
and
it
is
slightly
more
work
for
them
to
integrate,
but
it's
way
less
work
for
me
to
operate.
It.
A
A
But
this
is
http
structured,
there's,
there's
two
forms
of
http
and
that's
really
because
sometimes
in
some
languages,
it's
much
easier
to
deal
with
the
entire
event
payload
as
a
json
object,
because
maybe
you
know
maybe
it's
not
as
easy
to
inspect
headers
in
javascript
versus
in
go
or
in
python
or
in
in
whatever
pick
your
language
and
what
they
really
want
to.
Just
just.
I
want
to
look
at
the
just
the
json
part
to
implement
my
router
there's
other
protocols
like
nats
that
just
streams
the
json
object.
A
So
it
helps
to
have
a
json
format,
and
this
is
what
it
looks
like.
So
at
the
top
level,
there's
some
required
attributes
and
there
could
be
additional
extensions
with
some
rules
and
then
there's
the
data
piece
and
there's
some
nuances
there.
But
you
know
find
me
later
and
we'll
talk
about
the
nuances,
and
so
you,
you
know
your
weird
shape.
Object
gets
shoved
into
the
data
piece,
and
so
I
just
heard
a
question
yeah.
So
if
it's
an
image,
it
works
too,
but
it's
because
an
image
doesn't
fit
into
json.
A
Normally
it
gets
base64
encoded.
So
any
kind
of
data
can
get
pushed
into
this
data
field
with
some
rules
it-
and
you
know
we
pay
for
a
bigger
size,
but
we
get
to
send
this
binary
data
in
binary
mode
in
http,
all
of
those
routing
metadata,
all
the
the
you
know
right.
So
let's
go
back
to
why
we're
doing
this
right.
A
A
So
there's
some
required
fields
like
I
said,
a
spec
version,
type
source
and
id
and
then
there's
some
optional
ones
that
you
can
add
that
are
standardized
and
specified
by
the
spec.
But
you
can
add
anything
you
want.
So
if
you
needed
to
have
some
sort
of
custom
logic
and
adding
extra
attributes,
because
that's
what
your
application
needs
go
for,
it
there's
some
rules,
but
it's
that's
intended.
A
But
you
know
we
also
have
a
binding
for
for
what
a
github
web
hook
looks
like
in
cloud
events
that
we
specify
and
there's
a
couple,
others
that
are
in
our
documentation,
so
yeah,
okay,
so
you're
sold,
awesome
and
you're.
I
oh,
I
just
heard
another
question:
yes,
yeah
your
language
is
likely
supported
so
and
if
it's
not
talk
to
us,
maybe
you
could
help
us
make
the
new
binding.
A
All
it
takes
is
a
bit
of
dedication
and
reading
some
of
the
binding
specs
to
be
able
to
figure
out
how
to
take
the
natural
object
in
that
language
and
convert
it
to
the
protocol
specific
integration
in
that
language
and
there's
a
bunch
of
protocol
bindings
too.
I
don't
think
this
is
all
because
this
list
is
slightly
out
of
date,
but
I
the
following
slide
has
all
of
them,
and
so,
if
it
wasn't
clear,
I'm
gonna
say
it
again.
A
A
A
You
know
at
the
end
of
the
day,
this
is
about
your
weird-shaped
object
in
the
inside,
and
so
the
schema
registry
provides
a
mechanism
to
describe
the
schema
of
what's
inside
the
actual
event,
because
that's
honestly,
what's
important
right.
The
discovery
and
subscription
apis
are
about
being
able
to
orchestrate
flows
of
of
events
between
producers
and
consumers,
but
the
schema
registry
is
about.
Maybe
I
could
I
know
you
produce
this
event
and
it
has
this
kind
of
context.
A
Maybe
it
has
the
schema
registry
offline
documents
and
I
can
do
a
bunch
of
development
without
having
to
actually
interact
with
a
running
server
somewhere,
so
that
was
the
feedback,
we're
taking
we're
trying
to
roll
that
into
an
updated
spec,
but
we're
still
very
close
to
doing
an
rc
of
these
three
specs.
I
I
bet
in
the
next
couple
months:
we'll
have
an
rc,
so
if
you're
interested
in
that
too,
we
are
looking
for
more
people
to
go.
Do
that
exercise
of
read
the
spec
and
implement
it
they're?
Not
that
complicated.
A
We
just
want
to
make
sure
that
we
have
the
spec,
concise
and
clear,
because
you
know
being
a
working
group,
that's
based
in
specs.
If
the
spec
doesn't
translate
to
interoperable
systems,
we
aren't
doing
a
good
job.
So
we
need
to
get
that
straightened
out.
So
we
need
your
help
and
I
have
a
few
minutes
for
questions.
B
Thanks
for
a
great
presentation,
I
was
wondering
when
I
was
working
with
cloud
events,
why
you
made
the
design
decision
that
sometimes
you
put
in
the
payload
like
the
envelope
and
sometimes
it's
part
of
the
headers.
For
me,
it
was
a
more
obvious
choice
to
have
it
in
the
headers,
because
it
gives
you
the
flexibility
based
on
infrastructure,
whatever
making
routing
decisions
and
also
like,
based
on
the
request
filters
that
you
have
without
unmarshaling
the
whole
object.
Yes,.
A
Yes,
so
there
are
other
eventing
systems
that
natively
speak
json
internally,
and
so
it
would
be
expensive
to
try
to
figure
out
how
to
convert.
You
know
the
json
thing
into
a
non-json
thing
and
back
at
it,
and
so
the
the
answer
is
that
there
are
a
lot
of
systems
that
do
just
look
at
json
and
they
make
routing
decisions
based
on
a
very
simple
scan
of
the
the
schema,
and
they
do
that.
One
level
on
marshall,
they've
optimized
it
to
do
that.
A
A
But
there
are
other
systems
like
github
web
hook,
where
we
don't
really
want
to
wrap
their
payload
to
convert
it
to
a
cloud
event,
and
so
adding
headers
is
a
very
low
bar
of
entry
way
to
get
that
this
cloud
event
metadata
to
do
routing
and
the
cool
thing
is
that
you
can
convert
them
in
and
out
of
structured
or
binary
mode.
With
with
a
little
bit
of
processing
but
no
loss
but
yeah,
I
also
prefer
the
binary
mode
because
it
it's
it's
a
bit
cheaper.
A
C
A
Yeah
we
we
do
have
an
avro
binding
that
helps
address
some
of
that
and
we
also
have
a
proto
binding.
But
if
it's
already
been
serialized
it
it
complicates
matters.
So
it's
that's
kind
of
that's
that's.
What
I'm
hoping
to
get
across
is
that
it'd
be
easier
if,
upstream,
the
event
was
produced
as
a
cloud
event
versus
needing
to
figure
it
out
later.
C
Also,
if
the
event
is
also
if
the
event
is
produced
by
cloud
event,
so
I
want
a
structure
to
to
my
event.
The
event
is
a.
I
don't
know
it's
it's
class
of
human,
so
something
like
that.
The
protobuf
give
me
the
class
itself.
If,
if
the
it's
cloud
event,
I
don't
have
a
the
fields
that
I
I
need.
You
understand
what
I
mean.
A
A
There
hasn't
been
direct
communication
between
you
know,
libraries
that
are
doing,
although
I
there's
an
exception.
So
you
know
we're
just
another
integrator
with
those
libraries
and
the.
The
hope
is
that
we
open
source
that
work
and
we
we
accept
contributions
from
people
that
are
working
with
it
and
finding
bugs.
And
if
the
upstream
thing
changes
or
needs
some
update,
it
comes
down
and
we
can
upgrade
that
in
the
sdks
and
then
that
trickles
out
to
everybody
else,
that's
depending
on
those
kind
of
bearing
the
load
of
of
integrations.
A
A
slightly
other
direction
is
we
did
chat
with
the
open,
telemetry
folks,
a
bunch,
and
the
problem
was
if
you're
sending
a
cloud
event
as
a
producer
of
the
cloud
event
and
the
consumer.
You
kind
of
want
to
see
the
whole
chain,
but
the
perspective
of
open
telemetry
was
well
if,
if
the
protocol
switches
it's
a
different
trace,
but
what
I
really
want
to
see
is
http
to
nats,
to
http
to
a
producer
or
a
consumer
and
getting
that
whole
trace.
E
I'm
coming
from
a
perspective
of
a
developer
who's
building,
you
know,
applications
that
produce
events
or
application
that
consumes
events,
I'm
trying
to
understand
the
value
because
you
you
had
touched
earlier,
because
if
the
thing
inside
the
cloud
event
changes,
I
have
to
redeploy
both
anyways
so
and
in
in
an
architecture
like
that,
I'm
sort
of
like
all
the
routing
stuff,
I'm
relying
on
some
sort
of
a
messaging
system
right.
So
I
don't
play
in
that
space.
I'm
trying
to
understand
some,
you
know
where
would
you
know
where
would
this
fit
in?
E
A
Yeah
so
the
way
I'd
like
to
try
to
answer
this
question
tends
to
be
the
so
as
a
developer.
I
wanna.
I
wanna
write
that
slack,
that
tight
slack
integration
that
I
I
know
that
I'm
listening
to
this
thing
I
and
there's
several
events
that
I'm
interested
in
they
cause
other
things,
but
in
production,
it's
it's
a
kafka
and
it's
very
expensive,
and
I
want
to
be
able
to
test
it
in
qa
and
if
my
function,
that's
or
my
services
is
tightly
bound
to
kafka.
A
The
way
I
have
to
integrate
like
unit
tests,
that
is
by
standing
up
fake
kafka,
servers
and
and
pushing
data
through,
and
if
I
want
to
do
an
integration
test,
I
have
to
have
like
a
real
kafka
cluster
and
figure
out
how
to
tear
that
up
and
down
and
run
those
tests
through
it.
But
if
I
supported
this
idea
of
well,
I
could
shim
it
and
I
want
to
operate
on
the
cloud
event,
not
the
the
kafka
event.
A
Then
I
can
switch
my
protocol
inside
my
qa
environments
or
my
ci
environments
to
something
that's
you
know
cheap
and
cheerful.
Maybe
it
doesn't
have
persistence,
but
in
production
it's
rock
hard
and
has
persistence
until
for
for
all
of
time
or
whatever,
and
so
I
think
not
having
to
think
about
that
as
a
developer
is
the
hope.
But
it's
also
beyond
the
scope
of
what
cloud
events
is,
but
because
cloudvents
is
trying
to
define
this
common
shape.
F
A
We
we
are
internally
to
the
working
group,
we're
looking
for
volunteers,
to
read
the
specs
and
produce
an
implementation.
So
before
we
go
and
provide
an
sdk
in
a
bunch
of
languages,
we
just
want
to
make
sure
that
the
spec
reads
and
produces
compatible
compatible
results
with
other
implementations
of
the
same
spec.
So
there's
no
there's
no
like
commercially
available
thing.
Although
the
schema
registry
is
I
you
can
interact
with
the
beta
version
on
azure,
I
think,
and
for.