►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A Series of Fortunate CloudEvents - Ian Coffey, Salesforce
Serverless and Eventing are two ultra-popular areas of tech right now, describing a broad set of ideas and capabilities that can service a range of possible systems. We are told that these concepts will expand and help define the next generation of web services. That’s all well and good, but what is really going on inside these systems? What technology do those terms rely on and what does an Eventing workflow look like under the hood? Given the complexity and size of these projects’ codebases, it can be difficult to drill down and see what’s happening on a micro scale. Together, we will discuss, operate and modify a running distributed system built with CloudEvents and Knative Eventing. The system will be based around the concept of an automated conversation between kubernetes services.
https://sched.co/UaVh
A
In
my
conversations
with
end-users,
I've
definitely
seen
large
enterprises
that
you
know
some
would
consider.
Very
traditional
are
already
saying
for
a
serval
s.
First
engineering
org,
which
is
super
cool,
I,
think
it's.
The
cloud
providers
have
so
much
cost
savings
with
serverless
that
they
pass
them
on
and
incentivize
the
end-users
to
go
that
route
as
a
you
know,
as
the
first
first
step.
First
thought
step
that
you
think
of
so
that's
really
interesting
because
of
all
this
momentum.
A
There's
a
lot
of
open
source
projects
coming
around
and
key
native
and
cloud
events
are
two
such
two
such
initiatives.
So
this
particular
talk
is
very
interesting
for
me
because
there'll
be
a
live
demo
and
we'll
see
how
cloud
events
and
cloud
near
key
native
eventing
interacts,
which
I
think
will
clarify
a
lot
of
confusions.
I
have
and
hopefully
will
be
illuminating
for
you
as
well,
and
this
talk
is
by
Ian
Coffey,
who
is
in
the
engineering
org
in
Salesforce,
so
Ian.
Please
take
it
away.
A
B
Can
you
hear
me
I
think
my
mic?
There
we
go
hello,
everybody
I
am
Ian
I'm
super
excited
to
talk
to
you
about
this
topic.
Super
excited
that
so
many
people
are
excited
to
listen
and
participate
in
this
I'm
also
excited
that
this
room
has
magical
properties.
You
can
see
that
there
is
a
maximum
occupancy
over
like
330,
but
above
this
door.
If
we're
dancing,
it
goes
to
650.
So
that's
pretty
dope.
So
if
we
get
in
trouble,
we
got
a
back-up
plan
just
a
little
bit
about
myself.
B
I
think
we're
getting
a
little
bit
of
feedback,
but
we'll
press
on
and
lately
a
lot
of
my
time
in
the
open
source
world
has
been
sent,
concentrating
on
Tecton
and
Tecton
triggers,
and
things
like
that.
That's
kind
of
how
I
got
interested
into
cloud
events
was
introduced
to
these
concepts
is
like
trying
to
make
all
that
work
like.
B
How
do
you
shuttle
events
from
here
to
here
to
get
into
detective
pipeline
so,
and
also
just
thanks
thanks
for
checking
this
out,
I
wanted
to
take
a
second
to
have
like
a
little
bit
of
a
meta
discussion
about
like
why
this
format?
Why
are
we
sitting
here?
Why
are
we
spending
opportunity
cost
together
in
this
way
and
I?
Think
I've
just
noticed
in
my
career,
year-over-year
I
just
tend
to
spend
more
time,
I
guess
developing
what
you'd
consider
learning
materials?
Maybe
other
people
feel
the
same
way
that
you
know
they
can
take.
B
Many
forms,
maybe
like
getting
started,
guides
lightning
talks,
brown-bag,
demos,
all
those
sorts
of
things,
informal,
learning,
materials,
one-on-one,
mentoring,
sort
of
situations,
and
it
comes
up
to
me
a
lot
like
how
do
you?
How
do
you
best
spend
that
time?
How?
How
can
we
best
make
use
of
the
time
whether
it's
synchronous,
like
this
or
learning
materials
that
are
for,
like
the
open
source
community
that
you
consume
on
your
own
time?
B
It's
still
the
same
like
how
do
we
spend
the
30
minutes,
45
minutes
or
whatever
is
invested
in
it
the
best
way
and
how
to
remove
technical
barriers
for
people
to
actually
learn
to
you,
this
some
of
the
tools
that
we
have
available
to
us
now,
because
they're
not
super
useful,
if
nobody's
using
them
interesting
story.
I
think
that
kind
of
ties
into
this
is
I
noticed
for
a
long
time.
The
K
native
eventing
project
had
a
a
really
cool.
Readme
called
writing
your
own
event
source,
and
it
was
two
parts.
B
The
first
part
you
would
set
up
a
CRT.
You
would
like
bootstrap
your
environment.
You
would
bring
up
a
cluster,
you
would
do
a
whole
bunch
of
stuff
and
then
part
two
didn't
exist.
So
I
mean
it's
cool
to
have
this
technology,
but
it's
cooler
when
we
can
all
use
it.
I
tend
to
think
that,
like
slide
based,
demos
are
very
difficult
for
relaying
highly
tactical
information
like
fostering
aha
moments
or
like
lightning
bolt
moments
or,
like
you
know
you
just
get
it
I,
don't
get
that
a
lot
from
slide
based
demos.
B
Conversely,
workshops
great,
like
really
great
synchronous
workshops,
everybody's
working
together,
everybody's
helping
each
other
to
achieve
some
goal,
but
they
don't
scale
right.
You
can't
do
this.
Many
people
would
have
synchronous
setting
and
also
it's
really
hard
it's
hard
to
prepare
for
workshops.
It
takes
a
lot
of
effort,
maybe
teaching
assistants.
You
need
a
whole
bunch
of
materials
prep.
So
it's
it's
heavy.
B
My
neighbor
and
best
friends,
his
dad
was
a
mechanic
and
he
had
bought
him
a
transparent,
couldn't
internal
combustion
motor
and
we
were
super
into
cars
like
we
wanted
to
understand
everything
about
them,
and
you
know
we
tried
to
understand
them
just
from
books
and
diagrams,
and
things
like
that,
looking
under
the
hood
of
the
car
when
his
running,
but
it
was
this
moment
where,
having
a
motor
running
this
little
tiny,
you
know
completely
functional
but
see-through
motor
and
a
mechanic
like
explaining.
Oh,
this
is
what
the
cams
doing.
B
There's
lots
of
different
sources,
feeding
you
data
about
that
running
system
and
I.
Think
that
just
is
an
underappreciated
way
to
understand
technology.
I
really
really
feel
like
kubernetes
in
general.
Just
gives
us
an
awesome
platform
to
develop
those
sorts
of
learning,
environment
and
I'm.
Talking
about
like
self-contained
environments,
no
configuration
necessary
you're
not
going
out
and
making
infrastructure
creds.
If
you
don't
want
to
you,
don't
need
to
go
to
set
up
a
bunch
of
Secrets,
it's
easy
to
stand
them
up.
It
takes
low
processing
power.
B
You
learn
what
you
need
to
learn
and
then
they
are
easily
deletable
and
we
really
have
a
great
opportunity
to
kind
of
lean
on
that
and
not
just
build
cool
features
but
kind
of
describe
those
features
and
get
people
inspired
and
get
people
interested
in
those
technology
and
that's
kind
of
what
we're
doing
today.
We're
going
to
take
those
ideas
and
we're
going
to
try
and
build
a
cloud
event
and
Kay
native
based
learning
environment.
That's
self-contained
is
very
low.
Overhead
requires
no
configuration
and
you
stand
it
up.
B
There's
some
structured
learning
material
and
then
you
delete
it
when
you're
done
and
I
feel
like.
If
we
can
do
that
for
this,
we
can
do
that
for
most
or
all
of
these
projects
and
provide
like
a
low
barrier
for
folks
to
get
integrated
with
the
projects
they're
contributing
building
tools
with
them
stuff
like
that.
B
It
would
have
taken
a
lot
longer,
but
entirely
possible
and
I
think
the
best
way
to
describe
why
you
know
the
other
reason
you
include
cloud
events
is
because
the
name
of
the
talk
but
connecting
services
is
art.
If
you
can
picture
a
few
scenarios
scenario,
one
would
be
like
a
really
easy
scenario.
You
have
team
a
and
you
have
team,
B
and
team.
A
is
going
to
develop
a
service,
that's
going
to
admit
an
event
and
team
B
needs
to
consume
it.
Where
do
you
start?
What
are
you
gonna
do?
B
B
How
you're
going
to
receive
the
event
with
the
format,
the
transport?
How
are
you
serializing
it?
You
know,
and
that's
just
if
you're
dealing
with
basic
HTTP
if
you're
dealing
with
a
whole
bunch
of
other
type
of
transports,
you
can
get
really
complicated
and
then
you
can
take
a
step
further
back
from
that
and
like
what,
if
it's,
not
two
teams
working
synchronously,
what
if
one
service
already
exists
and
was
built
three
years
ago,
that
becomes
a
much
harder
proposition
and
then
you
can
take
a
step
back
forever
there
from
that.
B
And
what,
if
you
have
some
crazy
scenario
where
you
have
a
cluster
in
an
academic
research
facility,
and
some
group
has
been
given
license
to
use
that
resource,
so
they
want
to
admit
an
event
and
they
want
to
have
it
consumed
by
that
facility
like
how
do
you
even
start
that
conversation
there's
no
standardization?
It's
completely
Wild
West!
It's
all
about
interoperability,
it's
a
hard
word
to
say,
but
it's
so
important
to
start
thinking
about
now
that
there
was
events
flying
everywhere
later.
B
We
need
to
have
some
way
to
start
in
many
situations
describing
data
in
common
formats
and
at
the
end
of
the
day,
you
get
a
lot
of
things
out
of
it.
But
the
number
one
thing
from
my
perspective
that
you
get
from
this
common
metadata
on
events
is
routing
options.
You
can
use
this
completely
outside
your
apps
to
make
intelligent
decisions
about
who
wants
what
event
where
and
we
can
develop
a
pattern
where
services
can
subscribe
themselves
to
the
events
that
they
need
to
consume,
to
do
their
job
and
in
general,
I.
B
B
You
know,
there's
no
like
Oh
get
started,
suspect
it's
kind
of
like
I
was
thinking
of
parallels
and
one
would
be
if
you
notice,
there's
very
helpful
people
outside
this
door
that
have
been
asking
me
sign,
but
in
a
vacuum,
nothing's
gonna
happen
there.
You
need
an
actor
to
walk
up
and
ask
a
question:
we
need
to
utilize
it,
so
we
can
just
take
a
minute
here
and
talk
about
what
a
cloud
event
actually
is.
B
None
of
that
stuff
needs
to
exist.
We
can
get
rid
of
that
in
its
entirety
and
we'll
show
that
in
a
minute
and
I
think
another
thing
that
we
should
mention
is
that
cloud
events
like
a
really
cool
name.
It
sounds
like
a
really
massive
thing,
but
at
the
end
of
the
day,
the
framework
isn't
really
going
to
touch
your
logic
or
your
business
logic
or
how
you're
consuming
these
these
events
and
what
you're
doing
with
them.
B
B
The
first
for
bold
items
here
of
the
spec
are
required
and
the
rest
are
not
for
cloud
events.
The
spec
version
1.0,
was
released
recently
I
think
about
a
month
ago,
which
is
really
awesome.
The
event
type
is
a
very
important
field.
Cloud
events
are
a
very
low-level
concept,
so
you
can
kind
of
adapt
these.
How
you
need
to,
but
I
tend
to
think
of
the
cloud
events
type
as
a
namespace,
at
least
that's
how
it
plays
out
when
I
write
a
system
using
cloud
events,
and
it
feels
like
the
right
solution.
B
B
Your
app
probably
has
like
necessary
fields
and
things
that
you
need
to
route
on,
that
are
very
specific
to
your
event,
types
and
having
extensions
available
to
define
that
is
really
clutch
and
then
subject
is
a
newer
addition
to
the
spec
I
believe,
but
it's
also
something
that
is
really
really
useful
in
our
demo.
We're
gonna
use,
subject
to
kind
of
denote
where
the
events
going
and
who
should
be
consuming
it.
But
again,
these
can
all
be
adapted
to
the
workload
that
you
have
going
to
try
and
breeze
through
the
transports.
B
Funny
story
was
like
my
first
idea,
for
this
demo
was
to
build
a
demo
that
made
use
of
all
the
event
sources
and
if
you
can
picture
how
crazy
that
would
be
really
happy
that
didn't
happen
for
this
demo.
We're
gonna
stick
with
HTTP,
but
there
is
just
a
world
of
advantage
that
there
are
people
thinking
about
additional
transports
and
that
you
can
make
use
of
these
out-of-the-box.
B
Just
in
the
name
of
interoperability.
You
know
how
it's
serialized,
what
the
wire
protocol
is.
These
are
really
important
things.
If
you
want
things
to
be,
there
are
some
difficult
parts
and
I
don't
know
if
these
are
really
classifies
difficult
parts
again,
the
speck
is
low
level.
It
doesn't
really
seem
to
make
an
attempt
at
solving
these
problems,
but
event
ordering
is
something
that
comes
up
a
lot
when
I
talk
about
this,
like
how
do
I
get
things
in
a
specific
order,
you're
going
to
have
to
figure
that
out
yourself.
B
Unfortunately,
replaying
events
like
you
need
events
from
a
20
to
100.
That's
a
really
common
thing
to
do
right,
but
that's
not
something
that
you're
going
to
get
out
of
the
box.
You're
going
to
have
to
write
some
code
there
and
by
getting
new
sources,
that's
not
really
a
negative.
It's
just
kind
of
reality
is
its
reality.
B
Format
in
the
first
place,
and
there
are
many
SDKs
available
and
they're
wonderful,
wonderful
to
work
with
and
a
wonderful
advantage
to
be
able
to
say.
Like
we
said
earlier,
you
have
a
team,
a
team,
B
okay,
but
what?
If
team,
a's
go
and
team
b's
java?
Having
like
that
commonality
to
say
we're
speaking
on
the
same
terms,
we're
using
the
same
verbs
and
words
here
to
describe
our
event
format
across
these
different
languages
can
be
just
a
really
big
time-saver.
B
Who
wants
to
reinvent
things
over
and
over
again
I
mean
when
we
start
new
businesses.
Do
we
start
writing
new
kernels
from
scratch
that
we
just
use
linux,
because
what
value
is
there
to
reinventing
this
stuff?
I,
don't
know
if
there's
a
lot
of
value
in
reinventing
a
lot
of
the
things
in
cloud
events
in
some
circumstances,
so
it's
nice
that
we
can
just
say:
okay
for
most
of
the
languages
that
we
have.
We
have
a
baseline
of
support
that
we
know
that
we
can
use.
B
So
we
can
sum
up
and
at
the
end
of
the
day
cloud
eventing
just
gives
you
some
base
metadata
that
you
attach
to
events
that
you
can
use
to
do
some
intelligent
things
with
that
message.
With
that
event,
based
on
what
it
is
based
on
when
it
declares
itself
to
be
not
what
you
guessed,
it
is
not
what
you
inferred
by
like
checking
certain
parts
of
the
data
envelope.
B
B
Let's
start
writing
code
from
there,
Kay
native
eventing
we're
gonna
talk
about
it's
going
to
pick
up
the
ball
because,
like
I,
said
cloud
events
in
isolation,
don't
really
do
anything,
so
we
need
something
to
use
them
with
and
we're
gonna
use
it
with
Kay
native
eventing
and
we're
gonna
use
it
to
route
services
based
on
the
data
in
the
event
and
then
at
the
last,
we're
gonna
rip
all
that
awful
out
routing
code
out
of
the
apps.
All
those
case
switch
statements,
and
all
of
that
you
know
event,
detection
and
all
detecting
different
fields.
B
B
What
kind
of
use
cases
do
fit
this
pattern
we
just
talked
about
I
think
we've
talked
about
the
ICD.
This
cube
con,
more
than
I
could
have
ever
dreamed.
It's
just
like
seems
to
be
like
white-hot,
but
like
what
about
a
simpler
process?
What
about
Khurana
based,
like
let's
say
you,
you
have
a
kubernetes
cron
every
day
at
noon,
to
make
you
a
sandwich
like
you're
hungry
at
noon.
You
need
a
sandwich,
so
you
need
to
emit
an
event
to
your
sandwich.
Robot,
and
you
know
to
be
able
to
do
that.
B
The
sandwich
robot
doesn't
need
to
care
about
all
these
other
things.
It
just
needs
to
care
like
I
just
got
an
event.
I
know
what
I
need
to
do,
and
maybe
maybe
it's
a
turkey
sandwich.
So
you
can
set
your
subject
to
turkey,
so
the
turkey
sandwich,
robot
is
always
going
to
get
your
message
and
it
doesn't
need
to
care
about
everything
that
came
before
it.
B
It
just
needs
to
know:
I
need
to
make
a
turkey
sandwich
and
bring
a
tikki
in
and
eventing
is
the
other
half
of
this
project
here,
going
to
really
try
and
drill
down
on
these
three
concepts.
It's
a
big
concept.
It's
a
big
project,
but
broker's
triggers
and
container
sources
are
what
we're
going
to
experiment
with
when
I,
try
and
breeze
through
this,
because
going
pretty
slow
but
brokers
are
a
newish
project.
I.
Think!
B
B
Just
to
give
a
quick
detail
on
the
broker
details,
what
brokers
consisted
of
mainly
there's
two
pods
and
two
channels.
These
are
actually
should
be
reversed.
The
ingress
logically
would
come
first
and
the
ingress
pod
is
just
going
to
actually
accept
events
place
it
on
the
ingress
Channel.
After
doing
some
inspection,
the
filter
pod
is
going
to
check
that
or
pick
those
up.
It's
going
to
say.
B
B
Here's
an
event
or
soothe
me
an
example
trigger
filter,
and
you
can
see
in
this
one
there's
no
broker
defined,
so
this
will
end
up
on
the
broker.
That's
the
default
and
under
the
filter
in
the
spec,
we're
looking
for
all
events
that
have
a
subject
of
Dave
defined
and
now
this
extension
has
value
and
if
it
matches
that
the
filter
pod
that
we
just
mentioned
before
is
going
to
put
it
on
the
trigger
Channel.
B
It's
going
to
end
up
at
radical
service
2000
and
from
there
you're
off
and
running
your
event
can
then
be
processed.
So
we're
going
to
jump
into
demos,
and
this
demo
is
I-
didn't
want
to
do
something
that
represented
a
system
that
existed
in
real
life.
I
felt
like
you
would
give
a
better
cross-section
to
what's
happening
to
just
dream
up
something,
entirely
different
and
more
fun,
so
we're
gonna
build
a
tiny
distributed
system
and
it
has
little
AI
actors.
These
actors
are
just
pods
and
they're.
Gonna
have
a
conversation.
B
It's
ridiculous
and
I
have
no
idea
what
they're
going
to
say,
but
that's
the
point,
and
but
the
interesting
or
the
most
important
thing
to
pay
attention
to
is
that
these
actors
are
not
outputting
what
they
say
like
I
am
they're
outputting
what
they
hear
so
they're.
Not.
It
would
be
very
easy
for
a
pod
to
just
boot
up
and
say,
like
okay
format,
dot
print
line
say
something
and
we
could
see
those
lines.
No.
B
There's
many
parallels
between
and
the
reason
I
use.
The
conversation
is
because
I
feel
like
there's
a
lot
of
like
direct
correlation
between
the
system,
we're
building
events
and
conversations
and
here's
something
like
cloud
events
are
indicative
of
the
messages
we're
sending
or
like
the
sentences
or
paragraphs
or
ideas.
The
broker
is
going
to
represent
the
conversation
or
maybe
you
could
say
the
room
like
this
room
triggers
yeah.
B
B
So
we're
gonna
start
the
system
now
and
it's
tiny,
and
what
we're
doing
right
now
is
we're
just
running
an
up
script
and
that
the
up
script
is
doing
I
mentioned
earlier
self-contained
environments,
things
that
are
very
simple
to
get
involved
in
to
get
started
with.
That's
what
we're
doing
right
here
from
then
up
we're
gonna
create
an
entire
kubernetes
cluster
with
kind
which
is
awesome,
development
tool
that
I
would
strongly
recommend.
B
If
you
do,
a
lot
of
local
development
kind
is
just
awesome
to
use
and
we're
gonna
create
an
entire
kubernetes
cluster
with
that,
following
that,
we're
gonna
use
glue,
which
is
another
really
awesome,
project
to
initialize,
Kay
native
on
our
cluster
and
then
finally,
we're
going
to
install
three
resources
that
are
just
gonna
set
the
stage
for
our
conversation.
So,
let's
check
out
one
of
those
which
I
obviously
cannot
remember
the
name
of,
and
this
is
a
broker.
B
That's
all
we're
defining
here
and
in
this
broker
we're
saying
the
name
is
conversation
broker,
which
is
not
a
great
name
for
a
broker
because
brokers,
prepend
brokers.
So
this
is
conversation
broker
broker
and
what
we're
saying
is
this
is
an
in
memory
channel
and
it's
living
in
the
name,
space
work,
conversation
where
everything
will
live
and
when
you're
done
with
it
just
delete
the
name
space
and
you're
done
quickly.
We
should
probably
check
out.
What's
going
on,
kale
is
another
great
tool.
Kale
will
just
aggregate
all
the
pods
from
your
namespace.
B
So
if
you're
like
troubleshooting
something
you
don't
want
to
like
waste
time,
especially
if
it's
urgent
figuring
out,
what's
going
on,
as
you
can
see,
there's
nothing
going
on
our
namespace
right
now.
Traffic
is
very
low,
but
we
can
fix
that.
We're
gonna,
add
some
actors
and
we
should
add
an
actor
named
Tracy
we'll
add
an
actor
named.
Fred
I
think
Jane
wants
to
join
the
conversation
and
how
about
Peter,
and
so
this
is
gonna.
Take
a
few
minutes.
Internal
DNS
is
gonna,
take
like
a
minute
or
two
to
settle.
B
So
let's
take
a
minute
and
we'll
check
out
a
diagram
about
what's
happening
right
now
and
what's
happening
right
now.
If
you
start
at
the
top
left
and
go
counterclockwise,
we
created
the
pod
named
Tracy
and
Tracy
booted
up
and
she's
sent
two
containers.
She
said
an
event
or
a
cloud
event
via
Kay
need
of
a
container
source.
You
can
see
in
the
bottom
left.
B
This
event
is
of
type
message:
comm
and
coffee
conversation
message
is
the
event
type
and
in
the
bottom
left
we
can
also
see
that
the
subject
is
to
all
this
message
is
meant
for
everyone
in
the
conversation
and
the
source
was
Tracy.
Tracy
spoke
this
message
and
on
the
right
you
can
see,
Fred
exists
and
Fred
is
subscribed
to
all
messages.
Fred
cares
to
get
all
these
messages.
We
didn't
have
any
other
config.
We
can
create
as
many
actors.
If
you
want,
we
can
name
of
anything.
B
So,
let's
take
a
minute
here
and
jump
back
over
to
our
demo
and
check
out
what
it
looks
like.
First,
let's
see
how
that
traffic's.
Looking
now
that
looks
much
more
like
a
distributed
system
right
what's
going
on
here,
but
let's
drill
into
the
conversation
itself,
and
you
can
see
they're
having
this
really
strange
conversation
amongst
themselves
and
it's
ridiculous.
B
One
really
pivotal
moment
for
me
with
learning
how
internal
combustion
motors
work
was
seeing
inside
like
seeing
how
it
worked,
and
we
can
do
the
same
thing
here.
This
is
the
wire
protocol
of
what's
going
on
lots
and
lots
of
cloud
events
flowing
around
the
system,
and
this
is
what's
happening.
This
is
all
that's
happening,
we're
just
sending
sending
cloud
events
around
between
these
actors
in
this
little
tiny
distributed
system
so
that
they
can
have
this
conversation
and
let's
capture
one
of
these,
here's
a
good
one.
B
B
But
what
is
happening
in
our
namespace
like
what?
What
is
really
the
the
resource
situation
here
and,
as
you
can
see,
there's
a
lot
going
on
in
here.
All
of
these
container
sources
at
the
bottom
here
represent
one
message
that
someone's
saying
and
after
they
say,
if
these
actors
are
very
nice,
they
clean
up
after
themselves.
B
They
do
automatic
garbage
collection,
but
they
are
constantly
just
sending
these
container
source
messages,
and
you
can
see
above
here
the
reason
they're
being
received
is
that
we
have
these
subscriptions,
and
these
are
all
the
combinations
of
subscriptions
that
we
care
about.
So
Peter
cares
about
all
messages.
Traci
wants
messages
just
to
Tracy
things
like
that,
so
we're
defining
those
right
here.
B
But
I
think
we
can
take
this
little
bit
further.
What
if
we
wanted
to
send
a
new
event
type,
it's
a
really
common
thing
right.
You
have
a
service.
Now
it
needs
to
invent
in
just
a
different
kind
of
service,
type
or
event
type
like.
How
would
we
do
that?
Well,
let's
try
that,
with
a
new
event,
type
called
distracted,
we're
gonna,
distract
our
actors.
B
One
little
secret
about
them
is
they're
very
easily
distracted,
it's
just
like
normal
people,
so
we're
going
to
set
up
the
ability
for
them
to
ingest
this
new
event
type
and
then
we're
gonna
send
them
one.
Let's
check
out
what
that
looks
like,
though,
in
this
file
you
can
see
a
whole
new
set
of
triggers
this
bottom.
B
Hey
I
want
to
receive
these
messages
now,
so
let's
just
apply
these
real,
quick
and
well
now,
when
we
send
this
new
event
type,
instead
of
it
just
going
into
the
broker
and
hanging
out
forever
and
timing
out
and
being
dropped
now
it
will
end
up
being
delivered
and
we're
going
to
deliver
our
new
event
type
with
magic
wand.
An
all
magic
wand
is
a
fancy
little
script,
which
acts
as
a
template
for
sending
yet
another
container
source
event
type.
B
So
what
we're
doing
is
creating
a
container
source,
the
container
stores
boots
and
it's
going
to
send
a
cloud
event
wherever
we
tell
it
to
in
this
case,
it's
going
to
set
the
type
that
distracted
and
it's
gonna
send
it
to
everyone.
So,
let's,
let's
try
it
out
and
right
away.
We're
gonna
want
to
see
how
this
affected
them
right.
We
said
they're
easily
distracted.
What
does
that
look
like?
B
B
Well,
what
else
can
we
do
like?
What?
What
other
sorts
of
things
can
you
do
with
this
sort
of
setup?
I
mean
this
is
one
of
the
things
I
usually
referred
to
in
the
past
as
the
dream,
but
it's
a
really
complex
pipeline,
but
it's
just
very
powerful
and
if
you
start
at
the
top
left,
just
starting
from
a
git
push
we're
gonna
create
an
event.
It
doesn't
really
matter
where
it's
coming
from
what
gets
serviced
whatever,
but
as
long
as
it
can
be,
make
it
to
our
K
native
cluster.
B
It
can
be
received
by
serving
the
K
native
eventing.
Adapter
will
then
create
a
or
modify
it
to
become
a
cloud
event.
The
cloud
event
will
end
up
in
our
broker.
Moving
up
the
middle
line,
we
can
have
a
Tecton
trigger,
like
we
mentioned
eager
earlier,
when
we're
going
to
subscribe,
the
trigger
to
things
that
it's
interested
in,
so
the
trigger
can
be
completely
done.
It
does
not
need
to
know
anything
about
the
types
or
the
formats
of
things.
B
That's
getting
we're
handing
that
all
upstream
and
the
trigger
is
going
to
receive
that
message
and
it's
going
to
create
a
Tecton
pipeline
and
detective
pipeline
is
going
to
do
it's
awesome.
Magic
testin
is
awesome
and
we're
going
to
get
the
pipeline
started
to
create
all
of
the
things
on
the
right
go
test
without
building
a
docker
image,
pushing
all
of
these
sorts
of
things,
and
we
really
have
that
round
trip
nailed
down
and
if
we
want
to
upgrade.