►
From YouTube: CNCF Serverless WG: CloudEvents and Serverless Workflow - Doug Davis, IBM & Tihomir Surdilovic
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
CNCF Serverless WG: CloudEvents and Serverless Workflow - Doug Davis, IBM & Tihomir Surdilovic, Red Hat
In this session the Serverless WG will update the community on the CloudEvents and Serverless Workflow specifications. In this talk we will look into the importance of using workflows in event-driven, distributed applications. Then we will look at the specifics of the Serverless Workflow specification and what benefits it brings you for solving real-world business problems. We will also present a demo showing off the Serverless Workflow declarative markup in action. What will you learn: * Pros/Cons of using workflow-based orchestration in your event-driven, distributed applications * Benefits of using a specification-based workflow markup * How Serverless Workflow can improve portability of your apps * How to get started using Serverless Workflow
https://sched.co/ekIH
A
A
So
what
we're
going
to
do
in
this
session
is
first
talk
about.
What's
going
on
the
cloud
events,
just
very,
very
quick
update
there
and
then
the
bulk
of
the
session
will
actually
be
the
workflow
specifications
and
stuff,
and
that's
that's
the
more
exciting
piece
for
you,
guys.
Okay,
so
let's
go
and
jump
into
the
cloud
event
stuff.
So
I'm
not
going
to
talk
about
what
cloud
events
is
I'm
going
to
assume
everybody
already
knows
that
instead,
I
just
want
to
bring
you
up
to
date
on
what's
happening
with
it.
A
Since
the
last
time
we've
met,
which
I
guess
is
last
coupon-
north
america.
Since
then,
we've
released
version
1.0
of
the
spec
and
includes
not
just
the
specification
but
the
transport
bindings,
meaning.
How
do
you
actually
map
the
cloud
events
metadata
to
the
various
protocols,
http
amkp?
All
that
other
good
stuff,
also
including
the
according
I'm
sorry
also
included,
are
the
encoding
formats
of
how
to
encode
the
cloud
event
metadata
into
json
and
avro,
as
well
as
a
primer.
A
To
give
you
some
basic
information
about
some
of
the
decisions
we
made,
maybe
some
design
or
implementation
guidance
stuff
like
that
now
we
also
have
a
whole
bunch
of
sdks
out
there,
and
some
of
those
are
very,
very
active.
So
in
particular
take
a
look
at
things
like
the
the
java
one,
the
golang
one
javascript
very,
very
active
c
sharp
as
well,
because
there's
been
a
lot
of
activity
in
that
space,
because
these
sdks
are
really
the
main
starting
point
for
people
to
pick
up.
A
This
stuff
just
makes
your
life
a
little
bit
easier
for
dealing
with
these
cloud
event
metadata
things.
Okay.
Now,
because
we've
gone
1.0
what's
next
for
us
well,
the
biggest
thing
is
community
feedback
or
customer
feedback
right.
We
need
to
hear
from
other
people
who
are
actually
using
it
to
make
sure
we
didn't
miss
anything,
get
anything
wrong
and
stuff
like
that,
and
to
be
honest,
as
of
right
now,
we
really
haven't
heard
a
whole
lot,
which
is
really
really
good,
but
we're
not
just
sitting
back
and
waiting
we're.
A
Also
looking
at
sort
of
the
next
set
of
pain,
points
related
to
the
cloud
event
itself.
So
let's
go
ahead
and
go
to
the
next
slide,
and
what
I
want
to
do
is
quickly
touch
on
the
two
bits
of
work
that
we're
doing
related
to
this.
Now,
if
you
understand
what
cloud
events
is
it's
about,
how
to
help
the
producer
get
the
cloud
events
or
the
event
to
the
consumer,
so
it's
sort
of
the
tail
end
of
the
process
here.
A
So
let's
talk
about
the
first
spec
that
we're
going
to
be
looking
at
in
addition-
and
that
is
going
next
slide
and
that's
the
discovery,
api
spec
and
what
that's
about
is
the
consumer.
In
essence,
as
the
name
implies
discovering
who
produces
the
events
of
interest
to
them
or
what
events
each
producer
actually
does
produce.
A
Okay
is
that,
because,
obviously,
if
you're
going
to
get
events,
you
need
to
know
who
to
subscribe
to
what
events
you
can
get
from
them
and
stuff
like
that,
and
additionally,
you
need
to
figure
out
how
you
actually
do
the
subscription
itself
right.
Do
they
support
http,
maybe
amqp,
or
does
everything
come
across
kafka
that
kind
of
stuff
right?
So
you
have
this
discovery
step
in
the
whole
process.
A
Next,
you
then
have
this
the
subscription
api
itself,
okay
and
that's
how
you
actually
do
the
subscription?
Okay?
Where
do
you
send
the
the
subscription
request
to?
How
do
you
tell
it?
You
want
the
events
delivered
over
http
versus
some
other
mechanism?
What
are
the
format
of
the
messages?
How
can
you
filter
the
messages
if
they
support
filtering
stuff,
like
that?
A
Okay,
and
so
that's
what
we're
really
focusing
now
in
the
cloud
events
group
itself
is
the
discovery
spec,
as
well
as
the
subscription
specification.
Now,
these
specs
are
relatively
new,
but
we
are
far
enough
along
we're
actually
planning
on
doing
an
interop
event
in
the
november
time
frame,
so
if
you're
interested
in
either
of
us
but
of
those
specifications
and
you're
in
particular
interested
in
actually
starting
to
code,
these
things
up,
please
come
and
join
us
and
and
join
the
fun
okay.
B
All
right,
thanks
doug,
so
serverless
workflow
is
a
cncf
sandbox
sandbox
project.
It's
part
of
the
serverless
working
group,
so
the
group
that
doug
works
with
also
also
it's
open
source
and
apache
2.0
license
it's
a
community
project.
So
here
you
can
find
some
information
about
our
github
repo
website
and
the
community
chat
and
meeting
information.
B
The
serverless
workflow
defines
a
declarative
and
domain-specific
workflow
language
declarative
and
it
is
not
expressed
in
low-level
code.
However,
it
defines
an
abstraction
that
can
be
described
in
both
json
or
yaml
formats
and
domain
specific,
as
it
targets
the
domain
of
orchestration
of
event-driven
and
distributed
services,
and
just
to
show
this
as
an
example.
On
the
left-hand
side,
we
have
two
simple
requirements
written
in
natural
language,
and
these
are
when,
for
example,
a
patient
has
a
bladder
infection.
B
We
want
to
notify
some
a
doctor
specific
to
his
condition,
and
the
similar
thing
is
for,
let's
say,
regular
heartbeat.
We
want
to
notify
a
cardiologist
in
this
case.
On
the
right
hand,
side
you
guys
see
that
serious
workload
does
not
express
these
requirements
in
terms
of
code
like
if
else
statements
and
things
like
that,
neither
does
it
express
it
using
terminology
that
does
not
fit
its
domain.
B
Now,
in
order
to
start
utilizing
events
within
your
workflows,
you
first
have
to
define
them,
which
of
many
we're
interested
in
for
our
particular
use
case.
So
we
want
to
define
an
events
that
are
either
consumed
or
being
produced
and,
as
you
can
see
here
with
serverless
workflow,
we
have
a
direct
one-to-one
mapping
between
how
these
events
are
described,
using
the
cloud
event
specification
format
and
how
you
define
them
within
your
workload,
definitions
and
for
event
correlation.
B
Now,
once
we
define
an
event,
we
have
to
start
interacting
with
it.
So
what
can
events
do
within
workflows?
Events
can
start
workload
instances,
they
can
continue
existing
workload
systems,
they
can
be
like
we
said,
produced
or
consumed,
and
they
can
be
also
used
to
make
logical
decisions
in
the
right-hand
side.
We
see
a
very
simple
definition
which
just
says
before
we
end
the
workflow.
B
Similar
is
for
services
and
invocation
of
services.
We
want
to
define
the
operations
that
need
to
be
exit
on
these
services
that
need
to
be
executed
during
workflow
execution.
In
the
left
hand
side,
we
see
a
simple
open
api
definition
and
in
this
case
it's
just
a
part
of
it,
which
defines
one
particular
operation
get
inventory,
which
is
one
operation,
one
of
many
that
could
be
available
in
this
particular
service.
On
the
right
hand,
side
we
see
how
we
actually
defined
this
operation
and
the
service
it's.
B
Basically,
we
have
an
operation
parameter
which
contains
the
uri
or
the
path
to
the
definition
of
the
service,
the
open
api
definition
and
also
the
unique
identifier
or
the
operation
idea
of
the
operation
that
needs
to
be
invoked
during
workflow
execution.
So
you
don't
have
to
deal
with
things
like
authentication
and
putting
things
inside
of
your
workflow
definition.
B
There
is
not
really
related
to
it.
The
execution
of
your
workflow
model
that
is
very
specific
to
the
invocation.
We
actually
use
the
openmp
specification
for
that
as
well.
Now
we
understand
that
there
is
many
different
types
of
services
and
how
they
are
invoked.
So
with
serverless
workflow,
you
can
invoke
service
restful
types
of
services,
so
services
that
are
exposed
to
some
particular
endpoint,
but
you
can
also
invoke
event
triggered
services
or
services
that
are
triggered
by
some
particular
events.
B
The
last
part
of
defining
your
workflow
is
the
control
flow
logic.
So
here
we
define
the
states
and
the
order
in
which
these
states
are
executed
in
serverless.
Workflow
states
can
be
seen
like
a
little
black
box.
They
it
receives
input
either
some
data
or
an
input
event.
It
does
its
control
logic,
part
of
what
is
particularly
needs
to
be
done,
and
then
he
produces
some
sort
of
data
output
or
an
output
event.
As
the
result
of
the
execution
of
this
particular
part
of
the
control
flow
logic.
B
We
do
things
on
a
very
granular
level,
which
sometimes
becomes
ambiguous,
and
what
I
mean
by
that
is
it's
hard
to
figure
out
which
part
of
your
control
flow
fits
together
and
which
parts
of
your
control
flow
are
kind
of
like
a
unit.
They
perform
some
particular
piece
of
the
solution
of
your
business
problem.
So
in
the
bottom
we
see
that
we
have
decided
to
that.
Each
state
has
a
type,
and
the
type
really
describes
really.
The
control
flow
logic
that
this
particular
state
does.
B
B
Now
you
can
define
a
whole
bunch
of
different
control
flow
patterns
with
serverless
workload.
You
can
define
sequences
where
you
execute
one
piece
of
your
workflow
orchestration
after
another,
you
can
do
looping
structure,
sequential
parallel
execution
decisions
based
on
like
we
said
your
data
or
events,
things
like
that,
but
we
also
deal
with
a
little
bit
different
things
like,
for
example,
human
interaction
during
workflow
execution,
which
is
sometimes
might
be
very
important
in
different
use
cases.
B
Now,
let's
take
a
look
at
all
the
different
project,
components
of
serverless
workflows.
So
far,
we've
been
talking
about
this
middle
piece
or
the
language.
The
similar
workflow
language
is
defined
via
json
schema,
which
defines
all
the
rules,
and
things
like
that
on
how
you
actually
what
you
can
define
within
the
language
around
that
we
have
a
set
of
language
extensions.
B
So
these
extensions
do
not
influence
workflow
execution
or
the
control
flow
logic,
however,
enhance
it
in
order
for
runtime
systems
to
be
able
to
make
some
things
like
overall
performance
improvements.
In
terms
of
cost,
and
things
like
that,
in
addition
to
that,
serverless
workflow
also
provides
things
like
sdks.
We
have
them
in
java
and
go
currently
testing
kits
in
order
for
runtime
implementations
to
see
their
compliance
level
towards
the
specification,
and
we
also
have
a
set
of
plugins
for
ides
and
things.
B
So,
let's
take
a
quick
just
a
look
at,
for
example,
one
of
this
language
extension,
the
kpi
or
the
key
performance
indicators
is
extension.
This
allows
you
to
add
information
about
the
workflow,
which
are
the
expected
results
during
workflow
runtime
execution
and
comparing
with
the
actual
ones
that
you
gather
during
actual
workflow
run
times.
So
this
little
language
extension
can
help
us
improve
performance
of
your
workflows,
the
cost
effectiveness
in
cost
and
effectiveness.
B
Let's
take
a
look,
quick
look
at
the
java
sdk.
The
features
of
this
are
parsing
of
both
json
and
yaml
service
workflow
language
formats.
It
has
a
fluent
api,
so
you
can
basically
create
your
workflow
definitions
using
just
the
programming.
Language
includes
validation
against
the
specification,
and
it
also
allows
you
to
generate
diagrams
based
on
either
your
json
or
yaml,
or
your
object
model
represents
your
workflows,
and
the
last
thing
we
look
at
here
is
the
visual
studio
code
plugin
that
our
project
also
provides.
B
It
has
code
hints
and
code
snippets
they're,
based
again
on
the
on
the
serverless,
workflow
json
schema
or
the
language
definition.
It
again
provides
also
validation
for
both
json
and
yaml
files,
and
it
allows
you
to
visually
preview,
your
diagrams,
and
so
as
you're
modeling,
your
diagrams
in
visual
studio
code.
You
can
preview
them
at
the
same
time.
B
B
So
for
this
I
just
want
to
set
this
up
a
little
when
you
start
doing
using
workflows
to
orchestrate
things
really
you're
solving
business
problems.
So
what
you
have
to
do
is
you
have
to
first
understand
what
is
your
business
problem
and
then
you
want
to
see
what
kind
of
services
you
have
available
in
your
systems
that
you
can
utilize
in
using
some
sort
of
control
flow
logic
given
provided
to
you
by
the
workflow
solution
in
order
to
solve
your
business
problem.
B
B
Sorry
and
I'm
gonna-
have
the
application
running.
This
is
running
on
localhost
right
now
and
I'm
gonna
look
at
my
swagger
ui.
So
we
now
this
application
again
is
running
my
localhost
locally
for
the
sake
of
the
demo,
but
these
services
in
real
world
scenarios,
of
course,
would
be
deployed
on
a
container
platform
or
or
somewhere
distributed.
Basically,
but
here
we
see
that
we
have
two
services,
we
have
a
patient
service.
B
Of
course,
in
a
real
world
scenario,
we
would
have
a
much
bigger
set
of
services,
and
things
like
this
so
for
our
sake
of
the
demo,
is
just
two
so
to
look
back
at
our
business
problem
which,
on
boarding
a
patient
in
order
to
onboard
a
patient
for
our
demo.
We
want
to
first
invoke
the
patient
service,
and
then
we
want
to
invoke
the
scheduling
service
to
assign
a
doctor
to
this
particular
patient.
So
let's
kind
of
try
it
all
together
and
do
this.
B
And
after
I
close
like
50
million
windows,
like
usual
sorry,
now
this
is
my
application.
We
have
it's
a
little
java
application
that
runs
on
quercus.
You
can
really
use
any
particular
language
they
use
and
it
uses
a
java
runtime,
an
open
source
java
runtime
of
the
serverless
workflow
implementation.
B
So
we
have
two
resources
here
which
represent
our
two
services.
Now.
What
I
wanted
to
do
is
to
show
you
how
to
get
started.
The
first
thing
I'm
going
to
do
is
go
to
my
vs
code,
extensions
and
type
in
serverless
workflow,
and
I'm
going
to
download
this
extension
now.
This
is
the
extension
that
we
provide
from
our
serverless
workflow
project
that
we
talked
about
earlier
now.
B
We
want
to
go
and
create
a
new
file,
so
this
file
is
going
to
represent
our
workflow.
So
let's
call
it
on
boarding
and
in
this
case
we're
going
to
just
do
a
json
definition.
You
can
the
same
thing.
Do
yaml
so
one
of
the
things
that
once
you
downloaded
the
vs
code
extension
for
serverless
workflow,
you
get
code
hints
and
code
snippets.
B
So
in
this
case
I'm
going
to
give
my
workflow
a
unique
id
of
onboarding
make
sure
I
spell
that
right,
I'm
going
to
give
it
a
name
which,
let's
say
we
say,
new
patient
onboarding,
I'm
going
to
give
it
a
version,
let's
say
1.0,
and
at
this
point
I
want
to
start
defining
the
different
functions
that
need
to
be
executed
when
this
workflow
is
running.
So
what
I'm
going
to
do
is
I'm
going
to
define
a
functions
array.
This
is
real,
quick
and
I
want
to
start
defining
my
two
functions.
B
The
first
function,
I'm
going
to
give
a
logical
name
of
let's
say,
register
new
patient,
and
now
I
have
to
define
how
do
I
actually
invoke
this
function?
The
only
thing
I
have
to
do
is
create
an
operation
parameter,
which
then
points
to
my
open
api
definition,
which
I
have
here
and
we
can
take
a
look
at
it,
also
visually
in
vs
code,
which
is
kind
of
cool.
B
So
in
this
open
api
definition,
I
see
my
patient
service
and
the
post,
which
means
I
want
to
create
a
new
patient,
has
an
operation
id
of
add.
So,
let's
copy
that
go
back
to
our
workflow.
So
all
I
have
to
do
is
a
relative
path
to
slash
api,
slash,
open
api.json,
which
is
my
open
api
definition,
and
I
have
to
give
it
the
unique
operation
id.
B
So
I'm
just
going
to
copy
that,
and
now
we're
going
to
define
our
second
service
that
we
would
like
to
invoke,
and
it's
a
preparation
and,
let's
say,
assign
doctor
to
patient
and
it's
the
same
service,
open
api
definition.
But
here
we
go
down
to
schedule
and
we
see
that
the
one
we
want
to
call
is
has
a
unique
id
of
a
sign.
B
So
let's
go
do
this
and
that's
it
so
now
that
I've
done
I'm
done
with
my
service
definition.
So
I
want
to
start
creating
my
control
flow
logic.
So
for
this
we
have
an
array
called
states
and
my
I'm
going
to
create
a
new
state,
I'm
going
to
give
it
a
name
of,
let's
say,
let's
onboard
and
that's
it,
and
now
I
have
to
give
my
state
a
particular
type.
B
Now
the
extension
is
going
to
list
you
all
the
different
types
that
you
can
choose
here
depending
on
you
know
what
you
want
to
do,
the
one
we're
going
to
use.
It
is
a
simple
operation
state,
it's
a
state
that
runs
one
or
many
operations
in
this
case
invocations
of
our
services,
either
sequentially
or
parallel.
So
I'm
just
going
to
give
it
a
type.
B
Now
I
don't,
I
have
to
say
that
this
is
the
first
state
that
gets
invoked
when
my
workflow
instances
is
created,
so
I
have
a
little
star
definition
with
a
kind
there's
different
ways
to
start
the
workflow.
So
in
this
case
we're
just
going
to
go
ahead
and
start
it
without
any
extra
information,
and
I
want
to
say
my
action
mode
here.
I
want
to
execute
these
two
services
sequentially,
because
we
first
have
to
onboard
a
patient
before
we
assign
a
doctor
to
it.
B
Otherwise
there
could
be
some
cases
where
you
want
to
execute
in
a
parallel,
and
now
I'm
just
going
to
define
what
actions
do
I
want
to
use,
and
the
first
action
I'm
going
to
use
is
to
invoke
my
my
registered
new
patient
service.
So
for
this
I
don't
have
to
redefine
my
services
here.
I
just
reference
them
by
their
logical
name,
and
after
this
I
want
to
call
my
assigned
doctor
service.
B
Now
I
have
to
tell
the
workflow
that,
after
the
execution
of
this
particular
state,
I
want
to
finish
workflow
execution,
so
I
also
have
to
give
it
an
end
definition
and
again,
there's
different
ways
of
ending
workflows,
for
example,
sending
an
event
killing
the
entire
all
the
processes
running
things
like
that,
but
we
just
want
to
simply
end
it
this
this
case,
and
I
have
some
oh
yeah
yeah
me
and
jason
get
along
this
way,
so
you
see
just
with
30
lines
of
code
in
yaml.
That
would
be
probably
about
20.
B
B
While
we
wait
all
right.
So
that's
done
now.
One
thing
I
wanted
to
show
you
guys
is
that
workflows
are
not
some
weird
thing
that
you
have
to
use
a
special
way
of
invoking
or
it's
different
than,
for
example,
how
you
define
your
services.
Workflows
are
really
the
same,
and
here
we've
seen
the
definition
of
our
two
services
that
were
running
on
our
system
before
we
created
the
service
workflow.
Now,
if
I
refresh
this
page,
you
will
see
an
onboarding
service
and
what
is
this
well,
that
is
the
workflow
we
have
just
defined.
B
We
have
basically
taken
our
workflow
definition
and
it
self
deployed
it
as
a
service,
and
that
has
the
advantage
now,
not
only
it's
a
restful
service
that
we
can
call
this
endpoint
version
1.0,
which
is
the
version
of
the
workflow
that
they
find
and
onboarding,
which
was
the
unique
id
that
identified
by
that
we
put
in
our
workflow.
We
can
actually
interact
with
the
service
orchestration,
just
like
another
servers
that
we
have
defined
pretty
much
anywhere,
so
that
this
is
really
kind
of
what
wanted
to
do.
B
We
have
a
local
host
here.
I
created
a
simple
page,
and
this
first
form
allows
us
to
enter
some
information
about
a
new
patient
and
when
we
click
on
board
and
to
show
you
guys,
I'm
not
making
this
up,
we
have
a
little
post,
http
post
to
our
endpoint,
which
actually
will
trigger
a
new
workflow
instance
execution,
and
then
on
the
bottom.
We
will
see
the
results
of
the
workflow
orchestration,
which
should
be
a
patient
and
also
the
doctor
assigned
to
the
patient,
given
the
patient's
condition.
B
So
I
just
give
it
simple:
some
name
john,
and
this
guy
has
unfortunately
a
bladder
infection
and,
as
we
see
when
we
clicked
on
board
our
serverless
workflow
was
executed,
it
contacted
the
patient
services
stored,
the
particular
patient.
We
contacted
our
scheduling
services,
we
have
defined
and
assigned
dr
elizabeth
to
this
particular
patient.
So
that
kind
of
really
guys
shows
you
how
easy
it
is
to
get
started
these
days
with
workflows
and
also
how
it
is,
is
to
get
started
also
with
the
serverless
workflow
specification,
and
that's
all
I
have
for
the
demo.
B
All
right
so
well,
thank
you
guys
very
much.
I
hope
you
enjoyed
our
talk
for
more
information.
Of
course,
cloud
events,
great
specification,
you
cloud
events
that
I
o
for
serverless
work.
Well,
we
have
several
serverless
workflow
that
I
owe
we
hope
to
see
you
guys
in
the
community
and
if
you
need
more
help
here
is
the
context
for
doug
and
myself.
Thank
you
guys
very
much.
Thank
you.
Everybody.