►
Description
AsyncAPI Conference 2021 - Day 3
18th November 2021
The rise of Event Driven Architecture is a necessary evolutionary step towards cloud-native applications but events come also with challenges! One of the first you are facing when starting up as a development team - aside the technology choice - is how to describe these events structure? And then: how can we efficiently work as a team and improve collaboration to reduce the development life cycle and TTM (Time To market)? New standards like CloudEvents or AsyncAPI came up to address these needs allowing structure description. But, people often ask: Should I use CloudEvents or AsyncAPI? There is the belief that CloudEvents and AsyncAPI are competing on the same scope. I see things differently, and I’d like to explain why you may need both of them without increasing the level of complexity from the development perspective! I’ll also introduce Microcks: a tool to easily simulate and test CloudEvents and AsyncAPI combinations in minutes. In this session, we will: - Go over the introduction of both specifications, - Highlight their strengths and complementarity, - Give an overview of Microcks for mocking and testing “CloudEvent-ified AsyncAPIs” ;-)
A
A
First,
let
me
introduce
myself
so
my
name
is
lauren
brudu
and
I
am
wearing
many
hats
on
the
time.
I
am
wearing
a
red
one
being
a
solution
architect
at
red
hat,
working
on
clown
native
technologies
and
at
night
I
am
putting
on
my
my
open
source
contributor
suit
and
that's
why
I'm
here
talking
to
you
today
daily,
I
help
organizations
moving
to
cloud
native
architectures
and
practices
integrating
these
new
paradigms
with
their
legacy.
I
have
a
special
focus
on
everything
related
to
distributed
systems,
api
and
specifications
kubernetes
enterprise
integration
patterns.
A
A
A
It's
a
question
of
temporal
decoupling,
alluring
processing
of
events
in
real
time
or
a
long
time
after
their
creation.
It's
about
technical
decoupling,
allowing
different
technologies
to
be
used
to
be
integrated
together,
and
it's
about
runtime
decoupling,
adding
resiliency
and
retry
in
case
of
failures,
allowing
non-blocking
exchanges
enhancing
the
scalability
of
the
system.
A
But
we
know
now
that
the
the
rise
of
event-driven
architecture
often
comes
with
many
challenges.
If
this
architecture,
this
type
of
architecture,
it's
all
brand
new
for
you,
the
first
one
is
about
the
technology
choice,
and
this
is
a
very
broad
and
very
hot
topic.
It's
impossible
to
address
in
45
minutes.
We
are
not
that
ambitious,
but
I
think
it's
important
to
take
some
assumptions
on
this
one
as
it
may
have
consequences
on
the
two
of
us.
A
A
A
A
A
A
If
we
have
a
look
at
the
pain
you
try
to
solve,
it's
really
the
one
of
users
and
consumers
of
event-based
systems.
Let's
say
you
have
an
application,
a
system,
some
devices.
Whatever
on
the
left
that
present
eventing
capabilities
it
may
emit
or
process
asynchronous
messages
as
a
user
and
without
a
sync
api,
you
always
struggle
to
find
information
about
those
capabilities.
A
What
are
the
endpoints
and
protocols?
What
are
the
security
policies?
What
is
the
the
expected
data
format?
How
can
I
validate
my
message
and
so
on,
and
I
think
api
is
here
to
answer
that
its
goal
is
to
allow
an
easy
discovery
and
comprehensive
understanding
of
the
eventing
capabilities
of
the
system,
for
that
it
implies
the
the
same
principle
as
for
rest
apis,
so
that
event
endpoints
become
truly
managed
apis.
A
A
The
most
important
part
of
async
api
space
comes
from
the
channel
items.
Definitions
similar
to
the
paths
in
open
apis
channels
allow
us
to
to
define
endpoints
and
operation
on
these
endpoints
operations
are
of
kind,
publish
or
subscribe
and
are
holding
message
definitions
where
a
message
is
clearly
defined
using
headers
and
payload
data
schemas
informations.
A
A
The
spec
also
allows
you
to
to
define
components
like
schemas
traits
message,
definitions
that
you
may
reuse
across
different
channels
or
or
operations.
Okay.
So
now
we
have
a
broad
understanding
of
async
api.
Let's
look
at
cloud
events.
What
is
cloud
events
according
to
the
to
the
cloud
events.your
website?
It's
a
it's
also
a
specification
for
describing
even
data
in
a
common
way,
and
from
that
we
can
immediately
deduce
that
the
scope
of
cloud
events
is
more
narrow
than
the
one
of
a
sync
api
cloud.
A
Event's
focus
is
to
provide
command
formats
to
to
guarantee
interoperability
across
systems
and
platform.
In
fact,
it
defines
a
minimal
set
of
events,
metadata
and
serialization
rules.
For
that
cloud
event,
specification
is
organized
through
the
the
cloud
native
computing
foundation,
serverless
working
group
as
the
the
initial
work
around
cloud
events
was
triggered
by
the
need
to
deliver
invocation
events
to
serverless
and
function
as
a
service
framework.
A
A
A
So
we
can
find
the
cloud
event,
solutions
that
are
simply
general
purpose,
even
brokers.
That
is
what
is
providing
the
the
majority
of
cloud
providers,
but
cloud
event
is
also
very
well
suited
for
event-based
workflow
automation.
The
use
of
the
standard
by
the
orchestration
engine
guarantees
its
integral
interoperability.
A
A
A
The
core
specification
of
cloud
events
is
a
very
tiny
one,
as
it
just
defines
the
the
minimal
set
of
metadata
that
every
event
should
have
nothing
really
really
new
or
exotic
in
here.
It's
just
four
mandatory
attributes
and
for
optional
ones,
so
you've
got
attributes
for
defining
the
kind
of
events.
It's
the
spec
version
and
the
type
attributes
you've
got
attributes
to
clearly
identify
this.
The
event
this
is
the
the
id
attribute.
A
A
The
core
specification
also
defines
the
different
locations
or
modes
for
transporting
these
attributes.
The
binary
mode
is
adapted
to
two
existing
messages,
as
it
recommends
putting
the
metadata
attributes
outside
of
the
payload
within
the
protocol.
Headers,
the
structure
mode
defines
a
wrapped
message:
format
where,
where
the
metadatas
are
into
the
payload
wrapping
the
curved
data,
it's
indeed
very
useful
if
you
do
not
have
a
pre-existing
message
format.
A
In
my
opinion,
the
the
names
of
the
of
the
contact
modes
are
particularly
ambiguous,
as
you
can
carry
out
binary,
uncoded
data
using
the
structure
mode,
and
you
can
also
carry
out
text
and
coding
data
using
the
binary
model.
I
think
that
raw
and
enveloped
would
have
been
better
terms,
but
that's
how
it
is.
A
A
So
this
is
an
example
of
a
json
encoded,
structured
cloud
event
that
uses
the
http
protocol.
Imagine
you
have
pulled
a
get
endpoint
and
you
received
that
http
response.
The
first
thing
to
notice
in
structure
mode.
You
see
that
cloud
events
has
its
own
content
type.
It's
application,
slash
cloud
events
plus
json.
A
A
The
data
is
the
one
of
the
payload
and
the
response.
Content
type
is
simply
the
one
of
the
data
you
can
find
the
column
type
header
having
the
the
text.
Xml
value,
the
the
binary
content
mode
is
clearly
my
preferred
way
of
doing
things
as
a
it
allows
to
to
add
cloud
events
capabilities
to
existing
events,
but
also
because
I
think
it
leads
to
more
performant
implementation
of
the
middlewares
involved
in
routing
the
with
the
binary
mode.
A
A
A
Both
are
certainly
very
useful
when
dealing
with
large
system,
they
have
different
goals
to
provide
a
description
of
api
capabilities
on
one
side
to
ease
interoperability
on
the
other,
and
for
that
they
are
focusing
on
different
parts.
A
sync
api
helps
you
define
channels
to
be
used
for
applications,
and
let
you
choose
your
message.
Format
cloud
events
provides
you
useful
command
metadata
to
define
the
events
message,
format.
A
A
A
A
A
A
The
first
thing
would
be
to
cloud
identified
it,
so
we
define
a
type
to
make
the
difference
between
entering
or
exiting
the
frame.
This
is
the
bullet
one
and
we
you
can
see
that
we
also
have
a
lot
of
context.
Information
cloud
event
does
not
help
defining
the
data,
so
we
have
to
define
our
json
schema
outside
and
provide
it
into
the
data
schema
property.
A
A
For
the
moment,
this
is
an
extract
of
my
async
api
definition
for
my
animal
sensor,
and
you
first
see
the
different
channels-
definitions
here
and,
as
we
have
no
mean
in
business
data,
to
make
the
difference
between
in
and
out
events,
we
define
two
different
channels
that
may
result
in
kafka
topics.
For
example,
as
a
sync
api
leverages,
the
json
schema
it's
now
possible,
also
to
define
and
embed
the
description
of
the
carry
data
in
a
formal
way.
A
First,
we
structure
the
content
mode.
Okay,
so
we
now
have
to
change
harassing
kpi
file
and
you
can
see
on
the
the
first
bullet
that
we
just
have
to
add
a
reference
to
the
cloud
event
spec
here
in
the
message.
Payload
we
can
refine
different
types
of
events,
okay
and
we
can
locally
define
now
the
carried
out
data
schema
so
within
the
animal
data
type
we'll
find
that
the
same
properties
definition
as
before.
A
Let's
now
see
binary
content
mode
and
to
spice
up
things,
we
can
use
another
binary
encoding
on
the
data
this
time,
so
the
first
thing
will
be
to
to
define
another
schema
describing
a
new
animal
record
type.
This
has
to
be
saved
into
a
specific
avro
schema
file.
So
this
is
my
overall
record
definition
and
now,
looking
at
the
async
api
document,
you'll
see
that
we
have
changed
the
content
type
of
the
message
to
binary
avro
and
we
are
referring
to
navro
schema.
A
A
A
An
important
thing
in
starting
every
project.
Is
the
feedback
loop?
How
to
ensure
that
we
we
design
that
what
we
design
is
of
value
for
people
who
are
using
it
in
the
context
of
an
event-driven
system?
There's
the
the
additional
difficulty
of
having
access
to
the
infrastructure
it's
better
to
to
not
have
to
wait
for
the
sensor
to
be
plugged
and
to
detect
animals
in
the
garden
to
start
developments
of
processing
and
giving
feedback.
So
that's
the
problem
we
are
going
to
address
now
and
specifically
to
address
it.
A
A
Often
we
neglect
the
the
importance
of
examples
most
of
the
time
we
let
some
tools
generate
them
and,
finally,
all
the
string
properties
have
a
value
of
string.
All
the
number
of
properties
may
have
a
value
of
1
and
so
on,
but
I
do
think
that
it's
a
best
practice
to
pay
a
great
attention
to
the
examples,
because
they
should
represent
a
real
life
scenario
and
when
carefully
chosen
examples
can
be
really
good
illustration
of
business
expectations
and
that
they
can
be
later
used
as
executable
specifications.
A
A
Let
me
see
just
one
words
on
my
crocs,
my
crocs,
the
project
I
started
some
years
ago
and
it
reached
the
1.4
release.
Last
month,
it's
an
open
source,
kubernetes
native
tooling.
It
provides
a
tooling
for
api
marking
and
testing.
We
are
tackling
three
specific
concepts
when
dealing
with
with
api
of
macrox.
The
the
number
one
is
to
shorten
the
feedback
loop,
because
apim
are
products.
A
People
are
adopting
agile
methodologies,
so
they
want
to
get
feedback
very
early
in
the
process
and
they
want
to
be
able
to
rapidly
evaluate
new
changes.
So
this
is
the
main
driver.
The
the
number
two
is
how
to
parallelize
developments,
because
once
we
decide
what
is
the
api
to
develop,
we
absolutely
absolutely
want
to
avoid
any
bottleneck.
We
we
do
not
want
to
have
developers
consuming
apis
to
wait
for
back
end,
in
our
case,
wait
to
have
the
animal
sensor
plug
it
in
the
garden
number
three:
it's
how
to
validate
implementation.
A
This
point
is
getting
vision
when
you
are
releasing
numerous
versions
of
your
api
and
you
will
need
to
be
sure
that
your
implementation
is
still
backward
compatible.
So
microx
is
able
to
realize
contract
testing
with
each
and
every
changes,
the
big
differentiator
in
for
all
kind
of
apis,
even
driven
apis,
of
course,
but
also
rest
apis
legacy,
software
services
or
grpc
services.
A
So,
in
a
nutshell,
microx
proposed
two
different
use
cases.
The
first
one
is
about
simulation
or
mocking
it
integrates
with
your
source
of
truth,
your
git
repository
it
discovers
and
generates
live
endpoints
in
seconds,
so
the
api
consumers
can
start
playing
with
the
api
as
it
was
live
as
it
was
already
developed.
Without
writing
a
single
line
of
codes.
Okay,
the
second
one
is
about
ensuring
compliance.
A
So
once
your
team
has
started,
you
can
plug
in
minkrox,
within
your
your
favorite
ci
cd
pipeline
runner
and
within
each
and
every
comment
you
check
if
changes
break
compliance
on
your
api
version
contract.
Okay.
So
let's
finish
our
talk
with
a
rapid
demonstration
microx
on
our
garden
sensor,
use
case.
A
First
things
we
can
see
here
is
a
sync
api
definition
that
has
been
loaded
into
the
sync
api
studio
online
and
we'll
find
here
animal
sensor,
structure,
api.
This
is
the
structural
version
of
this
api,
and
one
thing
we
have
started
with
is
to
add
examples
to
this
api.
So
here
I
have
defined
two
examples
right
here
and
I
have
just
defined
them
using
yaml
structure.
A
Okay,
this
specific
notation
is
indeed
understand
by
by
microsoft
later
on,
we
will
be
able
to
to
produce
some
dynamic
values
within
the
the
example-
and
this
is
very
nice
for
the
different
consumers
that
will
play
with
this
exam
so
that
they
have
a
dynamic
data
with
a
rich
data
sets
okay.
So
let's
now
imagine
I'm
happy
with
this
design
and
I
can
save
everything
into
my
source
of
truth
into
my
git
repository.
A
The
next
step
is
now
to
import
everything
into
the
microx
tooling.
Here
I
have
the
microx
tooling
running.
Okay,
it
can
act
as
a
central
repository
for
all
your
api
and
services
definitions,
but
the
the
repositories
is
empty
for
the
moment.
Okay,
so
you
can
manually,
add
new
definitions
by
uploading
contracts
and
specifications,
but
you
can
also
import
them
from
your
source
of
truth.
A
From
your
git
repository
using
an
importer
importer
will
allow
you
to
to
define
a
scheduled
import
or
to
define
web
books
so
that
with
each
and
every
design,
revision
micros
will
be
updated
with
the
latest
changes.
So,
let's
start
with
the
the
structure
version
of
this
api
and
we
will
activate
it
into
microsoft.
A
It
will
normally
discovered
this
api
and
yes
populate
the
repository
right
here
we
found
we
find
the
animal
sensor
structure,
api,
okay,
we
have
access
to
the
async
api
contract
and
documentation,
okay,
and
we
can
see
the
detail
of
operation
the
subscription
when
you've
got
animal
detections
and
just
right
here,
you'll
see
that
microx
has
found
two
samples.
Two
marks
that
were
defined
within
our
specifications.
A
Microx
is
able
to
manage
different
protocol
bindings
for
your
async
api
kafka,
mqtt
or
websocket.
Kafka
is
currently
the
default
one.
So,
just
after
having
imported
the
api
definitions,
micros
has
created
for
us
a
new
kafka
topic
for
this
api
and
each
and
every
three
seconds
it
will
publish
new
messages
on
this
topic.
So
as
an
api
consumer,
I
can
just
start
playing
with
the
the
topic
that
is
managed
by
by
microx
and
each
and
every
three
seconds.
A
A
Microx
allows
you
to
bootstrap
your
feedback
loop,
okay,
and
we
can
check
that
each
event
right
here
has
a
unique
identifier
and
a
generated
timestamp
for
each
and
every
message:
okay,
so
very
nice.
Let's
now
check
the
the
binary
version
of
this
api
and
the
particularity
of
the
binary
version.
So
in
the
binary
version
I
want
to
use
a
binary
encoding,
so
I
have
had
a
reference
to
a
narrow
schema
within
my
async
api
file,
as
demonstrated
before
during
the
presentation.
A
The
schema
registry
will
allow
your
your
api
consumer
to
dynamically
retrieve
the
avro
contract
so
that
they
are
able
to
deserialize
the
data
carried
out
by
the
by
the
event
so
connected
to
microx.
I
have
a
schema
registry,
I'm
using
the
pico
registry,
that
is
for
the
moment
empty,
and
we
are
going
to
activate
this
api
in
micros
so
like
previously,
it
has
detected
this
api.
The
binary
version
you
can
see
that
it
has
also
found
the
avro
schema
right
here
and
you
have
the
details
on
the
operation
as
well.
A
So
this
time
the
different
cloud
events
meta
tata
is
mapped,
is
projected
onto
the
different
headers.
Okay
and
you'll
have
the
the
avro
data
of
the
sample
that
is
represented
as
json
right
here.
It's
better
to
to
display
json
here,
because
it
can
be
read
by
the
by
humans
like
before.
Microx
has
a
created,
a
topic
for
us,
okay,
but
also
it
has
dynamically
published
the
arrow
schema
on
the
registry.
A
So
now,
as
an
api
consumers
that
is
dealing
with
row,
I
can
directly
reuse
the
topic
that
has
been
generated
for
me
by
micros.
So
this
is
the
the
binary
topic
I
will
use,
but
this
time
I
specify
that
the
value
is
avo
binary
available
and
I
will
have
to
use
the
registry
to
dynamically
retrieve
the
schema
and
you
can
see
this
time.
Yes,
that's
it
each
and
every
three
seconds
I
still
receive
new
events.
A
I
have
all
the
cloud
events
related
metadata
that
are
provided
within
the
headers
by
microx
and
the
avro.
That
is
put
here
and
deserialized
and
displayed
as
json
for
for
ease
of
read,
so
you
can
see
that
by
setting
up
microx,
you
can
very
efficiently
set
up
a
feedback,
loop
and
bootstrap
your
development
team,
so
that
they
can
start
developing
in
parallels,
even
without
writing
a
single
line
of
code.
A
Okay,
so
let's
wrap
up
things,
we
addressed
the
three
eda
challenges
we
pre.
We
previously
identified
adding
a
mix
of
examples
and
microx
tooling
to
do
to
the
previous
one
to
ensure
a
quick
bootstrap
of
your
project.
Of
course,
it
required
a
lot
more
to
to
guarantee
efficiency
during
the
the
wall
project
life.