►
From YouTube: Knative Introduction for the Curious Developer
Description
Serverless is becoming the new default on top of containers. What does Knative hold for Java Developers? Workhop hosted by RedHat, facilitated by Roland Huß and Matthias Wessendorf.
Knative is a Kubernetes-based platform that comes with a set of building blocks to deploy and manage modern serverless workloads. Knative consists of two major areas: Serving and Eventing.
The session gives you a quick introduction of the different parts of Knative and walks you through an end-to-end demo, showing the lifecycle of an event-driven application, from a Java developer's perspective. The session explains how Knative uses Kubernetes and Istio features to provide request driven compute, so that services can autoscale, including down to 0, depending on the actual throughput.
You will learn how to configure your Java application to use Apache Kafka to enable high throughput messaging. Finally you’ll see how to integrate Knative with external applications using the Apache Camel DSL and Camel-K integration.
A
A
Ever
you
are
welcome
to
another
installment
of
the
developer
webinar
series
today.
We're
going
to
talk
about
K
native
introduction,
Airy,
stuff
and
I
am
very,
very
grateful
that
I
have
two
wonderful
speakers
over
here
to
amazing
Germans,
Matias
vecindad,
who
calls
himself
the
currywurst
king
or
a
senior
developer,
he's
working
for
our
middleware,
be
you
working
on
messaging
and
streaming
stuff,
and
also
dr.
Roland
who's.
A
Principals
of
the
engineer,
who's
also
working
on
connect,
a
native
so
Roland
I'd
love
to
give
it
over
to
you,
but
I
need
to
take
care
for
a
couple
of
housekeeping
items.
So
this
is
supposedly
a
very
interactive
webinar,
like
you
guys,
are
totally
free
to
ask
questions.
We
have
a
chat
window
that
you
can
use
throughout
the
complete
event
and
I
will
do
my
very
best
to
catch
up
with
all
questions
coming
up.
A
We
also
have
a
Q&A
section
to
bottom
right
of
your
screen
somewhere
there,
where
you
can
also
put
in
your
questions
whenever
you
have
some.
This
session
is
going
to
be
recorded
and
you
can
take
a
look
at
the
recording
afterwards,
whenever
it's
published
I
hope
it's
only
going
to
take
a
couple
of
days,
as
you
have
noticed,
there's
no
sign
up
requirements,
so
we
can't
let
you
know
that
the
recording
is
online.
A
B
You
Michael
Thanks,
so
yeah,
let's
get
started
so
today,
you're
talking
about
K
native
and
its
Canadia
itself,
it's
a
few
cuban
ad
space
platform
for
more
on
event
rhythm,
so
I'm
gonna.
So
this
is
quite
a
mouthful
and
before
we
chop
into
kinetic
I
native,
let's
talk
a
little
bit
about
service,
because
if
you
ask
10
people
about
server
less,
you
probably
get
10
different
answers.
What
sermon
is
this
and
so
I
picked
morn
as
randomly
this
one
is
from
the
CN,
CF
and
yeah.
B
This
is
a
quite
lengthy
definition
and
I
highlighted
the
parts
which
are
relevant
for
K
native
and
grayed
out
a
little
bit.
Those
parts
which
are
not
so
relevant
for
creative
itself.
So
but
let's
focus
on
the
important
part,
so
ever
less
in
the
context
of
Canada.
It's
about
applications
that
are
do
not
require
any
active
server
management,
so
you're
just
deploying
your
applications,
which
are
packaged
in
the
container
and
then
pin
it.
If
we
manage
that
for
you
and
it's
a
deployment
model,
this
is
important
because
it's
not
a
programming
model.
B
So
if
you
can
put
anything
what
you
want
into
your
container,
there's
a
little
bit
different
to
pass
these
functions
or
services
or
functions
which
are
more
also
implicate,
the
programming
model
and
we've
Canadia.
If
you
are
executing,
though
you
were
really
focused
on
the
demand
of
your
applications
or
the
number
of
requests
you
application
gets
and
those
are
executed,
scared
and
build
really
corresponding
to
the
demand.
So
actually,
when
there
is
no
demand
that
you
don't
have
to
pay
anything
because
then
your
application
is
not
running.
B
Okay.
This
is
a
write
proof
that
we
see
more
of
that
in
detail
later
on.
Yes,
here
that
guy,
of
course
it's
a
kind
of
joke
about
that.
So
what's
the
difference
of
servlet
VCG
I-
and
this
is
actually
more
talking
on
the
the
fact
that
very
serverless
is
quite
a
fussy
word,
which
is
not
very-
has
not
clear
boundaries
so
yeah,
maybe
you
can
convince
them
why
it's
not
really
only
tGI's!
Okay
name
is
for
sure
a
little
bit
more
than
CGI.
Okay,.
C
C
B
But
actually
it's
always
focused
on
a
stinking
machine,
so
this
is
I
think
this
is
the
main
difference
between
the
old
could
all
CGI
brains
from
there
all
the
time
there
oh
yeah
yeah,
but
actually
you're
completely
right.
So
it's
really
a
something
you
throw
a
code
over
over
the
fence
and
then
somebody
is
running
it,
and
this
is
a
little
bit
like
this
right.
B
B
The
other
part
is
a
body
painting
and
materials
we'll
talk
about
this
later
on,
and
it's
about
the
common
infrastructure
for
consuming
producing
events
that
will
stimulate
your
painting
of
services
or
applications.
So
the
one
thing
is
about
really
serving
your
application
and
the
other
products
about
how
to
connect
this
to
the
outside
world.
B
We
are
inventing,
let's
have
some
look
at
some
background
information,
so
we're
screening
of
coming
from
so
Kenneth
has
been
started,
mid
2018
by
Google
as
an
open
source
project,
so
it
has
to
be
started
from
scratch
and
contains
a
lot
of
experiences
that
Google
has
gained
over
the
time
with
the
operating
service.
Publications,
it's
community
driven
and
part
has
also
a
lot
of
vendor
backing.
So
actually
there
are
quite
some
companies
with
which
are
involved
in
the
this
project.
So,
of
course,
Google
is
the
initiator,
but
also
Red.
B
Hat
is
one
big
contributor
to
Kennedy
IBM.
We
America
mesh
s
AP
and
many
more
community,
while
it's
organized
organized
and
bootable
working
groups
which
would
have
weekly
meetings,
and
you
find
here
the
link
to
the
kind
of
defin.
Also,
the
kid
up
are
archived
and
you
find
all
of
this
on
these
pages.
A
lot
of
documentation
also
examples
we
are
currently
at
the
release.
B
Then,
let's,
how
could
you
try
yourself?
Can
edit
god?
This
is
one
of
very
important
questions,
because
it's
quite
easy
to
set
up,
so
you
can
use
it
directly
on
given
human
s
caster,
you
can
use
any
criminal's
cluster
if
you
like,
you'll
find
the
installation
documentation
on
the
Canadian
death
website
as
well,
but
you
can
also
use
a
hosted
version
of
Canada
and
there
are
two
prominent
offerings
which
you
can
use.
One
is
called
Google
cloud
run.
This
is
running.
B
This
is
funny
because
it's
not
really
running
on
communities,
it's
running
on
App
Engine
and
you
can
try
it
out.
There's
a
free
tier.
You
can
try,
but
it's
important
to
note
that
not
all
Canadian
features
I
had
we
made
it
out
of
the
box.
For
example,
you
cannot
use
conflict
maps
for
the
configuration
other
stuff.
This
is
this
is
due
to
the
nature
that
cloud
one
is
based
on
that
engine.
If
you
want
Roland.
A
B
You
can
try
this
out
as
well,
so
op
shift,
so
you
see
observing
us
with
the
buffering
from
reddit.
You
can
direct
install
it
from
operator
hub,
and
this
is
also
included
in
code
ready
containers.
So
you
can
try
this
also
on
your
local
machine,
if
you
like
to,
but
you,
of
course,
you
can
use
any
open
shift,
the
opposite
cluster
and
install
the
product
and
I.
Have
it's
a
good
question,
because
I
can
show
you
how
this
looks
like
on
from
the
overshift
console.
B
So
you
see
it's
the
knob
shift
for
three
cluster
here
which
you
can
use
and
you,
if
you
know
OpenShift,
you
also
probably
familiar
familiar
with
the
operator
hub
and
then
visit
the
more
that's
breaking
news,
because
we
release
the
operative
service
operator
here.
I
think,
one
week
ago
my
tears
I
think
it
was
one
week
ago,
the
GA,
so
you
can
start
it
directly
from
the
right
app
and
then
you
have
this
operator
running
here.
B
Well,
this
is
very
easy
stuff
to
set
up.
So
if
your
upper
shift
user,
this
is
really
the
perfect
way
to
how
to
thrive,
and
the
good
thing,
of
course,
as
operation
surveillance
is
based
fully
on
vanilla
Canada.
If
there
are
only
the
the
operators
which
has
been
wrapped
around
the
Canadian
installation,
you
can
benefit
from
alternative
features
which
are
included
okay.
B
B
It's
all
about
routing
getting
to
zero
and
tracking
Prohibition
history.
What
does
this
mean?
So
it's
about
that
you
can
scale
to
zero.
I
will
already
mentioned
that
it's
demand
based,
so
it's
not
based
on
CPU
or
memory
usage,
but
really
on
the
number
of
concurrent
requests
coming
in.
So
it's
really
kind
of
really
connects
to
a
kind
of
a
business
metrics.
B
It
separates
very
clearly
the
code
in
the
configuration,
but
in
an
if
is
not
suited
for
every
application,
so
it's
only
really
suitable
for
stateless
applications
which
have
some
restrictions.
This
is
due
to
to
the
fact
that
you
really
need
a
flexible
way
to
scanning
to
0
and
scaling
up,
and
so
what
you
need
to
do,
if
you
have
them,
stayed
full
application.
You
need
to
try
to
move
out
the
state
outside
of
your
application,
for
example
in
your
database,
or
also
with
the
browser
which
comes
in
with
some
cookies
on
it.
B
Now
this
is
important
restriction
which
you
no
then
it
also
has
a
rich
traffic
split
up
to
capabilities
which
allows
you
to
model
a
lot
of
different
custom
role
of
strategies
of
new
versions.
You
can
easily
create
your
own
Bluegreen
deployments
or
canary
deployments
with
fist
traffic
split
capabilities.
We
will
see
an
example
later
in
the
demo
as
well,
so
let
the
resources.
B
So
this
is
something
so
Canadiens
itself
is
runs
on
top
of
communities,
and
this
platform
is
contained
several
so-called
custom
resource
definitions
or
series,
which
is
an
extend
the
way
how
you
can
extend
communities
by
adding
new
types
with
the
system.
The
important
types
here
is
so
in
the
most
important
IPS
is
service,
which
is
the
use
of
facing
types.
So
if
your
intact,
with
Canada,
if
you
always
use
the
service
and
as
soon
as
you
create
a
service,
then
route
and
the
configuration
object
are
created
on
on
behalf
of
your
service.
B
So
it's
really
a
one-to-one
relationship
between
app
configuration
and
the
route
in
the
service
and
the
route
in
the
service
and
anytime.
You
change
the
configuration
of
a
service,
then
the
configuration
is
updated
and
a
new
revision
is
created,
reflecting
the
state
of
your
configuration
at
the
time.
B
So
with
this
mechanism,
you
can
build
up
a
complete
history
of
your
configuration,
which
allows
you
to
do
nice
things
like,
for
example,
you
can
have
a
relation
reflecting
your
version
of
one
of
your
application,
because
it
contains
the
reference
to
your
container
image
in
version
one,
but
you
also
can
have
the
no
relation
in
which
points
to
the
Russian
of
your
application,
and
then
you
can
create
a
route
which
makes
a
kind
of
a
traffic
split
and
which
distributes
the
traffic.
Among
these
two
revisions,.
B
Ok,
so
these
are
the
basic
objects,
and
actually
this
is
all
what
tentative
serving
is
about
and
also
the
what.
Why
is
this
model
so
appealing
for
developer,
because
it
makes
things
also
simpler?
It's
not
only
about
auto
scaling,
but
you
can
also
very
easily
create
your
application
and
deploy
everything.
B
What
you
see
here
now
is
a
deployment
if
you
know
to
analyst
or
per
shift.
You
know
that
our
deployment
looks
like
the
deployment
has
a
very
lengthy
specification
here
and
if
you
compare
the
corresponding
kind
of
service
you
see
if
it
is
different,
maybe
I
have
got
a
different
kind
and
a
lot
of
things
has
been
left
out.
B
For
example,
the
everything
which
is
in
gray
here
is
not
needed
on
service,
so
it's
just
yet
to
the
truth,
to
show
the
difference
to
the
deployment
and
it's
much
much
easier,
simpler
and
but
more
importantly,
it
not
only
creates
your
deployment
for
you,
but
also
the
Cuban,
a
disservice
torrent
and
the
increase
or
route
object,
which
also
creates
on
behalf
of
you.
So
if
you
deploy
like
a
native
service,
then
a
deployment
is
created
for
you.
Our
chip
analysis
services,
credit
for
your
endo
ingress
and
routers
for
you
yeah
here.
B
We
also
see
that
a
little
bit
of
problem
with
the
naming,
because
you
see
here
service
and
case
service
in
the
top
of
the
title-
and
this
is
a
little
bit
unfortunate-
that
Kenneth
also
has
chosen
service
at
the
name
of
its
entity
because
there
is
already
have
to
be
at
a
service,
but
both
of
those
are
totally
different
things,
but
one
is
really
yeah.
So
this
is
important
to
keep
in
mind.
Okay,
so
I
have
a
little
bit
naughty
more
five
minutes
or
so,
and
we
will
see
that
in
action
chunk
to
determinate.
B
So
what
I
have
here
is
now
I.
Have
my
terminal
F,
a
connection
to
the
tester
that
you
just
have
seen
and
in
the
top
of
half
of
the
screen
you
see
and
watch
on
the
pots.
So
you
see
all
the
pots
that
are
created
in
mind
namespace
and
what
I'm
going
to
show
you
to
now
in
this
demo
is
also
the
K
Native
Client
tool,
which
is
called
KN.
B
You
can
download
that
from
the
Canadian
website
you
can
use
guru
if
you're
running
on
Mac
OS
told
it
several
ways
how
it
can
install
that
and
all
what
this
tool
really
does.
It
creates
the
custom
resources
for
you
and
then
deploys
it
to
the
cluster
later
in
the
event
in
part,
but
here's
we'll
show
you
how
to
do
this
with
directory
with
this,
with
the
deployment
of
scriptures
with
direct
with
the
army
but
boss,
we
have
trust,
you
think,
n
and
let
let's
create
a
simply
kinetic
service,
so
you
use
give
it
a
name.
B
It's
called
random
here
and
the
only
mandatory
option
which
you
have
to
provide
is
the
pointer
to
the
Container
image,
so
I'm
using
here
a
rest
service
which
I
called
vendôme
and
it's
a
very
simple
reservists
which
is
based
on
co-workers
and
which
returns
to
you
trust
a
random
number.
Okay,
let's
do
that
in
the
top.
You
will
see
now
now
that
there's
a
pot
is
created
for
you.
This
is
your
application,
so
it
first
time
you
deploy
ask
a
native
service.
The
pot
is
directly
created
for
you,
and
here
you
see
a
little
bit.
B
Okay,
and
if
I
continue
talking,
you
will
see
that,
because
I
do
not
send
any
traffic
on
this
image,
then
it
will
scale
down
to
zero
easy.
And
so
so
you
can
look
into
the
service
described,
and
the
current
service
described
is
something
that
there
you
can
get
out
presentation
of
your
service.
You
can
look
at
it.
It
also
can
export
it
into
German.
So
you
can
easily
also
see
how
it
looks
like
behind
the
scenes
here.
You'll
see,
it's
really
quite
quite
shortage.
B
B
Now,
if
you
look
at
the
top
now,
you
see
now
because
I
have
talked
so
much
so
I
talk
to
talk
longer
than
one
minute.
This
is
before
you,
then
the
odd
scales
down
to
zero.
So
if
there
are
no
requests
within
one
minute,
it's
good
that
your
tentative
service
has
no
pots
running
anymore.
Okay,
let's
make
an
update.
B
And
what
I'm
doing
here
now
is
I'm
next
that
I'm
drawing
you
at
the
paranoid
of
concurrency,
so
I'm,
going
up
to
the
service
I
set
a
concurrency
limit
at
10.
This
means,
as
soon
as
a
pot
gets
more
than
10
requests
at
a
time
then,
can
I
have
service
scales
up
the
number
of
pot.
You
see
this
in
action
in
a
second
I'm.
B
Also
scared
changing
this
auto
scale
window
of
60
seconds
two
seconds,
which
means
that
it
will
scale
down
after
six
seconds
when
no
request
comes
in
and
I'm
entered
using
an
artificial
delay
of
one
second
or
thousand
milliseconds
know
that
I
can
simulate
some
kind
of
work
on
the
trustor.
Let
me
do
that
and
yeah
you
see
it
again.
B
So
they
are
running
here
now
presenting
the
requests,
and
you
see
all
that
there
are
more
than
five
sexually
I
would
expect
five
containers,
because
I
have
50
and
then
Ted
concurrent
requests
so
in
order
to
have
50
parallel
requests
serve
by,
but
that
pot
there,
of
course,
is
five,
but
a
little
bit
more
because
kinetic
decides
to
already
scale
up
earlier
before
it
gets
the
full
utilization.
So
it's
always
it's
below
100%.
It's
typically
it's
around
seven
seventy
percent,
but
you
can
tune
this
percentage
this
way.
B
Okay
and
now
after
six
seconds,
you
see
again
that
all
your
cuts
are
really
scaling
down
to
zero
and
everything
is
gone
towards
OK
after
example,
which
is
about
or
you
can
make
a
roll
out.
So
if
you
look
again,
is
there
revision
list
of
our
service?
We
see
now
that
we
have
two
revisions
of
one.
It's
our
initial
revision,
this
one
and
then
I
changed
some
parameters
and
I
get
a
technics
neck
shot
of
that
configuration
with
the
second
revision
100%
of
traffic.
B
So
we
can
see
again
the
revision
list.
We
see
another
detect,
we
won
and
the
next
step
is
now
I'm
rolling
orders,
second
version
aufm
application,
v2
and
now
make
a
traffic
split
directly
to
v1
and
v2,
or
that
okay
I
can
use
again.
Okay
and
sir
okay
in
service
update
a
third
random
image.
So
this
is
my
my
Toyota
come
to
the
top,
because
I
have
some
one
second,
so
here
so
you
see
here
the
image,
it's
called
version
OH,
but
then
I'm
saying
make
a
terrific
fit
so
I'll
use
traffic
Nate
is
50.
B
This
is
always
the
latest
deployed
version.
So
in
this
case
it's
then
version
2
gets
50%
and
then
every
one
which
is
also
50%
and
then
I
can
okay.
This
Auto
scale
window
I
can
I
said
again
a
little
bit
higher,
so
I
should've,
worn
my
oh,
it's
SP
broke
so
I
said
it
again
60
seconds
of
that
we
can.
It
doesn't,
but
it's
not
so
endemic.
B
B
You
could
also
do
Bluegreen
deployment
to
say:
ok,
I'm,
just
firing
up
my
new
version
so
and
then
you
switch
over
completely
from
100%
of
the
new
version
after
it's
everything
is
up
and
you
have
tested
it
because
also
every
religion
UF
and
has
also
an
old
URL.
So
you
can
test
your
business
directly
without
going
over
the
service.
You
see
this,
for
example,
in
opens
of
my
last
service
written
list.
If
here
can
our
oops
its
mission
list
tier,
for
example,
you
have
that
one
and
then
I
can
say
provision
described
append
them.
B
A
I
haven't
seen
anything
just
gentle
reminder
if
you
have
questions,
feel
free
to
put
them
in
the
queue
a
window
or
chat
window
which
is
somewhere
in
the
middle
of
your
screen,
where
he
all
days
so,
and
if
that
is
not
enough,
also
find
me
on
Twitter.
That's
my
fear
and
DMS
are
open.
So
if
there's
something
that
we
can
answer
I'm
more
than
happy
to
pass
on
me
the
questions
and
get
you
the
desired
relief
in
answers,
but
now
/
too
much
ESA
Mateus.
What's
the
story
behind
that
title,
like
the
currywurst
king,
a.
C
C
A
C
C
All
right,
yeah,
welcome
to
the
second
part
of
this
ke
native
introduction.
Roland
was
covering
the
basis
of
conserving
and
in
my
eventing
specific
section
year,
I'm
going
to
leverage
some
of
that,
because
I
use
Canadian
venting
to
actually
populate
the
services
that
were
deployed
as
Canadians
roofing
services.
Don't
Canada
venting,
as
I
was
already
saying,
was
one
of
the
biggest
parts
of
Canadian
football
project.
B
C
To
some
degree
you
can
summarize
the
eventing
project,
you
can
see
it
as
a
universal
kind
of
subscription
and
event,
delivery
and
management
of
events
and
very,
very
important
here.
It's
already
based
on
cloud
events,
which
is
the
public
digital
stander
from
the
CN
CF.
So
everything
that
we
will
see
and
everything
that
we
will.
C
Canada,
if
eventing
is
really
based
on
public
standard,
called
cloud
events,
canady
eventing,
as
I
was
already
saying,
is
based
on
cloudy
event.
It's
it's
really
important
to
actually
underline
it
again.
It's
based
a
little
fishin
standard,
so
that
is
also
very
important
for
interoperability
with
other
systems.
So,
for
instance,
if
your
existing
application
is
interested
in
omitting
some
of
the
events
that
say
to
some
part
of
Canada,
you
can
just
exchange
it
and
have
a
vanilla,
HTTP
call
to
the
Canadian
components.
It
is
a
very
plausible
mechanism
for
the
overall
event
delivery.
C
It
has
the
concept
of
a
channel.
There
are
different
implementations
available
in
the
creative
ecosystem.
The
in-memory
channel
is
kind
of
the
toy
that
comes
with
kinetic
eventing
default
choice.
However,
you
can
also
pick
HMO
implementation.
It's
based
on
Angie
Kafka,
there's
also
alternatives
that
are
leveraging
messaging
infrastructure
from
Google
of
sub-project.
C
The
the
specific
routing
from
events
to
a
different
thing
is
done
through
llamó
configuration,
and
the
really
interesting
part
here
for
the
integration
with
third-party
systems
is
a
source.
So
you
can
easily
develop
your
own
source
where
you
can
call
into
your
own
legacy
system,
for
instance,
or
into
your
specific
database
or
whatever
kind
of
third-party
system.
You
have
the
received
events,
and
then
you
meet
them
as
cloud
events
to
the
Kay
native
components
like
these
things
and
in
our
case
I
think
is
addressable.
C
C
A
C
Not
specifically,
in
that
sense,
K
native
is
more
like
as
a
universal
system
for
like
you
could
see
it
as
your
eventing
mesh,
like
different
components,
produce
messages
and
deliver
them
to
the
system
and
later
on,
I
explain
a
concept:
that's
called
the
K
native
broker
and
mister
broker.
You
have
some
kind
of
trigger
where
you
can
do
some
kind
of
filtering
based
on
the
metadata
of
the
cloud.
Even
but
I
wouldn't
not
really
compare
it
so
much
with
technologies
like
JMS
JMS,
so
the
protocol
site
is
proprietary.
C
Every
system
uses
their
own
protocol,
so
there
is
not
that
much
great
inner
operability,
but
here
the
the
protocol
or
the
wireframes
that
on
protocol
side
is
HTTP
and
cloud
events,
so
you
have
much
lower
standardized
approaches
there,
so
you
can't
make
some
mesh
different,
JMS
implementations.
So
if
you
use
vendor
one,
you
have
to
use
vendor
once
APR.
You
cannot
combine
that
in
here.
It's
ready
through
a
real
official
standard,
not
JCP
standard
as
an
api
compliant
see.
If
that
makes
sense,
it.
C
Right
channels
and
brokers,
a
little
bit
more
advanced
topic,
really
important
for
the
actual
integration
and
that's
the
biggest
exposure.
4K
native
users
is
really
we
have
pool
of
different
key
native
event
sources
and
they
allow
you
of
a
nice
way
to
actually
integrate
your
certified
systems
with
K
native.
So,
for
instance,
you
could
ride
your
java
application
using
particles
for
instance,
and
call
into
your
database
receive
those
database
events
and
turn
them
into
cloud
event
objects.
C
And
then
you
emit
them
to
the
thing
that
is
injected,
which,
at
the
end
of
the
day,
would
be
just
an
HTTP
URL
where
your
source
would
perform
the
HD
post
most
of
the
like
full-blown
sources.
They
come
with
their
own
custom
resource
definitions,
so
they
are
very
declarative
when
you
create
them,
and
some
of
them
are
actually
running
to
an
operator.
You
can
have
different
integration
models
there
you
can
have
like
push
or
pull
based.
C
For
instance,
we
have
a
Kafka
source
that
I'm
going
to
show
you
later,
which
like
gets
the
messages
from
the
broker,
but
we
also
have
in
the
key
native
eventing
echo
system.
We
have
a
github
source.
So
the
get
up
sources
based
on
web
hooks
that
basically
inform
your
cluster
source
that
there
was
some
new
traffic
on
a
certain
pull
request
and
the
kind
of
requirement
that
all
of
these
sources
have
that
they
basically
convert
the
like
third
party
or
proprietary
event
form
art
into
standardized
cloud
events.
C
So
it
is
easy
for
consumption
on
different
languages
and
different
systems,
etc.
So
you
can
have
your
go
based
source,
which
is
delivering
events
as
HTTP
cloud
events
to
a
Java
service
that
is
doing
the
consumption.
We
have
a
few
sources
built
into
the
que
native
project.
So
as
in
que
native
eventing,
the
main
repository,
we
have
a
ping
source
which
is
kind
of
really
similar
to
what
you
can
do
with.
It
was
a
cron
job.
C
C
Instead
of
writing
a
full-fledged
operator
and
see
RDS
and
whatnot.
And
then
there
is
a
cane
ativ
contribution
repository
there's
a
bunch
of
other
stuff.
For
instance,
I
mentioned
to
get
up
source
already.
I
mentioned
the
Kafka
source
that
we
will
see
later
in
action
and
there's
also
integrations
using
apache
camel.
We
have
a
chemist's,
or
so
you
can
run
all
of
your
integrations
with
the
DSL
that
you
know
from
the
apache
camel
and
can
deliver
messages
from
camel
to
any
service
consumers
there,
as
well.
C
Now,
with
k
native,
we
see
three
big
areas
of
youth
cases.
Let
me
start
with
the
first
most
simple
one:
there
is
a
one
by
one
connection
to
a
cane,
a
dove
source
and
one
k
native
service
using
as
a
sinker.
So
there
is
a
direct
connection
and
this
is
actually
the
most
simple
way
to
get
cloud
events
from
a
source
to
your
application.
That
is
consuming
these
events.
However,
there
is
a
one
by
one
connection
like
a
direct
connection
from
the
source
to
the
service.
C
That
means
there's
a
little
bit
of
drawbacks
here,
so
there's
like
no
back
pressure,
support
or
no
active
cueing
support
when
service
is
not
available
and
only
one
service
consume
that
event.
So
if
you
want
to
have
two
services
that
want
to
consume
the
event,
you
would
have
to
kind
of
scale
up,
you
need
a
second
source
and
you
need
a
second
service.
But
again,
this
is
the
first
way
in
Duquesne
native
for
consuming
and
there's.
C
C
Two
files
here
in
my
folder
one
is
a
event
display,
which
is
a
key
native
proving
service.
Let
me
just
quickly
show
you
what
the
Yama
looks
like
so
it's
API
service
for
serving.
Is
it
kind
of
serving
I?
Have
it
in
a
mincer
display
and
I
bring
my
image
if
it's
key
I/o,
mats,
W
and
then
event.
So
this
is
my
case
go
application
that
is
receiving
now.
This
thing
is
already
deployed,
but
there
is
no
traffic
to
that
particular
candidate
serving
service.
So
it's
not
yet
SCADA.
C
However,
let
me
show
you
what
a
ping
source
would
be
looking
like,
so
ping
source
has
the
API
version
here,
a
native
death
and
then
even
alpha-1,
and
it's
a
kind
of
dipping
sauce.
Here
we
have
a
name
it's
to
test
pink
sores
in
our
case,
and
what's
really
important
here,
is
inside
of
the
speck
object.
C
We
have
that
schedule
so
every
every
minute
we
get
some
data
here
and
then
all
of
the
events
that
are
created
from
the
source
are
emitted
to
a
sink
and
we
use
a
destination
here
or
my
ping
display,
which
is
a
kanay
disturbing
service.
Let
me
apply
the
file
and
what
you
will
see
is
that
hopefully
a
pod
is
starting
up.
It
is
starting
up.
C
We
can
now
take
a
look
at
the
lot
when
a
container
has
been
started
and
is
fully
created,
though
we
should
see
a
message
that
says
hello,
redhead
developers
on
the
lock
console
I
need
a
log.
I
provide
the
full
name
of
the
pot
and
then,
as
you
can
see,
there
is
two
containers
and
we
are
interested
in
chooser
container
here.
So
what
we
see
is
here
a
little
bit
of
emoji
I
print
out
the
entire
payload
off
my
cloud
event
here.
So
it
has
some
specification
version.
It
has
type.
C
So
the
type
of
the
source
is
a
ping
source.
I
have
like
the
source
where
it
actually
came
from
the
event
like
the
event
source
source
is
my
name
space
default
here:
ping,
source
etc.
It
has
an
ID,
it
has
time
stamp
and
it
has
data
content
and
then
in
cloud
events,
it
specified
that
all
of
the
data
comes
inside
of
the
data
body,
but
every
minute
there
is
event
and
now
I
was
talking
over
a
minute.
We
see
the
second
event
here
again,
it
says
is
a
valid
cloud
event.
C
It
has
some
nice
emoji
on
there
in
my
logger,
that's
pretty
much
the
first
hello
world
kind
of
experience
with
key
native
eventing,
so
the
next
step
is
a
little
bit
more
flexible,
so
the
source
to
service
delivery
is
now
done
through
the
concept
of
a
channel
which
is
basically
an
abstract
mechanism
or
yeah
receiving
data
and
then
delivering
data,
but
on
different
principles.
Here,
the
multiple
services
can
basically
consume
the
same
event
with
just
one
and
it's
done
through
a
subscription.
C
What
we
see
here
on
my
slide,
deck
on
the
left
side
is
I
have
now
two
sources
that
are
Boost
emitting
their
events
to
the
same
channel
like
one
channel
object,
but
now
I
have
two
subscriptions,
so
my
first
service
here
is
receiving
all
of
the
messages
and
the
second
one
is
receiving
the
same
type
of
the
messages.
So
this
is
a
little
bit
more
flexible.
I
am
also
the
opportunity
to
bring
in
a
different
channel
I.
Don't
need
to
use
the
default
choice
of
the
'memory
channel.
I
can
go
with
an
Apache
Kafka.
C
So
if
you
deploy
the
channel
behind
the
scenes,
the
control
for
the
Kafka
channel
is
creating
a
specific
topic
with
a
specific
setup
like
replication
factors
and
participations
as
specified
them
when
you
set
it
up
and
but
it's
all
taken
care
of
for
you,
so
you
submit
messages
to
the
channel
and
then
with
the
subscription
each
subscriber
against
the
same
message.
So
there's
still
a
little
bit
of
drawbacks
there.
C
It
has
some
kind
of
infrastructure
needs
because,
as
I
said,
if
you
go
in
with
a
Kafka,
you
have
to
Kafka
running
somewhere
and
still
there
is
no
filtering,
because
every
subscribed
service
is
basically
receiving
all
of
the
and
the
last
more
Universal
is
really
the
source
and
service
delivery
through
a
broker
and
a
trigger,
and
this
is
really
a
nice
way
to
see
all
of
the
benefits
from
Canadia
venting.
Basically,
you
use
the
Canadians
broker,
as
you
were
eventing
mesh
for
distributing
all
of
the
events
in
your
specific
page
here.
C
What
we
see
here
is
I,
have
a
green
source
and
I
have
a
yellow
source
and
I
have
a
few
events
emitted
to
the
same
broker.
The
que
native
broker
and
then
I
have
not
really
a
subscription,
as
I
had
before
it
uses
subscribers
behind
the
scenes,
but
this
is
a
trigger
that
has
deployed
here
so
the
first
trigger
says
a
little
broker,
I'm
interested
in
all
of
the
yellow
events.
So
this
service
is
not
getting
every
event
on
the
broker.
C
It's
only
getting
the
yellow
event
and
to
trigger
here,
for
my
second
service
is
saying:
hey
I'm
only
interested
in
this
greenish
event,
so
he's
also
just
getting
the
green
one,
though
three
events
go
into
the
broker.
One
is
going
to
my
second
service
and
two
of
them
are
going
to
my
first
service,
so
I
have
a
fine-grain
way
to
actually
trigger
event.
Delivery
based
on
attributes
of
the
cloud
events,
so
I
was
using
the
type
filter
here.
So
I
said
the
type
is
a
yellow
event
and
the
type
is
a
green
event.
C
We
also
have
the
opportunity
to
use
a
multi
tenant
broker
options,
so
that
is
a
broker
running
in
a
global
Canadian,
eventing
namespace,
and
not
in
your
user
name
space,
where
the
programs
and
then
the
trigger,
is
really
the
driver
and
the
routing
component
here.
So
it
filters
events
based
on
the
type
or
based
on
the
source.
C
So
if
you
have
a
few
different
sources
providing
all
of
the
same
cloud
event
type,
you
can
filter
I,
want
it
just
from
source,
a
or
just
from
source
B
with
the
type
of
blah
blah
you
can
also
easily
eat.
As
I
was
saying
earlier
on
with
your
existing
applications,
you
can
deliver
messages
direct
to
the
broker
and
feed
it
in
there,
and
then
the
trigger
also
would
still
apply
to
everything.
C
That's
available
and
the
trigger
can
also
basically
produce
new
events
and
return
them
I
guess
it
replied
to
the
broker
and
all
of
that,
and
that
again
is
very,
very
important.
It's
all
done
through
standardized
cloud
event
objects.
So
there's
like
really
big
interoperability
with
multiple
vendors
and
multiple
programs
as
possible.
Here
my.
A
C
The
Canadian
broker
is
really
the
eventing
match.
That
is,
that
is
the
thing
that
is
distributing
all
of
the
events
based
on
a
trigger.
It's
not
really
related
to
a
broker
in
the
sense
of
the
messaging
brokers
that
you
may
be
confused
with.
However,
the
broker
uses
a
channel
underneath
the
scenes
for
the
distribution
of
all
of
the
messages.
So,
if
you
say
I
want
to
have
a
can
a
diff
broker,
it
gives
you
an
object
of
the
broker
in
a
per
namespace,
then
behind
the
scenes
it
is
using.
C
C
C
C
One
is
actually
the
ingress
of
the
broker
and
the
other
one
is
for
the
filter
of
the
broker,
and
those
two
parts
in
combination
are
basically
the
broker
that
I'm
going
to
use
here.
Now
these
services
they
are
already
applied,
so
they
are
already
actively
running
in
my
namespace,
but
since
there
was
no
message
delivered
by
the
broker
slash
trigger
to
either
ease
of
serving
services,
none
of
them
are
now
running.
Now.
C
C
The
Kafka
source
is
in
the
same
API
version
group
here
it
is
sources,
cañedo
death
and
it
has
a
kind
of
Kafka
source
here,
I,
give
it
a
name
and
then
inside
of
the
specification,
that's
what
really
interesting
here
is
I
gave
it.
It
comes.
I
gave
it
a
consumer
group,
in
my
case,
I'm
using
demo
and
here
I'm
using
the
cluster
that
I
haven't
locally
on
my
OpenShift
instance,
here
I'm
using
scrim,
Z
or
redhead
empty
streams.
C
Here
it's
running
in
the
Kafka
namespace
and
my
bootstrap
server,
that's
the
default
setup
from
the
strategy
project.
Is
this
URL
and
I'm
having
the
topic,
so
the
source
is
listening
to
one
topic
in
our
case.
Topic
is
called
my
topic
now.
The
important
difference
here
between
the
previous
definitions
is
that
the
thing
is
now
no
longer
a
que
native
serving
stress.
It
is
the
broker
and
it
is
the
default
go.
C
What
we
see
here
is
the
part
that
I
was
laid
with
creating
your
based
on
my
labeling
is
actually
that
different
default
broker
running
in
my
namespace.
So
all
of
the
events
that
are
coming
from
the
topic
choose
it
to
the
source
here
to
the
Kafka
source,
are
being
transformed
or
being
distributed,
broker
and
later
on
for
consumption.
Let
me
apply
my
Kafka
source
here
and.
C
I
made
a
change
to
the
ping
source,
though
again
here
we
have
the
test
ping
source.
There's
no
modification
in
terms
of
the
payload,
however,
when
I
apply
it
I,
basically
really
configured
a
currently
running
ping
source
and
I
will
have
the
events
from
that
source
going
through
my
broker
now,
instead
of
the
que
native
serving
service,
so
the
ping
display
will
eventually
go
away
because
it
will
all
receive
any
message,
because
the
reconfigured
version
of
the
pink
source
is
going
to
emit
all
of
its
events
like
every
minute.
C
What
we
see
here
is,
it
doesn't
say,
create
it
because
I
just
changed
it,
and
here
we
see
a
new
pod
is
coming
up
now,
that
is
representing
the
latest
configuration
and
when
this
specific
pod
is
actually
running,
we
will
see
the
old
guide
will
be
terminated
and
then
this
instance
is
no
longer
emitting
the
events,
this
failure
and
that
will
go
away.
Okay.
Now
what
we
have
here
is
we
have
two
sources
configured
to
emit
events
to
the
broker.
C
However,
we
are
not
yet
consuming
them,
so
this
is
where
all
of
the
magic
comes
in
and
the
broker
is
really
just
a
black
box
concept.
The
user
usually
doesn't
have
to
deal
with
it
much
it's
more,
an
interoperability
through
the
triggers.
Now
let
me
see
the
triggers
for
some
event
filtering
here.
So,
for
instance,
how
can
I
filter
events
from
my
current
source?
So
this
is
basically
the
API
that
users
are
mostly
interacting
with,
so
there
is
a
kind
trigger
that's
innovating,
namespace
and.
C
What
is
interesting
here
inside
of
the
specification
I
say:
I
want
to
listen
on
the
default
broker
and
I
want
to
apply
a
few
filtering
rules,
so
I
have
filter
based
on
cloud
event,
attributes
and
every
cloud
event
does
need
a
attribute
called
type
and
in
our
case
mr.
Kay
Native,
Kafka
sourced
event
type
for
all
of
the
Kafka
events
are
actually
JFK
native
Kafka
event,
and
then
it
is
basically
delivering
the
events
to
the
interested
subscriber,
which
in
our
case,
is
a
cane
ad
serving
service
vodka
broker.
Let
me
apply
this
trigger.
C
A
A
C
A
buff
in
the
schedule
is
the
pod.
I
was
talking
a
little
bit
longer
here
and
I
have
already
prepared
a
lot
of
dumping
messages
to
my
Kafka
object.
So
sorry
to
my
Kafka
topic,
oh
there's
a
lot
of
messages
already
in
that
topic
and
based
on
the
scaling
facility
that
Roland
was
explaining
now,
okay
native
sees
there
is
messages
delivered
from
the
broker,
choose
a
different
Kafka
display
here.
C
C
The
events
here
come
from
my
default
names
brace
and
come
from
the
Kafka
source,
which
has
a
name
and
which
is
bound
to
a
specific
topic.
It
has
some
subject
that
is
an
attribute
specified
in
the
Claudia
vent
specification.
In
our
case,
we
see
this
is
message
number
719
on
partition.
Number
number
57.
C
We
use
some
cloud
event
extensions.
Are
we
using
here?
So
basically
the
message
was
hopping
through
different
channels,
as
the
broker
mechanism
was
playing
with
it.
So
we
see
here
that
there's
a
que
native
history,
so
it
came
through
a
trigger
based
channel
before
it
was
actually
delivered
to
my
service
and
then
here
I
see
some
data.
That
is
just
some
JSON
data,
which
is
basically
the
exact
payload
that
I
would
receive
from
the
WebSocket
service
that
my
background
application
is
hammering
data
to
okay.
I
have
a
second
trigger.
C
What
I
have
here
is
I
have
a
different
filter,
I'm,
basically
saying
I'm
only
interested
in
events
that
are
ping
like
a
native
to
our
desk,
a
native
sources
ping,
and
then
it
is
routing
these
events
to
a
different
service.
So
let
me
apply
that
I
have
already
applied
that
and
I
guess.
I
have
two
words
messages
here
and
you.
C
C
And
then
you
can
see
that
actually,
this
guy
is
only
having
messages
for
the
pink
source.
Yeah,
there's
no
kafka
message
in
there.
We
have
seen
this
before
still
in
the
context
as
well.
Now
it
went
through
the
broker,
so
we
see
the
extensions.
That's
the
difference
to
my
first
example
was
the
ping
source
that
we
see
as
well
how
it
was
transferring
through
the
cluster.
C
It
says
it
came
from
the
channel
behind
the
broker
and
there's
some
time
of
arrival
when
that
actually
was
delivered
et
cetera
and
there's
some
tracing
information,
you're
known
as
well
yeah.
So
this
was
the
filter
for
the
ping
message
and
the
other
one
was
to
filter
for
the
kafka
messages,
and
that
basically
was
my
demo
a
little
bit
more
there's
few
more
types.
There
is
an
event
registry
which
is
about
discoverability
of
events.
C
You
can
specify
them
on
the
sources
and
through
event,
types
so
that
you
can
actually
have
the
developer
know
what
kind
of
event
are
available
for
me
to
consume,
and
there
are
some
more
concepts
that
allow
you
to
basically
have
some
chaining
of
different
services
or
branching
events
with
different
filters.
That's
called
parallel
and
the
other
one
is
called
a
sequence
and
that's
probably
it
with
the
full-blown.
In
any
event,
in
demo,
lots
of
Kafka
messages
flying
around
they're.
A
Nice,
thank
you
so
much
so,
unfortunately,
we
don't
really
have
any
kind
of
questions,
so
I
assume
that
everybody
is
happy
again.
If
you
want
to
rewatch
this
session
is
going
to
be
recorded
and
published
on
the
same
website
that
you
got
the
calendar,
invite
from.
Is
there
anything
else?
I
wanted
to
talk
about?
Yes,
just
briefly
mention
that
is
going
to
be
the
other
way
around.
A
There's
going
to
be
a
new
session
with
Gavin
Johnson
talking
about
hibernate
coming
up,
June
16th
website
is
going
to
be
updated
to
very
soonish,
make
sure
to
also
reach
out
to
materials
or
roland
or
myself
on
twitter.
If
you
have
any
further
questions
and
yeah
unless
roland
wants
to
have
the
last
final
words
and
ask
some
more
questions
or
Matias
wanted
to
say
something
else,
I
guess
that
spin
it!
So.