►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello
once
again,
folks
welcome
to
thinking
out
loud.
This
is
number
17,
so
yeah.
This
is
really
cool
today,
we're,
as
you
may
know,
we're
gonna
have
james
or
cohort
and
clemens
fasteners
as
well.
So
we're
gonna
be
the
three
of
us
chatting
about
cloud
events
and
async
api
and
you
know
even
driven
architectures
and
even
the
worldwide
flow
which
we
might
have
to.
We
might
need
james
to
explain
what
is
this
concept
if
you
haven't
heard
about
it
really
cool
concept
that
way?
A
But
before
we
start,
let
me
just
do
the
usual
ceremony,
so
I
always
say
like
don't,
don't
be
shy
during
the
conversation
and
and
it's
true,
so
we
can
see
that
we
have
folks
from
dallas
and
guadalajara
in
mexico,
so
so
yeah
welcome
everyone,
and-
and
don't
I
mean
don't
hesitate
to
ask
questions,
let's
make
it
as
collaborative
as
possible.
We
can't
be
all
of
as
in
stream.
A
That
would
be
unmanageable
right,
but
we
can
all
be
chatting
and
via
text
via
chat,
right
and
and
having
conversation,
so
yeah
don't
have
to
hesitate
to
participate.
A
Closed
captions,
it's
not
available
in
twitch
and
other
platforms.
So
sorry
for
that
we'll
try
to
do
better
next
time
next
season
actually
and
yeah.
I
usually
continue
saying
that
please
follow
us
on
asking
kpi
spec,
because
you'll
see
lots
of
cool
stuff,
but
I
think
that
you'll
see
lots
of
cool
stuff.
A
That
could
be
interesting
for
you,
but
today
I
can't
continue
with
without
saying
something
that
that
guy
in
the
chat
lucas,
gornicky
told
me,
I
killed
you
if
you
don't
mention
it
and
he's
polished,
and
I
fear
him
so
so
yeah
I'll
have
to
mention
so
we're
organizing
the
async
api
conference
2022.
A
this
year
is
going
to
be
in
person
and
virtual.
It's
going
to
happen
in
november.
This
year
days
are
still
to
be
defined
and
you
can
find
more
information
in
conference
dot,
async
api.com,
but
a
specific
thing
that
I
want
to
highlight
here
is
we
don't
have
the
days
yet
exact
days?
We
don't
have
the
exact
location
yet
and-
and
that
is
all
because
we're
organizing
this
with
the
community,
so
we're
surveying
the
community
and
we're
telling
the
community
to
participate
and
and
say
like
hey.
A
Where
do
you
prefer
that
we
organize
this
this
conference
right?
So
we
have
like
a
list
of
locations
and
and
yeah
so
head
over
to
the
website,
and
there
you'll
see
a
survey
and
and
yeah.
So
you
can
collaborate
there
as
well
and
hey
michael
from
ottawa,
so
yeah
and.
A
That's
it
from
from
now
let
me
introduce
the
our
guests
today,
so
please
welcome
james
wood,
cohort
and
clemens
pastors
hey
folks,
good
afternoon
and
good
morning,
hello
morning
or
for
us
actually
evening,
almost
in
germany,
it's
almost
evening
in
spain
and
still
morning,
maybe.
B
A
C
A
So
yeah
thanks
thanks
a
lot
for
for
joining.
You
might,
as
you
might
want
to
introduce
yourself
and
explain
a
little
bit
better.
What
you
do,
who
you
are
and
so
on.
D
Who
starts?
Who
goes
for
change
sports?
All
right?
My
name
is
james
zurkert,
it's
been
a
long
time
writing
about
cloud
computing,
so
some
of
you
may
know
me
from
a
blog.
D
I
did
called
the
wisdom
of
clouds
years
ago,
but
I've
always
been
somebody
who's,
sort
of
very
analytical
about
technical
trans,
architectural
trends,
and
so
currently
I
work
for
vmware,
I'm
helping
out
with
the
vmware
tanzu
application
platform,
which
development
multi-cloud
development
platform
that
we
are
offering
and
I've
been
studying
and
working
very
closely
with
our
customers,
developers
and
and
operators,
and
sort
of
understanding
the
patterns
of
use
there.
And
then,
finally,
I
wrote
a
little
thing.
So
there
we
go.
D
D
He
has
a
sign
cap
somewhere,
but
but
we'll
talk
a
lot
more
about
the
the
subject
matter
of
the
book,
but
really
it's
focusing
on
what
I
think
is
going
to
be
a
dramatic
change
to
the
way
data
moves
online
as
things
like
async,
api
and
and
cloud
events
and
other
things
become
more
increasingly
adopted
as
standards
or
whatever
it
may
be
in
the
future,
because
there's
no
guarantees
yet.
But
so
that's.
B
Me,
okay,
clements
fastest.
I
am
the
lead
architect
for
all
the
messaging
services
in
the
azure
platform,
so
we
have
numerous
services,
event,
grid
service,
bus
event,
hubs
and
the
relay
that
are
kind
of
in
our
direct
team.
B
And
then
we
also
have
numerous
other
kind
of
services
that
are
messaging
related
in
the
azure
platform,
iot
hub,
signalr,
the
signalr
service
and
web
pops
up,
as
it's
called
for
non.net
platforms,
notification
hub,
so
there's
a
number
of
as
a
fairly
broad
portfolio
of
messaging
services,
which
are
then
which
we
liaison
with
and
they
use
the
the
base
that
we
built
under
the
covers,
and
architect
means
that.
I'm
also
that
I'm
dealing
with
technical
strategy,
part
of
technical
strategies,
also
standardization,
and
in
that
capacity
I've
been.
B
Working
on
horizontal
standards,
for
several
years,
I've
been
working
in
the
mkp
technical
committee,
I'm
the
co-chair
there.
I've
been
quarterbacking
our
efforts
in
the
mqtt
technical
committee
for
5.0,
and
I'm
a
member
directly.
Now
in
that
mpdtc
I
am
a
co-architect,
I
would
say
of
cncf
cloud
events.
We
don't
have
kind
of
formal
roles
in
that
effort,
but
I'm
I'll
just
claim
to
be
one
of
the
architects
of
it,
and
I've
also
been
involved
in
various
vertical
standards.
B
For
instance,
I've
been
working
with
the
opc
foundation.
That's
a
standardization
effort
for
the
for
the
manufacturing
industry,
automation,
industry,
who
are
standardizing
across
800
vendors.
I
think
who
make
industrial
machinery
and
they
have
a
communication
standard
and
it's
kind
of,
like
you,
think
of
it
as
as
more
usb
bluetooth
kind
of
model,
but
that
kind
of
start
allows
for
industrial
machinery
to
stick
to
to
click
together,
and
that
is
also
obviously
emitting
events,
and
so
we,
the
pops
up,
binding
for
how
can
these
industrial
machinery?
B
How
can
that
go
and
create
eventing
exhaust
into
it
systems?
That's
a
standard
called
opc
ua
pub
sub
and
I've
been
the
architect
for
it
in
in
that
effort,
I'm
so
fairly
broad
portfolio
of
involvement
in
in
standardization
and
so
cloud
events
is
currently
the
the
most
active
effort
that
I'm
that
I'm
involved
in.
A
That's
really
cool
and
extensive.
We
all
knew
that
you
were.
A
You
were
really
well
known
in
the
in
the
standards
space
specifically
for
eventually
architectures,
so
I
can't
only
say
like
thanks
for
all
your
work
in
mqp
and
qtt
and
cloud
events
like
you've
done
a
really
great
job,
so
so
yeah
thanks
a
lot
for
that
thanks
a
lot
both
for
all
the
jobs
you're
doing,
and
thanks
also
for
all
the
things
that
you
did
wrong
in
the
past.
So
so
we
can
learn
from
them.
A
No
just
kidding,
I'm
just
oh,
no,
no!
That's
a
balance.
B
It
is
important,
though
so,
for
instance,
doug
davis,
and
I
so
that
doug
is,
is
the
effectively
the
chair
of
the
cncf
condiments
group.
He
used
to
work
for
ibm
forever
and
then
he
just
recently
came
and
and
joined
us
at
microsoft,
which
we
were
very
honored
by
and
still
are,
and
but
but
doug
and
I
we
started
being
involved
in
this
whole
standardization
story
with
web
services
with
the
original
xml,
so
web
services
stuff.
B
Udi
for
the
younger
people
is
the
universal
discovery
and
directory
interface.
I
think-
and
that
was
an
xml
web
service
interface
for
doing
catalogs
of
web
services,
so
allowing
you
to
find
buy
criteria
a
web
service
endpoint
and
then
go
and
discover
effectively
its
wizzle
it.
So
it's
it's
it's
interface
definition
and
then
be
able
to
communicate
with
it
and
that's
a
completely
programmatic
fashion,
and
that's
something
that
would
be
fantastic
if
we
had
that
today.
B
But
we
don't,
because
it
was
embedded
in
this
giant
hairball
of
super
complicated
things
which
then
ultimately
was
sunk
by
w
security,
so
yeah.
So
so
it's
it's
good.
These
are
these
are
mistakes
from
the
past
that
we're
well
aware
of,
and
they
are
actually
benefiting,
the
cloud
events
effort,
for
instance,.
D
And,
and
by
the
way,
you
know
I'll
argue
and
there's
a
big
part
of
the
argument
behind
the
book
is
like
our
needs.
The
the
you
know
the
need
of
data
to
essentially
flow
to
where
it's
valuable
is
driving
a
lot
of
invention
that
that
helps
to
overcome
this.
You
know
the
first
of
all.
It
decides
standards
in
reality
and
then
second
and
then.
Secondly,
it
will
figure
out.
How
do
you
overcome
a
bad
standard,
a
bad
attempt
at
a
standard?
D
And
so
you
know
you
could
argue
that
the
replacement
for
uddi
that
we
have
today
is
google
right
and
and
stack
trace
and
and
a
number
of
services
that
people
can
use
to
discover
services
and
how
to
use
them
right
and-
and
I
in
the
book,
I
believe
that
there
will
be
a
formal
discovery
need
for
event.
Driven
this
and
we'll
talk
about
flow
a
little
bit
more,
but.
D
But
but
I
also,
I
clearly
admit
that
it
could
just
end
up
remaining
that
right.
It
could
just
end
up
remaining
that
human
beings
search
websites
and
they
find
the
descriptions
what
they
need
they
implement,
what
they
want
and
then.
D
Anyway,
it's
an
interesting,
that's
an
interesting
example
for
sure,
because
we
do,
we
did
learn
a
lot
from
that.
We
learned
a
lot
from
so
for
sure.
We
learned
a
lot
from
the
initial
definitions
of
object-oriented
architecture
and
and
the
attempt
to
sort
of
lock
down
definitions
of
of
spaces
and
domains
and
and
how
that
just
you
know,
wasn't
very
resilient
and
and
caused
us
more
problems
than
it
helped
to
solve,
and
so
we
would,
you
know,
I
I
think
to
me
again.
D
It
goes
towards
the
the
what
makes,
what
reduces
toil
and
reduces
risk
reduces
both
toil
and
risk.
If
you
don't
do
both,
then
you
can't
really
develop
with
it,
and,
and
so
I
think
we
are
getting
to
a
point
with
eda
now
with
the
event
driven
architectures.
Now
that
we
are
at
the
next
phase
of
looking
at
how
do
we
reduce
toil
for
certain
things?
We
do
with
events
and
how
do
we
reduce
the
risk
involved?
D
Not
only
with
you
know,
security
and
things
like
that,
but
but
the
risk
that
the
choices
we
make
will
burn
us
in
the
future.
And
so
so
you
know
which
brings
us
to
the
standards
and.
A
A
Yeah,
I
speaking
of
past
mistakes
I,
and
we
at
the
async
api.
We
have
a
few
things
to
say
and
actually
we're
working
towards
now
version
three
trying
to
solve
all
the
mistakes
that
we
did
in
version
two
and
previous
versions
and
and
yeah
like
this.
This
was
this
has
been
a
pain
for
us.
A
Like
you
know,
we've
been
committing
a
lot
of
mistakes
in
the
past,
trying
to
like,
first
of
all
and
and
and
the
biggest
one,
I
would
say-
is
treating
or
coming
up
with
asian
kpi
from
open
api.
You
know,
like
I,
just
duplicated
open
api
and
it
was
like
okay,
let's
just
change
some
things
and
get
put
post,
no,
who
needs
that
just
probably
subscribe
and
and
then
at
some
point
it's
like
there
was
an
inherent
mistake
there
that
was
almost
hidden.
A
That
was
that
the
perspective
of
the
of
the
operations,
the
publish
and
subscribe
right,
like
what
does
publish
and
subscribe
means.
Does
it
mean
that
the
application
is
publishing
or
subscribing
to
a
channel
topic
or
something
like
that
or
a
queue?
A
No,
it
means
that
a
potential
client
can
subscribe
to
the
one
that
you
are
providing
in
your
application,
which,
in
in
api
terms,
makes
total
sense.
It
is
like
here's,
the
endpoint,
you
can
request
and
you'll
get
a
response,
but
in
terms
of
even
driven
architectures,
some
of
them,
especially
broker-based
architectures.
A
It
is
highly
confusing.
It
is
kinda
backwards,
right
and
and
with,
for
instance,
with
with
web
sockets.
Client
server
model
in
web
sockets
also
works.
Well,
as
I
yeah
it's,
it
has
more
to
do
with
the
topology
right
like
client
and
server,
that
more
than
let's
say
the.
A
The
protocol
itself,
so
you
could
be
using
proto
websockets
with
a
broker
and
you
will
have
the
same
problem
so
yeah
so
when,
when
we've
been
always
trying
to
communicate
this
in
social
networks
as
well
like,
like
hey
we're,
trying
to
come
up
with
a
better
solution
for
this,
we
need
to
reorganize
the
whole
spec
and
that's
what
we're
doing
for
version
three.
A
It
was
still
in
the
process
so
help
us
shape
this
right
and-
and
I
remember
coming
from
clements
on
twitter,
saying
like
the
api
concept
on
the
so
that
that
goes.
That
question
goes
for
you
clements.
Let's
say
it's
like
you
said
something
like
the
the
api
concept
on
some
kpi
is
is
toxic
or
something
like
that.
A
I
think
you
said
so
and-
and
I
was
a
little
bit
like
what
does
he
mean
like
I
know
I
think
I
know
what
you
mean
but
yeah,
let's
just
let's
give
you
the
opportunity
to
explain
what
we
meant
there
and
then
and
I'll
continue.
B
Later
so,
there's
a
the
first
version,
so
the
first
version
of
async
api
that
I
looked
at
was
clearly
trying
to
model
an
api,
meaning
a
set
of
operations
with
requests
and
responses
over
asynchronous
channels,
and
that
is
something
that
people
do,
but
it's
not
doing
the
infrastructure
and
also
what
people
do
with
those
infrastructures,
justice,
and
it's
also
a
a
very
peer-to-peer,
focused
view
on
things
and
what
what
happens
with
eventing,
with
eventing
systems,
but
also
with
general
messaging,
is
that
flows
are
far
more
complicated
so
effectively.
B
If
you
are,
if
you're,
if
you're,
limiting
the
the
definition
of
a
contract
to
a
client
talking
to
a
party
and
then
make
that
kind
of
a
correlated
request
response
scenario.
That
is
something
that
satisfies
some
some
use
cases,
but
it
doesn't
allow
you
to
kind
of
create
a
view
of
the
greater
contract
that
exists.
There
is
a
standard
that
is,
unfortunately,
an
itu
standard,
which
means
it's
illegible
and
it's
itu-1.
B
B
I
have
x
amount
of
actors
and
those
extra
actors,
collaborate
on
on
getting
an
outcome
and
that's
actually
closer
to
the
reality
of
how
messaging
systems
are
being
used.
You
have
messaging
systems,
are
trying
to
establish
a
decoupled,
temporally
decoupled
and
also
comes
from
a
transactional
perspective,
decoupled
set
of
workflows
that
are
where
control
passes
through
through
message
flows.
B
I'm
not
talking
about
venting
for
the
moment,
but
really
talking
about
core
messaging
for
a
second.
So
you
order
something
from
a
website
when
you
once
you've
ordered
when
you're
ordering
something
from
the
website.
That's
already
kind
of
you're
being
handed
over
your
transactions
already
being
handed
over
through
cues
on
the
back
on
the
backs
on
the
back
side.
Sometimes,
but
then,
once
you
press
the
order
button,
your
payment
is
being
settled.
B
Your
order
is
being
transferred
to
one
or
two
more
fulfillment
centers,
the
fulfillment
centers
that
need
to
go
and
go,
and
you
know
collect
the
stuff
that
you
order.
You
need
to
go
and
package
them.
They
need
to
go
and
pass
information
onto
a
a
service.
That's
initiating
you
know
shipments.
The
shipment
is
then
being
being
confirmed.
Then
you
need
to
go
and
create
the
package
label
it.
B
So
there's
all
of
these
activities
and
all
of
them
are
kind
of
initiated
through
some
form
of
messaging
and
and
having
a
full
view
like
if
a
complete
view
of
that
whole
interaction
that
entire
flow,
I
think,
is
useful
as
a
con
as
a
contract
definition
and
then
out
of
that
entire
contract
definition,
you
get
effectively
a
slice
out
of
that
kind
of
the
messages
are
being
passed
between
two
swim
lanes
and
they
become
effectively
an
interface
that
is
then
implementable
by
one
of
those
actors.
Every
actor
that
kind
of
has
a
swim.
B
B
The
story
is
such
that
events
are
being
raised
as
statements
of
fact
and
not
of
j
as
jobs,
which
means
you
have
a
state
change
that
happens
in
the
system
and
the
system
has
no
expectation
of
anything
being
being
done
with
that
state
change.
So
let's
say
you
are
in
a
crm
system.
In
that
crm
system,
a
new
lead
has
been
created,
someone
a
sales,
a
sales
person
has
a
contact
with
a
person.
B
So
that's
an
that's
another
way
of
like
that's
where
the
pops
up
thing
comes
in
right.
You
have
your
publishing
information
and
then
you,
volunteering,
that
information
to
third
parties
and
the
third
part
is
kind
of
attached
to
those
things.
B
That
again
is
not
an
api
in
the
sense
of
you
making
a
command
but
you're,
basically
offering
information
up,
and
then
you
have
consumers
which
go
and
grab
that
data
on
the
other
side,
and
but
you
may
have
one
of
those
subscribers
you
may
have
n
of
those
subscribers
and
it's
a
feature
that
the
publishers
don't
know
who's
subscribing
right
and
that
they
can't
count
them
and
that
they
can't
give
them
instructions.
B
It's
a
feature
of
that
that
the
coupling
is
the
future
and
also
in
terms
of
temporal
decoupling,
being
able
to
put
a
job
into
a
queue
or
being
able
to
put
an
event
into
a
queue,
and
for
that
event,
then,
to
be
sitting
there
potentially
for
a
minute
10
minutes
an
hour
depending
on
what
the
load
on
the
on
the
back
end
is
that's
fine,
and
if
you
have
an
api
lens,
meaning
you
do
a
call,
and
that
call
is
something
you
await
or
just
block
on.
B
Then
the
characteristics
these
rpc-like
characteristics
assume
that
your
the
calling
thread
will
still
be
alive.
When
that
answer
comes
back
and
that's
often
not
true,
it
is
often
a
I
issue
this
activity
and
then
it
takes
a
while
for
that
to
complete
and
then
the
activity
will
go
and
come
back
will
be,
but
it
will
be
coming
back
that
information
will
come
back
on
effectively
on
a
callback
that
is
not
on
the
same
thread
that
issued
the
original
call.
A
So
as
as
you
were,
as
you
were
speaking,
you
were
mentioning
this,
like
this
whole
landscape
or
big
picture
of
how
the
activities
are
happening
right
like
what's
happening
in
the
big
picture
right
and
then
as
a
as
a
side
effect
of
defining
that,
then
you
could
get
slices,
as
you
mentioned,
write
slices
of
this
information
and
you
could
get
even
point-to-point
interactions
right
as
a
as
a
side
effect
of
that
now.
B
Certainly
the
contract
definition
that
you
will
use
to
go
and
generate
code
for
any
individual
party
which
plays
a
role
in
this,
is
going
to
be
scoped
to
the
few
messages
and
and
channels
that
they
use.
B
B
I
just
believe
that
this,
the
the
greater
picture
is
interesting.
Also,
these
are
unidirectional
flows
and
that's
that's
important
right.
It's
not
a
it's,
not
a
call.
It's
a
message
flow
and
that's
a
that's,
a
very,
very
important,
different
differentiation.
It's
not
an
operation,
that's
being
executed,
it's
it's
a
message,
flow,
that's
being
accepted
or
or
emitted.
D
It
is
important
to
note
that
the
act
of
subscribing
is
a
call
and
response
action
right.
The
act
of
saying
I
want
to
subscribe
to
this
message
flow,
so
it
always
starts
with
a
call
response
activity
in
the
initial
initiation
of
the
connection,
and
I
think
that's
important
to
note,
because
I
I
do
believe
that
there
will
be
that
the
pub
sub
part
of
this
is
gonna
absolutely
be
a.
D
D
If
you
want,
if
you're
going
to
work
in
a
complex
system
space
which
increasingly
these
things
are
absolutely
like-
one
critical
form
of
definition
of
an
adaptive
system,
but
if,
if
you're
going
to
work
in
these
spaces,
the
only
way
that
I've
seen
a
successfully
done
at
scale
at
all
is
that
you
need
a
picture
of
what's
going
on
across
the
system.
You
need
to
understand
the
flows.
You
need
to
understand
the
feedback
loops.
D
You
need
to
understand
who
the
good
actors
are,
who
the
best
bad
actors
are
right,
but
you
can
only
take
action
at
the
at
the
individual
agent.
You
can
only
change
what
other
agents
that
agent
is
connected
to
or
change
the
rule
set
that
the
agent
is
is
is
implementing
right.
D
And
so
from
that
perspective
I
think
you're.
I
think
you're
very
right
about
that
aspect,
and
so
when,
when
I
look
at
this,
I
really
haven't
thought
a
lot
about
this.
D
In
terms
of
contracts-
and
it's
probably
really
good
that
clemens
talks
to
that
stuff
for
me
when
I
really
think
about
in
terms
of
reducing
the
cost
of
integration,
which
is
really
kind
of
where
my
focus
has
been,
then
it
does
come
down
to
a
picture
like
what
you
you
talked
about
a
little
bit
from
right,
which
is
like
I'm
really
only
going
to
connect
to
individual
streams.
D
Maybe
you
know
whatever
and
then
I'm
going
to
do
whatever
processing.
It
is
against
that
data
if
there
are
no
problems
there,
and
but
I
do
agree
that
if
I
can't
visualize
how
the
system
is
flowing
to
the
scope
that
I
care
about
and
can
do
something
about.
If
I
can't
visualize
that,
then
I'm
gonna
have
a
absolute
really
high
risk
mess
on
my
hands
in
very,
very
short
orders.
D
That
is
something
that's
a
very,
very
complicated
thing,
and
maybe
it
may
end
up
being
super
simple
and
that
it's
just
you
know
human
and
or
or
simple
programmatic
relationships
to
say.
Yes,
I
process
that
event.
Okay
and
that's
enough
or
it
may
need
to
be
within
an
enterprise.
Much
more
sophisticated.
There
might
might
need
to
be
a
graph
aware
view-
and
you
know
I've
seen
this
week-
a
big
explosion
and
talk
about
graphql
and
and
things
related
to
that,
and
so
there
may
be
some
aspect
of
that.
D
That
comes
into
play,
that's
necessary
to
make
this
work
in
an
enterprise
scale.
I
almost
think
brett
ql,
specifically,
let
me
be
clear,
but
some
way
of
programmatically
being
able
to
understand
what's
happening
with
flow,
get
signals
when
we
need
to
be
responsive,
but
also
to
be
able
to
query
and
ask
the
system
what's
happening
here.
B
The
holistic,
this
holistic
perspective
is
important
for
complex
systems,
not
only
because,
because
once
the
flow
ends
right
messages
are
photons
and
and
once
the
the
data
is
no
longer
in
motion,
it
gets
stored
somewhere,
but
you
know
it's
still
the
same
data,
meaning
that
there
is
a
holistic
view
you
need.
That
is
goes
beyond
just
the
messaging
part.
B
So,
for
instance,
let's
talk
about
data
schemas
for
a
second,
we
we
go
and
move
data
around
that
is
schematized
structured
data
is,
is
the
most
common
that
we
move
and
the
way
how
the
structured
data
is
is
formed
is
because
of
business
shapes
business
requirements,
business
data
that
you're
flowing
may
that
be
you
know.
Business
may
also
be
something
that's
purely
technical
like
whether
it
comes
out
of
a
sensor
or
whatever
that
data
then
gets
gets
arc.
B
That
needs
to
be
put
somewhere.
That
schema
is
valuable
for
messaging,
but
it's
also
valuable
for
storage,
meaning
you
know
being
able
to
go
and
deal
with
deal
with
data
in
batches.
It's
also
important
for
stream
analytics,
meaning
you
you,
transport
data
with
with
an
event
stream
engine.
You
have
a
stream
analytics
engine
at
the
edge
of
it.
The
stream
analytics
analysis
engine
attaches
to
the
stream.
It
goes
and
reads
the
payloads.
It
needs
to
go
reason
about
the
payloads.
B
All
of
that
is
kind
of
schema,
driven,
which
means
the
schema
story
needs
to
be
one
that
works
across
all
those
platforms.
One
of
the
async
ipi
observations
is
because
of
the
open
api
heritage.
B
The
model
is
upside
down
because
it
starts
with
the
server
and
then
has
it
starts
with
the
end
point
basically
and
then
sorts
under
everything.
Underneath
with
this
messaging
story,
it's
actually
exactly
opposite
that
the
most
shared
piece
that
everybody
needs
to
go
and
deal
with
is
data
put
in
an
envelope,
moved
in
an
envelope
taken
out
of
the
envelope
and
now
being
handled
somewhere
else.
That
is
the
most
important
thing
at
in
in
ac
apis.
B
It
stands
it's
kind
of
the
thing
at
the
leave
of
the
definition
right,
because
it's
just
treated
as
a
and
that's
not
a
criticism
per
se
on
async
api,
but
it
comes
out
of
the
heritage
of
where
it
comes
from
right.
Open
api
is
treats
a
message
as
just
a
response
to
a
call
the
operation
thing,
parameters
for
the
operation
and
return
values
for
the
operation,
that's
the
central
aspect,
but
really
for
message:
flows
for
eventing
flows.
B
B
B
When
you
talk
about
a
candidate
list
of
events
that
may
come
out
of
the
of
a
pipe
so
that
you
can
go
and
do
a
drop
down
list
in
the
tool
and
say
okay,
which
of
these
five
events,
do
you
want
to
handle
okay,
this
one
all
right
go
and
generate
the
code,
that's
required
for
it
and
the
dispatch
the
dispatch
logic
for
it.
So
that's
the
the
the
order
is
schema
and
then
the
message
definition
and
then
those
met.
Those
message.
Definitions
may
then
be
grouped
together
and
form
effectively.
B
We
have
three
sources,
maybe
three
different
versions
of
sources,
which
are
three
different
devices
which
are
sending
data,
but
they
send
this
through
a
common
through
common
telemetry
path,
which
then
ends
up
in
an
analytics
platform
which
has
to
deal
with
all
these
three
single
streams.
At
the
same
time,
because
we
need
multiplexing
because
panels
are
impo
are
expensive,
etc.
So
that's
the
that's
and-
and
if
you
look
at
the
constructs,
we're
currently
working
on
the
cloud
events,
they
actually
mirror
that
we
have
a
schema
registry.
B
We
have
a
message
catalog,
and
so
we
have
these
base
pieces
that
we
believe
are
useful
and
valuable
for
just
this
basic,
this
basic
capability
of
annotating,
a
a
channel
with
the
messages
that
may
go
in
and
that
might
come
out.
A
So
that's
really
cool
and-
and-
and
I
love
that
you're
saying
this
because
it
maps
very
well
with
what
we
have
planned
so
far
for
version
three,
so
something
that
we
realize
is
is
precisely
the
importance
of
messages
or
events
and
and
the
flows
right
or
the
pipes
or
channels
or
call
it
wherever
you
want.
A
So
those
are
like
you
know
first,
first
class
citizens
now
in
the
spec,
all
of
them
right
and
but
we
still
have
something
that
we're
discussing
is
so
so
we
move
out
of
this
application
perspective
or
service
perspective
that
we
have
right
now
like
because
so
far
what
people
are
asking
us
is.
We
want
to
generate
code
as
much
as
possible
for
my
application,
so
I
need
to
understand
what
my
application,
or
what
this
application
is
doing
or
is
going
to
do
or
could
potentially
do
right.
A
So
is
it
going
to
publish
a
message
into
this
channel?
Is
it
going
to
subscribe
to
this
channel
and
and
receive
messages
that
are
flowing
there?
If
so,
what
are
the
messages
in
these
channels
so
or
how
they
look
like?
So
I
can
get
this.
I
can
generate
code,
I
can,
I
can
generate
documentation,
so
I
I
completely
get
your
vision
of
the
like
the
holistic
vision
of
the
organization.
Like
that's-
and
I
agree
like
this-
is
to
me.
A
That
is
the
best
way
to
unify
how
messaging
works
in
organization
or
in
the
world
in
the
case
of
worldwide
flow,
which
you'll
have,
let's
not
forget,
so
you
can
mention
something
about
it
and
but
then,
on
the
day
to
right,
job
developers
are
more
interested
in
something
they
can
deal
with
and
they
can
touch
right
and
those
globally
or
company
level.
Defined
rules
are
slow
per
se
for
for
for
development,
because
it's
not
it's
the
way.
A
Usually,
companies
work
like
responsibility
is
divided
by
teams
or
by
squads
or
whatever
you
want
to
call
it,
and
then
each
of
this,
and
especially
in
the
case
of
microservices,
which
is
and
not
just
micro
but
service,
oriented
architectures.
A
These
teams
have
the
the
responsibility
of
an
area
of
the
business
right,
and
so
they
want
to
create
applications
or
services
that
are
going
to
publish
and
subscribe
to
different
channels
and
they're
going
to
be
living
with
cross-cutting
concerns,
which
are
the
messages
right.
So
the
messages
probably
are
going
to
flow
to
another
team
responsibility
and
another
one
and
another
one
right.
A
So
when
I
proposed
back
in
new
relic
and
and
also
talking
to
some
friends
like
when
I
propose
like
why
don't
we
make
it
like
a
unified
thing
for
the
whole
company
and
if
you
want
to
add
something,
a
new
message,
a
new
channel,
something
like
that?
We
go
to
a
central
repository
if
we
want
our
central
place
and
everything
is
managed
there,
and
so
you
cannot
do
weird
stuff.
Everything
is
there
and
there
will
be
a
review
process.
So
architects
can
review
it.
A
It's
getting
overwhelmed
right,
yeah,
it's
getting
overwhelming
because
of
the
amount
of
of
requests
right,
so
they
were
looking
for
something
more
from
their
side
from
their
team
side
from
the
for
the
comfort
of
their
team
right,
and
so
they
can
expose
that
and
then,
as
a
side
effect.
They
were
like.
We
want
to
standardize
this
in
the
company.
Let's
make
sure
we
follow
guidelines,
but
some
companies
care
about
those
guidelines
and
some
companies
don't
care
at
all
right
because
they
don't
they
don't
need
or
they
don't
think
they
need
to
standardize.
A
This
message
driven
communication
right.
So
so
that
is
why,
like
like
my
my
concern
here,
is
that
are
we
forgetting
about
the
developers.
B
Daily
job
here,
so
what
so?
What?
So?
What
we're?
What
we're
doing
with
the
so
the
subworking
group
that's
currently
dealing
with
schemas
discovery
and
the
catalog
effectively.
What
were
so
we
have.
We
have
decided
what
we're
not
going
to
do
and-
and
we
are,
we
have
to
set
it.
What
we're
going
to
do
so.
We
have
decided
that
we
will
not
tackle
contract.
B
Yes,
because
we
think
that's
a
that's
a
huge
work
on
its
own
and
we
don't
think
we
want
to
go
and
bunch
that
into
into
together
with
what
we
do
and
contract
meaning.
What
is
the
relationship
of
the
application
to
messages
and
how
does
and
how
do
messages
correlate
with
each
other
and
do
they
correlate
at
all?
So
that's
an
area
where
async
api
is
actually
doing
work
and
that's
an
area
where
we
have
but
we're
actually
drawing
the
line.
I
said
we
have
been
looking
at
this
itu
spec
and
said
interesting.
B
There's
lots
to
cover,
there's
lots
of
value
in
there,
but
we
need
to
go
and
do
the
basics
first
yeah,
what
we,
what
we
are
aiming
for,
so
we
have.
We
have
drafts
of
these
three
specs
in
the
repo
right
now.
So
there's
schema
registry,
which
is
already
implemented
by
epicurio
and
event
hubs
in
azure.
There
is
the
the
discovery
spec
and
there's
the
message:
catalog
spec
we're
currently
trying
to
get
them
all
kind
of
integrated
into
a
single
into
a
single
effort.
B
That
single
effort
will
do
will
have
two
shapes
one
is
it's
gonna
have
a
document,
which
means
you
will
be
able
to
express
everything.
That's
expressible
in
these
three
things
in
a
single
dot,
which
means,
if
you,
if
you
start
as
a
developer,
you'll,
be
able
to
specify
the
schema
and
the
shape
of
your
messages
and
your
endpoint
in
a
single
place.
B
But
the
tool
should
always
be
the
the
tools
that
go
with
these.
These
specs
should
always
be
able
to
work
on
a
dock
and
that's
kind
of
the
local
experience.
That's
the
the
local
developer,
just
getting
started
and
just
want
to
want
to
do
their
local
thing,
but
that
should
also
also
work
with
that
central
repository,
because
there
are
companies
where
there
is
this
giant
central
repository
where
the
management
needs
to
happen.
B
Where,
for
legal
reasons,
there
needs
to
be
governance,
around
particular
fields
of
of
messages,
because
they
need
to
be
labeled
with
certain
labels
and
all
that
stuff.
That
needs
to
happen.
But
the
goal
is
that
we're
building
for
the
areas
of
schema
and
message,
definitions
and
then
discovering
these
endpoints.
Where
those
message
messages
go
flow
into
and
out
of,
that's
that's,
that's
the
scope
of
it
that
we
can
define
a
model
which
is
both
document
based
and
in
the
simplest
case,
in
a
single
doc,
and
also
can
go
and
spread
across
three
hyper
scale.
B
B
That's
why
I'm
saying
the
document
having
a
having
a
docky
you
can
go
and
check
in
with
your
repo,
which
is
the
foundation
for
the
code
that
you
generate
is
just
as
important
as
having
an
api
and
that's
the
first
iteration
that
we
did
with
these
with
these
services
or
with
those
definitions
that
were
purely
a
purely
api
based.
You
had
to
have
a
running
thing
to
make
those
things
usable
and
we
we're
now
saying
no,
no,
the
start
for
a
a
message
for
message.
B
Catalog
is
really
you
have
message,
definition
that
sit
in
the
github
repo,
and
then
you
may
have
a
smarter
thing
which
can
do
validations
as
except
for
with
a
dedicated
endpoint,
but
to
start
is,
is
have
a
loca.
Have
a
single
developer
be
able
to
go
and
define
all
those
things
on
their
local
box
as
a
start?
D
Okay,
I
see
what
you
mean
so
and
since
we
just
have
a
few
minutes
left,
I
want
I
wanted
to
pop
out
my
my
big
observation
about
sort
of
where
the
overlap
between
interfaces
and
protocol
exists,
which
is,
I
think,
is
pertinent
to
what
we're
just
talking
about,
which
is
the
more
I
look
at
it,
the
more
it
feels
like
it's
the
bindings,
it's
the
the
code
generation
for
the
for
the
interface
calls
that
enable
you
to
use
mqtt
or
amqp
or
websockets
or
whatever
it
is,
and
it's
the
it's.
D
D
I
know
that
there's
there's
strong
action
there
and
there's
still
a
a
binding
function
in
an
async
api,
at
least
in
two,
at
least
in
version
two
that
when
I
read
through
it
reads
like
oh
we're
going
to
take
care
of
the
data
mapping
as
well
as
this
just
sort
of
the
interface
mapping
piece
of
things,
and
so
that's
the
one.
B
D
A
Will
you
mind
expanding
on
the
worldwide
flow
concept?
Maybe
so
people
understand.
D
The
idea
behind
flow
architectures
is
is
pretty
straightforward,
I'm
I,
I
was
thinking
for
a
long
time
about
the
movement
of
data
towards
value,
and
you
know
I
have
this
mental
image
that
I
use
and
it's
helpful.
Sometimes
it's
circle
sometimes,
but
you
know,
when
you're
a
kid
you
took
a
bucket
of
water
you'd
run
up
the
beach
somewhere,
you
dump
the
bucket
of
water
and
you'd
watch
all
that
water
figure
out
a
way
to
get
back
to
the
lake
or
ocean
or
whatever
you're
talking
about
right
to
me.
D
Data
is
constantly
because
of
human
beings
and
human
needs,
and
greed,
and
all
that
stuff
right,
because
human
beings
are
directing
the
flow
of
data,
data
is
constantly
seeking
value.
It's
constantly
seeking
a
place
where
it
can
add
to
in
some
way
benefit
some
group
of
people
or
person
somewhere,
and
so
what
you
know
where
we
are
right
now
is
the
async.
Are
they
sorry,
the
api
economy,
kind
of
the
rest
world
kind
of
exploded,
the
idea
of
of
sort
of
commands
and
requests
being
made?
D
Sort
of
that
that
instant,
that
synchronous,
instant
conversation
becoming
something
that
sort
of
exploded
open
to
all
kinds
of
new
ways
of
doing
business-
and
I
was
thinking
very
much
about
event,
driven
and
going
well
streams
wow.
What
can
we
do
with
that,
and
I
had
breakfast
with
tim
o'reilly
one
day,
and
I
said
you
know-
I
tim
asked
me
what
I
was
currently
thinking
about
working
on,
and
I
said
this
is
the
thing.
D
That's
that
I'm
obsessed
with
right
now
is
what
would
happen
if
it
was
really
cheap
to
be
able
to
both
publish
data
that
other
people
find
valuable
and
consume
data
from
others.
That
is
valuable
in
the
form
of
events,
and
so
you
get
the
state
change
information
and
very
quickly
with
very
little
analysis.
I
came
to
the
conclusion
that,
oh,
my
god,
that's
going
to
open
the
floodgates
for
real-time
data
exchange
across
organization
boundaries.
I
mean
it
is
going
to
you
already
see
it
in
places
like
walmart.
D
They
were
already
starting
to
dictate
event
stream
requirements.
As
I
understand
it,
the
articles
that
I've
read
right,
where,
where
vendors,
have
to
sort
of
signal,
current
inventory
state
changes
in
order
for
walmart
to
be
able
to
clearly
express
on
their
website
that
we,
you
know,
we
can.
We
have
x
in
stock.
Well,
that's
because
we're
we
don't
have
it
in
stock,
but
our
vendors
have
it
and
stuff,
and
so
the
and
we're
seeing
it
with
the
faa
is
it.
D
This
is
the
one
with
solace
the
one
of
the
event
streaming
companies
our
event,
routing
companies
solace's
points
out.
The
faa
is:
has
a
massive
customer
base
that
are
just
consuming
event
streams.
Basically
using
you
know
again
their
proprietary
protocol
or
standard
interface.
It's
not
standard
that
other
people
are
using,
but
it's
already
happening
and
it's
already
incredibly
valuable
and
it's
already
changed
the
game
in
a
huge
way.
D
D
The
worldwide
flow
is
simply
than
the
idea
of
when
all
of
this
becomes
really
standard
and
programmers
don't
even
have
to
do
work
really
to
say
hey.
They
just
configure
something
to
say,
connect
to
the
stream
and
start
consuming
data
using
this
protocol
using
this
data
schema,
then,
at
that
point
in
time,
everything
all
activity
will
become
interconnected
and
so,
like
http,
connected
the
world's
information
and
created
the
world
wide
web
yep.
My
belief
is
that
these
flow
protocols
are
going
to
connect
the
world's
activity
and
create
the
worldwide
form.
A
C
A
B
A
A
few
years
from
now
so-
and
I
was
like
yes
so
now-
we
can
work
backwards
and
see
what
we
have
to
do
to
to
get
there
right.
So
that
is
that
is
actually
super
super
cool
and
just
to
to
wrap
up
a
little
bit
because
we're
already
over
time,
but
we
started
late.
So
let's
stay
fair
enough
for
a
few
more
minutes.
A
So
I
think
to
get
to
the
point
and
correct
me:
if
I'm
mistaken,
I
think
async,
api
and
cloud
events
have
to
collaborate
closer.
A
That
is
a
must,
because
we're
covering
different
areas
of
that
scenario
right,
so
they
need
to
be
integrated
somehow
and
in
the
next
versions
of
fixing
kpi
like,
I
said,
we're
kind
of
the
coupling
firm,
there's,
request,
response
or
there's
tree
and
leaves
that
that
clemens
was
mentioning
before
with
the
messages
and
the
servers
on
top
and
so
on.
So
that
would
be
good
enough
to
at
least
start
the
new,
the
new
reorganization
of
concepts
here
and
next
step.
A
For
me,
I
will
say,
at
least
for
me
what
I
would
love
this
to
to
be
done
is
in
async
api.
You
should
be
able
to
define
an
envelope
or,
more
specifically,
you
should
be
able
to
define
that
your
envelope
is
a
cloud
event
right.
If
you
want
to
call
it
an
envelope
or
if
you
want
to,
I
don't
know,
but
you
should
be
able
to
select
hey.
This
is
not
just
one
message,
any
kind
of
message.
A
This
is
a
cloud
event
message
right,
and
this
is
the
cloud
event
definition
it's
here
go
and
get
it
and
interpret
it
and
do
whatever
you
want
to
do
with
this
right
and
something
that
I
recently
discovered
by
going
to
the
cloud
events.
Repo
is
that
you
guys
are
working
on
a
subscription
api
and
the
discovery
api.
A
The
discovery
api
got
my
attention
because
we
were
kind
of
doing
some
similar
effort
on
sync
api
for
or
thinking
about
it,
but
not
doing
it
yet
for
version
3,
but
it
was
too
much
right.
So
I
was
thinking
that
maybe
that
discovery
api
this
discovery.
In
short,
like
this
discovery,
api
is
returning
a
list
of
services
right,
a
list
of
services
that
are
exposed
in
certain
events
and
so
on.
A
Right
so
and
those
services
are
defined
using
a
specific
format
that
you
created
on
cloud
events-
and
I
was
instantly
saying
this-
is
what
we're
doing
on
some
kpi
we're
defining
the
same
information
or
almost
the
same
information
like
cool
cloud
events,
be
returning
an
array
of
facing
kpi
documents
in
this
case
or
subset,
or
at
least
a
subset
of
ap
sync
api
documents
for
that.
So
so
everything
works
together
and
it's
like
completely
integrated
right.
So
you
want
to
use
cloud
events.
A
You
can
use
it
in
in
missing
kpi
if
you
want
to
use
this
in
kpi
in
the
discovery
api.
Sorry,
if
you're
going
to
use
the
discovery
api,
you
get
a
sync
api
in
that
list
and
then
you
get
the
snkpa
tools
instantly
ready
to
deal
with
those
things
right.
So
that
is
my
understanding
so
far
of
how
how
things
could
be
moving
forward
and
and
from
here.
This
is
like
a
statement
from
my
side
that
we
should
be
collaborating
yeah
more
actually,
not
more.
B
We
haven't,
we
haven't.
We
haven't
been
some
some
as
exhaust,
so
so
to
speak.
Of
that
definition,
work.
There
is
some
some
stuff
that
is
kind
of
in
nowhere
in
no
man's
land,
if
you
will,
for
instance,
cloud
events
is
very
condiment
is
focused
on
events,
which
means
unidirectional
flows
of
facts
and
and
kind
of
kind
of
constrained,
within
with
the
constraints
of
the
seven
attributes
that
we
have
and-
and
we
have
intentionally
stayed
away
from
correlation
or
anything
that
kind
of
drives
us
into
general
messaging
because
there
it
gets
complicated.
B
Right
from
the
mkp
side,
there
is
a
need
for
having
these
contract
definitions,
which
look
almost
exactly
alike
right.
We
need
to
have
the
same
kind
of
schema
registry
and
stuff
for
the
payloads.
We
also
need
to
have
definitions
and
templates
for
what
messages
look
like,
but
they're,
intended
for
a
different
purpose,
they're,
more
fully
kind
of
request,
response,
messaging,
there's,
a
notion
of
correlation
of
certain
kinds:
there
might
be
session
stuff
involved,
so
that
is
for
me.
B
It
makes
no
sense
for
that
to
be
a
very
different
dialect
of
how
how
you're
going
to
find
those
things
they're
just
defining
a
different
kind
of
message.
One
is
the
cloud
event
and
it's
a
broader
set,
and
then
you
have
a
narrower
story
which
kind
of
around
amqp
message:
brokers
which
have
cues
and
and
have
are
more
even
more
opinionated,
and
that's
something
that
async
api
covers
too.
B
So
when
I
think
of
message
catalog,
there
is
a
message:
catalog
schema
type
sort
of
that
is
cloud
events,
but
then
there's
also
a
message:
catalog
type,
that
is
an
npp
type
and
then
there's
an
mqtt
type,
potentially
so
and
and
those
things
don't
are
not
exactly
at
home
in
the
cloud
events
effort,
but
I
don't
think
they
need
to
be
different.
I
don't
think
we
need
to
have
a
completely
new
structure,
a
new,
a
different
kind
of
api,
just
because
the
base
schema
of
the
envelope
is
different.
B
So
that's
that's
an
area
of
of
collaboration
where
it
might
be
that
you
know
cloud
events
owns
the
the
shape
of
the
cloud
event,
definitions
and
the
cloud
event
schema
and
then
we'll
have
a
an
amqp
which
kind
of
defines
what
that
looks
like
and
then
maybe
there's
an
mqtt
collab,
which
goes
and
defines
what
the
other
things
look
like.
That's
something
we
can
go
and
take
a
look
at.
I'm
certainly
for
me
and
speaking
for
microsoft,
we're
totally
open
in
where
to
house
those
things,
especially
because
async
api
is
a
linux
foundation.
D
You
know,
I
think
it's
awesome,
and,
and
really
you
know
the
the
complexities.
I
think
one
of
the
things
that
this
conversation
really
hopefully
exposes
to
people
who
may
not
have
been
worried
is
it's
not
having
a
pub
sub
api
and,
having
a
you,
know,
a
message
and
payload
format
that
you
that
we
all
kind
of
agree
right:
basics
that
all
we're
all
kind
of
cool.
D
With
that
it's
it's
that
detail
level
of
of
how
do
you
make
sure
that
these
things
behave
well
in
a
variety
of
really
unusual
use
cases
that
makes
this
hard
and
where
the
conversations
really
have
to
go?
Where
does
the
interface
end?
Where
does
the
protocol
begin?
Where
does
the
wider
protocol
end
and
the
data
protocol
begin?
D
Those
are
the
hard
questions
that
we're
all
kind
of
beating
our
head
around
here,
and
so
it's
really
fun
watching
you
know
I
I
should
participate
more,
but
unfortunately,
my
day,
job
isn't
as
directly
related
to
this
stuff,
as
I
would
like
it
to
be
at
times,
and
so
you
don't
really
participate
in
it.
No,
this
is
so.
This
is
what
I
did
instead
right
is,
is
write
the
book
and
I'm
happy.
You
know
I'm
on
twitter,
as
as
we
all
are
and
happy
to
answer
questions
for
folks.
A
So
thanks
a
lot
folks
for
for
joining
today,
I
have
to
fill
in
that
we
left
lots
of
things
untouched.
So
maybe
we
have
to
be
meeting
again
in
the
future,
so
so
yeah
or.
A
Right
so
yeah
me
too,
I
will
be
super
happy
to
do
it
so
so
yeah
again
thanks
a
lot
for
joining
thanks.
Everyone
for
watching
and
participating
in
chat
thanks
chris
for
this
ituc,
120
name,
which
we're
cool
to
figure
out
so
yeah
thanks
a
lot.
Everyone
and
and
yeah
see
you
soon
and
thank
you
stay
well
he's
good.