►
Description
Check out demo #5, "Cloud Events Orchestration with Knative and Zeebe" by Mauricio Salatino, principal software engineer at Comunda.
A
Working
quite
okay,
I'm
just
trying
to
also
learn
more
about
gay
native
and
see.
How
can
I
contribute
and
by
just
creating
simple
applications?
It's
pretty
clear
to
me
that,
or
I
might
be
missing
some
stuff
or
some
stuff
that
we
can
create
in
order
to
make
like
you
know,
the
user
experience
a
little
bit
better,
not
on
decay
native
stuff,
but
in
some
components
that
can
help
people
to
build
like
applications.
Basically,
so
let
me
try
to
go
over
the
application.
My
name
is
maurice
salatino.
I
work
for
a
company,
that's
called
camunda.
A
They
have
been
doing
workflows
for
a
long
time
and
I've
been
working
with
workflow
related
companies
for
the
last
10
years
or
so
so.
I've
seen
like
a
fair
share
of
implementations
of
applications
using
workflow
technologies
and
how
you
know
they
create
these
workflow
engines.
This
company
has
a
project,
that's
called
cv,
that's
the
one
that
I'm
going
to
be
showing
today
and
that
project.
Basically,
it's
a
cloud
native
reimplementation
of
what
we
traditionally
know
as
a
workflow
engine.
That's
quite
cool.
A
It's
adapted
to
you
know
the
modern
infrastructure
and
I'm
also
a
learning
instructor
with
coordinates
trainings
for
that,
I'm
pretty
sure
that
we
are
all
familiar
with
kubernetes
by
now.
So
a
quick
disclaimer
here
I
will
be
running
a
live
application
running
in
a
remote,
kubernetes
cluster,
it's
using
web
sockets
and
native
cloud
events
and
a
bunch
of
other
stuff.
So
what
can
possibly
go
wrong?
I
would
say
everything
and
if
something
can
go
wrong,
it
will
go
wrong.
A
A
Let
me
go
to
the
application
and
the
application
again
is
simulating
that
that
idea
of
you
have
you
need
to
sell
tickets,
for,
let's
say
a
concert
that
it's
in
high
demand
and
you
probably
have
less
tickets
than
people
wanting
to
buy
the
tickets.
So
you
might
need
some
kind
of
queuing
system
in
order
to
be
able
to
serve.
You
know
in
a
first
come
first
serve
approach
right.
A
So
in
order
to
do
that,
you
will
need
to
have
some
kind
of
a
queue
and
you
will
start
queuing
customers
while
they
arrive,
and
in
the
moment
where
the
tickets
go
on
sale,
you
are
going
to
start
processing
that
queue
and
just
letting
a
bunch
of
customers
at
a
given
time
to
proceed
and
reserve
the
tickets
right.
If
they
manage
to
receive
the
tickets
in
their
session,
they
will
just
acquire
the
tickets.
If
not,
they
will
just
leave
the
tickets
for
the
next
person
in
the
queue
right.
So
this
is
basically
the
application.
A
A
So
I'm
just
pushing
events
through
each
of
the
you
know,
customer
browsers
in
order
to
just
update
their
position
in
the
queue
right.
That's
just
a
thing
just
to
take
into
consideration
from
like
the
architecture
of
the
application.
So
what
I
can
do
here
is,
I
can
just
simulate
people
just
going
out
of
the
queue,
so
I
just
jump
towards
the
first
place.
B
A
Beginning
of
the
queue,
so
next
it's
going
to
be
my
turn.
I
can
wait
for
that
and
make
that
happen
and
again
I
will
be
just
notified
because
I'm
getting
a
websocket
notification
message,
saying
yeah
now
it's
your
turn.
Now
you
can
reserve
your
tickets
right
and,
as
you
can
see,
there
are
a
bunch
of
weird
ideas
there
that
represent
my
session
and
basically
will
validate
that.
A
I
am
now
you
know,
allowed
to
move
forward
into
the
process
of
buying
my
tickets,
and
here
you
can
just
select
the
amount
of
tickets
on
the
type
of
tickets
right.
Let's
say
I
just
want
to
reserve
two
tickets
and
as
soon
as
I
click
reserve,
the
main
idea
here
is
that
I'm
going
to
go
to
the
pool
of
tickets
available
tickets,
and
I
will
lock
in
this
case
two
for
my
reservation
and
those
tickets
will
be
locked
until
I
pay
for
those
tickets.
If
I
manage
to
pay
correctly,
then
the
tickets
will
be
mine.
A
If
I
do
not
manage
to
pay
correctly
and
for
some
reason
there
is
an
error
or
I
just
do
not
pay,
those
tickets
are
going
to
be
automatically
put
back
there
into
the
pool
right
and,
as
you
can
imagine,
if
you
have,
you
have
a
payment
service
or
payment
system,
it
might
be
kind
of
like
a
third
party
payment
system.
So
as
soon
as
I
click
pay
here,
I
will
just
send
my
details
to
a
third-party
application
and
I'm
using
an
iframe
and
again
a
callback
in
order
to
verify
that
the
transaction
was
approved.
A
So
when
I
click
here,
I'm
just
going
to
a
third-party
application.
This
is
not
the
application
of
the
tickets
portal,
it's
a
third-party
thing
and
then
I'm
just
waiting
for
a
callback
to
come
back
and
say
that
my
transaction
was
approved
or
rejected.
It
was
approved
and
I
also
get
a
websocket
notification
saying:
yes,
you
can
continue
and
you
can
get
your
tickets.
So
that's
pretty
much
what
the
application
is.
A
That's
kind
of
like
the
normal
flow
of
the
application
and,
based
on
this,
you
can
go
and
say:
okay,
if
you
want
to
architect
an
application
like
this,
you
can
use
like
an
event-driven
approach
right
and
if
you
use
an
event-driven
approach.
Basically
what
will
happen
is
that
you're
going
to
be
meeting
events,
some
services
will
be
meeting
events
and
some
other
services
will
be
consuming
events
in
order
to
make
all
this
flow
happen
right.
A
So
these
are
kind
of
like
the
events
that
you
would
expect
to
have
in
this
kind
of
like
situations,
you
join
the
queue
you
exit
the
queue
you
reserve
the
tickets,
you
send
the
payment,
the
payment
gets
authorized
and
then
the
tickets
gets
admitted
right.
If
you
go
more
to
the
architecture,
this
is
kind
of
like
how
I
started
working
with
this
application.
So
I
created
four
different
services.
A
When
I
started
building
these
services,
I
started
saying:
okay,
let's
use
cloud
events
to
share
information
between
these
services
and
I
started
using
like
the
http
bindings,
so
sending
http
post
requests
between
the
services
and
at
that
point
my
services
needed
to
know
exactly
where
I
was
sending
those
requests
right.
So
from
the
front
end,
if
I
want
to
interact
with
the
queue
service,
I
just
need
to
send
a
post
request
to
the
q
service.
A
That
pushed
me
to
know
in
the
front
end
application
to
know
where
the
queue
service
was
right
and
you
can
quickly
do
that.
You
can
easily
do
that.
But
if
you're
building
a
more
real
life
application,
you
might
need
to
have
some
more
advanced
stuff
and
we
are
in
the
k
native
meetup.
So
I
don't
need
to
explain
what
k
native
serving
or
k
native
venting
is,
but
I
started
looking
quite
heavily
into
k
native
eventing
in
order
to
implement
a
more
robust
solution
of
communicating
this
service
together
to
be
able
to
scale.
A
So
I
started
using
eventing
and
you
ended
up
with
something
like
this,
where
you
do
not
communicate
the
services
between
each
other,
you
just
you
know,
create,
send
messages
to
the
broker
using
a
channel.
I
started
with
a
memory
channel
and
then
I
switched
to
kafka
and
you
have
a
broker
where
you
just
publish
your
messages
or
your
cloud
events,
and
then
you
create
triggers
for
subscriptions
for
those
events.
So
different
services
will
subscribe
to
different
event
types
and
by
creating
the
right
you
know
subscriptions
and
by
publishing
the
right
cloud.
A
Events
to
the
broker
you
kind
of
like
implement
this
flow.
At
some
point,
I
needed
to
create
some
kind
of
a
checklist
to
understand
how
the
flow
was
composed
right.
It
was
something
like
this
I
said:
okay,
the
front
end
needs
to
generate
that
generates
the
cloud
event
that
it's
been
pushed
to
the
broker,
and
then
there
needs
to
be
a
trigger
in
the
queue
service
to
consume
that
event.
A
To
do
something,
and
the
same
here
with
the
q
service,
when
the
q
service
generates
the
customer
exit
event,
there
needs
to
be
a
trigger
in
the
front
end
to
be
able
to
consume
that
and
allow
the
customer
to
move
forward
right.
So
for
this
very
simple
scenario,
I
needed
this
checklist
and
it's
collect.
A
I
can
definitely
understand
it
now
and
it's
easy
to
build,
but
you
can
imagine
that
if
you
have
tons
of
triggers
and
tons
of
tons
of
these
subscriptions
and
tons
of
messages
being
generated,
it
might
tend
to
become
a
little
bit
more
complicated,
so
definitely
kind
of
like
my
first
experience
was
okay.
Yes,
I
know
how
to
build
my
application.
I
know
how
to
create
these
things.
A
The
idea
of
creating
triggers
on
top
of
the
broker
like
subscription,
based
that
you
wired
more
like
in
runtime,
not
when
you
are
designing
your
applications,
so
your
services
doesn't
know
about
each
other.
It's
pretty
cool,
it's
very
declarative
and
I
really
love
that
things
from
from
kennedy
preventing,
but
it
becomes
kind
of
like
a
thing
like
how
do
you
visualize
how
things
are
being
connected
together
at
a
given
time?
What's
the
sequence
of
events
that
needs
to
happen
in
order
to
complete
the
flow?
A
What
happens
when
you
want
to
change
the
sequence
you
know,
but
how
do
you
understand
what
was
the
sequence
that
was
excused
executed
yesterday?
What's
the
sequence
that
it's
required
today,
for
example,
it's
hard
to
see
where
things
are
at
the
given
time?
You
need
to
implement
some
kind
of
like
your
own
dashboard,
to
understand.
What's
going
on
and
when
things
go,
when
things
things
go
wrong,
it's
also
difficult
to
understand
what
exactly
is
going
wrong
right
like
did
you
miss
a
trigger?
Did
you
misconfigure
trigger
or
what's
going
on
right?
A
So
it's
good
to
know
that
gay
native
also
have
knd
flow,
which
basically
implements
a
bunch
of
things
about
a
couple
of
constructs
sequence
and
parallel
that
allows
you
to
start
defining
and
in
a
declarative
way,
these
kind
of
things,
and
it's
really
nice
from
these
concepts.
Again,
I
will
not
spend
time
explaining
these
concepts,
because
it's
the
canadian
meetup
that
again,
you
just
define
them
declaratively
and
they
also
start
doing
interesting
things
like
automatically
provisioning
channels.
A
You
know
this
important
sequence
of
events
or
how
to
process
a
cloud
event
against
like
different
services,
how
to
send
how
to
route
events
across
multiple
services,
which
is
a
really
interesting
idea,
and
that's
why
I
wanted
to
talk
a
little
bit
about
cv
because
cv,
it's
a
workflow
engine
and
it's
basically
designed
for
doing
this
kind
of
things.
So
there
is
an
overlap
there
with
k
native
flow,
but
this
is.
I
would
say
that
this
is
a
little
bit
more
high
level
right.
It's
not
the
replacement
for
that.
A
You
might
end
up
having
like
loads
of
different
events
at
different
levels.
Yeah,
you
know
one
more
technical
event,
more
high-level
events,
and
with
this
you
can
choose
exactly
which
events
are
you
interested
and
then
map
them
into
a
model
like
this
and
again
here
we
are
not
influencing
the
application
behavior
in
any
way.
A
These
are
the
instances
that
I've
started
before
when
I
did
the
first
demo
and
I
had
like
20
instances
running
in
there
and
I
completed
one
of
the
flows
right
and
now
I
created
a
new
one,
which
is
the
one
that
is
here,
I'm
already
out
of
the
queue.
I
should
reserve
my
tickets
and
let
me
see
if
I
can
order
them
in
the
right
way.
So
this
should
be
the
instance
that
I'm
looking
at
right.
So
what
I
can
do
here
is,
I
can
just
reserve
the
tickets.
A
Let's
say
that
I
want
to
reserve
four
tickets
and
I
should
be
able
to
see
here
that
this
you
know
flow
it's
moving
forward
as
soon
as
it
receives
the
events.
It
will
move
forward
right
now.
It's
waiting
for
the
payment,
so
pretty
easy
to
visualize.
If
I
go
back
to
the
dashboard,
I
can
see
all
the
instances
that
are
running
like
with
a
quick.
You
know
quick
overview
exactly
where
my
customers
are
by
just
mapping
the
application,
the
application
events
that
are
already
happening
right.
A
The
dashboard
that
I
showed
before
it's
called
operate.
That's
the
yellow
box
there
in
in
the
bottom,
and
the
workflow
engine
has
been
already
provisioned
and
it's
running
in
camunda
cloud.
So
it's
not
running
in
the
same
cluster,
where
I'm
running
the
services
of
my
applications,
but
the
workflow
engine
can
be
provisioned
in
the
same
cluster.
If
you
need
to
do
that,
because
you
are
in
an
on-prem
solution
or
something
like
that,
and
because
of
this
collect
of
architecture,
nothing
stop
us
to
say.
A
Okay
now
we
want
to,
you
know,
create
the
triggers
for
notifying
the
cloud
event
router
about
the
events
of
my
application.
So
the
only
thing
that
I
needed
to
do
in
order
to
tap
into
that
broker
and
get
the
events
been
sent
to
the
workflow
engine
is
just
to
create
an
extra
bunch
of
triggers
just
to
send
the
normal
events
to
the
right
services.
A
But
all
the
events
also
to
the
events
router
that
I
have
right
and
the
funny
thing
is
that,
because
I
have
a
model
here,
that
it's
defining
already
the
interests
in
different
event
types
I
can
automatically
generate
those
triggers
dynamically.
There
is
no
need
for
the
user
to
create
these
extra
triggers
right
if
they
are
defining
models
that
are
interested
in
events.
A
So
one
of
the
things
that
you
can
do
as
shown
here
is,
you
can
start
adding
timers,
for
example,
for
time-based
notifications
and
something
that
is
quite
common
keeping
track
of
time
and
then
sending
notifications
or
executing
actions
after
a
certain
amount
of
time
happen
right.
So
let
me
go
out
of
here,
just
go
to
the
model.
A
What
I
have
here
is
the
second
version
of
the
model,
and
what
I'm
doing
in
the
payment
section
is
basically
having
two
different
timers
one
timer,
that
it's
non-interrupting.
That
basically
means
that
I'm
going
to
do
something:
that's
not
going
to
influence
the
flow
of
the
application.
It's
just
going
to
in
this
case
send
a
reminder
right
and
then
I
have
another
timer
that
it's
going
to
influence
the
the
flow
of
the
application
in
this
case,
and
it's
going
to
just
notify
the
user
that
the
reservation
was
timeout.
A
So
this
is
a
little
bit
more
aggressive
right.
This
is
going
to
do
something,
and
then
I
have
these
two
extra
boxes
which
are
basically
creating
cloud
events,
so
I'm
just
going
one
step
further
further
and
now
I'm
generating
cloud
events
from
the
flow
right.
So
if
I
zoom
out
and
if
I
deploy
this
new
version,
so
basically
what
I'm
doing
now,
if
you're
using
a
workflow
engine,
usually
you
have
versioning
like
built
in
into
these
tools,
so
I
can
deploy
a
new
version.
A
I
should
be
able
to
go
back
to
the
dashboard
and
see
here
that
I
have
a
new
version
deployed.
Let
me
see
if
I
have
a
new
version
now
I
have
a
new
version
and
I've
configured
my
application
just
to
basically
use
the
latest
version
all
the
time.
So
now,
if
I
have
a
customer
that
is
coming
back
here
at
the
beginning,
it's
coming
back
at
the
beginning
and
joining
the
queue
it's
going
to
start
using
the
new
version
of
the
flow
that
I've
described
here.
A
So
at
some
point,
if
I
refresh,
I
should
be
able
to
have
a
new
instance
coming
being
created
here
with
this
model
and
of
course,
it's
going
to
take
more
time
than
usual
because
it's
a
live
demo
right,
that's
how
it
works.
Yeah,
that's
really
interesting.
Let's
wait
for
a
few
more
seconds.
If
it
doesn't
appear
there,
then
I
will
try
to
start
it
again.
It's
not
appearing!
That's
really
interesting!
A
A
A
Now
I
need
to
pay
now.
I'm
here
now
remember
that
I
changed
the
model
here,
just
to
schedule
some
timers.
So
as
soon
as
the
workflow
arrives
to
this
stage,
every
10
seconds
it
will
be,
it
will
start
sending
a
notification.
That's
what
this
timer
is
saying
every
10
seconds
you
just
do
that
and
that
sending
now
notification
is
basically
creating
a
new
cloud
event
that
is
sent
to
the
broker.
A
So
any
application
can
be
picking
those
events
and
in
this
case
the
front
end
is
already
configured
to
pick
those
events
and
show
here
a
notification
right.
So
I
have
have
a
cloud
event
being
emitted
every
10
seconds,
it's
appearing
here
and
then,
as
I
mentioned
before,
I
had
another
cloud
event:
that's
going
to
be
generated
when
you
know
the
reservation
time
out
after
two
minutes,
and
we
can
see
that
if
we
wait
for
two
minutes,
we
are
going
to
be
kick
out
from
our
current
session
back
to
the
queue
right.
A
A
We
we
in
in
the
workflow
terminology
orchestration
it's
a
little
bit
more
about
taking
control
and
making
you
know
flow
control
and
decisions
based
on
the
data
that
we
have
so
orchestration
is
when
you
take
control
of
the
things
of
the
flow
of
the
application,
so
not
only
consuming
and
mapping
things
that
are
happening,
but
also
executing
things
in
the
flow
right.
So
you
can
do
stuff
like
this
right,
so
you
can
have
more
complex
flow,
which
is,
for
example,
in
this
case,
using
a
soup
flow
here.
A
That
is
basically
saying
every
time
that
we
start
buying
the
tickets.
We
are
in
customer
buying
tickets
stage
or
milestone,
or
something
like
that
or,
like
you
know,
in
this
this
space
and
for
more
bigger
and
more
complex
flows.
That
makes
a
lot
of
sense
because
you
might
end
up
having
lots
of
events
being
emitted
or
consumed,
and
then
you
want
to
separate
them
in
different
stages,
and
it
also
allows
us
to
register
these
kind
of
boundary
events
that
basically
allows
us
to
say
no
matter
where
we
are
in
the
flow.
A
So,
as
also
as
you
can
see
here,
it's
like
we
are
just
not
listening
to
events,
but
we
are
also
generating
events
in
the
middle
of
the
normal
application
flow
right,
and
this
basically
having
these
kind
of
tools
that
allows
you
to
change
the
models.
Dynamically
and
deploy
new
versions
of
the
models
allows
you
that
flexibility
of
changing
and
adapting
to
you
know
changes
in
the
business
side
right.
A
A
So
it
might
be
interesting
to
create
some
kind
of
like
router
for
websockets.
That
does
that
automatically.
So
we
can
go
here
and
you
can
see
that
I'm
in
the
new
in
the
new
section
again.
This
here
is
highlighting
that
there
is
one
instance
in
this
section
and
if
I
go
and
generate
more
instances
here,
you
should
be
able
to
see
that
now
you
have
more
instances
being
created
there.
A
At
some
point
they
will
just
go
there
believe
me
and
it
might
be
because
they
are
completed
already
right.
So
I
can
see
here
also
with
some
filters
how
many
were
completed.
How
many
are
active,
and
also
I
something
that
I
didn't
show
that
I'm
planning
to
add
to
the
demonstration
is
incense
so
finding
when
things
are
going
wrong
right,
maybe
getting
events
out
of
order
or
maybe
getting
something
that
I
was
not
expecting.
A
A
So
basically,
there
is
a
crd
type
that
takes
this
model
and
allows
you
to
declarative,
say
I
have
a
new
flow.
Just
you
know
applied
with
qctl
and
then
automatically
deploy
that
into
the
infrastructure.
Deploy
that
into
the
workflow
engine
generate
all
the
triggers
that
you
need,
and
then
you
know
just
allow
the
users
to
create
new
instances
of
those
things
and,
of
course,
that
operator
nowadays
is
creating
instances
in
your
infrastructure.
But
it's
part
of
the
plan
to
also
be
able
to
create
instances
remotely
on
the
software.
A
As
a
service
approach
as
well,
so
that's
kind
of
like
one
of
the
things
that
I
will
be
working
on
in
future
iterations
next
steps
for
me
like
based
on
where
I
am
right
now.
It's
definitely
work
a
little
bit
more
on
those
templated
channels,
like
in
sequence
and
parallel,
so
I
just
want
to
be
able
to
replicate
the
same
experience
so
that
those
candidates,
you
know
native
types,
have
that
idea
of
creating
templated
channels
and
kind
of
like
improving
the
mechanisms
on
how
I'm
doing
things
on
the
on
the
workflow
side.
A
That
needs
to
need
some
more
refinement
than
I
will
appreciate
any
feedback
around
that
workflow
engines
also
they
are
being
built
by
default
to
you,
know,
mix
and
allow
interactions
between
humans
and
systems
and
events
in
this
case.
So
what
I
want
to
add
to
the
demo
is
something
like
an
intermediate
step.
So,
for
example,
in
here
where
the
user
is
like,
there
is
an
admin
user
or
someone
that
needs
to
execute
some
kind
of
like
tasks.
That
requires
a
specific
form
and
a
specific
connection.
A
So
I
can
just
model
that
and
include
user
interactions
in
here.
If
I'm
interested
to
do
that,
there
are
some
use
cases
that
make
it
more
clear
for,
like
you
know,
for
high
level
uses
and
again
the
thing
that
I
mentioned
about
web
sockets
using
stop,
I'm
not
using
stone.
Now
I
should
be
using
stump
and
also
I
was
looking
a
little
bit
into
our
socket,
which
looks
pretty
promising
so
kind
of
like
trying
to
understand
if
they
can.
A
If
it's
interesting,
the
canadian
community
is
interested
in
having
some
components
around
that
just
to
forward
cloud
events
and
just
to
being
able
to
build
these
more
organic
reactive
applications.
So
that's
pretty
much
my
presentation.
I
hope
that
I
didn't
spend
too
much
time
on
it
and
I
hope
that
I
give
enough
information,
for
you
know
for
getting
some
feedback
from
from
this
amazing
community.
A
B
A
Can
you
point
me
out
to
which
one
so,
for
example,
like
these
ones,
like
the
payment
reminder
yeah?
So
this
is?
This
is
not
a
delay.
This
is
a
timer,
so
this
is
like
a
recurring
timer
that
it's
going
to
trigger
an
event
every
like
a
timer
definition
right
like
so
you
can
say
every
10
seconds,
just
repeat
and
generate
that
event
and
as
soon
as
that
event
gets
triggered
you're
going
to
execute
whatever
this
is
in
this
case,
and
you
can
add
any
number
of
steps.
A
Yeah,
that's
a
good
question,
so
in
general,
let's
me,
let
me
go
back
here,
so
that's
part
of
this
piece
right.
The
workflow
engine
will
solve
that
for
you
in
a
transparent
way.
You
don't
really
need
to
care.
Where
is
that
running
because
again
the
functionality
that
that's
providing
it's
just
the
timer
service,
it's
like
a
cron
job
kind
of
thing,
but
it's
transparent
for
you
and
how
it's
running
and
in
the
back,
what
is
happening
is
that
this
workflow
engine
is
not
just
a
single
entity.
A
I
think
that
that's
a
quite
common
requirement
for
building
applications
also
having
like
ways
to
schedule
timers,
so
I
would
say
yes,
these
components
are
already
implementing
some
of
those.
So
how
do
you
define
that
in
canadian
as
well?
If
you
don't
want
to
use
these
components,
it's
a
very
good
question.
Yes,
I
could
think
that
it
might
be
a
good
stuff
to
have.
I.