►
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
KEDA: Event Driven and Serverless Containers in Kubernetes - Jeff Hollan, Microsoft
Event driven and serverless architectures are defining a new generation of apps. However, to take full advantage of the serverless benefits of event driven, your application needs to scale and react to those events instantly - scaling from zero to potentially thousands of instances. These events may come in the form of queue and Kafka messages, or events from a cloud provider like AWS SQS or Azure Event Hubs. KEDA 1.0 is an open sourced component created in partnership with Red Hat and Microsoft Azure that provides event driven autoscaling for your Kubernetes workloads. In this demo-filled session, learn how to get started with KEDA, how customers are using it to efficiently scale and run event-driven apps, and how everything from a simple container to a serverless function can integrate seamlessly and scale natively in an event-driven and Kubernetes world.
https://sched.co/Uaa6
A
Perfect,
thank
you.
So
much
Wow
I
haven't
done
anything
yet
wait
to
clap
until
I
actually
do
something
now.
Thank
you
all
very
much.
We're
gonna
try
to
make
this
really
fun.
I'm,
honestly
thrilled
and
very
humbled
to
be
here
today.
This
is
my
first
ever
cube.
Con
I've
been
a
Youtube
attendee
for
the
last
few
years.
A
It's
it's
been
an
incredible
week,
so
hopefully
I'll
be
able
to
share
some
stuff
here
that
you'll
be
able
to
take
away,
but
also
one
of
the
things
that
I
really
love
about
cube
con
in
this
community
is
that
I
also
want
to
open
this
up
to
a
dialog
and
whether
it
happens
in
this
room
or
after
the
fact
at
the
booth
on
Twitter
and
community
stand-ups
is
we're
kind
of
moving
this
world
of
serverless
and
kubernetes
forward.
So,
as
just
mentioned,
I'm
Jeff
Holland,
we'll
have
a
fun
session
today.
A
In
fact,
I
was
well
I.
Switch
to
this
first
slide.
I
was
gonna,
make
this
entirely
Star
Wars
themed
and
have
like
gifts
all
over
the
place
from
Star,
Wars,
stuff
and
I
had
all
the
jokes
written.
But
then
earlier
this
week
as
I
was
going
through,
the
deck
has
like
I,
don't
know
how
someone
from
Disney
is
gonna,
be
here
or
they're.
A
Gonna
catch,
wind
and
I
do
not
want
to
get
sued
by
Disney,
so
just
use
your
imagination
and
I
still
snuck
some
in
at
the
end,
I've
got
a
fun
demo
that
will
tie
it
back
to
Star
Wars,
which
I'm
very
in
the
mood
for
right
now.
Okay,
so
to
start
with,
serverless
means
a
lot
of
things
and
it
means
nothing
because
marketing,
but
for
now
just
focusing
on
how
I
think
about
service
to
set
the
context,
regardless
of
Technology.
A
In
my
mind,
serverless
is
really
about
enabling
developers
IT
admins,
really
anyone
dealing
with
code
to
be
able
to
focus
primarily
on
just
their
application
logic
and
all
the
other
pieces
that
you're
usually
thinking
about
when
shipping
an
application.
You
don't
have
to
worry
about
anymore
they're,
taking
care
by
the
platform
by
tools
behind
the
scenes
to
enable
you
to
be
faster
and
more
efficient.
Now
service
has
a
lot
of
attributes.
This
isn't
a
requirements
list,
there's
a
whole
spectrum.
Some
things
are
service
and
they
have
some
of
these.
A
But
a
few
of
the
qualities
are
things
like
event-driven,
something
triggers
an
event.
It
triggers
your
code
to
say:
hey
something's
happened
here
to
run
and
as
part
of
that
event-driven
it
means
that
that
compute
will
be
made
available
on
demand
as
well.
So
hey
an
event
happen
that
I
need
to
run
this
code,
for
let's
make
sure
that
we
have
computable
just-in-time.
A
For
that
event,
and
there's
often
this
aspect
of
paper
use
and
again
this
can
vary.
There's
an
entire
spectrum.
Sometimes
paper
use
is
like
running
an
AWS
lambda
or
the
Azure
function
service,
and
you
literally
only
pay
when
your
code
is
actually
executing,
but
paper
use
might
also
just
mean
that,
because
you're
doing
event-driven
and
on-demand
computing,
that
you're
scaling
your
resources
only
when
you
need
them
and
so
you're
able
to
more
efficiently
use
your
underlying
compute.
A
In
fact,
I
was
just
looking
over
the
last
just
the
last
three
weeks,
there's
been
over
a
quarter
of
a
trillion
executions
that
happened
around
as
your
functions,
so
we
have
a
bunch
of
stuff
that
make
up
those
executions,
often
where
people
get
started,
our
simple
automation,
type
tasks,
a
pull
request
gets
open.
Can
you
add
this
label?
Can
you
add
these
checks,
a
5
o'clock
p.m.
can
you
shut
down
these
machines
or
run
an
update?
A
Can
you
post
a
slack
when
it's
lunchtime
and
ask
for
a
vote
on
where
we
want
to
go
for
lunch
really
good
way
to
get
started?
I
often
call
automation
and
serve
a
list
like
the
gateway
drug,
but
often
it
grows
from
there,
and
people
can
start
to
use
them
for
other
things.
Glue
is
another
very
common
place
to
see.
Serverless
containers
and
functions
used
I've
got
over
here.
I've
got
sequel
over
there.
They
need
to
be
able
to
talk
better
to
each
other.
Maybe
I
can
glue
them
together
with
some
serverless
rapid,
api's
I.
A
Think
about
how
Netflix
is
documented,
how
they're
using
service
Tekken's
to
service
methodologies,
where
they
have
front-end
developers,
writing
the
UI
for
Netflix,
who
need
to
be
able
to
fetch
fetch
data
from
back-end
services
and
rather
than
having
to
spin
up
a
full
micro
service
to
fetch
that
data
from
they
empower
their
developers
to
just
write
little
functions.
They
go
grab
the
data
that
they
need
and
return
it
back
to
the
UI.
A
So
these
very
rapid
API
is
for
mobile
apps
web
apps,
you
name
it
are
a
big
one
and
then,
as
things
kind
of
grow,
up
kind
of
the
bigger
ones
that
we
see
are
really
around
event
streaming
and
cue,
processing,
billions
of
messages
funneling
through
queues
and
streams,
and
kafka,
processing
and
ricci,
transforming
the
data
making
insights
and
analysis
full
suites
that
are
made
up
of
hundreds
of
functions
with
data's
being
passed
around
all
with
those
service
principles.
I
talked
about
before.
Actually
a
good
example
of
this
is
Best
Buy.
A
They
gave
a
talk
at
the
spring
one
conference
that
honestly
I'd
recommend
checking
out
if
you're
interested
about
how
they're
using
server
lists
and
other
tools
to
build
a
modern
retail
experience.
So
they
have
a
few
cool
stuff
here.
One
is
that
they
do
a
lot
of
processing
on
premises
at
regional
data,
centers
they're
using
things
like
kubernetes.
A
You
can
see
open
shift
here
and
at
some
point,
some
of
that
data
is
gonna,
make
its
way
to
a
cloud
they're
using
a
Kafka
like
service
in
Azure
called
event
hubs,
they're,
processing,
those
Kafka
events,
those
little
lightning
bolts
that
you
see
those
are
functions
so
they're
using
some
service
functions
here
to
be
able
to
scale
rapidly
transform
the
data,
put
it
into
the
right
databases
and
power.
Things
like
the
bestbuy.com
experience
and
Best
Buy
had
a
lot
of
requirements
right.
One
of
them
is
hey.
We're
gonna
have
things
like
Black
Friday.
A
We
need
to
make
sure
that
our
compute
can
scale
rapidly
at
midnight
or
whenever
Black
Friday
is
earlier.
Every
year.
It's
probably
like
8
o'clock
in
the
morning
on
Thanksgiving
now,
but
at
8
o'clock
in
the
morning
on
Thanksgiving.
They
need
to
be
able
to
scale
rapidly.
They
also
had
some
other
requirements.
They
knew
Kafka,
they
loved
Kafka
they're
like
hey.
If
and
if
an
exception
happens.
If
something
goes
wrong,
we
want
to
be
able
to
know
that
we
have
control
to
say
you
know
what
don't
checkpoint
the
stream.
A
We
need
to
retry
these
messages
and
the
last
one,
which
is
an
important
one,
we'll
get
to
it
later
in
the
presentation
ordering
was
super
important.
It
very
much
mattered.
If
the
item
was
purchased,
item
was
cancelled,
shipment
was
created.
What
order
those
events
get
processed
was
very
important
to
them.
They
were
able
to
build
this.
They
say
in
a
matter
of
weeks
where
traditionally
it
would
take
them
months.
A
Yes,
a
bunch
of
cue
messages
will
eventually
cause
the
CPUs
to
rise,
but
the
real
thing
I
want
to
be
able
to
scale
on
is:
oh
there's
a
million
cue
messages
here
that
need
to
get
processed
and
that's
just
not
what
kubernetes
is
doing
by
default.
So
we
looked
at
this.
We
looked
at
some
of
the
learnings
that
we
had
and
the
thing
that
we
kind
of
developed
and
released
again
in
partnership
with
Red
Hat
was
kaida,
so
this
just
went
1.0
this
week
on
Tuesday
and
kada.
A
Is
that
event-driven
scale
controlling
that
can
run
inside
of
any
kubernetes
cluster,
so
kada
can
monitor
the
rate
of
events
to
proactively
scale
a
container
even
before
the
CPU
has
been
impacted.
So
in
the
example
of
queues
that
I
was
using.
Keita
can
actually
say:
oh
wow,
there's
a
million
queue
messages
here.
I
need
to
hurry
and
scale
out
to
a
bunch
of
replicas
I,
can't
just
wait
for
the
autoscaler
defaults
to
scale
it
out.
It's
all.
It's
doing
behind
the
scenes
is
just
feeding
this
data
into
the
native
kubernetes
api.
A
So
we
didn't
reinvent
anything
here.
It
allows
containers
to
scale
to
and
from
zero
as
well,
in
the
same
way
that
a
function
or
a
lambda
in
the
cloud
can
scale
to
and
from
zero.
It's
completely
open
source.
We
just
worked
with
the
service
working
group
and
got
buy-off
we're
not
working
with
the
Oversight
Committee,
and
our
plan
is
to
onboard
this
to
the
CNC
F
in
the
coming
months.
A
All
right
I
was
eating
some
popcorn
before
I
think
at
a
kernel
stuck
in
my
throat
anyway,
so
onboarding
to
the
CNC
F,
which
we're
excited
about
an
install
into
any
cluster.
So
kate
is
very
non-intrusive.
You
can
pop
it
into
a
cluster
e
where
you
already
have
deployments
and
you
could
just
map
it
to
only
scale
things
you
want
to
it's,
not
a
decision.
That's
gonna
change
everything
and
it's
got
a
bunch
of
extensible
trigger
sources.
A
It
knows
about
as
your
events,
it
knows
about
Kafka,
rabbitmq,
Nats,
Redis,
AWS,
GCP,
a
lot
of
contributions
from
the
community
as
well
to
improve
this
library.
So
to
kind
of
show
you
this
in
action,
I'm
just
gonna,
do
a
very
quick
demo.
I
have
a
cluster
already
set
up
and
the
only
thing
I
have
in
this
cluster
right
now
is
well.
First
I've
already
installed
the
k2
operator,
which
I'll
go
into
how
that
works
in
a
second
and
then
I.
A
Have
this
RabbitMQ
consumer
this
container
that's
going
to
trigger
and
consume
rabbitmq
events
and
you'll
notice
right
now,
it's
scaled
all
the
way
to
zero
and
the
reason
it's
scaled.
All
the
way
to
zero
is
because
k2
knows
that,
there's
nothing
on
that
queue
that
it
needs
to
run.
Let
me
actually
switch
to
the
right
directory,
so
what
I'm
gonna
do
here
is
I'm
gonna
run
this
job
that
will
publish
a
thousand
messages
to
this
queue.
Let's
go
ahead
and
watch
what
happens.
A
You'll
see
the
job,
spinning
up
the
job
just
completed,
so
it's
publishing
those
messages
and
right
away.
You'll
see
that
a
consumer
has
just
popped
up.
Keita
noticed.
Oh
there's
actually
work
to
be
done
here
and
it's
now
added
one,
but
even
before
I
finish
this
sentence,
it's
not
just
waiting
for
the
CPU
Keita
actually
can
see.
Oh
there's,
actually
a
thousand
messages
here
we
want
to
be
able
to
very
rapidly
scale
out
so
I'm
already
at
four
I.
Would
guess
by
the
time
that
I
get
to
the
end
of
this
next
sentence.
A
It
will
scale
out
to
eight
there
we
go
like
magic.
It's
gonna
continue
to
scale
out
this
bursty
serverless
scale
consume
those
messages
and
if
we
left
this
open
for
about
thirty
seconds
once
that
queue
is
empty,
Keita
will
help
drive
the
scaling
decisions
to
bring
that
all
the
way
back
down
to
zero,
so
I'm,
providing
these
service
container
x'
to
consume
compute
only
when
I
need
them,
because
Keita
is
helping
kubernetes
know.
I
only
need
these
containers
to
run
when
there's
actually
events
to
process.
A
It's
a
very
simple
demo
there
to
see
kind
of
that
in
action,
so
you're,
not
just
looking
at
slides,
so
what's
happening
behind
the
scenes
here,
as
I
mentioned,
there's
an
operator
this
you
can
install
with
like
a
helm,
chart
yam
or
whatever
else,
super-lightweight
entirely
written
and
go
it's
helping,
monitor
those
event
sources
at
a
configurable
period,
and
it
also
has
with
it
those
scalars
the
knowledge
of
those
event
sources.
This
is
extensible
as
well.
A
You
could
write
a
G
RPC
discoverable
scale
or
you
can
contribute
directly
to
Keita
and
the
other
pieces
here
is
the
metrics
API
that
kubernetes
exposes
already
in
the
horizontal
pod
autoscaler.
That
knows
how
to
talk
to
that.
Metrics
api-
and
the
other
piece
I
have
here
is
my
event
source
and
the
demo.
I
just
said
it
was
rabbitmq.
This
could
be
Kafka,
it
could
be
AWS.
Sqs
right
could
be
anything,
and
now
the
last
thing
I
have
is
I've
got
my
deployment.
A
I
have
my
actual
deployment,
my
set
of
containers
that
I
need
to
run
in
kubernetes
in
the
way
that
I
describe
my
relationship
between
the
deployment
and
the
event
source
is,
with
this
custom
resource
called
the
scaled
object.
So
I,
don't
know
how
much
you
can
read
this
now.
I
know
the
fonts
a
little
bit
greyed
out.
All
this
really
has
is
it
says:
hey.
A
What's
the
deployment
that
I'm
scaling
that
scaled
target
reference,
which
I'm
calling
my
deployment
here
I
can
set
some
metadata
like
how
frequently
to
pull
for
events
you
can
control
minimums
and
maximums.
If
you
want
to
make
sure,
maybe
you
never
want
to
scale
to
zero?
Maybe
you
never
want
to
scale
about
60,
and
then
you
can
just
define
the
metadata
for
your
event.
Source
like
in
this
case,
hey
I,
want
to
listen
to
Kafka.
This
is
where
to
find
Kafka.
A
This
is
the
consumer
group
I
care
about,
and
this
lag
threshold
thing
that
lets
you
control,
how
aggressively
it
scales.
Sometimes
the
single
message
might
represent
a
lot
of
work,
so
you
want
to
scale
out
very
aggressively
and
other
times.
A
thousand
messages
might
just
be
a
second
of
work,
so
you
want
it
to
scale
more
conservatively.
You
have
some
options
here
to
control
that
more
as
you
need
so
once
I'm
ready
to
go.
I
can
then
just
apply
that
deployment
to
kubernetes,
throw
it
in
there.
A
In
this
case,
like
I,
did
before
I've
grade
it
out,
it's
scaled
to
zero
and
all
the
Keita
operator
is
doing
now.
Is
it
identified
that
scaled
object,
and
it
just
constantly
is
asking
that
event
source?
How
many
events
are
being
generated
right?
Is
there
work
to
be
done
here
and
eventually,
a
queue
message
or
a
Kafka
stream
message,
or
whatever
else
is
going
to
land?
On
that
event?
A
Source
k-tiz
can
identify
it,
and,
just
like
you
saw
my
demo,
it's
going
to
scale
it
up
to
one
and
then
potentially
help
the
HPA
and
again
the
HPA
is
doing
all
the
scaling
here.
Kate
is
just
feeding
at
the
right
data
eventually
scaled
out
to
as
many
as
you
need.
Okay,
so
that's
kind
of
how
Keita
works
in
a
nutshell,
and
there
were
a
few
core
principles
that
we
as
a
community
had,
as
we
were
building
kata
the
first
one
is.
A
We
didn't
want
to
rebuild
that
kubernetes
already
offered
out-of-the-box
kubernetes
has
an
auto
scaler
great.
Let's
use
that
one
kubernetes
has
a
metrics
concept.
Let's
use
that
concept,
it's
just
augmenting.
What
was
out
of
the
box
with
additional
data
and
insights
and
capabilities
to
bring
up
these
service
workloads.
It
is
also
extremely
single
purpose:
it's
not
a
service
platform.
This
is
not
trying
to
do
everything.
It
only
does
one
thing
event-driven
scaling
and
it
tries
to
do
that.
A
One
thing
very
well
super
simple,
very
non
intrusive
to
see
RDS,
and
that's
it
just
that
single
operator
running
in
a
cluster.
It
can
work
with
any
container
in
any
workload.
I'll
show
you
later
today,
you
could.
You
could
take
that
container.
It
could
be
running
your
own
custom
code.
It
could
be
running
an
Asscher
function,
doesn't
matter
any
workload
if
it
has
an
event
source
cated
knows
how
to
scale
it.
We
also
in
kind
of
a
design
principle
and
what
makes
kata
different
and
we'll
get
to
this
a
little
bit
too.
A
We
wanted
to
make
sure
that
application
developers
could
take
advantage
of
all
of
the
features
that
make
message:
brokers,
great
RabbitMQ,
Kafka
Nats.
All
of
these
have
really
rich
pieces
of
functionality
that
can
improve
my
application.
We
didn't
want
that
to
get
lost
in
the
translation
of
bringing
service
containers
and
then
finally
is
open
built
with
the
community,
which
will
go
into
more
there's.
One
scenario:
I
want
to
call
out
quickly.
A
It's
important
to
note
when
you
think
about
these
rapid
scale
out
and
also
rapid
scale
in
and
that's
what
do
I
do
if
I
have
a
long-running
execution.
This
came
up
very
early
with
kada.
It
came
up
with
a
few
of
our
customers
that
we're
working
with
where
they
were
like:
hey,
yeah
Jeff
and
your
demo.
You
dropped
a
thousand
rabbitmq
messages
and
you
pretty
much
just
printed
out
hello
world,
but
what?
If
every
cue
message
actually
represented
a
significant
amount
of
work?
A
What
if
every
cue
message
is
a
video
that
has
to
be
transcoded,
that's
going
to
take
8
hours
and
the
problem
here
can
be
imagine:
I
drop
a
thousand
videos
that
need
to
be
transcoded.
Ok
to
cease
it
you've
configured
your
scale,
settings
enough
and
k2
scales
you
out
to
a
number
of
different
replicas
and
I've
it
here
there
could
be
like
a
progress
bar.
This
is
how
far
they
are
on
their
eight-hour
job.
Okay,
you
can
see
instance,
two
and
three
are
close
to
being
done.
A
A
The
way
I
like
to
think
about
it
is
that
the
HPA
is
very
much
like
vanos
and
that
it's
gonna
snap,
its
fingers
and
it's
gonna
get
rid
of
a
bunch
of
my
instances,
but
it
has
no
regard
if
you
are
spider-man
or
Iron
Man.
It's
just
gonna
snap,
its
fingers.
So
the
problem
here
with
kada
is
that,
if
I'm
seven
hours
into
an
eight
hour
job
and
the
HPA
snaps
its
fingers,
it's
very
possible
that
the
thing
that
only
needed
ten
more
minutes
just
got
killed,
and
so
we
were
trying
to
figure
out.
A
How
do
we
solve
for
these
more
kind
of
advanced
messaging
workloads
that
might
be
long
running
so
there's
two
options
that
we
have
to
combat
Thanos.
We
call
them
Hulk
and
Iron
Man.
This
presentation
is
full
of
spoilers
by
the
way.
So
if
the
words
baby
Yoda
or
if
you're
sensitive
to
those
words,
you
might
just
want
to
leave
now.
Okay,
so
there's
two
options:
you
have
here
option
one
you
can
just
leverage
the
out-of-the-box
kubernetes
life
cycle,
so
kubernetes
does
a
few
things
it
can
do
like
pre
hooks.
A
It
sends
a
signal
to
delay
termination.
If
you're
one
hour
into
an
eight-hour
job,
kubernetes
can
say
hey.
I
want
to
scale
you
down
and
you
can
be
just
hold
on
a
minute
and
you
can
tell
just
hold
on
a
minute
for
hours
and
hours
and
hours
it
works.
Some
people
don't
like
it
a
whole
bunch
because
you
see
it
as
a
terminating
state
for
eight
hours,
but
it's
an
option.
The
other
option-
that's
really
cool
here-
is
that
while
we've
been
talking
a
lot
about
scaling
deployments
with
Keita,
you
can
also
tell
it.
A
You
know
what
I
have
an
event
source
here,
but
for
every
event,
I
actually
want
you
to
create
a
job,
and
in
that
case,
Keita
will
schedule
a
job
for
every
event.
You
can
control
the
parallelism
and
those
jobs
can
run
to
completion.
So
in
the
video
example,
I
might
have
a
thousand
things
drop
in
that
queue.
Keita
will
spin
up
a
few
jobs.
A
Wait
for
a
job
to
complete
clean
it
up
spin
up
another
one
and
that
way
I
don't
have
to
worry
about
running
to
completion,
so
the
patterns
a
little
different,
the
intent
of
those
jobs
would
be
grabbed
one
event
process
it
to
completion
and
then
terminate,
but
it
works.
It's
a
really
useful
pattern
that
I
wanted
to
make
sure
I
called
out
here
to
enable
those
long-running
scenarios.
Alright,
let's
see
what
I
have
next.
Oh,
this
is
a
great
discussion
point
before
we
get
to
the
last
demo.
A
Is
this
the
best
way
to
do
a
vent
driven,
okay
and
I
specifically
use
the
word
the
best,
because
that's
a
very
loaded
question,
there's
very
rarely
ever
the
best
way
to
do
anything,
but
I
did
want
to
present
some
of
the
reasons
that
we
feel
the
pattern
of
how
kada
is
doing.
Event-Driven
containers
is
useful
and
a
useful
tool
to
have
in
your
toolbox
and
there's
a
few
patterns
that
are
pretty
common
here,
especially
in
the
world
of
server
lists
and
we're
not
the
only
ones
who
do
it.
A
This
way
and
there's
not
just
one
one
project
or
one
company
who
does
things
the
alternative
approach,
but
these
are
kind
of
the
two
most
common
ways
to
handle
event
ribbon.
So
how
kate
is
doing
it
and
some
others
like
nucleo,
is
that
you
have
your
event
source
and
the
thing
that's
actually
consuming
those
events.
The
thing
the
developer
is:
writing
they're
in
charge
of
actually
connecting
and
pulling
that
event
directly
from
RabbitMQ
or
Kafka.
The
other
alternative.
A
That's
super
common
for
a
bunch
of
server
list,
platforms
and
frameworks
is
that
you
have
your
event
source,
but
all
the
developer
rights
is
an
HTTP
container.
The
whole
world
is
HTTP,
all
I
have
to
think
about.
Is
I'm
gonna,
write
an
event
driven
container
expose
an
HTTP
endpoint
and
then
there's
some
channel
or
adapter,
or
something
else
that
actually
is
converting
those
messages.
You
can
imagine
it's
Kafka
something's,
pulling
those
messages
of
Kafka
and
then
throwing
out
HTTP
requests
to
any
service
containers
that
are
interested.
A
So
there's
pros
and
cons
to
both
of
these
approaches,
but
I
want
to
help
explain
where,
where
kata
kind
of
fits
in
here.
So,
let's
look
at
the
one.
I
talked
about
the
alternative
approach.
The
big
Pro
here
is
that,
if
I'm
a
server
list
developer,
if
I'm
a
developer
wants
to
do
an
event
trip
in
container
I
only
I
don't
have
to
know
anything
about
how
to
use
the
SDKs
SDKs
can
be
a
pain
in
the
butt
to
use.
I.
Don't
have
to
think
about
that
in
this
model.
A
A
Think
of
a
cue
message:
I,
don't
know
how
many
of
you
have
used
a
lot
of
cue
technologies
before,
but
when
you're
consuming
messages
from
a
cue
there's,
often
this
very
common
gesture
where
you
lock
the
cue
message
to
say
I'm
working
on
it
and
as
your
developer
in
your
code,
you
actually
have
a
few
choices
you
can
make.
You
can
say
I've
completed
processing,
which
DQ's
the
message
and
it
will
never
get
processed
again.
You
can
abandon
that
message.
You
can
say:
hey
something's
gone
wrong.
I
wasn't
able
to
finish
doing
this.
A
Someone
else
should
go.
Try
to
do
this
one
again
and
abandon
it,
and
then
the
third
choice
is
you
can
dead-letter
it
you
could
back.
You
know
what
this
message
is:
crap.
No
one
should
waste
their
time
on
this
message
again:
I'm
gonna,
explicitly
dead-letter
it
so
even
just
with
queues.
There's
these
three
distinct
options.
A
If
I'm
in
this
world,
where
my
code
has
been
separated
from
the
event
source
by
this
middle
layer,
it
becomes
much
harder
for
me
to
know
how
do
I
do
an
HTTP
response
that
may
be
an
abandoned
may
be
a
complete
and
it
may
be
a
dead
letter.
It's
a
lot
harder
for
me
to
reason
around
it.
I
have
to
re-engineer
those
patterns
for
every
single
event
source.
Some
context
will
also
always
be
lost
in
transition
as
you're
converting
something
from
a
rich
type
and
then
transferring
it
to
a
bunch
of
headers
in
a
body.
A
There's
always
going
to
be
some
stuff:
that's
gonna
have
to
get
lost
in
the
mix,
especially
when
you
wanna
make
it
language
agnostic.
So
it's
a
trade-off.
You
have
to
be
aware
of.
It
also
becomes
really
difficult
to
do.
Some
of
those
common
patterns
like
ordering
I
mentioned
in
the
example
before
Best
Buy
really
wanted
service,
but
they
really
needed
ordering.
We
work
with
a
bunch
of
financial
customers
who
very
much
care
when
Jeff,
when
Jeff
bought
Microsoft
stock,
when
Microsoft
stock
went
down
and
when
chef
sold
that
stock.
A
The
order
of
those
three
events
are
extremely
extremely
important.
Okay,
so
I
need
ordering.
But
if
I
have
this
middle
layer,
it's
hard
for
me
when
I'm
shooting
off
all
these
HTTP
events
to
make
sure
that
HTTP
requests
one
got
processed
and
completed
before
you
should
be
event.
Two
there's
ways
around
it.
You
could
be
I,
actually
only
send
one
request
at
a
time
and
wait
for
it
to
finish
and
then
send
the
next
one.
But
again
things
like
Kafka
just
have
this
out
of
the
box.
A
It's
like
grab
a
whole
batch
of
messages
process
of
an
order.
Super
high
throughput
super
high
control,
the
only
other
one
I'll
flag.
This
is
more
of
an
it
too.
Somebody
has
to
worry
about
the
SD
case.
Someone
has
to
make
sure
that
the
events
are
successfully
getting
pulled
from
something
like
Kafka
in
this
model.
A
If
it's
not
the
developer,
then
it's
someone
else
who
has
to
make
sure
that
all
these
events
adapters
are
working
they're
connected
to
the
right
sources
and
that
they're
everything
making
work
and,
in
my
mind,
very
often
as
a
developer,
I'm,
okay,
being
aware
of
the
fact
I'm
pulling
from
Kafka
and
I'll
be
the
one
who
worries
about
that:
SDK.
Ok,
so
again,
this
isn't
necessarily
wrong.
It's
not
necessarily
right,
but
there's
important
trade-offs
here
and
that's
why,
with
kada
we
just
wanted
to
call
out.
This
is
a
different
approach.
A
Right
kata
will
monitor
the
rate
of
events
and
it's
going
to
scale
your
container,
but
it
assumes
that
your
container
is
going
to
connect
with
a
whatever
protocol
it
wants
to.
This
could
be
HTTP,
it
could
be
AMQP,
it
could
be
mqtt
I,
don't
know,
there's
1,800
different
ways
to
pull
messages
from
something,
but
here
we
can
support
them
all
without
having
to
build
adapters
that
can
do
the
translation
layer.
Okay,
so
something
I
wanted
to
kind
of
pause
it
into
this
room.
Now.
A
A
Is
it's
pulling
a
message
from
RabbitMQ
imprinting,
hello,
world,
but
I
need
all
this
code
to
just
establish
the
connection
peek
the
message,
all
those
other
things,
that's
a
whole
bunch
of
code
that,
if
you're
using
the
alternative
approach,
the
developer
doesn't
have
to
right.
So
the
only
last
thing
I
want
to
show
and
then
I'll
do
our
last
Star
Wars
demo
is
that
this
is
where
we
start
to
think.
More
programming
models
and
programming
frameworks
can
help
fill
in
that
gap.
So
I
mentioned
at
the
beginning,
as
you're
functions
is
completely
open
source.
A
Just
ignore
the
word
azure
for
now
we'll
take
care
of
that.
It's
all
on
github,
it's
open
sourced.
This
is
what
an
azure
function
looks
like
that's
doing
the
exact
same
task.
I
just
say:
I
have
a
function,
I
care
about
a
queue
print
hello
world.
Now
the
SDK
is
still
there,
but
it's
managed
by
the
azure
functions
runtime.
So
as
a
developer,
I
can
say:
I
want
to
write
a
service
function,
just
write.
A
My
four
lines
of
code
still
use
kata,
it's
still
doing
peak
walking
behind
the
scenes
and
I
can
even
pass
an
SDKs
to
say,
complete,
abandon
checkpoint
whatever,
but
I'm
not
having
to
worry
about
it
in
my
face
as
much
okay.
So
is
this
where
it?
No,
not
quite
where
I
do
it,
so
you
might
be
looking
at
this
and
thinking
Jeff.
Why
are
you
talking
about
Azure
again?
We
were
talking
about
kata
and
kubernetes.
You
can
take
any
Azure
function.
A
You
can
run
an
it
docker
only
and
kubernetes
deploy
and
you
can
deploy
any
Azure
function
that
you
write
wherever
you
want
to.
You
could
deploy
it
to
Asher.
You
could
deploy
it
to
Google.
You
could
deploy
it
and
run
it
on
premises.
You
don't
pay
us
anything,
there's
no
license.
We
don't
care,
you
can
take
that
as
your
function
and
run
it
wherever
you
want
to
so
with
that.
Here
is
our
final
demo.
This
is
a
fun
one.
So
what
I
have
here?
What
I
want
to
build?
I
have
here
a
dashboard
in
power.
A
A
Now
I
have
here
an
azure
function,
so
you'll
notice,
there's
no
code
here
about
Kafka
I've
just
said:
hey
I
want
a
Kafka
trigger.
You
worry
about
pulling
the
messages
from
Kafka
I'm
gonna
pull
in
these
events
in
order
process
them
in
order.
You
know
this
is
in
typescript
could
have
done
this
in
Python,
whatever
Java
and
here
I'm,
just
gonna
pull
in
the
Twitter
event,
I'm
going
to
grab
I'm
gonna
run
some
sentiment
analysis
on
it.
Are
they
happy
about
Star
Wars?
Are
they
angry
about
Star,
Wars
I,
assume
everyone's
happy
about
Star
Wars?
A
Maybe
should
I
bring
up
the
last
Jedi,
though
that's
a
more
controversy
and
then
the
last
thing,
I'm
gonna
do
I'm
just
going
to
make
a
simple
HTTP
post
to
that
real-time
dashboard.
Now,
what's
nice
here
and
one
of
the
things
that
makes
this
programming
model
nice
I
can
go
ahead
and
set
a
breakpoint
press
f5
to
start
spinning
up
and
actually
run
that
open
source.
As
your
functions
runtime
directly
on
my
machine
you'll
see
here's
the
beautiful
ASCII
art
also
represented
on
my
shirt,
saying:
okay,
we're
gonna
spin
up
we're
gonna.
A
Look
at
this
app
we're
going
to
load
up
the
user
code
that
Jeff
wrote
here.
It
actually
already
pulled
a
tweet,
so
you
can
see
I
hit
my
breakpoint,
let's
just
step
through
this
a
bit
whatever
tweet
this
was.
It's
got
a
score
of
zero.
So
it's
neutral
and
we
could
even
come
in
here
and
see
what
is
this
tweet
about?
Hopefully,
there's
Star
Wars,
the
Mandalorian
Disney
Plus
baby
Yoda
I
warned
you
I
warned
you
it
mentioned
baby
onna.
A
Ok,
so
I
can
break
point
to
bug
this
and
when
I'm
ready
to
go,
I
can
publish
it,
but
let's
just
not
do
a
boring,
publish,
let's
do
an
exciting,
publish
so
I'm,
just
gonna
one
run
more
command.
I'm
gonna
switch
the
context
of
my
cube.
Ctl
I'm
gonna
connect
to
Google
Cloud,
so
I'm
gonna
switch
here.
Let's
do
this
whole
thing
on
Google,
so
I've
just
switched
over
to
a
kubernetes
cluster
running
on
Google
cloud
and
here's
where
I
can
run
the
funk
kubernetes
deploy
it's
gonna.
Look
at
this
Asscher
function.
A
It's
gonna
put
it
inside
of
a
docker
container,
build
that
container,
publish
it
to
my
registry,
public
or
private,
and
then
deploy
that
to
my
cluster.
Now
I,
don't
want
to
have
to
worry
about
Wi-Fi
and
publishing
this
image.
So
I
actually
already
built
the
image
this
morning.
So
let's
just
go
ahead
and
apply
it
quickly,
not
that
one.
A
So
I
took
that
function
and
I
just
deployed
it,
and
here
we'll
switch
to
this
screen
where
it's
a
little
bit
bigger
I
could
do
the
same
thing
where
I
say:
watch
pods
and
you'll
notice
as
soon
as
I
deployed
it.
It's
actually
already
said:
there's
actually
a
bunch
of
tweets
happening.
So
it's
spun
up
one
of
my
Azure
functions
in
Google,
Cloud,
kubernetes
and
I
would
imagine
to
an
assuming
you
can
all
participate
in
the
room
as
well.
If
you
tweet
anything
about
Star
Wars,
there's
enough
tweets
happening
right
now.
A
It's
automatically
scaled
me
out
to
four
of
those
functions.
So
now
the
real
moment
of
truth
when
we
switch
back
to
the
bored.
This
has
now
come
to
life
with
real-time
data.
The
real-time
sentiment.
You
can
see
that
heartbeat
of
everyone
in
the
world,
who's
tweeting
about
Star,
Wars
right
now,
I
see
some
tweets
coming
from
over
here
in
San
Diego,
so
way
to
go
room
way
to
participate
right.
So
we
can
see
here
there's
a
bunch
of
weird
hashtags
I,
don't
see
anything,
hopefully
nothing
inappropriate.
A
This
is
unfiltered,
but
that
just
gives
you
the
idea.
Is
there
something
bad
here,
I
hope
not
yesterday,
yesterday,
when
I
was
testing
it,
there
was
something
suggestive
in
one
of
the
tweets
and
I
was
like.
Please
do
not
retweet
this
in
the
middle
of
my
presentation,
people
just
need
to
figure
their
lives
out,
but
again.
This
is.
This
is
a
really
cool
way
that,
in
in
the
40
lines
of
azor
functions,
runtime
code
by
deploying
this
to
kubernetes
in
this
case,
Google.
A
Turning
on
Keita
with
that
serverless
scale,
I've
been
able
to
write
a
server
this
app
that
can
scale
to
millions
of
events
but
run
it
wherever
I
want
no
vendor
lock-in,
event-driven
scale
event
driven
containers,
whatever
I
need.
Okay,
so
that's
a
fun
way
to
see
what
you
can
start
to
do
with
this
stuff.
So
that's
it!
That's
all
I
had
to
share
today
we'll
have
a
little
bit
of
time
for
questions.
A
If
there's
any
a
few
resources,
if
you're
interesting,
kaida
SH,
that's
the
landing
page,
it
will
give
you
the
docs
the
deployment
scripts,
everything
you
need.
The
code
is
all
on
github
and
we
also
have
community
stand-ups
every
Thursday.
So,
if
you're
interested
in
participating,
you
want
to
help
with
the
design,
you
have
feature
requests.
You
want
to
contribute
some
scalars
Docs
samples.
Whatever
we
love
it,
all
please
I
would
encourage
you
to
join
those
stand-ups.
Thank
you
all
very
much
again,
you've
been
so
welcoming
I
mentioned.
This
was
my
first
cube.
A
Con
I
really
hope
I
get
to
go
to
more
of
these.
This
has
been
such
a
fun
conference.
My
twitter
handles
there
at
the
very
bottom
at
Jeff
Holland
as
well.
If
you
have
any
questions
as
well,
so
with
that,
we
do
have
like
three
minutes.
If
there's
any
questions
in
the
room,
we
can
answer
them
here,
but
thank
you
all
very
much.
It's
been
a
pleasure.
B
C
So
excellent
presentation
so
I'm
fairly
new
to
the
kubernetes
OpenShift
and
those
sets
of
technologies,
I've
heard
of
K
native
service
technology,
but
don't
know
the
details
of
it,
but
I
was
wondering
if
you
could
compare
and
contrast
K
native
Takeda
and
where
there's
any
intersection
or
how
they
integrate
with
one
another
overlap.
Things
like
that
great.
C
A
I
think
from
the
the
biggest
one
k
native
is
an
entire
I
kind
of
mentioned.
Kata
super
single
purpose.
It
only
does
the
event-driven
scale
thing.
K
native
is
like
a
full
platform.
It's
got.
Candide
of
serving
Candide
of
eventing
event-driven
scale
is
one
of
the
ten
things
that
Canada
can
do.
So
that's
one
of
the
big
differences
in
considerations.
It's
still
evolving
we're.
Actually,
even
just
this
morning
we've
been
working
with
the
K
Native
team
to
see
what
opportunities
there
might
be
there.
So
kata
itself
is
very
single
purpose.
A
The
only
other
difference
is
K
native
eventing
today
does
use
that
kind
of
alternate
eventing
strategy
that
I
talked
about
where
Kate
is
different,
so
there
there's
kind
of
a
change
there,
but
you
can
also
mix
and
match
these
two,
like
we've,
been
working
I
mentioned
with
red
hat
red
hats,
obviously
involved
with
K
native
they're,
using
K
native
with
kata,
and
they
even
have
customers
who
are
using
that
width
as
your
function.
So
there
is
a
bit
of
mixing
and
matching
kata,
though
very
single
purpose.
Canada
is
a
much
broader
kind
of
platform.
A
A
Question
so
this
will
this
comes
up
very
often,
kata
itself
won't
do
the
cluster
auto-scaling,
but
because
it's
going
to
be
requesting
pods,
it
will
drive
that
so
how
it
work.
You
would
set
up
like
a
cluster
Auto
scale,
rule
and
say:
if
I
need
more
resources.
I
want
you
to
see
out.
Keita
might
say:
I
need
ten
containers
that
each
need
one
core.
Those
scheduling
requests
will
drive
the
cluster
autoscale
decision
so
indirectly
it
does
it
just
not
directly.
A
You
can
also
use
this
to
kind
of
indirectly,
as
well
with
things
like
the
virtual
cubelet
or
virtual
nodes,
so
the
one
I
didn't
do
it
in
this
demo,
because
I
was
on
Google
Cloud,
but
if
I
did
this
on
aks
I
might
also
have
those
scale
out
into
serverless
containers
like
far
gate
or
ACI,
and
you
can
also
drive
scale
out
into
manage
containers
as
well
pattern.
Great
question,
a.
E
A
We
actually
enforce
it
on
Kafka,
but
it
will
never
scale
out
beyond
the
number
of
partitions
that
you
have
available
so
that
you're
not
over
provisioning
in
that
way,
but
kata
will
do
the
best
that
it
can,
with
the
knowledge
that
it
has,
but
there's
also
some
some
responsibility
to
make
sure
you've
got
the
right
maximums
in
the
right
pod
requests,
so
you're
requesting
just
the
CPU.
You
actually
need
as
well.
A
F
A
Tried
it
there's
nothing
that
would
prevent
it.
The
one
thing
that
came
to
mind
when
you
were
asking
that
is
there's
some
workflow
tools,
at
least
that
I'm
familiar
with
like
Brigade,
that
let
you
do
like
kubernetes
jobs
and
execute
a
workflow
I
would
imagine
that
there's
a
world
that
you
could
do
the
job
thing
and
have
that
kick
off
a
brigade
workflow
and
it
would
actually
just
work
so
I
guess
the
short
answer
is
I.
A
Haven't
personally
tried
it
I,
don't
think,
there's
anything
blocking
it,
but
that's
a
fantastic
feature
request
that
even
I'll
try
to
mend
remember,
but
that's
something
I'd
love
to
see
that
kind
of
stuff
to
kick
off
more
of
these
stateful
workflows
as
well.
Yeah!
Okay!
So
that's
it!
Thank
you
all
again
for
coming
we'll
be.
If
you
have
other
questions
about
kata,
you
can
find
us
at
the
booth
later
today,
thanks.