►
From YouTube: Message-driven microservices orchestration - T. Surdilovic, T. Technologies & C d'Avernas, Neuroglia
Description
AsyncAPI Conference 2021 - Day 3
18th November 2021
CNCF Serverless Workflow is a vendor-neutral and open-source workflow ecosystem. The project hosts the core specification defining a domain-specific workflow language, as well as a set of developer tools and runtimes supporting the specification. Serverless Workflow is standards-based and provides support for AsyncApi which plays a big role in defining message-driven orchestrations of third-party microservices. In this talk we will give an introduction to the Serverless Workflow project. We will also describe and demo how AsyncApi is integrated with the spec and showcase how AsyncApi plays a big role and solves important problems in workflow orchestrations.
A
A
The
dsl
itself
can
be
represented
as
markup,
so
both
in
json
and
yaml,
and
the
idea
is,
is
that
as
a
specification,
we
define
all
the
rules
of
the
dsl
as
a
json
schema,
so
it
can
be
validated
and
things
like
that.
We
also
write
tons
of
documentation
about
every
single
piece
of
functionality
of
the
domain-specific
language
and
we
also
provide
you
know
different
a
lot
of
different
examples.
A
A
So
every
dsl
out
there
has
to
kind
of
you
know,
conform
to
some
sort
of
technology
or
fit
in
some
sort
of
technology
domain
and
for
serverless
workflow.
We
we,
we
are
in
the
serverless
tech
domain,
meaning
that
we
really
focus
on
things
like
defining
events
and
also
function
invocation.
So
for
events,
we
use
the
cloud
event
specification
and
what
you
can
do
in
the
dsl
is
define
things
like
how
you
want
to
consume
events,
how
you
want
to
do
event,
correlation
produce
events.
A
Basically,
we
use
standards,
so
we
use
things
like
async
api,
open
api
graphql
and
things
like
that
and
and
really
kind
of
focus
on
using
the
standards,
rather
than
providing
some
sort
of
proprietary
ways
of
invoking
services
and
functions,
which
is
kind
of
typically
the
case
in
most
of
the
dsls
that
you
roll
can
around
there.
So
as
far
as
function
invocation
with
the
serverless
workflow
dsl,
you
can
define
things
like
invoking,
of
course,
third-party
function,
sync
or
async,
defining
retries
in
case
of
some
sort
of
failures.
A
A
The
dsl
itself
provides
very
powerful
control
for
logic,
so
it
has
some
sort
of
core
features
which
are
kind
of
you
know.
People
are
used
to
having
those
are
pretty.
Much
must
have
type
of
control
flow
logic.
That's
that's
present
in
any
sort
of
dsl
or
useful.
Dsl
such
as
you
know,
defining
a
sequence
of
executions,
so
you
can
define
your
pipelines
and
stuff
like
that
decision,
making
which
can
be
either
data-based
or
event-based.
A
Things
like
that.
You
can
define
looping
structures,
retries
human
decisions
as
well
with
a
dsl.
You
can
define
parallel
and
sequential
executions
and
of
course
it
has
very
powerful
error
handling
features
as
well.
On
top
of
that,
serverless
workflow
also
provides
a
number
of
enhanced
features
so,
for
example,
automatic
retries.
You
can
define
that
you
know
your
function
invocation
in
case
of
errors.
A
We
have
a
very
pluggable
expression,
language,
every
dsl
out
there
that
you
know
they
has
to
have
some
sort
of
expression
language
in
order
to
make
it
fully,
you
know
executable,
and
we
allow
that
to
be
pluggable.
So
by
default
we
use
you
know
jq,
but
you
can
really
plug
in.
As
you
will
see
in
the
demo,
we
we
we
I'm
going
to
plug
in
jsonpath,
for
example,
and
use
that
as
well.
A
The
dsl
itself
supports
defining
both
short
and
long
running
workflows,
and
we
have
other
features,
for
example,
continue
as
feature
which
allows
you
to
continue
your
workflow
execution
at
some
point,
as
you
know,
as
a
new
execution
or
a
new,
completely
different
type
of
workflow.
That
needs
to
continue
at
some
point
in
time.
A
Compensation
we
provide
custom
function
types.
So
if,
if,
for
example,
even
if
you
don't
want
to
use
some
of
the
standards
as
we
defined
and
some
sort
of
custom
invocation
of
of
some
sort
of
services,
you
can
define
it
as
well
things
like
cron
execution,
sleeps,
resource
authentication
and
a
lot
more.
So
the
you
know
check
out
the
the
documentation
and-
and
you
can
really
see
in
any
our
examples,
showcase
all
these
features
as
well.
A
On
top
of
the
bsl,
we
also
provide
some
custom
extensions,
so
these
are
some
sort
of
extensions
that
you
can
enhance
and
and
and
use
to
enhance
the
workflow
definitions.
So
today
we
provide
out
the
box
our
key
performance
indicators
extension.
So
you
can,
you
know,
use
it
to
to
define
you
know
and
measure
your
improvements
of
workflow
as
far
as
performance
and
cost
and
all
kinds
of
different
things
like
that.
A
Another
extension
that
we
provide
is
rate
limiting,
so
you
can
actually
define,
on
top
of
you
know
the
workflow
definition,
which
invokes
some
services,
whether
that
be
synchronous
or
unsynchronous,
or
whichever
way
you
you
define
them,
you
can
rate
define
rate
limiting,
for
example,
function,
invocation
concurrent
functioning
locations
for
some
sort
of
time,
and
things
like
that.
As
far
as
the
user
of
our
project
goes
or
or
dsl,
you
can
define
your
custom
extensions
as
well,
so
this
is
not
just
limited
to
to
do
what
we
provide
it's
very,
very
pluggable.
A
A
So
we
provide
a
set
of
sdks
we're
currently
having
ingo
java.net
and
typescript,
and
these
sdks
can
help
you
whether
you're
you
know
just
like
a
developer
or
or
you're
building
a
runtime
for
for
our
dsl
provides
things
like
parsing
validation,
both
schema
and
object,
type
of
validation
that
can
be
also
extended
to
to
fit
your
needs.
We
provide
a
set
of
utility
methods,
especially
if
you're
developing
runtimes
there's
a
large
set
of
utility
methods
that
will
really
help
you
to
deal
with
with
not
having
to
deal
with
writing.
A
You
know
custom
parsing
logic
or
some
sort
of
things
like
that,
and
we
also
provide
diagram
generation.
So
even
though
our
dsl
is
not
flowchart,
based
or
or
you
know
graphical,
so
it
is
defined
again
with
json
or
yaml
markups.
We
do
provide
a
visualization
of
of
of
your
workflow
definitions
that
you
define
in
our
dsl.
In
addition
to
that,
we
also
host
some
project,
some
runtimes
in
our
projects,
so
we
are
open
to
hosting.
A
You
know
if
you
have
a
runtime
that
implements
the
service
workflow
specification
and
would
like
to
make
it
part
of
our
project.
You
can
contribute
that
and
we
currently
have
synapse
and
charles
has
contributed
that
to
our
specification,
which
is
a
kubernetes
native
runtime.
Now,
of
course,
we
support
all
the
all
the
different
runtimes
equally,
whether
that
be
you
know,
you
host
it
yourself
somewhere
in
your
companies
or
or
want
to
contribute
to
a
project.
A
So
that's
equal,
but
there
is,
you
know,
just
an
opportunity
if,
if
you're
willing
to
we're
more
than
happy
to
to
to
work
with
you
on
hosting
and
helping
you
with
growing
your
your
runtime
within
our
project
as
well,
so
in
addition
to
that,
we
also
provide
a
web
tooling
support.
Basically,
we
will
look
at
this
is
the
demo.
A
The
most
important
thing
about
our
project
is,
of
course,
the
community.
Like
I
said
we
are
part
of
cncf
and
also
the
linux
foundation.
We
have
been
a
project,
for
you
know
sandbox
for
about
a
year,
and
this
project
has
been
around
for
for
longer
than
that,
and
the
most
important
thing
is
our
community.
A
So
as
far
as
adoption
goes,
it's
kind
of
important
you
know
to
know
for
every
project.
We
do
have
some
partner
projects
within
cncf
that
that
we're
collaborating
with
cloud
events,
async
api,
of
course-
and
things
like
tremor
and
argo
as
well,
and
we
also
have
some
open
source
code
collaborations
with
different
companies
they're
interested
in
using
our
specification.
A
The
list
is
much
bigger
than
that,
but
this
is
what
currently
we
can
show
right
now.
So
as
far
as
different
implementations
goes
here,
some
of
course
you
know,
implementations
that
that
that
are
have
publicly
exposed
or
allowed
us
to
to
show.
But
there
is
many
more
that
are
currently
in
the
works,
so
hopefully,
by
next
year
we
will
see
this
list
grow
a
lot
more.
A
So,
as
far
as
any
sort
of
open
source
project
that
you
encounter,
you
might
want
to
know
some
sort
of
you
know
stats
about
it
before
you
pick
it
up.
So
this
is
kind
of
like
just
a
short
list
of
of
things
that
we
have
done
over
the
last
year
and
we
have
shown
as
a
project
continuous
growth.
We
had
a
ton
of
different
prs.
A
We
had
over
2000
commits
by
over
30
different
contributors
from
10
plus
different
companies,
so
we're
very
diverse
and
again
we
are
kind
of
involved
in
and
and
trying
to
help
everybody
that
is
interested
in
using
the
specification
we
added
two
new
project
maintainers
and
currently
we
have
five
all
from
different
companies,
so
we
really
show
diversity
within
the
project.
As
far
as
that
goes,
we
added
over
the
last
year,
two
new
sdks,
so
we
added.net
and
typescript,
and
also
released
a
lot.
A
You
know
had
a
lot
of
different
releases
for
other
sdks
and,
of
course
you
know
as
as
as
mentioned
you
know,
charles
here
has
contributed
the
the
synapse,
which
is
the
kubernetes
navy
runtime
that
is
hosted
by
in
our
github
repositories
as
well
as
far
as
the
project
roadmap
goes.
This
is
kind
of
like
a
year
in
review.
We
we
started
off
with
kind
of,
like
you
know,
a
release
schedule
and
released
a
version
of
five.
A
In
november
last
year
we
had
steady
sort
of
releases
in
throughout
the
last
year.
Currently,
the
current
version
of
serverless
workflow
specification
is
v07
and
we're
planning
to
release
08
next
month.
As
far
as
10
goes
we're
looking
currently
at
april
next
year,
and
but
you
know
even
now,
what
we're
doing
is
with
if
you're
picking
the
service
worker
project
up
right
now
or
thinking
about
using
is
it
would
be
version
of
seven,
the
latest
and
until
one
no,
we
we,
we
will
only
do
backwards,
compatible,
updates
and
features.
A
A
Async
api
plays
an
integral
role
within
serverless
workflow
and
basically,
like
we
said,
if
you
look
at
dsls
right
now,
probably
most
of
them
are
going
to
have
some
proprietary
ways
of
of
you
having
to
define
how
you
want
to
invoke
some
sort
of
function
or
services
out
there.
Workflows
itself
are
orchestrators
right.
So
your
work.
A
Will
you
define
your
control
flow
logic
and
and
deal
with
things
like
how
you,
when
you
want
to
import
services,
and
then
you
have
to
deal
with
like
some
sort
of
data
manipulations
and
things
like
that
that
they
represent
your
orchestration
efforts.
So
what
we
do
is,
instead
of
defining
some
proprietary
ways
of
of
you.
You
know
on
how
to
invoke
these
services.
We
use
async
api.
A
So
we
use
our
specification,
basically
relies
on
ac
kpi
definitions,
so
you
can
have
one
or
more
there
that
defines
some
sort
of
services
that
you
want
to
communicate
with
and
while
we're
executing
our
workflow,
we
define
basically
the
dsl.
All
you
have
to
define,
as
we'll
see
is,
is
the
path
to
async
api
definition,
and
you
have
to
provide
the
operation
id
and
with
that.
A
Basically,
our
workflow
dsl
describes
everything
how
what
events
have
to
be
produced
and
what
type
of
channels
and
things
like
that
and
all
is
defined
with
asic
api,
rather
than
it
being
hard-coded
or
being
proprietary
inside
the
dsl
itself.
So
the
idea
is
that
the
serverless
workflow
workflow
definition
utilizes
the
async
api
to
not
only
define
to
define
how
this
functions
or
services
have
to
be
invoked
and
then
async
api
provides
all
the
information
to
the
runtime
that
executes
the
workflow
definition
on
how
to
do
that.
Actually.
A
So
that
really
allows
it
for
for
specification,
based
communication
between
between
the
your
workflows
or
orchestration
of
your
business
logic
with
with
any
type
of
service,
and
it's
fully
described
via
async
api,
to
look
a
little
bit
deeper
into
this.
On
the
left
hand
side
we
see,
for
example,
a
json-based
workflow
definition
that
is
written
in
the
serverless
workflow
dsl,
and
here
in
the
little
yellow
box.
On
top,
we
have
a
function
definitions.
A
These
are
you
know
the
the
definition
that
is
reusable
between
multiple
workflows
and
basically
defines
some
sort
of
function
to
some
sort
of
service
that
we
might
want
to
invoke
during
executional
workflow.
So
we
see
here
in
our
function,
definition
that
we
have
a
domain
specific
name
which
is
called
invoke.
Banking
service
and
each
function
definition
has
a
type
in
this
type.
A
In
this
case,
type
is
async
api,
so
your
runtime,
when
it
wants
to
invoke
this
function,
knows
exactly
that
we're
dealing
with
with
with
async
api
definitions
here
and
then
we
have
the
third
parameter
called
operation,
and
so
this
parameter
defines
the
path
or
the
uri
to
our
open
api.
I
mean
async,
api,
sorry
definition
and
just
and
then
the
second
part
of
the
operation
parameter
value
is
the
operation
id.
So,
on
the
right
hand,
side
we
see
our
banking
yaml
async
api
definition.
A
So
what
we
see
here
we,
you
know
we
have
this
channel
on
on
customer
transaction
03
channel
and
it
has
a
published
definition
and
with
the
same
matching
operation
id
that
we
specify
in
our
workflow
definition-
and
that's
it.
You
know
the
async
api
definition
really
defines
everything.
What
type
of
event
has
to
be
sent
to?
What
channel
has
to
be
sent?
What
should
be
it's?
It's
it's
it's
what's
or
its
bindings.
A
Basically,
and
what
is
the
message
in
its
format
that
needs
to
be
sent
in
order
to
invoke
this
particular
service
on
the
bottom
of
the
left-hand
side
in
the
little
green
box,
we
actually
see
the
control
flow
logic
of
our
workflow
definition
and
we
define
a
single
state
and
you
know,
there's
different
states,
each
state
or
task,
or
you
know,
step
or
whatever
you
might
want
to
call.
It
defines
a
piece
of
of
control
for
logic.
A
In
this
case
we
have
an
actual
action
and
this
action
references
our
function
definition
and
can
pass
in
some
arguments.
So
at
that
point
we
say:
okay,
we
want
to
actually
invoke
this
particular
service
and
the
async
api
definition
defines
everything
that
we
need
to
know
or
the
runtime
needs
to
know
in
order
to
actually
execute
it
all
right.
So
let's
go
to
the
cool
part
about
the
demo.
A
A
Our
banking
service
or
banking
service
is
using
the
async
api
definition
that
we
showed
earlier.
So
this
is
the
async
api
definition
or
banking
service.
He
basically
has
a
channel
is
a
publish
operation
with
our
sentries
action
operation
id,
and
he
also
has
a
subscribe
channel
that
that
you
can
send
results
of
the
invocations
events
to
to
to
to
to
this
particular
endpoint.
Both
of
the
bindings
that
we
use
are
kafka
bindings.
A
You
know
we
can
use
mqtt
or
whatever
and
since
we're
running
this
locally,
we
have
a
server
which
is
a
local
host
port
and
a
protocol
is
kafka,
so
we
have
kafka
running
locally
in
our
system.
Now,
what
I've
done
is
I've
used
the
async
api
code
generators
to
actually
generate
this
banking
service
spring
boot
project.
So
it's
all
java,
based
in
this
demo
and
and
I've
used
the
tool
link
to
actually
generate
the
whole
project.
A
So
just
from
this
simple
definition
with
the
async
api,
tooling,
you
can
generate
the
whole
service
and
what
I've
done
only
is
in
the
generated
message
handler.
This
is
the
handler
which
actually
sorry,
I'm
making
this
bigger
receives
the
the
event
that
basically
comes
from
our
workflow
orchestration,
and
we
have
also,
after
we
receive
the
event
that
we
process
it
and
then,
according
again
to
our
async
api
definition,
we
send
it
to
our
publish
channel
the
results
as
well,
so
that
is
the
application
itself.
A
It's
spring
our
service
that
we
want
to
invoke.
The
second
application
that
I
have
is
actually
a
quercus
application,
and-
and
this
is
where
our
our
our
workflow,
we
we
define
our
workflow
and
also
it's
able
to
execute
it
as
well
in
in
itself
uses
the
our
banking
async
api
definition
the
same
one.
That
is
also
describes
the
the
service
that
we
just
created,
and
this
is
used
by
the
the
workflow
runtime.
A
A
Start
our
core
course
applications,
which
is
our
demo,
actually
the
one
where
the
hosts
our
workflow
definition
and
the
runtime,
and
it
needs
to
communicate
with
our
banking
service.
So
once
we've
started
that
up
also,
I
wanted
to
just
show
you.
We
have
zookeeper
here
running
and
a
local
kafka
instance
running
as
well,
and
just
to
show
here
on
the
last
tab
that
we're
communicating
via
the
kafka
broker.
A
A
Now
this
is
our
ui
of
our
actual,
the
the
the
quarkx
application
or
the
demo
application,
and
here
we
see
some
of
the
serverless
workflow
project,
kind
of
utilities
or
the
ecosystem.
On
the
left
hand,
side
we
have
a
little
web
editor
that
you
can
use
to,
for
example,
define
your
workflows
and
it
has
things
like
validation
and
also
auto
completion
as
well,
which
is
based
on
on
the
serverless
workflow
json
schema
that
defines
the
dsl.
A
So
you
you
also
have
validation.
So,
for
example,
if
we
removed
one
required
parameter,
we
should
see
here,
for
example,
a
missing
property,
spec
version,
for
example,
and
things
like
that.
So,
if
you're
exposing
this,
for
example
to
to
your
end
users
or
customers
to
define
their
own
workflows,
you
know
you
have
a
lot
of
help
there.
You
know
that
it
helps
them
to
to
to
to
write
a
proper
and
valid
workflows
on
the
right
hand,
side.
We
also
have
a
workflow
diagram
generation.
A
You
can
change
or
update
your
workflows
here
and
click
on
the
button
to
generate
the
the
diagram
for
the
particular
workflow
that
you're
writing,
so
just
real
quick
to
go
through
the
the
demo
and
the
workflow
that
we're
going
to
be
using
today.
First
of
all,
we're
going
to
look
at
the
again
the
function,
definitions
we
do
have.
You
know
similar
to
what
we've
shown
in
the
slide,
a
single
function
defined,
which
is
involved
banking
service.
A
It
is
async
api
type
and
it
has
a
operation
of
banking
on
yaml,
which
our
you
know
during
execution
of
our
workflow
is
going
to
be
parsed
and
we're
going
to
get
the
the
send
transaction
operation
id
and
then
figure
out
how
to
or
where
to
send
our
our
you
know,
events
to
in
order
to
trigger
execution
of
our
of
our
banking
service.
As
far
as
the
control
flow
logic
go,
we
have
the
states
block,
and
here
we
have
a
single
state.
A
It
is
json,
but
we
can
also,
of
course,
visualize
that
in
in
web
as
well,
so
here
what
we
can
do
in
order
to
start
the
workflow,
we
can
give
it
some
input.
So,
let's
give
it
an
let's
say,
a
customer
id
of
789,
for
example,
and
let's
do
some
transactions.
So
let's
say
this
user
had
a
deposit
of
hundred
dollars
and
these
are
space
separated
into
you
know
for
the
case
of
the
demo.
You
can
you
can
do
the
ui
better.
A
So
let's
say
we,
we
did
a
withdrawal,
fifty
dollars
and
then
we
had,
let's
say
another
deposit
of
twenty
dollars,
so
these
are
type
of
the
the
transactions
that
this
user
has
done
and
we
want
to
process
these
transactions
with
the
banking
service.
If
we
run
the
workflow,
actually
we
will
start
the
workflow.
A
The
workflow
is
going
to
look
at
the
async
api
definition
when
it
comes
to
actually
execution
of
our
of
our
banking
service,
it
is
going
to
send
you
know
the
event
on
the
appropriate
topic
of
of
our
for
kafka
and
is
going
to
communicate
with
the
banking
service
through
that.
So
let's
go
ahead
and
run
the
workflow.
Our
workflow
results
are
on
the
right
and
I'm
going
to
expand
that.
A
So
what
we
see
as
far
as
workflow
execution
goes,
we
have
workflow
results
and
you
can
see
them
also
here
in
our
demo.
One
second
yeah
so
result
is
json,
but
we
can
also
see
them
in
the
ui
we've
seen
that
the
customer,
the
789
which
we
specified,
we
see
the
transactions
that
have
been
entered
here
as
well,
and
we
see
all
the
different
functions
that
have
been
invoked
in
this
case.
A
We
invoke
our
banking
service
function
here,
three
times
for
each
one
of
the
inputs
or
the
customer
transactions
that
we
have
provided
and
also
since
our
baking
service
produces
a
result
back.
So
so,
via
your
event,
we
can
see
here
that,
for
this
particular
user,
the
current
total
or
the
total
in
their
account
right
now
after
these
transactions
is
70,
which
is
50
plus
20.
I
guess
in
this
case
that
would
be
right.
A
So
let's
take
a
look
at
also
one
more
thing.
So
here
we
have,
since
we
are
running
this
on
on
temporal
and
its
runtime
temple,
provides
us
with
a
web
ui
as
well,
and
we
can
see
here
that
we
had
one
workflow
that
has
been
executed.
It's
serious
workflow
customer
transactions,
it
has
a
particular
run
id
and
we
can
see
here
that
we
have
completed.
You
know
during
the
demo,
this
workflow
execution.
A
Now,
if
we
can
also
look
at
the
history
here,
we
can
see
the
input
which
is
the
dsl
and
and
and
also
we
see
here,
the
results
as
well,
and
one
thing
that
you
can
do
here
also
with
temporal,
but
also
other
runtimes.
You
know
probably
as
well.
You
can
have
a
complete
history
of
what
has
happened
during
the
workflow
execution.
So
we
can
see
here
that
we
have
executed
a
number
of
temporal
activities
or
in
our
case
would
be
the
the
the
actual
request
for
function,
execution
and
things
like
that.
A
So
you
know
you
have
full
control
with
with
with
the
runtime.
You
know
in
some
sort
of
visualization
and
information
that
you
can
get
using
serverless,
workflow
and
and
as
well.
So
that's
it
for
for
the
demo.
I
hope
you
guys
enjoyed
again.
Thank
you
very
much
on
behalf
of
myself
and
charles
and
the
whole
serverless
workflow
team.
I
would
like
to
say
thanks
for
having
us
here
on
the
ac
kpi
conf,
and
I
hope
you
have
a
great
day.