►
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.
Serverless Workflow – New Approach to Container Orchestration - Tihomir Surdilovic & Ricardo Zanini Fernandes, Red Hat
With the rise of Serverless Architectures, Workflows have gained a renewed interest and usefulness. Typically thought of as centralized and monolithic, they now play a key role in service and events orchestration and coordination. With many different architecture approaches already in place, the Cloud Native Computing Foundation has started an initiative to specify Serverless Workflows Specification to ensure portability and vendor neutrality. In this talk, we introduce the CNCF Serverless Workflow specification and provide examples and demos running on Kubernetes and Kogito, Red Hat’s business automation toolkit. You will learn: * The what, why, and how of the CNCF Serverless Workflow specification * Why using the Serverless Workflow specification and orchestration can improve your serverless architecture * Define and deploy Serverless Workflow custom resources on Kubernetes
https://sched.co/ekEn
A
Yeah
in
this
talk,
we
will
present
to
you
guys
the
serverless
workflow
project.
We
will
give
a
introduction
to
the
project,
look
at
some
of
its
use
cases
and
then
ricardo
is
going
to
present
us
his
really
cool
demo
on
how
serverless
workflow
fits
within
a
container
orchestration
environment
using
kubernetes
and
k
native
thanks
all
right.
So
serverless
workflow
is
a
cloud
native
foundation,
sandbox
project.
It
is
part
of
its
serverless
working
group.
It
is
open
source
and
apache
2.0
license.
A
All
right,
serverless
workflow,
defines
a
declarative
and
domain
specific
workflow
language.
Declarative
is
not
expressed
in
low-level
code,
however,
defines
an
abstraction
language
which
can
be
defined
in
both
json
and
yaml
formats
domain,
specific,
as
it
does
target
specifically
the
domain
of
orchestration
of
event-driven
and
distributed
services,
and
to
give
an
example
of
that
here,
on
the
left-hand
side,
we
have
two
simple
requirements:
written
in
a
natural
language,
the
first
one
being
when
a
patient
has,
for
example,
a
bladder
infection.
A
We
want
to
notify
a
urologist,
so
a
doctor
dealing
with
that
type
of
issue
and
the
same
thing
with
the
second
one.
When
a
patient
has
a
regular
heartbeat,
we
want
to
notify
cardiologists
for
that
type
of
issue.
On
the
right
hand,
side
we
see
that
serverless
workflow
does
not
express
its
language
in
code
or,
if
else,
statements
and
things
like
that,
neither
does
it
express
it
using
terminology
that
does
not
fit
the
specific
to
me
domain
targets
on
the
bottom
right
hand.
Side.
A
You
can
see
that
these
type
of
requirements
we
can
translate
directly
into
events
and
services
for
so,
for
example,
a
patient
having
a
bladder
infection
or
irregular
heartbeat.
We
can
look
at
it
and
translate
it
into
events
that
could
be
produced
by,
for
example,
in
this
case
some
different
hospital
systems
and
notifying
a
doctor.
In
this
case,
the
particular
doctor
who
deals
with
the
patient
issue
can
be
translated
into
location
of
distributed
services.
A
All
right,
serverless
workflow,
is
based
on
standards
for
event
definition.
We
use
the
cloud
event
specification
to
define
events,
events
that
can
be
produced
or
consumed
and
also
define
correlations
between
many
different
events
that
could
be
happening
in
your
systems.
We
use
the
open
api
specification
to
define
operations
and
services
that
need
to
be
invoked
during
workflow
execution.
A
A
So,
in
order
to
start
using
events
within
your
workflows,
you
have
to
first
start
defining
them
like
we
said
events
can
be
either
consumed
or
produced
during
workflow
execution
with
serverless
workflow.
You
can
see
here
that
we
have
a
direct
one-to-one
mapping
between
how
events
are
actually
expressed
within
the
cloud
events,
specification
format
and
how
you're
actually
defining
it
within
your
workflows.
A
A
All
right,
so
how
can
you
now
now
that
you
define
your
events?
How
can
you
now
interact
with
them?
So,
as
we
said,
events
can
either
start
workflow
execution.
They
can
continue
workflow
execution
at
some
way
points
they
can
be
either
consumed
or
produced,
and
they
can
be
used
also
to
make
logical
decisions
on
the
right
hand,
side.
A
We
see
a
very
simple
end
definition
of
the
serverless
workflow
language
which
says
okay
at
this
point,
we're
going
to
end
the
workflow
execution,
but
before
we
end
it
we're
actually
going
to
produce
an
event
of
type
workflow
completed
event.
Now
this
event,
then,
can
be
consumed
by
other
different
services
in
your
systems,
for
example,
other
workflows
or
pretty
much
anything
else
that
is
listening
to
this
type
of
event.
A
Thanks
similar
to
events,
we
have
want
to
define
services
and
the
operation
on
this
distributed
service
that
we
want
to
invoke
during
workflow
execution
and,
as
we
said
for
this
serverless
workforce
project
user
utilizes.
This
open
api
specification
on
the
left
hand
side
here
in
the
box.
We
see
a
simple
open
api
definition
in
this
case
written
in
yaml,
and
it
shows
one
particular
operation
of
this
service
that
we
want
to
invoke
during
workflow
execution.
On
the
right
hand,
side
we
see
that
there
is
again
a
one-to-one
mapping.
A
So
in
order
to
define
this
particular
operation
and
the
service
that
you
want
to
invoke
during
workflow
execution,
you
basically
have
an
operation
parameter,
which
is
a
combination
of
the
path
or
the
uri
to
the
open,
ipi
definition
of
the
service
and
the
unique
operation
id
which
gives
you
unique
one-to-one
mapping.
So
your
runtime
should
exactly
know
what
operation
needs
to
be
executed
on
the
service
whenever
the
workflow
requests
for.
A
It
now
that
we
have
defined
the
services
we
want
to
be
able
to
evoke
it,
and
we
understand
that
there
is
many
different
types
of
services
that
you
might
want
to
invoke
during
workflow
execution
with
serverless
workflow.
You
have
the
ability
to
define
and
invoke
restful
services
that
we
see
on
the
left-hand
side
an
example,
but
also
your
have
the
ability
to
define
invocation
of
services.
They're,
not
restful,
they're
not
probably
exposed
at
some
end
points,
but
how,
however,
are
triggered
by
events,
so
that
is
also
possible.
A
The
last
part
of
defining
the
the
workflow
is
actually
the
control
flow
logic.
Here
we
want
to
define
states
and
the
order
in
which
they're
executed
with
serverless
workflows
states
are
kind
of
like
a
black
box
that
does
some
particular
control
flow
logic.
Type
states
can
receive
either
data
inputs,
or
can
they
inc
receive
events?
A
Control
for
logic
can
be
very
granule,
granular
in
which
means
that
it
becomes
at
some
point,
ambiguous,
ambiguous,
and
what
we
wanted
to
do
is
kind
of
try
to
eliminate
that
it
is
often
very
hard
to
see
during
control
flow,
even
visually,
what
parts
kind
of
fit
together
and
which
parts
in
combination
define
a
control
flow
logic
block
that
makes
sense
on
a
domain
specific
or
a
logical
level.
On
the
bottom,
we
see
that
each
state
within
serverless
workflow
has
a
specific
type,
and
this
types
are
somewhat
clear.
A
For
example,
we
have
an
event
type
or
which
basically,
okay,
at
this
point,
we're
doing
dealing
with
a
control
for
logic
that
has
to
do
with
events
the
same
thing,
for
example
a
switch
type.
It
is
clear
that
this
particular
state
is
going
to
deal
with
logical
decisions
based
on
either
data
input
or
the
event
payloads.
A
A
A
A
You
can
make
decisions
like
we
said,
based
on
either
data
or
some
sort
events
you
you
can
deal
with
error
handling,
for
example,
issue
retries
or
define
how
errors
are
handled
during
your
workflow
execution.
In
addition
to
that,
serverless
work
also
allows
you
to
deal
with
control
flow
that
has
to
do
with
human
interactions,
which
is
sometimes
very
important
during
execution
of
your
workflows,
and
there
are
some
other
things
and
they're
all
specified
within
our
specification
documents.
A
Next
now,
let's
take
a
look
at
the
overall
project
components
or
what
is
all
included
within
the
serverless
workflow
project.
So
far,
we
have
been
talking
about
the
serverless
workflow
language,
which
is
described
as
a
json
schema,
and
this
json
schema
really
defines
all
the
rules
and
and
the
patterns
that
you
can
use
when
defining
your
language.
A
Some
of
the
language
extensions
that
we
provide
are
kpi
or
key
performance
indicators,
extensions
for
tracing
simulations
and
and
we're
adding
more
as
we
go.
Another
part
of
the
serverless
workflow
project
is
things
like
software
development
kits.
We
have
them
currently
in
both
for
both
the
java
and
the
go
languages,
testing,
com,
tck-
or
this
is
a
compatibility
kit
for
runtime
implementations
where
they
can
compare
their
implementation
to
to
the
requirements
of
the
serverless
workflow
specification.
A
So,
let's
take
a
look
at
some
of
these
or
one
of
this
language
extension
the
serverless
workflow,
provides
in
this
case.
Let's
take
a
look
at
the
kpi
extension
and
this
particular
language
extension
allows
you
to
basically
compare
expected
versus
actual
data
of
your
runtimes
or
information
produced
during
the
runtime
of
your
workflows,
and
it
helps
you
really
try
to
improve
your
workflows
in
terms
of
performance
cost
and
its
effectiveness
and,
on
the
right
hand,
side.
You
can
see
a
small
example
of
the
definition
of
this
kpi
extension.
A
Again,
all
the
extensions
just
like
the
actual
servos
workflow
language
can
be
expressed
both
in
json
or
yaml.
So
you
have
the
choice
to
do
that,
but
here
basically
allows
you
to
to
define
some
expected
metrics.
They
have
to
deal
with.
What
do
you
expect
to
happen?
How
many
times
you
think
that
some
services
should
be
invoked?
A
The
next
thing
we
want
to
take
a
look
at
is
the
java
sdk,
and
this
particular
sdk
provides
features
like
parsing
of
json
or
yaml.
Did
a
runtime
implementations
can
easily
use
and
don't
have
to
deal
with
that
it
provides
a
fluent
api.
So
it
allows
you
to
define
your
workflow
definitions
just
using
programming
language
rather
than
dealing
with
with
the
json
or
yaml.
It
provides
validation,
so
validation
against
the
serverless
workflow
specification
itself,
and
it
also
provides
diagram
generation.
A
Visualize
one
more
thing:
we're
going
to
take
a
look
at
here
is
the
serverless
workflow
visual
studio
code
plugin-
and
this
is
a
plugin
that's
available
on
the
visual
studio
code
marketplace.
You
can
download
it
now
and
start
using
it
and
its
feature.
Sorry
provides
code
hints
and
code
snippets
for
both
json
and
yaml
files
again
against
the
serverless
workflow
json
schema,
it
provides
validation
and,
at
the
same
time
it
also
provides
diagram
generation.
A
B
B
We
have
this
very
particular
use
case
that
I
I
wish
to
open
a
pr
against
a
project,
a
github
project,
and
I
wish
to
have
my
pr
being
labeled
exactly
with
what
this
is
supposed
to
be
labeled
and
I
wish
to
have
you
know
my
pull
request
be
reviewed
by
someone,
so
would
be
nice
to
have
like
maybe
a
bot
that
could
label
my
pull
requests,
and
maybe
you
know
also
add
the
correct
reviewer
from
for
michael
request.
So
having
this
in
mind,
we
draw
a
proposed
workflow
for
that.
B
So
imagine
that
we
could
receive
an
event.
Change
like
a
pr
has
been
open
or
changed.
So
we
received
this
event
on
our
system
and
based
on
that
event,
we
can
analyze
the
context
of
the
pull
request
and
understand
what
what
have
been
changed.
So
we
can
understand
by
based
by
the
context,
by
the
files
that
have
been
changed
and
based
on
that
we
can
call
the
github
api
to
apply
the
correct
labels
and
also
to
add
the
required
reviewers
and
and
the
nd
workflow.
B
We
can
create
and
publish
a
new
event
saying
to
the
platform:
hey,
the
pr
has
been
verified
and
you
can
do
whatever
you
want
with
this
this
event.
So,
having
this
workflow
in
mind,
we
prepared
implementation
with
some
technology,
around
kubernetes
k,
native
the
surface
workflow
and
some
some
runtimes
implementation
of
the
serverless
reflow,
and
the
first
thing
is
once
we
receive
a
pull
request.
We'd
like
to
you
know,
to
receive
this
event
on
a
broker.
B
So
in
this
case
you
know
on
a
k
native
broker,
and
then
this
broker
will
broadcast
this
event
for
anyone
interested
in.
In
this
case,
we
have
our
serverless
workflow
runtime
running
in
this
platform
and
we'll
listen
to
this
event
of
this
pull
request
event
and
we're
going
to
do
everything
that
we
that
we
explained
in
the
last
slide
like
analyzing,
the
pull
requests.
B
What's
going
on
with
this
pull
request,
and
one
of
the
things
is
to
query
the
github
api
for
the
files
that
have
been
changed
in
this
vr
and
also
apply
the
labels
apply
the
reviewer.
So
for
that
we
need
these
github
api
functions
also
deployed
on
our
platform
on
our
kubernetes
platform
that
we
are
going
to
call
like
github
api
functions.
So
we
have
all
those
k,
network
server
functions
deployed
in
there
that
we
can
consume
using
our
workflow
engine
and
also
is
the
the
the
workflow
is
finished.
B
We
will
publish
a
new,
a
new
event
to
the
broker
and
the
broker
can
also
you
know,
broadcast
this
event
for
any
interested
part
of
the
this
event,
and
in
this
case
the
pull
request,
verified
event
will
be
consumed
by
our
notification
service.
So
this
notification
service
can
be
anything
you
can
not
five
yeah
mail
via
slack
telegram
or
whatever
other.
You
know
channels
that
you
have
out
there
in
your
company.
B
So
that's
the
the
main
architecture.
You
know
the
implementation
of
what
we
have
and
then
we
basically
have
this
broker
implemented
with
native
eventing
system.
So
kennedy
painting
will,
you
know,
delegate
the
broadcast
events
around
the
kubernetes
namespace.
We
have
this
workflow
runtime
implemented
with
our
own
runtime
implementation
of
the
service
workflow.
B
The
project
we
have
k
native
to
serve
the
platform
to
be
the
infrastructure
for
us
for
the
serverless
infrastructure
to
handle
cloud
events
for
us
in
the
in
the
kubernetes
name
space
to
handle
our
functions
in
there.
We
also
have
some
the
java
functions
that
you
saw
the
github
functions
they
are
all
implemented
in
java
with
quercus
could
be
implemented
in
any
language.
Actually,
so
you
use
java
because
we
are
users
to
that
and
we
have
came
with
the
kremwell
framework.
B
That
is
an
integration
framework
for
communicate
with
this
like
api,
to
make
a
a
nice
notification
to
a
given
like
channel.
So
I'm
going
to
change
my
screen
now
to
the
to
the
front
part
like
j
homie
set,
so
first
of
all
we're
going
to
just
watch
the
pods
on
our
namespace.
So
for
now
you
everything
that
we
have
here
in
this
in
the
application
space
is
the
workflow
engine
running
and
our
coached
operator
running
there
as
well.
This
operator
will
is.
B
Deployed
the
service
and
is
controlling
the
service
and
how
things
should
be,
and
the
state
of
the
the
workflow
should
be
so
that's
why
there's
a
part
of
the
operator
in
there
and
here
in
the
bottom,
I'm
in
my
project.
So
I
have
this
given
you
know:
cogito
serverless,
workflow
demo
project
in
github,
so
I'm
going
to
start
creating
a
new
branch.
A
B
B
B
B
Hello
demo,
hey
onsen,
open
a
pull
request.
You
know
a
new
event
will
come
to
my
to
my
kubernetes
namespace
and
can
canada
will
handle
that
and
we'll
start
you
know
the
operation
of
the
overall
operation
inside
the
namespace,
so
the
broker
the
broker
will
take
this
event
and
we
broadcast
to
our
cogito
workflow
to
our
runtime
workflow
engine.
B
B
You
see
that
the
the
pull
request
just
added
the
you
know
the
the
workflow
added
to
the
correct
label
and
then
did
the
correct
guy
here
to
reveal
our
pr
and
as
well.
The
notification
service
was
no
waking
up
to
receive
a
notification
in
here.
So
you'll
see
that
we
received
some
notifications
about
the
changes
that
we
made
in
in
the
pr.
A
No
we're
good,
I
think
here
you
can
find
more
information.
Definitely
our
website
the
server's
workflow.io
again
like
ricardo,
and
I
we're
community
members
of
the
project
and-
and
we
would
like
to
also
invite
everybody
that's
watching
to
join.
We
have
like
we
said
community
bi-weekly
meetings
there.