►
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
Intro: CNCF Serverless WG/CloudEvents - Scott Nichols, Google & Klaus Deissner, SAP
This session will provide an introduction to the CNCF Serverless Working Group, the CloudEvents specification and the new Workflow sub-group. It will give an overview of our history, status of the work, demo of CloudEvents spec and future plans for the WG and CloudEvents project.
https://sched.co/MPhO
A
B
I'm
closed
I
stopped
from
s
AP
and
before
Scott
later
on,
we'll
go
into
more
details
with
actual
coding
and
also
a
demo.
I
will
give
some
background
of
what
the
service
working
group
is
actually
doing
and
how
cloud
events
were
started.
So
the
working
group
was
established
in
the
middle
of
2017,
and
first
thing
that
was
done
is
to
create
a
white
paper
to
determine
what,
as
what
is
actually
server
is
it
was
a
floating
buzzword
at
the
time
and
also
to
come
up
with
recommendations.
B
Yes,
cloud
events
was
then
established
as
a
sandbox
project
about
a
year
ago,
and
another
activity
that
was
happening
was
to
create
a
spec
for
function
workflows.
So,
let's
start
with
eventing
actually
went
when
I
joined.
This
working
group
I
was
first
wondering.
Why
are
they
so
interested
in
events
and
and
had
to
recall
what
I
learned,
maybe
earlier
on
and
I
had
that
time?
New
events,
mostly
from
things
like
UI
frameworks,
where
you
get
those
button,
clicked
events
and
write,
event
handlers,
and
so
we
had
some
more
formal
definitions
or
things
around
events.
B
B
From
that,
then
an
event
is
created,
which
is
a
data
record,
and-
and
usually
you
do
this,
of
course,
to
trigger
something
to
trigger
an
action.
But
the
most
important
thing
here
is
that
the
occurrence
is
actually
decoupled
from
this
action,
so
it
doesn't
really
know
and
shouldn't
really
care
if
any
action
is
triggered
by
the
immense,
its
events,
its
emitting
and
yeah.
So
in
the
UI
frameworks,
I
refer
to
before
event
is
just
something
like
like
a
plain
old
object
and
the
handler
may
be
just
an
interface
implementation.
B
But
how
does
this
look
like
in
distributed
systems?
So
I
just
picked
one
example,
and
so
what
you
see
here
is
you
have
a
message
broker
in
the
middle
that
is
providing
the
technical
decoupling,
so
routing
messages
between
different
participants,
usually
something
like
a
pop
stop.
Schemer
is
used
for
this
and,
on
the
left
hand,
side.
There
is
an
application
that
may
be
emitting
some
events
depending
on
the
domain
of
that
application.
Something,
like
you
know,
other
approved
or
something
like
this,
and
then
there
are,
on
the
right
hand,
side,
there's
a
function.
I
mean.
B
B
There
may
also
be
some
cloud
offerings
and
it's
it's
well
known
that
they
also
provide
usually
webhooks
notifications,
and
so
the
network
endpoint
here
is
then
providing
as
a
bridge
between
this
epic
notification
and
the
message
broker,
and
so
what
can
now
the
cloud
events
and
what
we
are
doing
in
the
serviceworker
group
do
for
you
here
and
first
of
all,
we
have
transferred
bindings
for
several
message:
messaging
protocols.
So
this
this
part
of
transporting
events
between
the
different
participants
in
this
distributed
system
is
covered.
B
We
have,
of
course,
also
bindings
for
HTTP
and
several
flavors,
and
it's
not
just
about
I
mean
what
we
achieved
by
this
is
that
we
can
transport
events
in
a
uniform
way
among
or
over
several
hops,
and
the
benefit
here
is
that
we
have
this
unified
event
context
and
that
this
can
then
be
used
for
things
like
filtering
routing,
subscription
handling.
And
although
we
in
the
working
group
do
not
define
how
exactly
this
filtering
or
routing
has
to
happen,
that's
done
implementation
specific.
But
the
idea
of
the
event
context.
B
This
unified
context
is
to
really
enable
those
things
a
bit
independent
from
the
rest
of
the
spec.
We
also
have
a
specification
for
the
book
delivery
so
how
exactly
some
web
yeah?
Some
events
can
be
delivered
by
a
web
hook
like
like
protecting
the
sender
against
some
abuse
and
things
like
this
and
yeah.
Then
there
are
the
workflows
that
make
use
of
the
event,
definitions
for
state
transitions
and
last
and
certainly
not
least-
and
we
will
see
later
on
a
bit
more
about
this-
the
cloud
event
SDKs.
B
So
after
we
had
some
draft
of
the
specification
also
the
SDK
work
started.
We
are
supporting
several
languages
already,
and
this
enables
10
developers
in
all
parts
of
this
distributed
system
to
work
seamlessly
with
with
cloud
events,
and
one
other
important
aspect
here
is
that
all
those
components
seen
in
this
picture
might
be
provided
or
operated
by
different
parties.
So
interoperability
in
this
whole
game
is
really
important.
B
We
also
have
a
certain
set
of
well-documented
or
known
extensions
and
where
we
think
that
they
are,
they
might
be
of
general
interest
and
we
want
to
watch
if
they
get
more
adopted
and
if
they
are
widely
adopted,
and
we
might
even
think
of
adding
them
to
the
standard
later
on
and
yeah
for
all
this
they
are
transport
bindings.
Here
is
listed,
jason,
HTTP
and
mqtt.
B
We
also
have
a
mqp,
protobuf
and
nuts
I
think,
and
so
quite
a
few
already,
and
it's
I
think
this
is
even
growing
some
principles
I
observed
over
the
discussions
and
the
in
the
group
are
or
that
transport
bindings
are
not
supposed
to
be
another
communication
layer.
So
the
protocols
that
I
use
for
inventing
already
layer,
seven
protocols
and
adding
layer
eight
doesn't
really
make
sense.
So
it's
it's
more
describing
how
to
use
those
protocols
to
transport
events
with
primitives.
They
already
provide
also
things
like
batching
of
events.
B
If
the
underlying
protocols
already
support
that
pretty
well
like,
for
example,
nqp,
that's
not
really
the
concern,
then,
of
the
cloud
event
standard
contacts,
attributes
I
mentioned
already.
That
less
is
more,
usually
so,
the
the
guidance
here
to
have
as
few
as
possible
but
of
course,
as
many
as
needed
as
they
are
put
into
things
like
the
headers
and
certain
protocols.
B
It's
really
important
to
think
about
the
cost
of
transporting
all
those
attributes
and
if
there
is
really
the
need
to
have
them
in
the
event
context
or
if
they
can
also
be
put
into
the
payload
of
an
event
when
they
are
just
used
and
the
event
consumer
and
do
not
really
provide
additional
use
for
for
intermediary
hops
of
the
event,
it's
important
to
mention
that
event.
Attributes
should
also
not
contain
confidential
information,
as
the
event
context
is
used
for
routing
it's
not
really
feasible
to
do
end-to-end
encryption.
B
B
Cumbersome
I
would
say
so
we
separate
this,
so
the
sauce
is
now
about
the
context
where
the
event
occurs
and
the
subject
is
more.
What
it's
related
to.
What
yeah
and
content-type
has
now
renamed
the
attribute
to
data
content
type
to
avoid
misunderstandings
in
certain
cases
where
you
have
content
type
and
the
header
and
the
data
content
type
in
the,
for
example,
the
JSON
format.
B
We
have
some
new
documented
exchange
in
the
data
ref.
That's
supporting
the
claim
check
pattern
where
you
do
not
send
the
actual
data
as
part
of
the
event,
but
just
a
link
to
the
data
to
avoid
a
huge
data
transfer
and
also
to
enable
some
kind
of
authentication
authorization
for
the
receiving
end,
and
we
discussed
things
like
patching
and
what
I
said
before.
That
batching
is
not
really
to
be
handled
by
cloud
events,
but
by
the
transport
layer
and
but
for
HTTP.
B
A
A
Slash
SDK,
go
I
in
my
day
to
day
work
at
Google,
I
work
on
kay
native
eventing,
and
we
use
cloud
events
internally
in
K
native,
and
so
we
had
a
we
had
a
library
and
we
up
streamed
it
to
the
cloud
events,
org
and
so
I'm
gonna
show
you
an
example
of
running
this.
So
here
is
a
simple
example
that
the
payload
will
be
this
simple
struct,
that's
just
a
name
in
the
data
and
I
can
use
this
method
called
a
new
default
client,
which
I
can
show
you
all
it
does.
A
So
this
is
this
is
the
outline
of
what
this
sk2
sdk
does
the
main
wrapper?
Is
this
client
object
and
you
give
it
a
transport
and
because
the
transport
has
a
set
interface,
the
client
doesn't
need
to
know
how
the
data
is
gonna,
be
sent
on
the
wire
this,
the
little
radio
icon,
that
the
transport
encodes
its
own
codec,
so
I
kind
of
decoupled,
the
the
cloud
event
as
the
piece
of
data
and
the
on
the
wire
representation
for
the
transport,
so
the
the
transports
job
is
to.
A
If
you
send
an
event,
a
cloud
event
object.
It
goes
in
to
send
it
goes
into
the
in
code
and
it
goes
out
the
wire
if
an
event
comes
in
on
the
transport
it
goes
into.
The
decode
turns
it
into
a
from
a
message
to
an
event,
and
then
it
gives
the
transport
receiver
that
new
event,
so
your
function
gets
activated.
So
I'm
gonna
show
you
this
in
practice.
A
A
Because
I
do
some
magical
reflection,
but
the
one
I'm
going
to
choose
is
I
get
a
vent
which
is
a
cloud
event.
Ok
and
then
I
write.
Now
it
you
say:
I
have
a
struct.
Please
turn
the
payload
into
the
struck
that
I
know
it
does
some
magic
marshalling
thing
and
then
I
can
print
out
my
name,
hello,
whatever
right
hello,
world,
ok,
so
we're
gonna
run
that.
A
And
it's
super
and
I
have
a
little
curl
command
that
I
can
copy,
so
we're
gonna,
curl
Earl
and
we
at
an
event
translate
it
into
the
kind
of
this
transport
and
specific
version
of
that.
So
you
can
see
the
the
context
attributes
the
the
routing
information
that
you
can
use
to.
If
you
in
a
bigger
system
and
then
the
the
data
payload,
which
in
this
case
was
this,
is
HTTP
binary
mode.
It
shows
that
shows
the
payload
okay
cool.
A
So
let's
say
you
would
like
to
send
data
to
that
I'm
doing
some
magic
here,
but
I
make
an
outbound
HTTP
transport,
which
means
I,
am
making
a
cloud
events.
Transport
I,
give
it
a
target
which
there's
other
ways
you
can
do
this,
but
it's
okay
and
I'm,
saying
use
binary
encoding
for
sending
and
then
I
give
that
to
the
client.
Note
that
I'm
using
the
different
method,
this
one
actually
per
view
provide
the
transport
instead
of
having
the
the
same
default,
which
is
normally
HTTP.
A
Okay,
so
I
have
some
magic
methods
that
do
things
like
defaulting
you
IDs,
if
it
basically,
it
says
like.
If
you
know,
if
the
context
doesn't
know
and
the
IDS
and
said
just
make
a
new
UID,
some
kind
of
some
convenience
methods
there,
so
we
are
going
to
run
this
and
all
it
does
is
says
client
that
send
the
event
we
just
constructed
all
right,
so
hello,
Barcelona
and
the
name
is
Hana
for
HTTP.
A
And
so
that
has
sent
a
message
over
HTTP
from
one
thing
to
another:
okay,
that's
cool,
but
you're,
saying
well,
I,
don't
really
use
HTTP
I
actually
use
Nats.
Okay,
so
I
can
do
the
same
thing
where
I
make
a
new
Nats
transport
I
have
Nats
an
ad
server
running
locally
on
my
laptop
I
set
the
subject
as
hello
and
then
I
make
a
new
client
the
same
method,
so
I've
I've
constructed
that
transport
and
given
it
to
the
cloud
events,
client
and
now,
I
can
call
the
same
method.
A
A
So
it's
it's
starting,
but
I,
don't
know
how
to
curl
Nats.
So
I
can
change
the
greeter
to
use
the
Nats
version
of
the
transport,
which
is
exactly
the
same.
I
set
up
the
transport
ice
I
returned
it
back,
I'm
panicking
for
demos.
This
is
not
production
code.
Don't
do
that
and
I'm
using
that
same
thing,
but
we'll
do
eight.
A
Okay.
So
now
you
have
this
kind
of
fun
dynamic.
Where
you
can
inject
the
transport
I
realized,
you
can
do
other
fun.
Things
like
I
can
make
an
inbound
Nats
an
inbound,
HTTP,
client
and
then
an
outbound,
client
and
I
can
choose
the
transports
that
go
in
those
things,
so
I'm
giving
Nats
I'm
gonna,
listen
on
Nats
and
HTTP
and
I'm
going
to
make
a
four
word
function,
which
is
just
going
to
use
the
outbound
client
to
send
the
event
that
it
received.
A
A
So
that's
the
forwarder
okay,
so
it's
gonna
do
its
thing
and
then
watch
this
window.
Here
we
can
still
Curl
Curl
Earl.
We
can
send
the
greeter.
The
grader
is
still
running
Nats.
So
this
this
has
gone
to
Nats
through
the
forwarder
via
HTTP
to
the
original
hello
person
right,
but
we
can
also
you
can
change
this
back
to
HTTP.
A
A
A
A
A
A
A
A
Okay,
so
we
we,
the
cloud
events
working
group
had
been
working
with
somebody:
that's
working
with
the
Heathrow
Airport
to
move
simulate
like
a
what,
if
a
big,
complicated
thing
like
an
airport
had
all
of
the
entities
sending
cloud
events
to
a
central
hub
so
that
you
could
watch
those
events
and
respond
to
it.
Maybe
something
simple
like
some
room
continues
to
be
hot
and
somebody's,
probably
a
broken
a/c
peace
somewhere,
and
maybe
that
data
needs
to
filter
up
to
some
central
place.
That's
the
eventual
goal
and
to
to
make
it
interesting.
A
So
the
thing
that's
interesting
here
is
that
we're
all
talking
over
a
central
bus
which
is
AMQP
but
every
every
new
logo,
and
this
picture
is
actually
in
a
different
cluster
somewhere
else
on
the
internet
and
they're
all
bridging
AMQP.
But
that's
only
on
the
outer
pieces.
So,
for
example,
K
native
takes
AMQP
and
uses
basically
that
same
forwarder
code
and
says
AMQP
to
http
and
I,
send
it
to
some
internal
details
of
what
K
native
uses
and
there's
other
talks
that
talk
about
that.
A
The
everyone
is
using
a
different
transport
to
communicate
internally,
which
is
kind
of
cool.
But
we
all
have
that
same
core
piece.
That
is
the
cloud
event.
So
we
all
know
and
understand
how
to
route
pieces
to
each
other
without
having
to
share
the
transport
details,
because
we
have
all
agreed
that
we
can
use
the
cloud
of
inspected
to
translate
between
different
transports,
which
is
compelling
so.
A
A
It
the
question
is
in
my
line
about
the
central
bus,
the
that
there's
a
like
we've
all
agreed
to
speak
together
on
one
central
AMQP
channel,
but
internally,
there's
all
there's,
probably
as
many
cues
as
you
see
representations
here,
because
everyone
internally
can
pull
messages
off
that
central
bus
and
then
distribute
internally.
Whatever
that
means
and
like
Canada
is
all
written
and
go.
I
know
that
the
the
function
framework
from
sa
P
is
written
in
JavaScript
right,
like
they
actually
bridge
from
the
AMQP
into
an
HTTP.
A
Doug
is
go
okay,
let
a
little
bit
of
node
in
there
too
yeah,
but
so
anyway,
it's
we're
trying
to
show
that
you
can
mix
languages
and
you
can
whatever
your
proficiency
is
shouldn't
block
you
from
also
working
together
and
the
goal
of
cloud
events
is
to
make
sure
that
the
transport
is
agnostic
to
your
goal.
So
hopefully
that's
what
we're
that's
what
we
conveyed
any
other
questions
that
answer
that,
yes,.
C
A
You
can
register
for
events
of
a
certain
type
and
then
it
will
do
a
watch
for
you
and
then
turn
that
into
a
cloud
event
and
then
route
it
to
a
destination
for
you
and
I
guess:
technically
it
can
be
off
the
cluster
because
it's
just
a
URL,
but
somebody
is
maybe
going
to
talk
about
a
service
reconciler
for
kubernetes,
using
cloud
events
and
Kay
native,
so
yeah,
it's
a
I,
don't
know
if
we're
gonna
upstream
that
stuff,
but
we've
came
native,
has
been
building
adapters
and
I.
Think
various
other
companies
as
well,
where.
A
D
A
So
so,
yes,
we
it's
it's
up
to.
You
have
code
that
and
we're
still
like
cloud
events
are
still
getting
worked
on,
but
it
not
to
plug
my
own
code
again
but
I.
There's
an
organization
on
github
called
bot
lists,
which
was
a
demo
thing,
that
I
wrote
for
coop
con
China
and
it
uses
cloud
events
and
K
native
to
bridge
multiple
chat
devices
and
then
translate
that
into
a
bot
command,
and
then
that
gets
invoked.
A
So
you
can
actually
wire
up
as
many
different
chat
services
as
you
want
and
maybe
a
different
command
types,
and
so
you
get
this
because
I'm
using
cloud
events
all
the
way
through
I
and
I.
Have
these
little
filter
functions.
I
can
turn
it
into
the
same
shape
and
then
invoke
on
the
same
command,
but
it
comes
from
different
different
areas.
So
it's
very
interesting.
The
venting
thing
happens.
What
is
happening?
A
If
you
go
to
the
view
page,
but
we're
showing
you
what
the
the
raw
cloud
event
looks
like
and
you
can
see
here-
is
the
the
context
attributes
the
depending
on
the
transport
they
get
wired
up
at
different
places.
So
for
binary
mode
on
HTTP,
it's
part
of
a
header
yeah.
You
could
also
have
it
structured
mode
where
it
would
look
like
this
as
the
body
of
the
HTTP
in
AMQP.
It
gets
mapped
into
headers
and
the
payload
becomes
mapped
into
the
data,
the
data
body,
so
it
in
every
transport.