►
From YouTube: CNCF Serverless WG: CloudEvents and Serverless Workflow Updates - Tihomir Surdilovic, Red Hat
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
CNCF Serverless WG: CloudEvents and Serverless Workflow Updates - Tihomir Surdilovic, Red Hat
In this session the Serverless WG will briefly update the community on the release of CloudEvents v1.0, and then dive into the latest with the Serverless Workflow specification. With the rise of Serverless Architectures, Workflows have gained a renewed interest and usefulness. In this talk we introduce this Serverless Workflow specification and provide examples, details, and use cases. We will also show a demo with a Java-based reference implementation of the specification, running on Quarkus. In this session you will learn: - The what, why, and the how of the Serverless Workflow specification - Why using the Serverless Workflow specification and orchestration can improve your serverless architecture
https://sched.co/Zeut
A
A
Let's
go
ahead
and
go
to
the
next
slide,
all
right,
so
obviously
the
agenda,
here's
two
main
things
update
on
the
service
working
group
and,
in
particular
the
cloud
events
itself,
we're
going
to
spend
maybe
about
four
or
five
minutes
on
that
not
very
long
and
then
really
hand
it
over
to
teamwork.
To
talk
about
the
workflow
specification,
which
is
the
main
point
of
this
whole
presentation.
So
let's
go
and
go
next
slide,
and
here
we
go
okay,
so
cloud
events.
A
Now
I'm
not
going
to
talk
a
lot
about
cloud
events
is
hopefully
most
you
folks
know,
but
for
those
of
you
don't
very
quickly,
it's
just
a
specification
for
helping
deliver
events
from
a
producer
to
a
consumer
by
standardizing
some
common
metadata
and
where
you
can
find
that
metadata.
That's
a
that's
it
at
a
very,
very
high
level.
I'm
not
going
to
go
into
more
detail
about
that.
A
You
can
read
the
spec
if
you
need
more,
but
I
do
want
to
announce
that
we
have
gone
1.0,
so
that's
all
great
and
as
part
of
the
specification
work,
we
also
produced
things
like
transport
bindings.
You
know
how
these
these
bits
of
metadata
appear
on
different
transports,
for
example
atp
and
qp.
That
kind
of
stuff
also
how
it
appears
in
different
encoding
formats,
things
like
json.
A
It's
not
nothing
that
you
couldn't
do
yourself,
but
sometimes
sdks
make
your
life
a
little
bit
easier.
Okay.
So,
as
I
said,
this
is
all
wrapped
up
into
the
1.0
version
of
specification
now.
What's
next
for
the
cloud,
events
is
two
main
things.
Obviously,
now
it's
out
there
1.0
a
lot
of
people
will
actually
start
to
use
it.
We've
had
some
good
customer
feedback
already
even
before
we
went
one
point,
though,
but
a
lot
of
people
like
to
wait
for
the
1.0
label.
A
So
if
you
look
at
what
cloud
events
does,
as
I
said,
it
helps
get
the
events
from
the
producer
to
the
consumer
and
that's
all
well
and
good.
However,
there's
a
lot
of
stuff
that
really
needs
to
happen
before
you
can
actually
start
setting
those
events
across
the
wire.
Let's
hit
the
next
slide
and
in
particular
the
first
step
is
usually
a
discovery
type
of
spec
step
right.
How
do
you
find
out
who
actually
produces
the
events
of
interest?
What
are
the
events
of
producing?
How
do
you
subscribe
to
those
events?
A
You
know
those
kind
of
things,
it's
more
like
a
handshaking
kind
of
a
thing
right,
so
that
that's
something
else
that
we're
going
to
start
looking
at
is
a
discovery
specification
for
how
you
can
find
who
you
want
to
actually
subscribe
to
and
how
you
do
the
subscription
hit
the
next
and
then,
after
that,
obviously,
you
have
to
do
the
subscription
itself
right.
You
actually
actually
need
to
send
the
subscribe
operation
with
maybe
your
filter
criteria.
A
What
events
you
want
where
to
deliver
the
events
to
right
is
that
push
versus
pull
type
delivery,
that
kind
of
stuff.
So
we
have
another
api
spec
working
on
that
to
define
how
to
actually
do
a
subscription
in
an
interoperable
format.
Okay,
because
remember
the
point
of
all
this
is
to
get
interoperability
and
make
life
easier
for
people
to
actually
consume
these
events
and
sign
up
to
get
them
okay.
A
So,
as
I
said,
we're
going
to
be
looking
at
these
other
two
specifications,
discovery
and
subscription
going
forward
to
help
complete
the
picture
of
interability
around
event,
delivery,
okay
and
that's
it
for
the
cloud
events
side
of
the
house
and
mainly
for
the
rest
of
the
serverless
working
group,
because
we're
kind
of
focused
on
the
cloud
event
stuff
right
now.
However,
I
was
an
offshoot
to
the
workflow,
I'm
sorry
offshoot
of
the
serverless
working
group.
We
had
the
workflow
spec,
which
tmr
would
now
talk
about
all
right.
B
B
So
why
is
a
workflow
specification
needed
currently
out
there?
There
is
a
bunch
of
different
workflow
solutions,
they're
great
and
they
work
amazing
and
they
do
different
things.
But
one
thing
that
we
have
realized
is
that
when
you
start
as
a
user
using
these
different
workflows
or
pipes
pipelines
solutions,
you
run
into
some
problems.
You
run
into
some
sort
of
vendor
lock
issues
in
both
workflow
model
and
workflow
infrastructure
level.
So
once
you
set
up
your
operations
once
you
set
up
your
serverless
applications,
your
functions
and
you
start
orchestrating
it
in
one
certain
container
environment.
B
It's
really
hard
to
move
them
to
the
next
or
or
moving
pretty
much
at
all,
because
they're
bound
to
certain
way
of
defining
your
workflows
or
the
workflow
model,
and
as
well
as
the
orchestra
architecture,
that
the
current
cloud
provider
will
allow
you
to
integrate
with.
So
there's
definitely
need
for
a
portable
and
vendor-neutral
workflow
specification
in
terms
of
in
terms
of
a
workflow
model.
B
So
the
overview
of
the
serverless
workflow
specification
is
basically
we
provide
adjacent
schema
that
defines
the
this
declarative
workflow
model.
You
can
define
your
then
your
workflows
in
both
json
and
yaml
formats,
and
from
this
schema,
then
we
can
create
sdks.
We
can
create
tc
case
for
conformance
testing
of
runtime
implementations,
and
we
can
also
define
different
extension
points
that
go
beyond
just
the
execution.
Semantics
of
workflow
execution
such
as
kpi
simulation
tracing
and
things
like
that.
B
The
overall
goal
of
the
specification
is
to
define
json
yaml
format
based
workflow
models
that
you
can
take
and
move
from
one
time
runtime
to
the
next,
and
these
runtimes
then
can
run
on
different
cloud
providers
or
container
platforms.
So
that's
kind
of
like
the
basic
specification
goal
of
the
serverless
work.
Now
serverless
workflow
specification
uses
cloud
events
a
lot
and
he
uses
it
for
different
types
of
things.
B
For
one
thing
in
serverless
workflows,
you
declare
your
events
that
that
trigger
or
either
consumed
or
produced
during
workflow
execution
up
front
and
they're
all
declared
using
the
context,
attributes
or
the
attributes
of
cloud
event,
definitions
or
the
format
for
same
thing
like
if
you
want
to
declare
that
a
workflow
is
started
by
an
event
or
a
function
or
a
service
call
that
has
to
be
done
during
workflow
execution
has
to
be
triggered
by
an
event
and
also
its
results.
That
we
have
to
wait
for
then
are
contained
in
the
body
of
a
cloud
event.
B
Format
same
thing
for
decisions
during
workflow
execution
cloud
events
can
be
used
to
make
decisions,
for
example,
gateway
decisions.
Do
we
want
to
move
one
way
given
something,
or
we
want
to
take
another
way
of
execution
of
our
workflow
and
the
same
thing?
Is
we
use
some
context,
attributes
from
cloud
events,
so
cloud
events
itself
does
not
define
event
correlation,
but
we
can
use
what
cloud
events
has
in
order
to
define
further
things,
for
example,
cl
event
correlation,
which
means
how
do
we
associate
multiple
events
to
the
same
workflow
instance?
B
And
how
do
we
actually
continue?
Workflow
execution
from
an
event
that
is
associated
with
the
current
workflow
instance
that
we
we're
that
it's
waiting
currently
so
as
far
as
status
and
deliverables
we're
currently
waiting
on
version
0.2?
We
also
have
some
sdks
defined
in
both
go
and
java,
and
we
have
starting
to
define
some
workflow
extension
points.
So
these
were
extensions,
have
nothing
to
do
with
actual
execution,
but
they
enhance
the
workflow
definitions
to
be
able
to
then
interact
with
different
types
of
things
like
tracing
and
things
like
that
in
the
future.
B
So,
what's
next
for
the
specification,
we're
always
doing
model
improvements,
we're
looking
for
different
projects
to
collaborate
with
and
to
see
how
we
can
and
enjoy
efforts,
and
things
like
that
with
the
community
and
grower
community
and
the
same
thing
we're
looking
for
is
some
simulation
and
tracing
extensions
at
this
moment.
So
I'm
going
to
go
ahead
and
show
you
guys
a
demo
which
is
the
best
way
to
actually
show
something,
and
in
this
case
this
is
kind
of
like
the
architecture
of
the
demo.
B
It
has
to
do
with
orders,
so
this
basically
shows
off
the
serverless
on
the
left
side.
We
have
different
types
of
users.
We
have
mobile
users
or
users,
creating
new
orders
on
the
web
and
sometimes
orders.
We
can
also
draw,
for
example,
drop
a
file
into
a
directory,
so
we
have
two
ways
of
triggering
our
workflows.
One
is
web
based
which
will
show,
and
one
is
actually
file
based
for
the
file
based.
We
have
apache
camo
that
has
a
route
that
listens
to
a
certain
directory.
B
It's
going
to
pick
up
our
file,
it's
going
to
get
the
contents
of
the
file
and
actually
create
a
cloud
event
for
us
using
the
cloud
event
sdk
that
it
provides,
which
is
great
now,
as
our
broker
we're
going
to
use
kafka
messaging
and
this
event
is
going
to
be
published
onto
a
kafka
topic.
It's
going
to
get
picked
up
by
our
serverless
workflow,
and
actually
we
will
trigger
the
workflow
instance
same
thing
from
web
or
mobile
clients.
B
We
have
a
rest
service,
it
gets
a
request,
creates
the
cloud
event
and
triggers
our
workflow
execution
on
the
right
side,
we'll
see
during
workflow
that
we
can
integrate
with
different
types
of
services.
That's
kind
of
what
workflow
is
really
about.
We
want
to
orchestrate
different
services
to
create
some
sort
of
or
solve
some
sort
of
business
problem
that
we
have
in
this
case
our
business.
Probably
is
we
have
an
order.
We
have
to
sometimes
either
get
a
rule
service
to
say:
hey.
Can
we
auto
complete
this
order?
B
If
we
cannot,
we
need
human
interaction
and
in
this
case
we
want
to
trigger
a
human
task
service
to
get
a
manager
approval
for
for
this
particular
order,
so
that's
kind
of
like
what
it
is
and
I'm
going
to
exit
out
of
presentation
and
show
you
guys
the
demo
all
right
one.
Second,
all
right,
so
I
have
here
the
application
already
started
and
once
you
started,
you
can
go
to
localhost
8080
orders,
so
this
is
going
to
be
our
orders
kind
of
ui,
and
I
also
wanted
to
show
you
guys
one
second.
B
I
wanted
to
just
show
you
quickly,
I'm
sorry.
I
forgot
to
open
this
beforehand
the
actual
workflow
so,
as
we
said,
workflows
and
I'm
just
going
to
open
real,
quick,
the
image
for
it
all
right.
So
here
that
goes
all
right,
so
this
makes
more
sense
to
look
at
on
this
side
here.
On
the
left
hand,
side
we
have
the
actual
json,
so
workflows
can
be
represented
in
json
and
yaml
formats,
and
they
can
be
all
right.
So
here
we
go
and
basically
what
we're
doing.
B
We
have
a
couple
of
event:
definitions
for,
for
example,
what
we
showed
the
new
order
event.
A
new
order
is
created
whenever
somebody
either
drops
a
file
as
we
see
or
creates
a
rest
client
request
for
a
new
order.
We
have
some
function,
definitions.
Those
are
the
way
ways
of
interacting
with
services.
B
In
this
case,
we
have
a
couple
of
functions
defined
one
from
our
auto
approval,
which
will
contact
our
business
rules
service,
and
one
is
our
order-
management
approval
function,
which
basically
is
going
to
call
our
human
task
service
and
have
a
manager
approve
it.
So
then
we
go
through
some
states
and
not
to
go
through
everything.
I
will
show
you
on
the
right
side.
The
image
we
first
go
into
a
handle
new
order
state.
This
is
an
event
state,
which
means
this
workflow
is
triggered
by
an
event
as
we've
seen
previously.
B
B
We
just
go
ahead
and
go
to
an
approved
state
which
generates
a
cloud
event
for
our
results,
which
the
type
approved
or
if
we
need
manager
approval,
we
go
to
another
state
which
basically
just
calls
our
human
task
service
waits
for
the
manager
approval
and
then
completes
the
workflow
execution,
sending
a
cloud
event
as
a
result
for
whoever
wants
to
consume
it,
in
this
case
our
ui.
So
let's
kind
of
take
a
look
at
the
actual.
How
that
will
work?
B
B
Oh
and
here
we
go
so
what
we
see
here
under
workflow
instances
is
basically
that
the
event
that
apache
camel
the
cloud
event
has
put
on
the
kafka
topic
has
triggered
workflow
execution,
and
in
this
case
we
have
one
workflow
orders,
workflow
instance,
and
because
the
cost
was
under
300,
we
see
here
in
order
decisions.
This
table
right
here
is
going
to
listen
to
all
the
cloud
events
with
our
order
decisions.
It's
picked
that
up
because
the
workflow
has
completed
execution
and
send
the
cloud
event
with
the
results
and
it
says
approved.
B
So
this
is
one
way
of
triggering
workflow
execution
through
some
sort
of
integration
platform
such
as
apache
kafka.
Now,
let's
try
doing
it
via
the
rest
client
so,
for
example,
this
simulates
somebody
on
the
mobile
phone
creating
an
order.
So
let's
say
I
want
an
order
here.
My
address
I
would
like
overnight
shipment
for
a
ps4
that
cost
me
three
thousand
dollars.
So
when
I
create
this
again,
rest
clients
is
going
to
create
a
cloud
event.
B
Push
it
onto
a
kafka
topic,
our
workflow
that
is
going
to
listen
to
it
and
because
of
the
cloud
event,
is
going
to
actually
create
an
instance
of
their
workflow.
So
when
we
create
this
couple
of
things
happen
number
one.
If
you
under,
if
we
see
under
workflow
instances,
we
have
created
a
new
order,
workflow
instance,
but
instead
of
completing
it
is
currently
active.
What
does
that
mean?
So
you
remember
our
steps.
We
go
through
a
rule
service.
We
called
it
and
said:
hey.
B
B
Because
here
we
have
a
manager
approval
to
deal
with
here
you
when
you're
developing
your
services,
you
can
put
it
send
an
email
out
to
a
manager,
whatever
you
like
to
do,
but
for
the
sake
of
this
demo,
we
show
it
all
on
one
page,
so
here
you're
a
manager,
you
can
approve
and
deny-
and
you
can
see
here
the
order
id
the
task
id
that
should
match
here
as
well.
The
order
id
should
match
our
active
one
and
let's
say
okay
for
ps4
three
thousand
dollars
is
way
too
much.
B
There's
probably
some
issue
with
this
order
anyways.
So
I'm
going
to
deny
it.
When
I
deny
it,
we
see
that
our
workflow
instances
went
from
active
to
completed
our
human
task
decision
manager.
Approval
went
from
ready
to
complete
it
because
we
denied
this
order
and
the
workflow
before
it
finished
execution
is
sent
out
the
cloud
event
with
the
results
of
the
night,
which
was
the
manager
approval
idea.
So
that's
kind
of
it
for
this
demo
and
let's
go
back
to
presentation
mode.
If
I
find
out.