►
From YouTube: Flow Architectures: The Future of Streaming and Event-Driven Integration - James Urquhart (VMWare)
Description
Flow Architectures: The Future of Streaming and Event-Driven Integration
James Urquhart (VMWare)
2021-03-19
OpenShift Commons Briefing
hosted by Diane Mueller (Red Hat)
Upcoming Talks: https://commons.openshift.org/events.html
#TransformationFriday #GTO
Abstract: Software development today is embracing events and streaming data, which optimizes not only how technology interacts but also how businesses integrate with one another to meet customer needs. This phenomenon, called flow, consists of patterns and standards that determine which activity and related data is communicated between parties over the internet.
In this briefing VMWare’s James Urquhart, global field CTO, author of the recently published O’Reilly book,”Flow Architectures: The Future of Streaming and Event-Driven Integration” will discuss the process and explore critical implications of that evolution: What happens when events and data streams help you discover new activity sources to enhance existing businesses or drive new markets? What technologies and architectural patterns can position your company for opportunities enabled by flow?
A
B
B
What
am
I
going
to
do
here
and
you
know
what
what
are
the
what's
the
next
big
thing
and,
of
course,
there's
a
million
next
big
things.
There's
not
just
one
but
the
one
that
struck
me
was
event
driven
architectures,
because
that
that
flow
of
information
and
removing
barriers
to
real-time
use
of
information
in
both
customer
experiences,
data
analysis
and
so
on
was
really
interesting
to
me.
So
that's
where
this
book
came
from.
B
So
what
it's?
What
are
we
going
to
talk
about
today?
We're
going
to
talk
about
the
future
in
reality,
we're
going
to
talk
about
something
a
little
bit
less
than
flying
cars
and
all
that
kind
of
stuff.
We
are
talking
to
talk
about
the
ways
that
organizations
are
are
looking
to
to
combine
their
real-time
information
with
that
of
others
to
take
action
and
so
kind
of
the
tagline
of
the
flow
architecture
book
and
we'll
define
flow
here
in
a
second.
B
B
What
I'm
talking
about
when
I
talk
about
flow
is
event
driven
integration
across
organization
boundaries,
so
not
just
within
a
single
application,
but
across
different
organizations
within
a
large
corporation
or
even
different
corporate
companies,
and
ideally,
in
the
long
term,
the
real
valuable
thing
will
be
when
different
companies
can
share
real-time
data
streams
with
each
other
through
standard
interfaces
and
protocols.
And
that's
really
the
thing:
that's
not
there
today.
The
thing
that's
not
there
today
is
that
there's
something
like
http.
B
That's
super
simple:
that
everybody's
code
is
written
to
consume
that
everybody,
you
know
very
quickly,
recognizes
what
a
you
know,
what
a
uri
is
for
it.
What
a
link
is
for
it
and
knows
how
to
how
to
take
advantage
of
that
knows
how
to
put
stuff
out
there
on
into
a
into
a
stream
and
so
on,
and
so
so
what
we're
gonna
do
is
talk
through
a
little
bit
more
in
detail
about
about
what
this
simple
definition
does
in
terms
of
in
terms
of
changing
the
game.
A
little
bit
I'll.
B
And
hopefully
this
will
give
you
an
idea
about
the
specificity
of
that
the
first
you
know
the
idea
is
that
consumers
are
in
are
have
control,
are
in
charge
of
making
requests
to
to
connect
to
streams
right,
so
so
they
they
can.
They
can
their
self-service
interface
can
say:
hey
I'd
like
to
start
receiving.
The
events
from
from
stream
x
say
receive
these
weather
events
from
the
from
the
national
weather
service
and
and
maybe
even
put
some
more
information
in
there
about
specifically
what
they
want
to
receive.
B
Producers
then
get
to
choose
who
they
allow
to
see
those
streams
and
and
which
requests
to
accept
or
reject.
Now
this,
I
I
do
say,
or
their
agents
in
here
frequently
just
real
quick
note
about
that.
In
reality,
it's
probably
not
the
actual
data
producer
or
the
actual
data
consumer
that
will
control
that
that
logical
connection
between
the
environments
there's
very
likely
to
be
infrastructure
involved
in
this,
and
there
are
a
number
of
companies
doing
really
interesting
things
in
that
space.
B
In
terms
of
sort
of
decoupling,
you
from
the
mechanics
of
establishing
one
of
these
connections
that
we're
talking
about.
So
keep
that
in
mind
when
I
say
producers,
it
could
be
that
a
producer
is
using
a
technology
that
does
this
for
them
or
a
service
that
does
this,
for
them,
consumers
or
their
agents,
don't
have
to
actively
request
it,
and
this
is
really
you
know.
This
is
what
streaming's
about
right
is
the
push
data.
B
So
when
an
event
occurs,
an
event
is
sent
and
the
consumer
receives
it
and
then
can
decide
what
they
want
to
do
do
with
it.
At
that
point
in
time
it
may
get
pushed
to
a
queue
on
their
behalf
so
that
they
can
retrieve
it
when
they're
ready
to
retrieve
it.
You
know
all
those
kinds
of
things
certainly
come
into
play,
but
the
logical
ideas
that
consumers
once
they
subscribe,
they
don't
have
to
actively
request
data.
B
The
data
is
coming
to
them
in
a
mechanism
that
is
pushed
to
them
and
then
finally,
producers
maintain
control
or
not.
Finally,
producers
maintain
control
of
what
events
are
transmitted
to
whom
and
when
so
they
are
at.
You
know,
basically,
as
the
as
the
the
party
that
is
pushing
data,
they
decide
what
data
they
want
to
push
in
a
given
stream
and
when
they
want
to
push
that
data
in
a
given
stream
and
then
the
last
they
are
transmitted
over
the
network
using
standard
protocol.
B
So
this
includes
things
like
tcp,
ip
and
tls,
and
you
know
all
that
kind
of
stuff,
but
but
it
also
includes
to
be
determined
protocols
specifically
designed
for
flow
mechanics,
and
that
includes
not
only
the
protocol
for
how
we
contain
and
package
events
and
the
metadata
related
to
events
which
we'll
talk
about
a
little
bit
more
significantly
here,
but
also
things
like
flow
control
and
and
requesting.
Maybe
a
series
of
events
from
a
certain
time
range.
Those
kinds
of
things
will
probably
be
also
defined
specifically
for
flow
over
time.
B
So
for
many
of
you
might
go
okay,
so
so
it
sounds
like
apis
a
little
bit,
but
it's
not
just
apis.
I
get
that,
but
now
it
sounds
like
pub
sub
and
my
answer
is
sure.
That's
probably
the
dominant
model.
Here
we
are
probably
talking
about
most
often
concepts
around
publish
and
subscribe
being
applied
into
the
way
that
streams
are
consumed
across
organizational
boundaries.
But
in
reality,
if
you
look
at
that
definition,
you
could
do
individual
connections
to
a
you
know
to
a
dedicated
uri
of
some
sort.
B
That
says:
hey
just
start
sending
me
events
over
this
connection
that
doesn't
really
have
the
full
semantics
of
publish
and
subscribe.
There's
not
really
topics.
There's
not
really.
You
know
a
a
subscription
id
or
a
or
a
stream
id
of
some
sort
that
is
used
to
figure
out
who
gets
what,
but
that
there's
more
of
a
direct
decision
to
make
connections.
B
But
so
you
know
just
keep
that
in
mind
that
you
know.
I
believe
that,
and
I
think
everybody
who's
been
looking
at
this
believes
absolutely
publishes.
Scribe
will
be
the
dominant
model,
but
it
doesn't
100
have
to
be,
and
so
we
can't
really
predict
that
it's
definitely
100.
You
know
100
gonna
be
published
and
subscribe.
B
So
one
thing
is:
is
when
we
have
standard
interfaces
and
protocols
we're
going
to
lower
the
cost
of
integration
of
real-time
data
integration
by
at
least
an
order
of
magnitude,
and
I
would
argue,
there's
a
good
chance
that
we
lower
it
by
orders
of
magnitude
we're
going
to
make
europe
the
ability
of
say
a
you
know.
Let's
say
a
a
a
service
company
to
to
understand.
B
You
also
get
increased
flexibility
of
solutions
so
now
because
of
the
decoupled
nature
of
this
sort
of
publish
and
subscribe
model
or
or
this
this
flow
connection
model
it's
much
easier
to
compose
solutions.
If
we
have
standard
protocols
where
you
can
say
all
right,
I
understand
what's
contained
in
the
event,
and
I
understand
what
I
need
to
know
to
interpret
the
payload
of
the
event.
You
can
begin
to
link
things
together
in
unexpected
ways,
which
is
the
the
parallel
I
give
to,
that
is
the
linux
command
line
and
piping.
B
It's
very
similar.
You
know,
because
you
know
ascii
is
being
sent
as
output
from
most
of
these
things
to
be
consumed
as
input
in
the
next
thing.
You
can
use
piping
to
link
things
together
in
really
really
interesting
ways,
and-
and
in
fact
this
you
know,
the
entire
industry
is.
Is
the
operation
side?
B
Is
largely
built
on
scripts
that
use
piping
fairly
regularly,
but
you
know
I
I
you
can
see
this
kind
of
manifesting
in
terms
of
the
interesting
new
ways
of
composing
things
like
if
I
have
a
business
process
to
what
we've
typically
done
up
to
now
is
we
have
outsourced
entire
business
processes.
So
you
know
my
payroll
process.
B
As
we
connect
the
world's
infra
activity,
the
expectation
will
be,
if
you
want
to
understand,
what's
happening
in
real
time
from
vendor
a
then
use
flow
to
subscribe
to
their
streams
and
and
it
will
grow
that
vendor's
ecosystem
that
much
more
and
the
overall
ecosystem.
Now,
why
would
anybody
even
want
this?
Well?
B
We
can
have
this
data
in
real
time
and
be
able
to
put
the
pieces
together
is
really
important.
But
what
turned
out
to
be
the
the
highest
thing
in
the
poll
in
terms
of
why
people
would
want
to
to?
Basically,
you
know:
do
digital
transformation
and
build
a
more
real-time
experience
is
employee
productivity,
which
is
not
super
surprising.
B
You
know
and
and
the
only
way
to
get
that
activity
is
for
you
to
have
an
employee
that
does
it
or
a
computer
application.
That
does
it.
If
you
could
basically
say
hey,
I
want
to
consume
that
that
sort
of
very,
very
standard
commodity
activity
as
a
service
you're,
very
likely
to
say.
Okay,
that's
great.
If
I
can
do
it
in
a
timely
fashion,
I
would
love
to
do
that
and
not
have
to
carry.
B
You
know
available
trucking
capacity,
information
in
from
from
say
you
know
an
uber
cargo
service
or
something
all
those
lines.
Those
things
are,
you
know
you
could
say:
hey
you
know.
Is
there
something?
I
can
add
a
value
here,
or
I've
got
an
idea
for
something
of
added
value
and
it
you
know
it's
like
cloud
computing
has
done
in
terms
of
getting
infrastructure
to
try
to
do
applications
at
scale.
B
Okay,
so
all
right,
this
is
all
cool.
This
is
all
the
value,
but
but
how
does
it
work
right?
How?
How
is
this
all
going
to
come
together
before
I
get
into
that
too
deeply?
What
I'd
like
to
do
is
just
kind
of
point
out.
One
thing
which
is
when
you
talk
about
flow,
and
you
talk
about
the
movement
of
data
just
flow
in
flow,
without
interaction
with
that
data
is
just
moving
data.
It's
just
moving
data
around
the
internet
for
no
good
reason.
B
So
as
we
evaluate
what's
what
flow
is
about
and
and
what
the
mechanisms
are,
or
at
least
what
the
components
are
that
would
come
together,
we've
got
to
consider
not
only
what
moves
events
across
the
internet,
but
we
also
have
to
consider
what's
on
either
end.
What's
on
the
producer
side,
what's
on
the
consumer
side
that
that
enable
you
to
take
that
information
and
make
it
valuable
in
a
new
way,
and
so
what
I
did
in
the
book
and
I
stepped
through
this
piece
by
piece.
B
The
users
for
that
need
that
you
know
this
is
a
user
need,
so
who
are
the
users?
The
need
applies
to
producers
and
consumers.
In
this
case,
and
then
I
said,
what
are
the
components
that
are
needed
to
meet,
that
user
need,
and
after
many
many
iterations
landed
with
this
value
chain
that,
I
think
pretty
succinctly
identifies
the
core
elements
of
of
what
will
make
up
the
flow
value
chain
in
the
long
term.
B
B
Oh
there
we
go
here's
a
little
bit
of
something
called
promise
theory,
which
is
another
modeling
technique.
This
one
from
mark
burgus,
worldly
mappings
from
simon
wardley.
That
allows
you
to
say:
hey.
You
know
I've.
What
is
the
intended
action
intended
relationship
between
a
promissor
and
a
promises?
B
So
it
really
helped
inform
the
simplicity
of
the
map
to
really
be
very
tough
on
myself
in
asking
the
question:
what
are
the
promises
in
the
value
chain
and
it
made
a
huge
difference
in
terms
of
the
quality
of
the
value
chain
that
I
ended
up
with
and
then
the
other
part
of
worley
mapping,
then
is?
Is
you
know
he
has?
You
can
go?
Look
it
up
on
the
internet?
B
If
you
don't
know
a
lot
about
it,
but
he
talks
a
lot
about
the
natural
progression
of
a
given
technology,
for
as
it
becomes
more
defined
and
more
certain
how
it
also
drives
more
consumption
and
more
ubiquity
and
calmness
in
the
environment,
and
he
identified
four
main
stages
that
that
any
technology
goes
through
in
that
journey
from
being
a
kind
of
unknown
novel.
We
don't
really
know
what
it
is:
kind
of
a
behavior,
that's
interesting
or
a
combination
of
stuff,
that's
interesting
to
being
an
all-out
commodity.
B
Everybody
knows
exactly
what
they're
getting
and
has
expectations
about
the
exact
behavior
of
of
what
they're
consuming
and
that's
genesis,
which
is
that
new
thing
custom-built
components
which
come
as
we
begin
to
understand.
The
general
shape
of
things
people
build
their
own,
ultimately,
a
few
ways
of
doing
this
work
better
than
others,
so
people
productize
those
and
sell
them
or
or
rent
for
physical
things
they
they
might
rent
instead
of
selling
as
a
product
and
then
eventually,
though,
we
say,
okay,
there's
a
very
specific
way
of
doing.
B
This
is
it's
sort
of
very
standard
way
of
consuming
these
things,
and
it
becomes
very
easy
for
somebody
to
either
offer
it
as
a
utility
of
some
sort
or
to
sell.
You
know
basically
mass
produce
this
thing
and
and
sell
it
as
a
commodity.
So
those
four
steps,
then
we
can
map
our
our
value
chain
into
those
four
core
components,
and
again
after
many
iterations
and
and
and
much
feedback
from
some
wonderful
folks
in
the
industry.
B
B
I
think
you
know
some
of
the
the
the
apache
stuff
are
beginning
to
be
seen
as
ways
that
you
can
integrate
across
organization
boundaries
a
little
bit
more,
but
they're
still
not
standard
interfaces
in
the
sense
that
there's
one
way
of
doing
things
or
a
very
small
number
way
of
doing
things.
They
have
their
way
of
doing
it
for
their
their
product
sets
or
their
their
technology,
and
I'm
not
gonna.
Go
through
every
single
one,
but
you
can
kind
of
get
an
idea
like
all
this
stuff
around.
B
You
know:
processing
and
queues
and
syncs
data,
syncs
and
and
visualization
syncs
and
all
that
stuff.
That's
all
cloud
computing
today
right,
there's
a
million
myriad
of
ways
of
interacting
with
flows
already
out
there
today
and
it's
just
a
question
of
taking
that
logical
connection.
From
being,
you
know
a
little
bit
more
of
a
productized
thing
and
the
interface
is
for
me
a
little
bit
more
product,
specific
things
and
beginning
to
commoditize
those
and
standardize
those
over
time.
So
the
on
the
note
on
the
protocol.
B
The
protocol
is
really
divided
into
two
pieces,
there's
metadata,
which
describes
information
about
the
event
that
you
might
need
to
know
in
terms
of
understanding
how
to
process
it.
Not
only
you
know,
what's
the
format
of
the
payload
etcetera,
but
also
what
time
did
the
event
occur?
What
you
know
what
type
of
event
category
does
it
come
from?
B
Maybe
it's
its
source
topic,
those
kinds
of
things
so
so,
and
then
there's
the
actual
payload,
which
this
is
the
one
area
that
will
standardize,
probably
less
so
in
terms
of
everybody
in
the
internet,
will
know
how
to
read
any
payload
but
will
more
likely
standardize
in
terms
of
standardized
in
terms
of
individual
industries
or
or
even
individual.
You
know
some
customer
ecosystems
or
whatever
so,
and
it's
already
happened
right.
If
you
look
at
the
way
we
do
batch
processing,
there
are
already
payload
standards
for
batch
processing.
B
There
are
already
standards
for
payload
processing
of
things
like
electronic
data,
interchange
gdi.
So
I
expect
that
many
of
the
payloads
that
formats
that
already
exist
for
other
uses
will
probably
transfer
very
well
into
the
event
processing
world,
but
that
will
evolve.
I
think,
as
the
metadata
usage
becomes
better
understood,
how
industries
use
it
will
evolve
as
those
industries
begin
to
consume
it
so
and
as
I
mentioned,
that
today's
technologies
fall
right
into
place,
there's
there's
a
lot
of
analysis.
B
I
do
in
one
chapter
of
the
book,
where
I
kind
of
step
through
a
number
of
these
technologies
that
you
see
here
and
kind
of
talk
through
what
they
are,
what
they,
how
they
work
with
an
eye
not
to
sort
of
teach
about
the
technology,
but
with
an
id
identify.
How
does
it
fit
in
the
map?
Does
it
fit
in
the
map?
B
Is
the
map
in
in
some
way
able
to
represent
how
these
technologies
that
appear
to
be
predecessors
to
flow
or
or
parts
of
the
flow
architecture,
overall
that
they
actually
would
fit
into
the
map
and
the
way
things
these
use?
And
so,
from
that
perspective
I
you
know.
So
it's
there's
a
it's
really
interesting.
B
If
you're
interested
in
sort
of
how
the
the
world
today
comes
together,
I
give
some
really
good,
solid
examples
of
this
and
then
there's
an
entire
appendix
in
the
back
of
the
book,
which
is
actually
about
a
quarter
of
the
book
that
goes
through
each
of
the
components
in
the
value
chain
and
gives
a
pretty
thorough
survey
of
what
the
technologies
are
in
that
component
space.
Above
and
beyond
what
I
discussed
in
the
chapter
as
well,
but
none
of
these
are
flow
right.
B
So
it
means
we
have
to
kind
of
evaluate.
How
are
we
going
to
get
there?
What
are
the
different
ways
that
we
will
begin
to
get
to
very
standardized
ways
of
doing
all
the
components
that
I've
talked
about
here,
and
so
one
of
the
great
things
about
worley
mapping?
Is
things
move
from
left
to
right
on
the
map
in
general,
as
we
saw
with
that
s-curve
earlier
things
move
along
that
chain
from
genesis
to
being
commodity
utility,
so
you
can
begin
to
ask
questions
about.
B
Some
of
this
is
left
as
an
exercise
the
reader
so
to
speak,
but
I
do
walk
you
through
three,
very
specific
ones,
and
just
as
a
highlight
of
it,
you
know,
like
the
standards
game
basically
says
you
know,
you
know
you
can
essentially
create
an
ecosystem
or
or
or
encourage
an
ecosystem
in
a
marketplace.
If
your
technology
is,
is
a
good
use
of
standards,
a
good
opportunity
for
standards
usage.
B
If
people
agreed
on
a
certain
way
of
doing
things
it
would
it
would
open
up
for
customers
a
larger
world
of
of
technologies
or
solutions
to
use
for
different
purposes.
Then
standards
might
be
a
really
good
way
to
kind
of
move
your
technology
for
forward,
so
standards
game
is
kind
of
at
the
heart
rate
of
what
I'm
said
with
flow.
Is
you
know
the
entire
event
driven
architecture?
B
Let's
bring
our
engineering
talents
together
and
figure
out
some
certain
solutions
that
we
can
put
together
that
we
can
then
share,
as
as
you
know,
open
source
technology
or
just
common
technology
approaches
towards
certain
problems
of
handling
patient
data
and
moving
patient
data
around
and
also
sort
of
you
know,
working
together
to
to
you
know,
one
group
of
vendors
working
together
to
compete
against
another
group
of
vendors
is
another
really
great
way
to.
I
think
so,
just
an
idea
there,
but-
and
you
get
a
lot
more
detail
on
that
stuff.
B
But
I
think
this
is
a
really
great
way
of
beginning
to
evaluate
a
technology
to
consider
the
future
and
there's
a
a
number
of
these
other
ones
that
apply
really
really
well,
and
you
know
I
have
a
blog
that
I
started
writing
around
this.
It's
it's
so
it's
you.
Can
you
can
google
it?
I
think,
probably
at
this
point
in
time
you
can.
Certainly,
if
you
follow
me
on
twitter,
where
I'm
just
at
james
earcup,
first
name
last
name
you
can.
B
I
I
certainly
will
share
all
the
blocks
that
come
up
there,
but
I
will
certainly
be
talking
about
more
of
these
gameplay
opportunities
there
as
well
as
time
goes
on.
Okay,
terrific,
that's
awesome!
That's
wonderful!
That's
great!
What
so?
What
do
I
do
with
all
of
this
like?
What
can
I
do
right
now
to
prepare
for
flow
or
help
drive
flow
forward
in
some
ways,
and
so,
in
my
opinion,
talk
and
I've
been
talking
to
a
lot
of
people
about
this
right.
B
B
First
there's
some
basic
patterns:
these
are
just
very
high
level
patterns,
but
they
have
different
sets
of
needs
in
terms
of
what
you
consider
in
terms
of
how
you
use
the
processing
technologies,
they
often
use
the
same
processing
technologies
just
in
slightly
different
ways,
but
so
I'll
go
through
these.
You
know
I
go
through
the
patterns
a
little
bit,
but
I
also
and
more
importantly,
I
go
through
a
set
of
use
cases
that
were
shared
with
me
by
derek
collison
that
are,
he
says,
you
know
as
he's
evaluated
messaging
and
inventing
applications
over
time.
B
Where
you
know
you,
basically
that's
using
events
to
then
send
you
know,
coordinate
activity
and
send
in
instructions
to
take
activity
or
events
that
trigger
activity
around
the
network.
Query
and
observability
is
about
the
ability
to
look
at
sort
of
specific
agents
or
specific
small
groups
of
agents,
smaller
groups
of
agents
in
terms
of
what
their,
what
their
specific
behaviors
are
and
specific
states
are.
B
So
the
ability
to
ask
questions
of
the
system
of
flow
that
you
have
and
all
the
agents
involved
in
that
flow
and
the
the
ability
to
observe
and
even
sort
of
receive
events
based
on
the
emergent
behavior
or
overall
behavior
of
the
system
of
that
small
group
of
agents
and
then
telemetry
and
analytics
are
the
same
thing,
but
for
the
system
as
whole
as
a
whole.
In
terms
of
understanding,
then,
without
identifying
specific
agents
identifying
a
little
bit
more
about
how
the
system
is
behaving.
B
What
the
overall
emergent
behaviors
in
the
system
are
and
whether
it's
generating
the
value
it's
supposed
to
generate
and
so
on.
So
I
go
through
those
as
well
and
talk
a
little
bit
about
sort
of
the
technologies
in
involved
and
the
approaches
involved
in
basically
addressing
those
use
cases
today
and
and
that
that
are
well
set
up
for
the
flow
future
and
then
there's
also
this
really.
B
This
is
to
me
was
my
big
aha
moment
in
writing
the
book,
at
least
I'm
writing
the
latter
part
of
the
book,
which
is
essentially
looking
at.
How
do
you
make
decisions
about
what
technologies
to
use
for
different
use
cases
and
different
aspects
of
what
you're
doing
and
cleveland
vasters
who's
a
lead
architect
of
the
the
messaging
and
inventing
systems
that,
for
microsoft,
azure
kind
of
pointed
me
to
talk?
B
If
you're
going
to
do
a
lot
of
interactive
conversation
between
agents,
you
might
want
to
use
a
message
queue.
They
won't.
You
know
they
they
want
scale
as
well,
but
then
those
kinds
of
conversations
don't
scale
as
well
anyway,
but
you
might
then
look
for
a
log
based
approach.
If
you're
looking
at
hey,
I
need
to
be
able
to,
you
know,
retrieve
a
series
of
events
from
a
certain
time
range
or
a
certain
related
larger
scale.
B
You
know
like
an
id
like
a
customer
id
or
something
and
or
you
might,
if
you
do
looking
more
discreet
things
you
may
say
hey.
I
just
want
every
time
I
get
an
event.
I
want
to
take
an
action,
or
I
may
say
you
know
what
every
time
I
get
an
event.
I
need
to
trigger
a
workflow
that
may
trigger
a
series
of
other
actions
and
of
either
through
events
or
through
api
calls.
In
a
number,
you
know
a
number
of
steps
to
resolve
whatever
action.
B
It
is
that
I
want
to
take
and
you
might
actually
choose
to
use
a
workflow
automation,
engine
things
like
step
functions
and
azure
logic.
Apps
fit
really
well
in
there.
So
this
is
actually
a
really
useful
little
section
of
the
chapter
and
sort
of
understanding
these
different
pieces
and
how
to
make
these
decisions.
B
And
with
that
I'll
say.
You
know
the
last
thing
that
I
I
talk
a
little
bit
about
and
I'd
love
to
see
more
people
do
the
reason
I
wrote
the
book
was
to
get
the
conversation
around
flow,
going,
get
the
conversation
around
how
we
can
make
more
of
a
broader
ecosystem,
more
of
a
commodity
ecosystem,
around
event,
streams.
There's
many
ways
you
can
get
involved.
There's
open
source
projects
to
get
involved
with
out
there.
Cncf
is
doing
the
cloud
event
spec,
which
is
looks
like
it's
a
you
know.
B
Very
much
has
the
inside
track
in
terms
of
metadata
protocol
for
the
way
events
are
being
passed
around
there's.
I
think
all
three
cloud
providers
have
been
involved
in
it.
There
are
a
number
of
technologies
involved
and
then
excuse
me
and
then
also
you
might
be
part
of
a
trade
organization
or
something
it's
good,
probably
to
have
a
at
least
a
little
conversation
to
go.
Do
you
know
with
the
data
protocols
that
we're
using
today?
Would
they
fit
well
into
an
event
payload?
B
What
would
we
have
to
do
to
change
them
to
make
sure
that
they
do?
If
that's
the
case-
and
maybe
you
know,
read
up
on
cloud
events
and
understand-
maybe
how
you
would
wrap
your
data
with
with
the
metadata
and
in
your
specific
use
cases
your
specific
industry
use
cases
and
then,
lastly,
just
you
know
a
friendly
friendly
push
to
say:
hey
the
book's
out
there,
it's
available
on
amazon,
it's
available
on
o'reilly,
it's
available.
B
You
know
where
books
are
sold
more
or
less,
and
I
I
highly
recommend
that
you
pick
up
a
copy.
I
would
be
grateful
for
for
your
for
your
feedback
if
you
have
any
once
you've
read
it,
I
I
write
to
learn
in
a
lot
of
ways
and
that's
what
I
hope
to
do
and
with
that
I
think
kind
of
open
it
up.
If
there
are
any
questions
or
comments,
people
want
to
make
I'm
open
to
hearing.
C
The
worldly
map,
the
the
first,
the
the
black
before
he
got
to
the
red
this
one
yeah
sure.
So
I
think
this
is
an
interesting
pla,
like
first
of
all,
meta-analysis
of
worldly
masters.
One
of
my
hobbies
so
bear
with
me.
I'm
I'm
curious
how
some
of
these
got
put
where
they
are,
and
we
could
talk
about
that
and
then
I
also
think
it's
worth
noting
like
when
you
think
about
what
worldly
map
implies
right.
C
It's
like
there's
a
a
a
current
state
and
then
there's
the
things
that
happened
before
and
lots
of
what
we're
talking
about
was
sort
of
like
the
way
the
big
web
was
built
right,
like
kafka
was
built
inside
of
linkedin
in
the
late
2000s,
some
things
right,
so
it's
open
source
in
2011,
the
very
first,
the
very
first
amazon
web
service
was
sqs
right.
So
that's
basically,
like
you
know
this
sort
of
proto
or
or
like
whatever
you
want
to
call
integration
street
streaming.
C
Queuing
type
of
type
of
thing
right
so,
like
lots
of
the
big
web,
was
built
with
these
sort
of
asynchronous
flow.
You
know
one
of
the
big
topics
at
velocity
conference
like
2010
was
conflicts
of
event
processing
and
that
kind
of
stuff
right
so
like
this
is,
is
all
interesting.
One
thing
I
I'd
be
curious:
how
you're
thinking
about
it
in
these
conversations-
and
maybe
kids,
you
could
argue,
it's
kind
of
buried
in
discovery,
is
governance
and
and
who
has
access
to
like,
I
I
think
it
gets.
C
This
is
something
that's
on
my
mind
because
of
some
of
the
projects
we're
working
on,
but
when
you,
when
you
start
talking
about
like
data
and
streaming
and
having
that
be
available,
that's
fantastic,
but
you
don't
necessarily
want
everyone
to
have
all
of
the
data.
So
I
wonder,
or
have
you
thought
much
about
governance.
B
Right,
that's
a
big
thing.
That's
a
big
problem
to
be
solved.
There
are
technologies
that
are
working
in
the
right
direction,
no,
not
blockchain,
but
but
there's
other
things
that
they
come
into
play
in
terms
of
in
terms
of
that,
so
you
know
someone,
there
are
some
technologies
that
begin
to
look
at
elements
of
that,
and
there
are
some
definitely
custom
solutions
in
that
governance
space.
B
B
That
flow
and
the
reason
it's
very
much
in
the
genesis
side
for
me
is
there
are
a
couple
of
companies
trying
to
already
move
into
the
product
space
on
this,
but
there
really
isn't
a
lot
of
understanding
when
you
talk
to
people
who
do
event
streaming
about
ways
to
to
catalog
the
streams
they
have
available
in
their
organization
right,
that's
that's
still
very
early.
There's
people
still
trying
to
figure
out
basics
and
there's
definitely
not
anything
out
there.
That
has
a
standard
way
of
describing.
B
You
know
what
are
what's
the
what's
the
data
rate
that
I
can
expect
from
this
flow?
What's
the
encryption
method
used
on
the
payload?
What's
the
you
know,
what
are
the
things
I
need
to
know
in
order
to
be
able
to
subscribe
to
the
stream?
What
what?
What
kind
of
id
do
I
have
to
have
in
order
to
be
able
to
be
granted
permission
to
access
the
stream,
and
so
I
put
it
very
much
on
the
genesis
side.
B
It
can
be
argued
to
be
in
custom-built
at
this
point
in
time,
maybe
approaching
product
and
I'm
open
to
that
argument.
But
I
think
it's
such
an
unknown
and
undiscovered
space
and
that
I
even
argue
that
you
know
it's
50
50,
that
it
could
just
end
up
being
google
and
web
pages,
because
discovery
could
just
be
like
apis
have
been
to
date.
There's
not
really
a
registry
of
apis.
You
just
go
google
hey!
What's
the
api
for
twilio?
What's
the
api
for
for
for
openshift,
right
and
so
or
or
for
tanzania,
so.
B
Yeah
there
are
some
catalogs
out
there,
like
bantic
a
low
code,
no
code
event
targeting
event
streaming
has
a
a
really
good,
interesting
catalog
of
the
the
event
streams
within
your
instance
of
antique
that
you
might
want
to
consume
and
there's
a
company
called
solace.
That's
doing
some
actually
has
launched
a
product
that
is
intended
to
be
an
event
stream,
catalog
standalone
product
that
you
can
consume.
B
C
So
so
this
might
be
nuanced.
My
my
initial
impression
when
I
first
saw
this
is
I
kind
of
wanted
to
push
a
lot
of
it
back
towards
the
left,
I'm
not
sure
some
of
it's
as
deep
into
commodity
as
it's
represented
here,
I'm
curious
when
you
talk
about
infrastructure
like
what
you're
putting
in
that
bucket
and
then
in
specific.
C
I
think,
there's
an
interesting
nuance
when
you
start
talking
about
some
of
the
things
people
want
to
be
able
to
do
with
you
know
what
what's
it
was
iot
and
now
it's
edge
or
whatever
you
want
to
call
it,
because
infrastructure
in
that
sense
is
in
different
phases.
Right.
I
think
like
when
you
look
at
cloud
computing
you're,
seeing
the
commodification
of
these
sort
of
centralized
pools
of
fungible
resources,
but
when
you
start
to
look
at
the
emergence
of
these
edge
solutions
that
that's
definitely
not
not
in
commodity
for
infrastructure,.
B
C
So
so
this,
I
think
this
is
actually
an
interesting
conversation
because
it
it
touches
on
what's
happening
with
cloud
computing,
so
I
think
you
can
argue
that
the
hardware
is
commodifying
or
commodified,
but
the
operation
of
that
hardware-
the
deployment
of
that
hardware.
Imagine
the
lifecycle
that
hardware-
that's
not
commodity!.
B
C
That's
why
all
these
companies
are
bad
at
this
because
they
think
like
what
you
just
said.
What's
that
I
said,
that's
why
all
these
companies
are
bad
at
this
is
because
they
think,
like
you
just
said,
I
I
I
would
argue
that
the
the
defining
advantage
of
the
cloud
natives
is.
Is
this
operational
excellence,
someone
better
care.
B
If
I
were
to
break
infrastructure
down
that
infrastructure
bucket
would
spread
out
depending
on
what
you're
talking
about
significantly.
I
I
completely
agree
with
that.
I
just
think
that,
for
the
technology
needs
stack
that
we're
talking
about
here,
I
think
the
scope
stops
at
the
fact
that
you
know
I
just.
I
need
the
basic
networking,
compute
and
storage
that
I
have
to
have
in
order
to
support
my
processor's
cues
things
and
sources,
that's
kind
of
where
yeah.
C
D
C
D
There's
two
there's
two
things
that
that
I
have
questions
about.
One
is
like
when
we
you
could,
we
could
say
the
infrastructure's
out
of
scope,
but
like
doesn't
things
like
data
gravity
issues
eventually
mean
that,
for
instance,
if
you
say
infrastructure's
out
of
scope,
because
you're
using
aws
they're
managing
my
infrastructure
but
they're,
also
managing
my
storage
and
therefore
the
map
isn't
actually
as
kind
of
free-form
as
as
you
might
think,
because
you're
more
likely
to
use
cues
processors,
consumers,
etc.
That
are
provided
by
aws
yeah
and
you
are
to
choose
from
random
things.
D
C
B
And
that's
a
complete,
although
all
of
them,
as
far
as
I'm
aware,
are
based
on
open
source
technologies
that
are
are
at
this
point
in
time,
something
that
you
could
go
pick
up
and
and
create
your
own
service
that
that
mimics
right.
So
with
the
expected.
You
know
the
exception
of
like
kinesis
is
kind
of
a
not
it's,
not
kafka,
but
it's
meant
to
behave
like
kafka
right,
but
but
you're
right.
You
could
do
a
map
of
these
for
each
of
the
major
cloud
providers.
B
That
would
probably
lay
some
things
out
a
little
bit
differently,
or
at
least
you
would,
instead
of
having
just
a
you
know,
processor
q
layer,
you
might
actually
have
for
pro
for
q.
You
might
have
four
different
services
that
could
serve
as
different
forms
of
queue
for
different
purposes
that
are
maybe
at
different
stages.
B
Basic
structures
are
very,
very
metaphorically
similar
structures,
and
in
that
way
I
fully
expect
that
edge
computing
is
actually
a
major
component
of
it
and
it's
fair
to
argue
that
edge
component
infrastructure
may
not
at
this
point
in
time
be
commodity.
That's
fair!
That's
a
fair
argument
totally
open
to
that,
but
I
would
I
would
say
that
ultimately,
the
the
capability,
the
compute
network
and
storage
capability,
that
you're
trying
to
get
out
there
through
the
edge
is,
is
at
least
commodifying.
If
not
at
this
point
in
time,
come
on
so.
D
The
second
thing
I
wanted
to
like
kind
of
poke
at
a
little
bit
like
when
I
squinted
this.
The
first
thing
it
makes
me
think
of
is
semantic
web
right,
like
you
got
discovery,
you've
got
producers.
You've
got
different
ways
of
thinking
about
data.
You
and
you
know,
so
what
went
wrong
with
semantic
web
like
what?
How?
How
did
semantic
web
fail
to
become
this
type
of
thing
and
part
of
it?
Is
they
started
with
owl?
D
B
That's
certainly
before
I
even
wrote
the
book.
That
was
something
I
spent
a
lot
of
time.
Thinking
about,
because
the
in
the
famous
debate
between
sam
johnson
and
ben
black
always
kind
of
comes
back
to
me
right
and
you
know
ultimately
ben
was
right
right,
but
but
the
so.
What
I
would
say
is
this
we're
not
talking
about
we
we
we
do
have
the
strong.
B
We
do
have
a
distinct
possibility
that
different
types
of
streams
that
that
that
map
that
I
showed
that
that
decision
chart
might
end
up
with
different
interfaces
and
protocols,
potentially
right
yeah,
but
in
the
end
an
event
is
an
event.
It's
a
it's,
an
encapsulated
state
change
right.
That
has
a
time
signature
and
a
couple
other
things
assigned
to
it.
So
that's
the
same
for
all
of
them,
so
so
it's
possible
that
the
interfaces
might
be
different.
B
It's
possible
that
there
are
aspects
of
what's
in
the
metadata,
for
instance,
that
might
be
different
for
different
use
cases.
A
really
good
example
is
I
talk
about
high
frequency
trading
a
lot
and
how
the
mechanisms
work
for
that
today,
you
could
with
the
way
I
have
defined
flow
right
now
and
the
technologies
I've
called
out
here.
You
couldn't
do
high
frequency
trading
with
flow
the
way
I've
defined
it
right
now,
so
maybe
an
interface
protocol
for
me
that
does
direct
port
to
port.
You
know
direct
ethernet
port
support
connections
to
maximize
speed
or.
B
D
The
consumer
isn't
required
in
any
way
to
absolutely
interpret
the
data
inside
the
event
the
same
way,
another
consumer
might
no
and
as
as
a
result,
you
get
these
relationships
that
are
always
dynamic
and
complex
between
producers
and
consumers,
especially
if
you
start
making
them.
You
know,
relationships
that
are
cross.
You
know
organizational
boundaries
or
industry
boundaries.
D
B
B
Is
they
acknowledged
that
the
almost
in
the
first
paragraph
of
the
standard
way
they're
like
look,
you
know
we,
the
the
all
we're
trying
to
do,
is
make
sure
that,
when
an
event
is
received
by
some
entity
that
processes
events
and
by
the
way
the
protocol
isn't
like
it's,
not
a
byte
protocol
right.
It's
not
something
that
says
this
is
the
way
you
lay
out
the
data.
B
Let's
define
the
the
nature
of
that
the
meta
nature
of
that
information.
That's
a
failure
right.
We
know
that
at
this
point
nothing
about
the
way
I
define
flow
tries
to
define
the
meta
nature
of
what
events
are
and
what
the
world's
activity
is.
I'm
not
trying
to
say
hey.
These
are
the
categories
of
activity.
These
are
that.
I
agree
that
that
won't
work
all
I
can,
and
I
can't
even
predict
what
the
future
is
other
than
say
boy.
B
A
So
I'm
gonna
we're
we're
almost
at
the
top
of
the
hour
or
actually
we
are
at
the
top
of
the
hour
and
one
of
the
things
I'm
going
to
say
right
off.
The
bat
is
that
this
probably
is
the
best
used
at
least
this
week
of
worldly
maps.
I've
seen
so
and
it
really
helped
drive
the
the
discussion
so
nicely,
and
you
know
I'm
also
a
big
fan
of
that,
as
well
as
the
the
promise
theory
stuff
that
you've
yeah.
A
So,
if
anybody's
listening
and
wants
that
look
on
the
calendar
and
that's
coming
up
soon,
I
I
love
this.
These
concepts
and
everything
they
kind
of
pull
together
where
we
sort
of
see
the
market
going
anyway.
This
is
almost
a
market-driven
technology
and
you
know
I
think
we
it's
going
to
evolve.
So
we'll
definitely
have
you
back
james
and
bring
you
back
as
as
this
all
evolves,
and
the
one
thing
I'm
going
to
say
about
this
worldly
map
and
right
off
the
bat.
A
A
So
I
I
think-
and
it's
still
and
in
this
map
it's
still
in
the
discovery
phase
it's
or
the
genesis
phase
here.
So
I
think
a
lot
of
work
and
conversations-
and
this
book
hopefully
will
drive
the
conversations
too
around
that
aspect
of
it,
because
jabe's
use
of
the
word
regimes
to
describe
how
different
vendors
or
different
groups
of
vendors
will
will
set
themselves
up.
I'm
always
leery
of
the
word
standards
or
standardization
as
well
owl
and
like
we
could
probably
go
on
for
days
about
other
standardization
efforts.
A
We've
all
been
in,
but
really
having
the
driven
piece
aspect
of
this
and
using
places
like
the
cncf
cloud
events
community
and
these
to
drive
these
conversations
and
figure
out
where
it
is
we're
going,
is
really
incredibly
useful.
So
james,
I
am
grateful
for
you
have
taken
all
the
time
and
effort
to
write
this
book,
because
we
all
know
how
phenomenally
hard
it
is
to
get
a
book
out
the
door
and
for
coming
today
and
sharing
the
conversation
and
andrew
and
jabe
and
everybody
else
who's.
A
Listening
in
this
is
really
the
beginning
of
a
really
good
journey.
I
think
that
we're
all
going
to
have
to
take
together
so
thanks
james
and
look
forward
to
posting
this
up,
getting
people's
feedback
and
making,
hopefully
the
slides
available
too
james.
If
you
send
them
along
with
me,
I'll
post
them
up
and.
C
B
Yeah
I
appreciate
that
it's
always
really
great
to
talk
with
you,
andrew
and
jay,
a
pleasure
to
actually
get
to
spend
some
time
with
you.
We
don't
we
don't.
I
think
we've
met
a
couple
times,
but
I
don't
think
we've
really
had
a
chance
to
kind
of
talk
through
things
very
much
but
yeah.
This
is
gonna,
be
a
great.
This
is
the
very
very
beginning,
it's
kind
of
cloud
circa.
B
Maybe
even
you
know
2007
2008,
maybe,
but
I
I
really
you
won't
see
this
be
a
thing
that
mainstream
is
worried
about,
for,
I
would
argue
seven
to
ten
years
easily,
but
it
is
something
it's
an
opportunity.
I
wrote
the
book.
I
wrote
the
book
to
get
people
thinking
and
talking
and
then
perhaps
somebody
creating
something
incredibly
innovative
and
crazy
that
none
of
us
expected.