►
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- 版本 1 正处于开始阶段 | CloudEvents - Version 1 is just the beginning - Ryan Horn, Twillio
自从去年 CloudEvents v1.0 发布以来，社区一直在关注还有哪些其他与事件相关的痛点可以从一些标准化活动中受益。为此，我们一直专注于努力缓解与活动管理生命周期的剩余部分相关的挑战…主要是围绕设置订阅。在此次讨论中，您将了解到正在开发的新规范，旨在帮助人们以编程方式发现感兴趣的事件生成器，以及他们如何订阅获得这些事件，这些事件以可互操作的方式交付。
Since CloudEvents v1.0 was released last year the community has been focused on what other eventing-related pain-points might benefit from some standardization. To that end, there's been a focus on trying ease the challenges that are associated with the remaining portion of the lifecycle of event management... mainly around setting up subscriptions. In this session you'll learn about the new specifications being developed aimed at helping people programmatically discover the event producers of interest and how they can subscribe to get those events delivered in an interoperable fashion.
A
Hello,
everyone
thank
you
for
coming
to
the
stock.
My
name
is
ryan
horn.
I
am
a
senior
architect
for
customer
data
infrastructure
at
twilio,
but
today
I
am
here
representing
the
sig
serverless
cloud
events
working
group
to
talk
about
cloud
events
which
will
include
an
introduction
to
the
project
for
those
who
aren't
familiar
the
current
status
of
the
project
and
some
new
things
were
working
on
as
part
of
the
group
so
to
explain
cloud
events.
A
Let's
first
look
at
a
situation,
a
lot
of
event
pipelines
find
themselves
in
here's,
a
hypothetical
but
realistic
pipeline
through
which
an
event
is
produced
by
some
system
and
eventually
consumed
by
some
consumer
application
for
an
event
to
get
to
the
consumers.
It
needs
to
go
through
a
series
of
intermediate
hops
that
physically
get
the
event
to
the
right
place
in
this
picture.
A
In
a
typical
deployment,
these
hops
are
strung
together
without
standard
interfaces
and
without
common
message
formats.
They
need
to
be
specially
coded
against
every
event,
structure
and
encoding.
They
know
about
which
is
problematic,
as
it
introduces
a
coupling
between
them
in
that,
if
the
event
structure
ever
changes,
the
software
spanning
all
of
these
hops
in
the
pipeline
must
be
carefully
updated
in
a
coordinated
manner
to
avoid
errors
and
data
loss.
A
If
we
don't
and
let's
say
the
format
changes
down
the
line,
this
becomes
a
potentially
expensive
change
to
make
across
all
of
your
pipeline
infrastructure.
The
focus
on
the
logical
model
also
allows
for
an
ecosystem
of
tools
and
implementations
to
emerge
around
the
common
format,
independent
of
a
specific
tool.
A
This
way
the
event
can
be
routed
and
handled
appropriately
and
independently
without
understanding
the
whole
event.
There
are
a
variety
of
reasons
that
this
is
important.
For
example,
the
contents
of
the
event
might
be
applications
specific,
both
syntactically
and
semantically,
in
a
way,
that's
unknown
by
the
intermediaries,
or
you
can
imagine
there
might
be
privacy
concerns
to
continue
with
a
physical
mail
analogy.
A
So
how
does
this
help
with
the
coupling
challenges
described
earlier
in
the
world,
where
we
don't
have
standardization
on
how
the
event
is
structured
and
we
don't
separate
event
content
from
metadata?
If
we
want
to
make
a
change
to
the
structure
of
the
event,
it's
a
complex
and
painful
coordination
with
a
high
chance
of
error.
A
A
Before
cloud
events,
in
your
event
producer,
you
had
your
business
logic
and
then
you
had
your
custom
glue
code
that
mapped
your
application,
specific
representation
of
what
will
go
into
an
event
that
to
the
protocol
and
delivery
mechanism
that
you're
using
to
send
it
such
as
amqp
or
kafka,
and
then
the
actual
delivery
mechanism
or
service
for
sending
the
event
itself
in
the
middle
and
something
similar
to
the
producer.
On
the
consuming
side.
A
A
In
effect,
what
does
this
enable?
First?
This
allows
you
to
focus
on
your
business
logic
instead
of
your
protocol
integration
logic.
Additionally,
because
cloudevents
defines
the
format
in
a
protocol
agnostic
specification
with
separate
bindings
that
implement
specification
for
a
particular
protocol.
You
can
switch
protocols
without
switching
formats.
A
So
enough
of
the
diagrams,
what
does
a
cloud
event?
Actually
look
like?
We've
got
two
examples
here
on
the
left.
You
have
an
example
using
json
over
http
to
represent
the
cloud
event
you
can
see
at
the
root
of
the
json
object.
We
have
the
envelope
metadata,
such
as
spec
version
type
source,
id
data
content
type
which
I'll
come
back
to
in
a
second,
and
then
you
have
this
data
key,
which
includes
the
actual
application,
specific
event.
Contents.
A
But
this
this
example
on
the
left
is
just
one
encoding
in
cloud
events.
Protocol
implementations
can
leverage
whichever
encoding
is
appropriate,
but
they
largely
fall
into
two
buckets
which
we
call
modes
which
are
either
textual,
such
as
json
as
you
see
on
the
left
or
binary
mode
which
you
see
on
the
right.
A
The
event
metadata
is
sent
via
whichever
mechanism,
your
particular
selected
protocol,
uses
to
enclose
message
metadata.
So
for
http
that
should
be
headers
for
kafka,
that's
kafka,
headers,
etc,
and
with
the
separation
intermediaries
such
as
routers,
which
need
to
just
understand
the
metadata
or
even
applications
which
might
want
to
inspect
the
metadata
before
attempting
to
parse
or
understand
the
event
can
do
so
without
accessing
or
understanding
the
event.
Contents.
A
For
example,
let's
say
that
you
have
a
microservice
architecture
that
is
standardized
on
json
over
http
and
rest.
As
the
communication
protocol,
you
can
start
leveraging
cloud
events
using
the
binary
mode
by
extending
your
protocol
using
http
headers,
rather
than
changing
your
services,
understanding
of
http
bodies
etc,
which
is
pretty
cool.
A
I
believe
this
slide
is
just
highlighting
the
metadata
that
is
part
of
the
envelope
portion
of
the
cloud
event.
So
I'm
not
going
to
spend
too
much
time
on
this,
so
you
might
be
wondering
hey.
This
looks
great,
but
how
do
I
get
started?
So
the
community
has
been
hard
at
work,
building
out
sdks
for
the
various
protocol
bindings
in
a
number
of
languages
and
platforms,
and
I
believe
this
is
an
up-to-date
list
of
what
we
support
today.
A
A
So
that
was
an
overview
of
what
cloud
events
is:
what
is
the
status
of
the
product
so
we're
currently
at
1.0
today,
which
we
got
to,
I
believe
a
little
over
two
years
ago,
and
that
was
largely
focused
on
getting
that
comment.
Protocol
and
format
defined
and
usable
and
we've
had
that
in
a
stable
place
for
a
while
now,
which
you
can
go
and
use
right
now
in
your
software,
with
the
sdks
that
I
just
mentioned
so
what's
next,
what
other
problems
are
worth
solving
around
this
space?
A
The
group
over
the
last
two
years
has
been
discussing
this
and
we've
come
up
with
three
new
projects
and
specs
that
are
being
worked
on
as
we
speak,
and
those
are
what
you
see
here.
We
have
discovery,
subscriptions
and
schema
registration,
and
these
are
not
all
independent
specs.
Well,
the
specs
are
independent,
but
they
do
work
together
and
together.
We
believe
that
these
will
ease
the
end
to
end
life
cycle
management
of
events,
how
they're
discovered
how
they're
received
and
how
they're
used
so
to
go
through
each
of
them
individually.
Discovery.
A
Attempts
to
answer
the
question
of
oh
okay:
we've
got
this
great
way
to
integrate
up
inter-operate
our
invented
systems,
but
as
a
consumer,
how
do
I
know
what
to
consume
and
how
to
consume
it,
and
where
do
I
go
to
consume
it?
How
do
I
discover
all
the
events
emitted
by
an
application
producer
that
I
know
about
and
what
is
the
shape
of
those
emitted
events?
A
A
Next,
if
we
take
this
a
step
further,
you
might
ask
the
question:
okay
great,
I'm
able
to
discover
what
events
are
produced.
How
does
my
application
actually
receive
them?
How
do
I
subscribe
to
them
for
this?
We're
also
working
on
a
subscription
api
that
provides
this
mechanism,
along
with
some
handy
features
such
as
being
able
to
filter
on
metadata,
to
receive
only
the
events
that
are
relevant
to
your
application.
A
A
How
does
the
consumer
know
the
shape
of
the
schema
of
those
contents?
For
this,
we
are
working
on
a
schema
registration
api
which
allows
a
producer
to
register
and
consumer
and
consumers
to
access
schemas
that
were
registered
by
producers
and
those
schema
syntactically
described
the
shape
of
those
events
and
their
contents
via
a
steamer
registry.
A
A
In
this
example,
we
fetch
a
particular
service
which
returns
a
service
object,
which
is
an
example
shown
here,
and
it
looks
like
this
includes
a
bunch
of
metadata.
Importantly,
it
includes
an
array
of
events.
This
producer
emits
and
information
about
the
subscription
endpoint,
such
as
the
url
and
supported
filtering
dialects,
which
I
will
go
into
in
a
bit.
A
A
A
Bringing
back
a
modified
version
of
the
diagram
from
before
now
that
the
consumer
has
discovered
the
events
it
wants
to
consume
and
has
set
up
a
subscription
events
will
start
playing
as
normal
according
to
the
rules
in
that
subscription
to
tie
this
all
together.
Let's,
lastly,
look
at
how
the
schema
api
fits
in
the
events
received
at
sync.
In
this
case
the
event
consumer,
we'll
of
course
use
the
cloud
events,
format
and
the
consumer
will
receive
an
event
like
the
following.
A
A
And
you
know,
following
the
the
pattern
of
being
agnostic
to
implementations,
schema
registries
and
event,
producers
are
free
to
choose,
whichever
schema
format
is
appropriate
for
their
use
case,
whether
that's
json
schema,
available,
etc.
So
here
you
see
the
event
consumer
reaching
out
to
the
schema
registry
to
fetch
the
schema
so
that
I
can
use
that
to
understand
what's
enclosed
in
the
event
that
it
just
received.
A
A
A
A
We
welcome
everyone
and
anyone
who
would
like
to
contribute
in
any
way
whether
you
want
to
come
help
contribute
code
to
the
sdks,
whether
you
want
to
brainstorm
on
some
of
the
newer
specs
or
maybe
you
have
an
idea
that
you
think
could
make
this
overall
ecosystem
stronger
and
want
to
contribute
that
please
come
join
us
and
work
with
us.
We'd
love
to
have
you
we'd,
also
love
to
have
some
examples
and
use
cases,
whether
they're
ideas,
pocs
or
production
applications.