►
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.
CloudEvents: Intro, Status and the Future... - Scott Nichols, Chainguard
The CloudEvents specification is one of those unsung hero projects that doesn't get a lot of attention, but is slowly making its way into some of the most popular OSS projects out there today. Why? Come join this session to see why and to learn more about how it can help make your eventing infrastructure more robust. After a quick introduction to CloudEvents we'll then look at what's been going on since we shipped v1.0 - including the new specifications that are under development all aimed at making it easier to produce and consumer events.
A
Okay,
thank
you
for
coming
and
delaying
your
lunch
time
by
a
little
bit,
I'm
sure
the
pesta
will
be
better
today,
we're
here
to
talk
about
cloud
events.
I
am
part
of
the
sig
service,
sig
serverless
community,
and
we
are
working
on
cloud
events,
and
this
is
the
working
group
update.
So
I'm
I'm
here
on
behalf
of
a
bunch
of
people,
dedicating
a
lot
of
time
to
try
to
make
cloud
events
and
this
these
connecting
bits
better
for
cncf.
A
I
am
a
co-founder
of
chainguard.
We
are
as
of
today
at
eight
days
old,
so
there
was
some
scheduled
changes,
so
yeah,
okay,
so
we're
gonna
roll
back
the
time
a
little
bit
to
circa
2015
and
if
you
think,
of
a
standard
pub
sub
model
application,
you
have
some
sort
of
event
producer
and
it
was
producing
events.
Maybe
you
have
several
of
them.
A
That
goes
into
some
sort
of
event
queue.
You
might
have
a
mediator
that
looks
at
the
events
and
says:
well,
actually
it's
high
priority
or
it's
for
production
or
it's
for
servicing.
The
chain
guard
t-shirt
sales
and
it
goes
to
a
specific
channel,
and
then
you
have
some
sort
of
event:
consumer,
which
is
your
application.
A
If
we
have
this
problem
and
we're
thinking
about
the
world
in
what's
the
future
of
serverless,
one
of
the
issues
is
that
we
don't
really
have
a
way
to
talk
about,
like
there's
no
common
language
on
the
event
itself.
Is
there
all
these
interesting
shapes
and
it'd
be
interesting
if
we
could
think
about
the
world
from
higher
order,
so
well
we'll
break
this
problem
down
and
we
have
some
event
producer,
which
is
likely
third
party
you're,
probably
going
to
you
know,
check
the
boxes.
A
You
have
this
custom
necessary,
evil
event,
mediator
thing
that
is
looking
at
those
things
and
kind
of
shuffling
it
to
the
appropriate
consumer
of
those
events,
because
you
don't
want
the
event
producer
to
be
tied
directly
to
the
event,
consumers
right,
because
then
you're
holding
the
event
producer
open
and
we
what
we
really
want
to
focus
on.
As
as
a
you
know,
people
writing
code
is
the
event
per
the
event
consumer
code.
That
wants
to
look
at
those
events
right.
A
So
in
essentially
the
the
first
pass
at
cloud
events.
Is
it's
an
envelope
definition
right.
So
what
is
an
envelope?
It's
you
stuff
it
full
of
something
you
you
seal
it
and
you
write
extra
metadata
around
like
if
it's
fragile
or
if
it's
going
to
go
to
another
country
right.
The
the
event.
Mediator,
takes
a
look
at
the
envelope
and
routes
it
to
the
appropriate
spot.
A
So
why
are
we
thinking
about
this?
Well,
I
kind
of
alluded
to
it
already
when
we're
composing
our
application.
One
of
the
first
things
you
have
to
think
about
is
okay.
Well,
I'm
going
to
be
producing
events
first,
choice,
which
kind
of
event
broker.
Am
I
actually
going
to
implement
because
that's
going
to
get
baked
into
all
the
layers
of
my
application.
A
A
Now.
All
of
the
events
are
are
unmodified,
but
they're
inside
their
own
little
box,
and
now
that
box
becomes
the
cloud
event
and
everything,
but
everything
between
the
producer
and
the
consumer
don't
really
need
to
care.
What's
inside
the
payload.
All
they
need
to
worry
about
is
what
what
are
the
metadatas
along
the
way
that
get
either
appended
or
added
by
the
consumer
or
the
producer,
so
that
the
consumer
can
actually
make
smart
decisions
on
what
it
should
do
and
all
of
the
intermediates
could
make
routing
choices
right.
So
now
it
becomes
really
standardized.
A
So
we
have
this
picture
right
like
event
producer,
maybe
there's
multiple,
maybe
a
couple
layers
of
event
queues
and
then
at
these
all
these
event,
consumers!
Well
what
happens
when
we?
We
want
to
make
a
new
event,
but
we
forgot
to
update
the
routing
the
the
event
mediator
right.
It
we've
updated
the
consumer
on
the
on
well,
was
it
your
your
right
side?
Am
I
right
that
everybody's
right
side,
but
the
event
mediator,
doesn't
know
about
that
event,
and
it
doesn't
know
how
to
route
yet
because
we
didn't
update
that
configuration.
A
So
before
cloud
events,
your
code
kind
of
looks
like
this
right,
there's
the
business
logic
that
you
care
about,
there's
some
custom
glue
code
to
tie
you
directly
to
whatever
transport
you're
trying
to
use
and
then
there's
the
delivery
protocol,
which
that's
that's
things
like
amqp
or
pub,
sub
or
kafka,
and
then
on
the
other
side,
it
goes
backwards
right.
There's,
there's
some
library
that
talks
to
that
broker
pulls
the
event
off
there.
You've
got
some
glue
to
pop
it
out
of
whatever
that
format
is
and
into
something
that
you
can
actually
understand.
A
A
So
what
does
this?
Do
it
potentially
lets?
You
write
code
once
because
you,
if
you
get
that
independence
of
I
want
to
talk
about
what's
inside
the
envelope,
not
the
envelope
itself
and
you
bring
off
this
off-the-shelf
code.
Now
the
we
can
pick
several
protocol
libraries
so
now
we're
sending
both
over
http
and
kafka
and
maybe
there's
some
some
magic
in
our
business
logic
to
select
which
one
or
maybe
we
send
it
on
both
or
there's
some
field
in
the
envelope
itself.
That
lets
you
do
some
selection.
A
Now
I
can
write
my
event:
consumers
and
use
that
off-the-shelf
glue
to
consume
those
events,
and
I
don't
really
think
about
the
exact
protocol
that
they
had
that
they
use
to
get
to
me.
I
just
care
about
what
the
content
of
the
data
is,
so
it
becomes
trivial
possible,
so
so,
okay,
so
what
does
a
cloud
event?
Look
like
this
is
for
http.
A
A
We
have
a
binary
version
of
a
cloud
event
and
it
we
can
take
all
of
that
envelope,
metadata
and
bump
it
up
into
the
headers
and
not
actually
mutate,
the
payload
that
you
have
today,
and
so,
if
you
choose
http
binary,
the
the
conversion
from
what
you're
doing
today
to
a
cloud
event
compatible
thing
would
be
adding
some
metadata
in
the
headers
and
you're
off
to
the
races.
Now
you
now,
you
get
to
participate
in
that
off-the-shelf
ecosystem
of
all
these
event,
mediators
and
delivery
mechanisms
and
sdks,
and
all
this
stuff.
A
A
Payload
the
whole
thing
so
interesting
side
note
I
was
helping
the
techton
triggers
team
when
they
were
thinking
about
how
they
should
consume
web
hooks
and
things,
and
I
convinced
them
that
they
should
rely
on
binary
cloud
events,
because
they
could
opt
into
other
things
like
argo
or
candidate
of
eventing
and
get
all
that
infrastructure
around.
How
do
events
get
routed
and
delivered
to
that
trigger
to
continue
the
tecton
pipelines
instead
of
trying
to
do
some
sort
of
proprietary
thing
where
they
were
going
to
make
a
scheme
in
their
own
standards?
A
Now
their
endpoint
consumes
cloud
events
as
binary
http
blobs,
but
it
also
consumes
direct
cloud
direct
github
web
hooks
because
they
can
choose
to
ignore
the
cloud
events
headers
or
not.
So
so
that's
the
for
their
particular
case.
It
kind
of
was
interesting
because
they
can
do
both
because
binary
doesn't
change
the
message
very
much.
A
What
a
binding
is
is
how
to
take
that
event
and
convert
it
into
the
special
protocol,
binding
http,
amqp
and
qtt.
Those
kinds
of
things
send
it
along
that.
The
though
that
open
standard
and
then
on
the
other
side,
consume
an
event
inspect
it
figure
out
it's
a
cloud
event
and
then
pop
it
back
out
into
the
conical
form
again,
which
is
how
you
get
that
code
independence.
A
I
think
we've
had
one
update
since
then
for
some
minor
typos
and
and
whatnot,
because
they
let
me
write
some
stuff
and
the,
and
there
was
some
clarifications
around
like
what
you
should
do
and
how
extensions
work
and
et
cetera.
So
what
we've
been
working
on
lately
so
recall
this.
We
kind
of
got
to
this
place
where
we
can
still
have
that
pub
sub
model,
but
now
we
we
can
kind
of.
A
We
can
replace
the
event
cues
and
the
event
mediators
with
off-the-shelf
components,
because
we
can
both
produce
and
consume
cloud
events,
and
we
can
kind
of
plug
and
play
that
those
pieces
with
with
some
caveats
right,
of
course,
but
there's
there's
still
some
problems
right
like
I
have
a
whole
library
of
event
producers
and
it
would
be
really
interesting.
If
I
could
look
at
one
and
say,
can
you
please
tell
me
what
kinds
of
events
you
produce
and
what's
the
the
outer
envelope
shape
right?
A
I
need
to
know
what
kind
of
mail
slot
I
need
to
make
or
whatever,
and
you
could
think
of
this
as
it's
kind
of
like
the
event
version
of
what
an
open
api
document
would
be
right.
Open
api
is
great
because
you
can
ask
the
host.
What's
your
rest
interface,
it's
really
difficult
to
do
that
with
eventing
and
event
systems,
because
you
don't
necessarily
there,
there
isn't
a
standard.
Yet
there's
there's
some
attempts
where
we're
attempting
to
make
a
discovery,
api
that
makes
that
interface
very
common.
A
So
it's
it's
a
rest
interface
and
I'll.
Show
you
a
little
bit
well
once
you
know
what
something
produces.
We
can
actually
point
you
to
the
mechanism
that
you
can
ask
that
producer.
I
would
like
to
subscribe
to
your
events.
Please
and
there's
some
proprietary
things.
You
know
actual
limitations
on
what
the
producer
is
going
to
do
right.
A
It
could
be
through
an
intermediate
queue
or
it
could
be
a
giant
data
warehouse
or
you
know
we're
trying
to
leave
room
for
interpretation
there,
but
so,
but
a
common
api
to
let
you
ask
those
producers
or
some
something
on
its
behalf.
I
would
like
to
be
subscribed
to
some
set
of
events
that
you're
going
to
produce,
and
then
I
showed
I
there's
a
bunch
of
optional
required
and
optional
fields.
A
One
of
them
was
schema
data
schema
data
schema,
describes,
what's
inside
the
payload,
so
kind
of
like
open
api
shows
you
what
the
responsive,
ap
and
if
you're
gonna,
do
a
post
to
what
what
shape?
Does
it
expect?
What
does
it
return
same
deal
right
like
what's
inside
the
the
envelope
so
that
I
can
potentially
do
code
gen
and
get
a
function
that
operates
on
just
the
core
kernel
piece
of
the
event
payload?
A
A
Only
so
many
names
in
the
naming
field
that
you
can
use,
but
the
idea
is,
you
can
query
for
the
services
that
this
thing
produces
and
from
that
for
a
particular
service
will
get
you
back
a
set
of
events
with
their
payloads
and
a
bunch
of
other
things
and
a
pointer
to
the
subscription
api
which
then
you
can
also
get
your
subscriptions,
create
and
then
edit.
Those
subscriptions.
A
And
then
we
have
a
much
larger,
much
more
chatty
api
for
the
schema
registry,
and
this
is
really
about
like
I
need
to
get
the
sub
components
of
the
the
schema
and
little
artifacts
and
cookie
crumbs
and
and
that
stuff.
So
these
three
things
together
kind
of
help.
You,
let's
see
yeah,
oh
sorry,
scheme
registry.
So
in
practice
with
this
it
can
look
like.
A
A
slide
that
I
didn't
update
the
schema
registry.
It
just
gives
it's
basically
json
data
from
open
api,
similar
stuff
or
json
schema
right,
not
saying
that
cloud
events
can
support
other
things.
Besides
just
json
right,
we
can,
you
can
send
over
xml
if
you
want,
or
you
can
send
a
binary
blob
or
you
can
send
an
image
and
decorate
it
with
some
headers.
So,
okay,
so
the
future.
A
If
we
go
back
to
that
big
picture,
we've
we've
kind
of
been
we've
thought
about.
The
connection
between
you
know
the
event,
queue
and
the
event,
mediators
or
the
event
consumers
and
the
queues.
We've
thought
about
how
you
find
those
producers,
we've
thought
about
how
you
might
be
able
to
ask
those
producers
to
deliver
your
stuff,
but
we're
still
still
on
the
table.
Are
things
like?
A
Well,
if
we're
in
kubernetes,
for
example,
what
does
the
shape
of
the
container
or
the
contract
from
the
data
plane
look
like
to
deliver
those
things
so
that
you
might
be
able
to
just
focus
on
functions
because
in
the
serverless
space
folks
are
very
excited
about
just
writing
code
and
having
it
like
wrap
up
in
some
magic
thing?
Maybe
there's
room
there
to
to
write
a
standard
expectation
so
that
I
can
just
write
code
and
I
understand
how
it's
going
to
get
wrapped
up
into
a
container
and
standardized
in
some
kind
of
runtime.
A
I
think,
let's
see
so,
if
you
would
like
to
join
us,
we
meet
thursdays
at
these
times.
For
me,
it's
9
a.m.
Coffee
time
you
can
come
check
our
website
out
at
cloudevents.io,
you
can
buy
sweet
swag
in
the
cme
cf
store.
We
have
a
of
course.
We
do
stuff
on
github
in
the
github
org
there
there's
sdk
dash
and
then
the
language
there's
a
whole
bunch
of
sdks
those
those
also
need
love
and
attention.