►
From YouTube: CNCF Serverless WG - Serverless Workflow Project Deep Dive - Tihomir Surdilovic & Doug Davis
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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 - Serverless Workflow Project Deep Dive - Tihomir Surdilovic, Red Hat & Doug Davis, IBM
The Serverless WG will provide a short update on the CloudEvents project and then give an in-depth update on the current state and planned future work of the Serverless Workflow project. In this session we will explain the benefits of using workflows in your application architectures. You will learn the ins and outs of the Serverless Workflow project and its ecosystem, its tight integration with the CloudEvents specification for event-orchestration, as well as its design and deployment strategies on cloud/container platforms. In addition we will show examples and explain some of the more advanced workflow language concepts such as error handling, retries, compensation, event-correlation, and long-running workflows.
A
All
right,
hi
everybody
and
welcome
to
the
serverless
working
group
update
tmr,
and
I
are
going
to
be
talking
about
two
different
projects
today
cloud
events
as
well
as
the
workflow
specification.
So
seymour
can
you
go
ahead
and
share
your
screens.
I
think
we're
going
to
vanish
now,
all
right,
let's
go
and
start
the
presentation,
and
here
we
go
so
I'm
going
to
be
up
first,
so
let's
go
to
the
next
slide.
A
So
just
a
quick
recap:
we
delivered
the
latest
version
of
the
spec,
which
is
version
101
back
in
december
of
last
year,
same
deliverables
as
before,
and
I'm
not
going
to
go
into
what
the
spec
is.
I'm
assuming
everybody
understands
what
that
is,
or
you
can
go
find
it.
This
isn't
that
kind
of
call
we're
going
to
go
into
deep
dive,
but
just
so
you
understand
what
the
deliverables
were.
A
It
was
obviously
the
specification
itself,
the
transport
bindings,
the
encoding
formats,
a
primer,
to
give
you
guidance
on
why
we
did
what
we
did,
how
to
use
the
spec
stuff
like
that
and
a
whole
bunch
of
sdks
to
help
you
get
started
with
cloud
events.
Okay,
now
in
terms
of
what's
coming
up
next
for
the
cloud
events,
deck
itself.
To
be
honest,
not
a
whole
lot,
we
are
doing
some
minor
bug
fixes
that
people
find,
but
for
the
most
part,
we're
finding.
A
The
spec
is
pretty
much
okay
and
we're
just
waiting
for
more
community
feedback
to
see.
If
there
are
things
we
need
to
work
on
in
the
future,
but
we're
not
just
toiling
our
our
fingers,
we're
actually
looking
at
the
next
set
of
pain
points
and,
as
you
can
see
here,
we're
going
to
start
looking
at
what
we
call
sort
of
the
life
cycle
of
event,
delivery
and
from
from
beginning
to
end.
A
Okay,
now
crown
events
helps
you
deliver
the
event
from
the
producer
to
the
to
the
consumer
itself,
but
in
order
for
that
to
actually
get
started,
what
has
to
happen
is
the
consumer
first
has
to
discover
what
event
producers
are
out
there
and
what
the
events
are,
that
they
actually
do
produce
okay.
So
what
we're
going
to
be
doing
is
working
on
a
discovery,
api
spec
and
that's
going
to
allow
producers
to
advertise
that
they're
out
there
and
what
the
events
are
that
that
people
can't
subscribe
to
so
a
consumer
will
then
hit
a
discovery.
A
A
Okay
after
that,
then
comes
the
actual
subscription
itself
now,
if
the
protocol
that
they
chose
does
not
actually
have
a
native
subscription
type
mechanism
built
into
it
like,
for
example,
http
does
not.
We
will
then
this
as
part
of
the
subscription
api
spec
to
find
how
the
subscription
should
happen
right.
So,
for
example,
http
will
define
the
rest
operation
to
do
the
subscribe.
A
Okay
and
inside
there
you're
going
to
specify
all
the
things
you
might
expect
right
which
events
you
want
to
get
if
there's
filtering,
how
to
specify
the
filters,
how
you
specify
where
to
deliver
the
events
to
the
format
of
the
messages
stuff
like
that,
as
well
as
some
apis
to
actually
manage
the
subscription
right?
How
do
you
make
updates
to
it?
If
you
can?
A
How
do
you
delete
the
subscription
very
obvious
types
things
and
then,
of
course,
at
the
end
of
the
life
cycle,
you
then
have
the
cloud
event
spec
itself,
which
is
going
to
be
used
to
annotate
your
events
to
figure
out
or
how
to
do
proper
routing
of
the
event
to
the
proper
destination
right.
The
extra
metadata,
that's
part
of
the
cloud
effects
spec.
So
that's
what
we're
going
to
be
looking
at
next
in
terms
of
life
cycle
specifications
to
complete
the
to
complete
the
complete
picture
around
event,
delivery
right.
So
one
last
little
speck.
A
I
want
to
talk
about
on
the
next
slide
and
that's
the
skimmer
registry
spec
as
one
of
the
little
bits
of
metadata
inside
the
cloud
event.
Spec
is
a
a
url
to
the
schema
of
the
event.
That's
being
transported
and
people
can
host
that
pretty
much
wherever
they
want.
But
we
realized
that
there
really
wasn't
a
standardization
effort
around
the
apis
of
the
schema
registry
itself,
meaning
how
can
producers
talk
to
more
than
one
schema
registry
to
actually
upload
their
schema
and
manage
those
schemas
right
version
them
and
stuff
like
that?
A
So
we
thought
okay,
let's
see
if
we
can
do
some
help
there,
so
we're
defining
a
set
of
apis
mainly
for
producers
to
figure
out
how
to
talk
to
the
schemer
registry
is
to
upload
their
schema
itself.
Okay,
very
simple,
little
crud
type,
apis,
nothing
earth
shattering
there,
but
it
will
have
automatic
versioning
in
there
so
that
you
don't
have
to
worry
about.
You
know:
versioning
numbers
of
the
urls
to
access
the
different
versions
of
the
schema
itself
will
help
you
a
little
bit
there.
A
A
Consumers
can
then
access
the
schema
registry
to
use
the
schema
to
then
figure
out
the
validation
make
sure
they
understand
how
to
parse
the
schema
or
deserialize.
I'm
sorry
not
participating
deserialize
the
event
into
the
right
format
and
stuff,
like
that.
The
same
thing
you'd
expect
even
without
the
schema
registry
there,
but
the
schema
registry
helps
get
the
interop
around
publishing
and
sharing
of
the
schemas
themselves
and
that's
the
last
bit
of
new
things
that
we're
working
on
okay.
So
that's
pretty
much
it
for
the
cloud
event
side
of
the
serverless
working
work
group.
B
We
typically
categorize
workflow
languages
in
different
buckets,
going
from
flowchart
based
workflow
languages,
form
based
or
code
base,
where
the
actual
workflow
language
is
the
underlying
programming
language
of
choice,
surveillance
workflow
falls
into
the
clarity,
workflow
language
character,
so
with
serverless
workflow
being
declarative,
we
focus
on
what
to
do
and
not
how
so
the
language
itself
is
dependent
on
time,
implementations
to
interpret
the
what
and
actually
execute
the
instructions
that
we
put
in
our
workflow
definitions
with
serverless
workflow.
You
can
define
workflows
using
json
or
yaml,
and
the
language
itself
is
completely
defined.
B
Now
we
have
to
look
many
different.
Workflow
languages
exist
out
there
and
we
have
to
look
typically
at
the
target
domains
of
the
workflow
language
to
pick
which
one
we
want
to
choose
for
serverless
workflow.
We
of
course
focus
on
the
business
domain,
meaning
that
you
can
express
your
workflow
definitions
with
terms
and
and
knowledge
that
you
gave
have
in
your
business
domain
but
at
the
same
time,
serious
workflow
targets
the
serverless
technology
domain,
meaning
we
can
also
express
things
like
functions.
B
Now,
one
advantage
of
serverless
workplace
that
is
completely
agnostic,
meaning
as
we
as
we
mentioned
earlier.
The
workflow
definitions
or
the
the
json
or
yaml
that
you
write
to
express
your
workflow
logic
is
not
programming
language
dependent.
At
the
same
time,
the
workflow
data
that
is
being
executed
and
that
you
can
update
and
and
work
with
during
workflow
execution
is
also
expressed
in
json
format
and
as
such,
serverless
workflow
is
a
domain
specific
declarative
language,
language
which
can
be
executed
on
many
different
runtimes
in
different
programming
languages.
B
B
So
this
there
are,
of
course,
a
lot
more
features
that
exist,
but
these
are
kind
of
like
the
cultures
that
we
looked
at.
What
we
look
at
when
we
think
about
orchestrating
microservices
as
events
so
serverless
workflow,
currently
is
somewhat
of
a
superset
of
the
other
declarative,
being
step,
functions
and
and
cloud
workflow,
but
is
a
subset
of
bpmn2.
B
But
again
it
focuses
on
the
feature
set
specific
to
its
target
domains
being
a
orchestration
of
of
of
microservices.
As
events
now,
one
thing
about
serverless
workflow
that
we
really
try
to
do
is
we
try
to
focus
on
standards,
and
you
can
see
here
some
of
the
standards
and
technology-wise
that
we're
we're
really
enforcing
within
our
workflows
and,
of
course,
one
being
cloud
events
now.
B
In
terms
of
longevity
and
things
like
open
source
and
specification
things
and
and
and
kind
of
enforces
that
side
as
well
now
and
besides
the
just
of
being
agnostic
and
and
things
like
that,
with
serverless
workflow,
we
also
took
a
look
at
the
logical
structuring
of
the
workflow
definition
itself.
The
workflow
definition
is
composed
of
three
parts.
B
The
first
one
is
your
control
flow
logic
block
which
includes
the
language
structure
such
as
synth,
async,
invocations,
looping,
branching,
parallel
execution,
the
typical
stuff
that
you
think
of
when
you
think
of
workflow
language
and
using
workflows
in
general.
But
at
the
same
time
we
also
have
event
definitions
and
event.
Definitions
are
completely
reusable
pieces,
so
you
can
define
your
events
that
are
supposed
to
be
consumed
or
produced
by
the
workflow,
either
with
inside
your
workflow
definition,
or
you
can
completely
expose
it
as
a
service
or
or
write
it
somewhere
else.
B
So
multiple
workflows
can
actually
access
them
and
reuse.
Those
definitions
we
for
enforce
cloud
event,
specification
here,
of
course,
but
the
source
or
the
actual
producers
of
those
events
could
be
many
different
things.
In
the
end.
The
third
part
of
the
workflow
definition
is
function,
definitions
and
those
again
just
like
event.
Definitions
are
completely
reusable
between
workflows.
They
can
be
defined
inline
as
well,
we'll
see
in
the
demo
later
or
you
can
expose
them
as
a
separate
file
and
and
treat
them
and
or
allow
them
to
be
used
by
multiple
workflows
definitions.
B
If,
if
you
wish
the
function,
definitions
define
some
invocation
of
a
service
or
some
invocation
of
a
particular
expression,
so
through
function
definition,
you
can
easily
utilize
things
like
open
api
grpc
or
you
can
even
define
a
container
that
you
have.
You
want
to
actually
execute
an
image
or
something
during
workflow
execution.
B
The
service
work
also
defines
the
motherboard
ecosystem.
So
not
only
do
we
define
the
core
language
and
the
structure
of
the
language
if
you
have
documentation
and
things
like
that,
that
describes
every
little
piece
of
of
of
the
workflow
language
that
you
can
use.
We
also
include
things
like
a
vs
code
extension
that
helps
kind
of
developers
include
set
of
sdks,
which
currently
they
they're
there
to
parse
workflow
definitions,
validate
them,
and
things
like
that.
We
currently
have
them
in
go
in
java.
B
Now,
even
though
serious
workflow
is
fairly
new,
we
have
received
a
lot
of
interest
from
different
people,
different
people
from
the
community,
and
we
currently
have
a
small
but
very
healthy
community.
We
have
a
couple
of
partner
projects,
as
you
can
see
here
within
cncf,
and
it's
very
important
to
us
to
grow
those
relationships
and
integrations
with
them.
B
We
do
have
currently
open
source
collaborations
with
multiple
companies,
as
you
can
see,
and
they're
already
a
couple
of
well
java
based
right
now,
open
source,
implementations
of
the
service,
workflow
specification
and
more
are
coming
in
the
future
in
different
languages.
Like
I
said
currently,
we
only
have
the
java
guys
are
predominant
in
this
basis.
B
Currently,
now,
as
far
as
the
project
release
roadmap,
we
currently
have
released
just
this
month,
version
0.6,
we're
planning
0.7
release
this
summer,
and
once
we
do
that,
hopefully
we
can
start
targeting
version
1.0
the
specification
at
least
the
release
candidate
won
by
november
of
this
year.
That's
currently
our
plan,
and
it
highly
also,
of
course,
depends
on
the
community
effort
and
and
contributions
as
well.
B
B
B
Service,
oh
and
actually
let
me
pipe
it
through
jq,
so
we
get
a
pretty
output
and
you
can
see
our
node.js
service
just
gives
us
a
little
piece
of
json
saying,
invoked
node.js
function
and
that's
it.
Our
second
service
that
we
want
to
run
is
a
go
service
and
we
have
a
handle.
That
goes
so
we're
just
going
to
get
this
started,
and
this
service
is
going
to
run
on
8081.,
oops,
sorry
and
let's
test
it.
If
it's
up
and
running,
we
can
issue
a
post
to
it
and
you
can
see
it
also
returns.
B
B
Which
currently,
this
is
running
on
quercus,
but
you
can
run
this
on
spring
boot
or
any
of
the
java
runtimes
or
environments
that
you
want
to
run
it
and
let's
see
this
has
already
started,
and
our
java
service
runs
on
port
82
and
it
has
a
little
end
point
of
greed.
I
think-
and
here
we
see,
we
have
invoked
it
via
curl
and
it
says
java
function
invoked
or
java
functions
now.
The
idea
behind
this
is
to
really
show
you
that
you
want.
B
We
want
to
with
serverless
workflow
orchestrate
microservices,
and
here
we
have
three
different
functions:
they're
written
in
three
different
languages.
They
can
be
really
deployed
anywhere.
You
want
or
live
where
you
know
not
a
localhost
of
course,
and
now
our
assignment
is
to
orchestrate
it
in
some
way
and
for
that
we
can
start
using
our
serverless
workflow.
So
for
this
we're
going
to
use
the
redhead
cogito
current
open
source
implementation
for
this
they're
like
we
saw
others,
but
let's
go
ahead
and
look
at
the
little
project.
I've
created
here.
B
Now
this
is
a
very
simple
java,
maven
project
and,
as
you
can
see,
there
is
no
java
sources.
There
is
no
particular
java
based
objects,
a
lot
of
runtimes
that
you
see
out
there,
especially
workflow
runtimes
kind
of
forces
you
to
use
a
particular
programming
language,
especially
for
the
data
model,
serverless
workflow
using
json.
So,
even
though
this
is
a
java
project
being
a
java
runtime,
the
way
we
express
orchestration
is
completely
agnostic
to
any
programming
language
itself
and
another
thing
that
we
see
here,
I
don't
have
a
workflow,
yet
we
will
define
it
together.
B
However,
one
thing
I've
defined
is
little
open,
api
definitions
and
if
you
see
here
we
can
see
in
our
vs
code,
we
can
generate
a
little
open
api
and
you
can
see
our
our
in
this
case
our
go
service
which
was
just
invoked
during
curl.
It
has
one
end
point
and
just
slash,
and
we
can
invoke
that
as
well.
The
same
thing
we
have
defined
here
is
for
java
service
and
our
node
service
that
we
currently
invoke.
B
So
when
I
write
my
workflows
or
when
you
write
your
workflows,
you
don't
have
to
know
much
about
where
this
service
is.
If
it
needs
a
certain
authentication,
you
don't
have
to
define
it
inside
your
workflow
definition.
You
use
open
api,
which
is
a
standard
for
that,
and
you
let
the
runtime
engines
figure
out
how
to
actually
invoke
those
services
during
workflow
execution.
The
way
you
define
them
with
a
standard
definition
rather
than
something
proprietary
or
custom.
B
So
now
what
we
have
left
to
do
is
really
start
writing
our
workflow.
So
for
this
I'm
going
to
create
a
new
file,
and
it's
going
to
be-
let's
say
my
workflow
and
like
we
said
we
can
define
them
in
json
or
yaml
in
this
case,
let's
go
ahead
and
define
it
in
jason,
and
now
before
I
get
started,
I
want
to
just
show
real
quick
with
insert
vs
code.
B
I
have
the
serverless
workflow
plugin
installed
already,
but
it
if
you
work
with
vs
code,
and
so
it
makes
a
lot
of
sense
to
to
to
install
this
little
extension
as
well.
The
reason
for
that
it
gives
you
things
like
code,
completions
and
code
hints,
and
things
like
that
to
allow
you
to
easier
define
your
workflow
using
the
serverless
workflow
link.
So
let's
go
ahead,
our
id
of
the
workflow,
it's
a
unique
identifier
or
let's
call
it
just
simple,
workflow
and
we'll
see
what
why
this
is
important
to
define
the
id
later.
B
B
So
far,
so
good
right,
so
now
we
have
to
tell
the
runtime
engine
through
a
workflow
definition.
Well,
okay,
when
you
start
this
workflow,
where
do
you
actually
start
and
let's
call
our
starting
point
again,
let's
say
start
or
orchestration.
So
this
is
some
starting
point.
You
know,
and
the
next
thing
we
want
to
do
is
actually
do
the.
What
part
of
the
workflow
we
just
define
the
control
for
logic,
for
this
serious
workflow
gives
you
an
array
called
states.
B
Each
state
is
a
single
building
block
that
you
define
the
that
defines
how
the
control
flow
logic
should,
what
what
actually
the
workflow
should
do.
So,
in
our
case,
let's
define
a
state
and
we
have
a
name
which
kind
of
has
to
match
here
so
start
matching.
This
state
means
that
this
particular
workflow
state
is
going
to
be
the
first
one
executed
when
this
workflow
execution
happens
now
another
thing
with
serverless
workflow
that
you
have.
B
We
have
different
types
of
states,
and
currently
we
have
nine
of
them
so
for
the
one
that
we
want
to
use,
which
is
basically
just
invoking
functions
or
microservices.
We
have
this
thing
called
an
operation
state
and
an
operation
state
has
actions,
actions
actually
define
invocations
of
some
services
that
you
want
to
invoke.
So
in
our
case,
let's
give
our
first
action
a
name
and,
let's
call
it
invoke,
go
function
and
we
can
give
it
a
function.
Ref
and
our
function,
ref.
B
Yeah
and
basically,
to
tell
a
runtime
once
this
state
is
executed
or
three
functions
are
invoked.
We
want
to
end
workflow
execution
and,
as
you
can
see
so
far,
this
is
all
domain
specific.
We
didn't
use
any
programming
language,
we
didn't
use
any
weird
ways
or
proprietary
ways.
We
basically
once
you,
this
is
human
readable
and
once
when
you
read
you
can
actually
figure
out
what's,
and
you
can
of
course
use
your
domain
specific
language
to
define
everything
within
workflow
execution.
B
Now
that
we
have
defined
our
state,
we
do
have
to
tell
the
runtime
a
little
bit
more
about
the
functions
that
we
want
to
actually
invoke.
So
for
that
service
workflow
gives
you
a
little
functions
array,
and
now
the
name
of
our
function.
Definition.
Let's
we
have
it
references
the
function,
ref
parameter.
So
let's
call
this
a
go
function
and
our
operation.
B
At
this
point,
a
lot
of
workflow
languages
give
you
some
custom
parameters,
proprietary
things,
a
set
of
things
that
you
can
do
with
serverless
workflow.
You
basically
use
open
api.
So
for
us
this
means
that
we
want
to
actually
reference
our
api
definition
for
a
go
service.
So
we
say:
go
service.json
and
within
the
go
service
json
we
want
to
use
its
unique
operation
id
for
the
type
of
service
that
we
want
to
go
use,
and
this
operation
id
here
is
called
go.
B
So
this
is
it
with
this.
We
have
told
the
runtime
to
use
the
open,
ipi
definition
to
learn
how
to
invoke
this
service
and
when
it
evokes
it,
it
should
use
this
particular
unique
operation
id
telling
it
exactly
what
to
invoke
during
workflow
execution
now
same
thing.
We
want
to
use
again
three
times
so
for
this.
We
want
to
reference
this
one
and
we
have
node
service.json
here
and
the
unique
operation
id
is
node.
B
B
And
this
is
it:
this
is
our
workflow.
That's
going
to
first
invoke
our
go
function,
then
our
node.js
function
and
then
our
java
function
now
one
of
the
things
that's
also
important
here.
If
you
look
at
our,
for
example,
node
service,
we
have
for
this
particular
path
or
service,
but
to
invoke
we
use
get
now.
You
can
change
this
to
post
without
ever
affecting
your
workflow
definition.
C
B
Little
workflow
application,
so
what
this
particular
runtime
is
going
to
do.
This
java
runtime
is
going
to
read
our
workflow
definition
and
our
openid
definition
is
going
to
start
generating
things
for
us.
The
first
thing
that
is
going
to
generate
is
the
actual
code
to
invoke
the
open
api
stuff.
That's
using
the
open
api
as
the
case
in
different
languages.
B
Then
it's
going
to
actually
parse
our
workflow
definition
and
generate
some
particular
code
that
actually
is
going
to
expose
our
workflow
as
a
service,
and
the
particular
endpoint
of
the
service
that
is
going
to
expose
for
us
is
determined
by
the
id
parameter.
So,
for
example,
the
service
that
we
have
right
now
running-
and
this
is
running
and
just
to
show
you
in
port
8083,
just
to
be
different
from
the
other
ones.
It's
going
to
be
a
localhost
8083
and,
in
this
case
slash
simple
work
all
right.
B
Cubecon
eu2021,
so
I
don't
have
to
mess
it
up
there.
It
is,
and
I
might
have
to
change
it
a
little
bit
depending
on
our
definition.
So
let's
go
ahead
and
paste
this
now,
let's
see
our
endpoint
if
it
is
still
true,
this
is
slash
simple,
but
for
us,
our
id
simple
workflow.
So
let's
change
that
around
all
right.
So
when
I
do
this,
we're
going
to
should
be
getting
an
instance
of
a
workflow.
Our
workflow
is
going
to
execute
our
little
three
functions
in
this
particular
order.
B
So
let's
go
ahead
and
do
that,
and
here
is
our
output,
which
is
the
output
of
the
workflow
its
results
and
includes
the
three
outputs
of
our
services.
So
the
results
of
each
of
the
service
invocation
gets
merged
with
these
workflow
state
data
and
the
final
after
the
three
results
are
merged
into
the
state
data.
The
workflow
produces
this
particular
result,
so
that's
it
for
the
little
demo.
I
hope
it
really
helps.
B
B
All
right,
so,
thank
you
all
for
joining
our
talk
and
and
being
here
doug,
and
I
would
really
like
to
thank
you,
and
here
you
can
find
some
more
information
about
both
cloud
events
and
serverless
workflow
and
for
cloud
events.
Specifically,
they
have
cloud
event
says
weekly
calls
thursdays,
as
at
12
p.m.
Eastern
time
and
you
can
find
all
the
information
you
need
to
join
those
calls
on
the
servers,
workflow
github
repository,
I
mean
cloud
events,
sorry
same
thing
for
serverless
workflow.