►
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
Botless: A Serverless Chatbot Framework - Scott Nichols, Google
Botless is a serverless powered, CloudEvents connected chatbot framework. This talk will introduce the chatbot framework and describe the methodology for building highly extensible application using emerging compute and eventing technologies that are cloud provider agnostic.
To learn more click here: https://sched.co/FuKU
A
A
We
are
going
to
be
building
the
bottleless
framework
together
right
here
we
will
optimize
for
cost
and
flexibility
of
extensions.
The
customer
will
be
my
team
or
my
company,
while
building
bottleless.
Think
of
opportunities
for
you
to
provide
your
own
framework.
Encapsulation
and
reusability
are
powerful
techniques.
A
A
So
my
team
and
I
started
writing
more
useful
scripts
and
we
connected
them
to
our
chat
server
and
they
they
did
little
tasks
for
us
at
first.
These
were
little
one-off
programs
that
ran
on
our
desktops,
and
this
was
great
because
no
more
interruptions
now
each
command.
Each
script
could
respond
to
its
own
command
and
it
was
useful.
A
The
two
teams
noticed
each
other
scripts
and
started
working
some
of
them,
because
each
script
talked
to
a
different
chat
server
each
had
to
be
modified
to
work.
This
started
getting
out
of
hand
if
Bob
went
home
for
the
night,
we
stopped
being
a
to
check
the
health
metrics
or
deploy
the
latest
software
to
QA.
A
A
Each
new
command
met
the
chat,
BOTS
started,
costing
us
more
money
and
more
infrastructure.
We
knew
we
could
do
better.
Let's
pick
apart
the
aspects
that
became
important
to
the
team,
we
realized
early
that
using
kubernetes
and
containers
allowed
the
developers
on
my
team
to
write
in
whatever
language
they
wanted.
A
We
also
realized.
The
team
is
only
interacting
with
the
bots
for
a
small
portion
of
the
day,
and
even
when
we
are
interacting
with
only
one
chat
script.
At
a
time
further,
the
number
of
commands
that
we
created
increased
the
overall
cost
of
the
service
we
wanted
to
pay
for,
just
when
the
bot
was
being
useful,
not
idle.
A
If
the
chat
bot
supported
so
more
serverless
architecture,
we
could
stop
worrying
about
the
idle
cost
and
reserving
of
resources
when
we
interact
with
the
bot
what
the
one
command
that
should
be
active
and
the
rest
should
be
well
service,
not
running
server
list
means
no
servers
are
in
use
when
the
application
is
not
actively
doing
something
useful
it
scales
to
zero
server
list
means
elastic,
it
can
scale
up
very
quickly
to
handle
demand.
Server,
less
is
event-driven,
it's
reacting
to
something,
and
we
only
want
to
pay
for
the
amount
of
time.
A
Our
app
is
doing
something
useful
okay,
so
our
main
requirements
ended
up
being
one.
We
use
containers
so
that
everyone
can
pick
the
code
language
that
they
want
to
implement
and
to
use
a
server
less
technique
to
reduce
the
overhead
for
having
so
many
chat,
bot
commands
and
not
paying
for
the
idle
time.
A
A
A
A
A
A
A
And
the
general
picture
of
how
this
looks,
we
can
have
our
existing
chat
server,
communicating
to
a
receive
adapter
the
receive
adapter
bridges,
the
chat
protocol
into
a
common
protocol.
For
the
framework
to
understand.
We
will
need
to
parse
the
incoming
messages
to
understand
if
the
they
are
commands
or
not
and
then
route,
then
a
router
to
link
a
particular
command
to
a
service
function
that
handles
it.
A
Here
again,
the
chat
server
speaks
whatever
protocol,
it
happens
to
be
implemented
in.
We
cannot
change
that,
but
we
can
convert
it
into
something
standard
into
a
standard
format.
Here
we
will
take
raw
chat
events
and
the
receive
adapter
will
output
a
new
emerging
standard
cloud
events
with
an
event
type
say:
dev,
bodiless
chat
cloud
events
is
a
specification
for
describing
a
venting
data
in
a
common
way.
A
A
The
source
is
a
general
que
native
eventing
concept
for
a
component
that
pushes
events
into
the
cluster
we
can
represent
that
source
as
a
custom
resource
here
is
the
amyl
for
our
chat
source.
Each
logical
component
in
the
diagram
is
represented
inside
the
source.
Spec,
the
concept
of
a
source
is
abstract.
Its
role
is
that
it
pushes
events
into
a
sync
as
we
are
free
and
we
are
free
to
define
anything
else.
That
is
interesting
for
our
exact
use
case
for
that
source.
A
A
A
A
Channels
represent
a
delivery
method
for
events
in
practice.
This
means
in
a
venting
queue
something
that
allows
for
a
durability
of
the
event
delivery,
delivery
of
events.
Kay
david
has
distracted
this
away
to
be
able
to
use
things
like
queues
without
being
tightly
bound
to
a
particular
queue
implementation,
a
subscription
describes,
event
delivery.
A
subscription
tells
the
upstream
channel
to
first
call
a
subscriber
function
and
then
continue
the
reply
to
the
next
channel
channels
that
have
more
than
one
subscription
allow
for
a
fan-out
or
multiple
event.
A
Let's
expand
our
current
bottleless
framework
with
the
eventing
components
and
see
how
it
would
look
like
in
practice.
We
have
these
three
components
connected
the
source
to
the
parser
to
the
router
in
serverless
applications.
It's
best
to
never
call
a
function
from
another
function.
Kay
native
eventing
gives
us
primitives
to
implement
the
best
practice
channels
and
subscriptions,
and
it
would
look
something
like
this.
A
Events
flow
from
the
source
into
a
channel.
The
channel
passes
the
event
to
the
subscriber
subscribers
of
the
channel
for
bot
lists.
The
subscriber
of
the
new
message:
Channel
is
the
parser.
The
parsers
job
is
to
examine
the
new
chat
message
and
see
if
it
fits
the
format
of
a
bot
command,
but
commands
in
bot
lists
are
all
chat,
messages
with
a
forward,
slash
and
then
the
command.
A
A
If
the
parser
produces
a
bot
command.
The
message
is
passed
to
the
botton
command
channel.
The
bot
commands
its
events
to
the
router.
The
job
of
the
router
is
to
inspect
the
event
the
event
metadata
and
route
it
to
based
on
the
command
name.
The
router
looks
at
the
existing
channels
and
finds
the
one
that
matches
the
label
produced
from
the
command
name.
The
router
passes
the
bot
command
to
the
correct
champ.
A
The
command
channel
invokes
the
function
in
forwards.
Response
to
the
response
channel.
If
no
channel
is
found,
bottleless
will
has
a
default
channel
to
send
an
error
response.
A
command
that
is
a
command
is
not
very
useful
without
a
way
to
reply
back
to
the
original
requester,
we
need
to
add
a
component
for
transmitting
the
responses
back
to
the
chat
server
the
transmit
adapter.
A
A
A
We
have
looked
at
most
of
the
system,
but
not
actually
how
the
chat
bot
does
its
work.
What
about
those
commands?
I
said
they
are
serviced
here.
We
can
leverage
kenaf.
Sir
again
we
can
leverage
K
native
for
service
functionality,
K
native,
serving
provides
the
abstraction
for
running
a
container
as
a
service
function.
Ake
a
native
service
serving
also
provides
concepts
of
revisions
that
can
able
can
enable
deploys
for
your
functions
and
tools
to
help
route
traffic
to
them.
A
A
We
have
to
write
some
code
to
bridge
the
messages
from
the
chat
server
and
then
the
as
the
command
responds
the
two
components
and
then
the
response
object.
Those
two
components
are
linked
together
because
they
have
very
similar
code
that
implements
them.
In
fact,
they
show
they
share
authentication
required
to
communicate
to
the
chat
server.
Perhaps
they
could
share
a
persistent
connection
as
well.
If
the
component
has
both
a
receive
adapter
and
a
transmit
adapter,
it's
called
a
gateway
to
make
it
simple
for
us
to
manage
and
deploy.
A
We
made
a
new
CR
D
for
bottleless
to
wrap
the
up
the
Gateway
as
a
concept
this
deploys
inside
of
kubernetes
as
a
logical
unit.
We
define
a
new
custom
resource
definition.
This
plus
a
controller
that
runs
inside
of
our
cluster
that
manages
the
control
plane
aspect
gives
us
a
gateway,
and
then
we
can
create
a
chat
gateway
resource.
A
Like
this,
we
provide
the
remote
search,
chat,
server
and
the
two
channels
that
the
Gateway
communicates
with
to
the
rest
of
bottleless,
and
when
did
when
the
chat
gateway
is
created,
our
custom
controller
makes
sure
that
the
source
and
the
transmitted
adapter
are
created.
For
us,
we
focus
on
making
the
best
to
chat
gateway.
We
can.
A
A
A
A
Great
now
we
can
invoke
commands,
get
responses,
install
new
commands,
but
if
we
find
out
this,
but
we
find
out
that
the
sales
team
wants
to
use
the
bot
as
well,
we
can
have
them
build
upon
what
we
have.
We
can
build
them
a
talk
server,
we
get
a
sorry,
we
could
build
them,
a
talk
gateway
and
with
a
couple
of
correlation
IDs
the
messages
filter
out
just
fine
and
because
we
understand
how
to
produce
a
cloud
event
for
chat
event
types.
We
can
wire
it
up
to
the
existing
channels
without
worrying.
A
So
there
it
is,
we
made
a
service
chat
bot
framework.
We
are
leveraging
service
tech,
empowered
by
K
native
to
get
moving
quickly.
We
have
extended
kubernetes
to
encapsulate
the
features
of
our
application.
I
want
you
I
want
to
want
you
to
leave
here
with
these
thoughts
link
of
kubernetes
as
a
way
to
extend
your
application
development.
You
can
build
controllers
that
do
very
specific
things
very
well,
and
if
you
are
careful
about
composability,
you
can
build
very
complex
applications
that
are
also
maintainable.