►
From YouTube: Fission: a Serverless Function Framework on Kubernetes [B] - Soam Vasani, Platform9 Systems, Inc.
Description
Fission: a Serverless Function Framework on Kubernetes [B] - Soam Vasani, Platform9 Systems, Inc.
"Serverless" functions allow users to easily create services from source code without dealing with the packaging, deployment, scaling, etc.
Fission is a serverless function framework built on Kubernetes. Users write functions and map them to HTTP routes. They don't have to deal with container images, registries or even learn Kubernetes in much detail.
Functions can be associated with HTTP routes, events, or timers. Functions consume CPU and memory resources only when running; they are started on-demand and killed when idle. Fission makes on-demand function loading very fast, by keeping an idle pool of containers running, in effect creating a distributed "threadpool".
Fission is useful for:
* Creating web app backends or REST APIs
* Implementing webhooks
* Writing event handlers
We'll demo the creation of a simple web app using fission functions in Python. We'll also cover:
* Unit testing and integration testing of functions
* Function versioning
* Logging, metrics, tracing
* Extensibility -- how to add arbitrary dependencies
We'll also show how tying together Kubernetes Watches and Fission functions make it very easy to write custom behaviour triggered by changes to arbitrary resources on Kubernetes.
About Soam Vasani
Soam Vasani is a software engineer at Platform9 Systems Inc, where he | works on the Fission framework. In the past he's worked at VMware on | a distributed filesystem, a log analysis stack, and an infrastructure | management product. Before that, he spent some time working on the | GNU debugger and toolchain. He's interested in programming languages, | tools and frameworks, and in distributed systems.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
Okay,
just
it's
like
those
old
TVs
yeah
I,
don't
have
a
whole
lot
of
words
to
just
read
fast
before
it
disappeared,
all
right,
so
here's
the
picture
of
a
container
yeah,
but
but
really
what
so,
I
want
to
talk
about
containers.
As
about
the
word
flows
itself
that
we
have
around
containers,
we
created
great
workflows
and
operations.
They
made
everything
uniform.
You
don't
have
to
worry
about
virtual
end
in
your
production,
environment
anymore.
A
Every
single
thing
is
a
docker
container,
whether
it
has
you
know,
Python
or
node
or
whatever
running
inside
it,
but
the
development
workflow
got
heavier
and
somewhat
more
complicated.
You
now
have
to
any
you
know.
Have
you
end
here
knows
containers
very
well,
probably
so
yeah
try
to
my
you
know
the
time
before
you
before
you
are
so
familiar
with
containers.
You
have
to
learn
how
to
build
containers.
A
You
have
to
learn
what
docker
registry
to
use
you
have
to
figure
out
what
container
image
format,
to
use
you
to
figure
out
how
to
version
your
containers
and
so
on.
So
there's
a
certain
amount
of
development
process
weight,
that's
added
by
containers,
and
so
that
said,
can
we
have
the?
Can
we
have
the
benefits
of
the
operational
uniformity
of
containers
and
still
have
a
lighter-weight
development
process?
A
So
as
we
split
our
cloud
native
world
into
lots
and
lots
of
tiny
services,
we
end
up
with
a
lot
of
services
that
are
very
rarely
used,
but
every
single
service
that
you
deploy
needs
a
certain
minimum
memory
usage
and
if
it's
idle,
it's
not
consuming
so
much
CPU,
but
you
have
to
allocate
it.
And
so,
if
you
deploy
a
lot
of
these
services,
you
have
to
account
for
your
cluster
capacity
as
a
function
of
how
many
things
you
deploy,
rather
than
how
much
your
services
are
used,
and
so
can
we
can
we
have?
A
A
A
So
we
so
we
have
short
lives,
stateless
functions
and
and
and
functions
in
coats
because
they're
not
strictly
functions.
They
can
also
be
modules
or
packages
in
whatever
language
you
working
on
and
that
function
is
associated
with
an
event
or
a
trigger
of
some
sort
like
HTTP
or
a
timer,
or
something
like
that,
and
these
functions
are
only
activated
when
that
trigger
fires,
which
means
your
resource
usages,
is
proportional
to
the
actual
usage
of
the
function
and
since
your
function
can't
be
running
all
the
time,
but
it
has
to
be
started
on
demand.
A
A
So
we
come
to
defining
session
sufficient
is
a
open
source
functions
as
a
service
framework
that
works
on
top
of
kubernetes
and
as
efficient
user.
You
see
three
core
concept
functions
there,
a
function
or
a
module
in
various
supported
languages
and
environments.
Environments
are
the
runtime
dependencies
of
the
function.
Environments
are
also
the
only
language
specific
part
efficient.
A
Everything
else
is
is
language
agnostic,
and
so
there
is
a
node
environment,
Python
environment
ago,
environment,
c-sharp
and
Java
are
also
being
developed
and
as
PHP
as
well
and
of
course
triggers
are
the
events
that
activate
your
functions.
So
today
there's
a
DP
triggers
and
you
can
also
trigger
functions
based
on
kubernetes
watches,
and
we
see
a
demo
of
that
today.
A
So
you
can
you
can
fire
a
function
when,
when
something
on
your
kubernetes
resource
changes,
so
you
can
watch
a
set
of
pods
or
or
services,
and
so
on
so
I
want
to
talk
a
little
bit
about
how
efficient
works
are
fundamentally
to
get
a
fast
cold
start.
You
need
a
part,
that's
already
running,
because
you
don't
want
to
have
the
time
to
pull
an
image.
A
A
So
sorry,
the
pool
of
environments,
so
each
function
is
associated
with
some
environment,
so
node
or
Python,
and
so
on,
and
for
each
of
the
environments
that
exist,
a
pool
of
generic
parts
is
created
that
capable
of
running
any
function
in
that
language
and
then
there's
a
router,
which
is
where,
of
course,
the
requests
come
in.
So
that's
an
HTTP
request
comes
to
the
HTTP
router.
As
soon
as
the
request
comes
in
that
sort
of
cold
start
clock
is
ticking,
and
now
we
need
to
quickly
provision
a
part
with
that
function.
A
So
so,
let's
say
a
request
comes
in
for
that
purple
function
and
the
router
talks
today,
API
and
figures
out
what
function
is
associated
with
that
request.
That
thing
is
actually
cached,
so
it's
often
pretty
fast
and
then
requests
the
pool
manager
for
a
function,
part
for
that
function
and
the
pool
manager
creates.
That
part
gives
it
to
the
router
and
the
router
proxies
the
request
to
that
part.
A
So
that
typically
happens
in
about
100
milliseconds
or
so
it
also
depends
on
the
startup
time
or
the
load
time
of
the
function
itself.
The
bigger
it
is
the
more
dependencies
it
has,
the
longer
the
startup
time
of
the
function,
and
so
that
continues
for
other
functions,
they're
pulled
from
the
pool
and,
as
you
take
out
function,
parts
from
the
generic
pool
you
we
actually
use
a
deployment
and
a
replica
set
to
create
that
pool.
A
So
it
gets
replenished
when
you
remove
function,
parts
from
it
so
that
we're
ready
for
the
next
functions
to
be
taken
out
of
those
those
parts
are
cached
for
a
while,
even
when
there
are
no
requests
coming
in
for
a
few
minutes
and
after
a
certain
amount
of
time.
That's
when
those
pods
are
idle
there
killed.
So
your
resource
usage
goes
back
down
to
what
it
was
before
you
got.
These
function
calls
okay,
so
that's
that's
pretty
much
how
efficient
works
there
are.
A
Other
components
are
actually
watching
kubernetes,
but
this
is
the
basic
flow
of
HTTP
requests
and
functions.
So
so,
let's
move
on
to
what
you
can
actually
use
this,
for
we
see
sort
of
three
use
cases,
and
such
fast
frameworks
are
good
for
writing.
Really
small
REST
API
s
and
Web
books
where
books
are
basically
an
API
with
one
endpoint
and
they're,
also
really
useful
for
writing.
A
Kubernetes
watch
event
handlers
and
we'll
talk
about
that
in
a
bit,
but
kubernetes
watches
today
require
you
to
use
one
of
the
client
libraries
and
write
a
pretty
significant
amount
of
code
to
keep
track
of
some
sort
of
kubernetes
resource.
So
you
can
do
that
pretty
really
efficient.
So
let
us
move
on
to
a
few
demos.
We
have
gates
to
10.
A
Fishing
has
a
CLI,
that's
already
mapped
that's
already
configured
to
talk
to
this
cluster,
so
we
can
look
at
the
environment
that
already
exists
on
this
cluster,
so
we
have
node
and
Python
already
set
up,
but
if
they
aren't,
you
could
have
created
one
with
with
this,
and
you
can
just
specify
an
image.
So
you
could
create
the
go
environment
with
with
that
and
you
can
choose
what
environments
you
want
in
your
deployment
according
to
what
languages
you're
actually
using
ok.
So
let's
create
a
simple
hello.
A
A
Yeah,
what
you
usually
see
is
that
the
first
one
takes
100
or
so
milliseconds
and
the
next
one's
takes
around
tens
of
milliseconds,
depending
on
your
real
latency
to
wherever
you've
deployed
session
and
the
first
one
is
where
the
cold
start
overhead
actually
shows
up,
and
the
subsequent
requests
are
really
just
fast
routing
to
existing
instances
that,
as
fast
as
talking
to
an
odious
or
whatever
server
on
a
Python
server
on
on
kubernetes,
you
had
it.
I
can
take
a
couple
of
questions
where
I
want
to
move
on
to
that
difference.
Yeah
yeah.
A
Right
right
right,
so
there
is
a
it
calls.
So
there's
a
specification,
there's
a
interface
that
each
language
environment
has
are
from
that
that
efficient
expects
and
so
for
Python
its
main
for
node.js.
It's
you
know
the
main
export
of
a
module
and
for
forego
it's
the
default,
HTTP
handler
and
so
on.
So
whatever
idiomatic
in
each
language,
yeah.
A
A
A
The
you
know
deploy
on-demand
fast
model
and
some
services
was
much
better
than
their
long-running,
such
as
Redis,
there's
no
point
in
restarting
Redis
all
the
time
because
it
really
operates
in
memory.
So
here
we
have
a
little
guestbook
app
that
stores
its
state
in
Redis
and
as
a
couple
of
endpoints
a
gate
and
a
post
method,
the
get
retrieves
the
guestbook
from
Redis
and
generates
a
web
page.
A
Okay,
so
that
is
two
functions,
add
and
get
and
there's
a
redis
yama
which,
which
is
a
standard,
kubernetes
deployment
and
service
and
there's
a
shell
script
that
deploys
all
of
them
and
the
gate
function.
What
it
does
is
it
grabs
your
connection
to
read
is
simply
by
name
you
can
use
a
standard,
kubernetes
service,
discovery,
stuff,
reads
the
guesswork
and
outputs
HTML,
since
it's
just
a
little
toy
app.
We
have
it
in
line,
but
obviously
because
we
would
do
more
complex
things
when
it
says
when
it's
a
real
app.
A
All
right,
so
so
that's
the
guest
and
there's
nothing
inside
the
register
right
now,
since
we
just
deployed
it.
So
so
you
can
add
so
that
hit
the
add
endpoint
and
when
we
first
loaded
this
guess
when
we
first
did
that
reload
to
see
that
page,
that's
when
the
get
function
was
first
activated
when
I
hit
the
Add
button
is
when
the
add
function
was
first
activated
so
they're
fast
enough
that
you
can
just
that.
A
A
A
A
A
Think
and
you
don't
have
to
understand
all
this
code,
but
basically
this
is
the.
This
is
the
interface
that
you
get
when
you,
when
you
wire
a
function
to
a
kubernetes
event,
we
send
the
event
an
object
type
as
headers,
and
we
and
the
body
of
the
request
is
a
JSON
serialization
of
the
kubernetes
objects
that
changed.
So
you
can
get
so
you
can
deserialize
it
and
look
at
pod
and
service
data
in
any
language
you
want.
So
this
one
is
obviously
Python
and
what
this
does
is
it.
It
summarizes
the
state
of
a
pod.
A
It
looks
at
the
individual
container
states
and
figures
out
whether
they
are
running
or
waiting
for
an
image
and
so
on,
and
it
sends
it
to
a
little
server
that
I
have
running
here,
that
that
then
sends
servers
and
events
to
this
webpage.
So
the
idea
is
to
watch
to
be
able
to
watch
pods
from
a
web
page,
so
I
have
no
idea.
If
this
will
work.
A
So
we
have
some
existing
pods,
and
so,
oh
so
that
pod
watcher
function.
That
is
a
size
map
to
look
at
all
pods
in
the
default
namespace
and
call
the
pod
water
function.
So
you
can
just
efficient
watch
create
to
create
such
watches
that
one's
already
there.
So
let's
actually
make
some
part
so
that
the
thing
will
get
activated.
Oh.
A
A
A
A
So
obviously
this
is
a
sort
of
silly
controller,
but
you
can
write
the
real
behavior,
like
I
heard
of
a
user
who
was
using
this
to
watch
services
and
wire
them
up
to
their
internal
load,
balancer
using
f5
or
something
and
any
time
a
service
with
a
certain
annotation
was
created.
They
would
call
into
their
load
balancer
API
and
create
some
sort
of
entry
for
that
service.
So
normally
you
do
that
by
adding
a
specific
controller,
maybe
an
ingress
controller.
A
A
A
Since
then,
we've
got
decent
traction,
the
1,600
github
stars
for
what
that's
worth,
there's
a
we're
in
early
alpha.
We
intend
to
beta
around
mid
to
late
this
year.
There's
a
bunch
of
things
we
need
to
do
despite
it
works
well
for
for
the
demos,
but
we
have
when
you're
doing
functions
as
a
service.
You
need
better
observability
and
things
like
that,
because
you're
actually
creating
in
destroying
pods.
A
So
there's
various
improvements
that
that
are
coming
to
sort
of
improve
the
development
and
operations
workflows
and
there's
so
that
should
be
mid
to
late
this
year.
That's
one
thing
and
the
community
has
contributed
a
lot:
the
go,
c-sharp,
PHP
and
Java
support
all
came
from
the
community,
there's
a
web
UI
being
developed
and
lots
of
bug
fixes.
So
thanks
to
the
people
who
did
this,
if
any
of
you
are
here,
thank
you.
A
There's
a
whole
bunch
of
work
around
the
API,
and
you
know:
I
have
I'll
dive
into
it
more
their
documentation
on
the
on
the
github
repository,
we're,
adding
metrics
tracing
support
for
other
kubernetes
primitives
volume,
secrets,
config
maps,
and
so
on
so
on
to
stop
and
not
go
into
too
much
detail
there
we're
fully
open
source.
There's
no
there's
no
closed
source
component
here,
we're
on
github
there's
a
website
and
come
talk
to
us
on
slack
and
check
us
out
on
Twitter
and
have
we
have
five
minutes
for
questions.
A
A
A
Yeah
today
you
have
to
rebuild
the
environment
image.
So
with
each
environment
we
have
a
readme
that
says:
here's
how
you
add
dependencies
for
the
Python
environment,
you
you
edit
a
requirement
txt
and
rebuild
the
docker
image,
we're
also
working
on
automating
that
and
packaging
dependencies
with
the
function
itself,
so
you'll
be
able
to
upload
a
zip
file,
and
things
like
that
now
you
want
to
get
one.
A
A
It
would
be
easier
to
talk
to
the
router
than
to
replace
it,
but
you
could
rewrite
the
router
each
of
those.
If
you
go
back
to
that
picture,
the
the
router
calls
the
efficient
API
and
the
and
the
pools
managers
internal
API,
so
you
could
duplicate
that.
But
the
way
we
did
the
kubernetes
events,
for
example,
is
to
just
write
a
separate
service
that
watches
kubernetes
events
and
feeds
them
to
the
router.
So
it's
easier
to
just
feed
the
router.
A
A
A
Yeah,
that's
a
tricky
one,
because
so
today
we
don't
there's
a
kubernetes
feature
in
very
early
stages,
called
vertical
part
scaling
where
you
can
change
the
limit
of
a
CPU
and
of
CPU
and
memory.
So
it's
hard
to
it's
hard
to
increase
the
memory,
requests
or
CPU
requests
of
a
running
board,
but
you
could
always
reduce
it.
A
So
this,
your
question
goes
into
a
more
general
question
of
the
way,
we're
using
parts
we're
dropping
functions
into
them
and,
in
some
sense
we're
changing
water
part
is,
after
it's
run,
so
there's
various
things
that
that
we
might
have
to
try
and
make
more
dynamic
and
we're
sort
of
in
touch
with
kubernetes
community
and
will
will
talk
to
various
things
about.
You
know,
say
volumes.
For
example.
Today
you
can't
mount
a
volume
in
a
running
part.
You
have
to
restart
that
part.
So
for
us
options
are
you
can
just?
A
A
Did
it
authorization
yeah
so
again,
more
generally,
the
question
is
how
to
do
more,
complex,
API
gateway
stuff,
and
you
mean
for
the
functions
right.
So
the
users
functions
right,
so
we
want
to
be
able
to
integrate
with
existing
API
gateways,
either
using
kubernetes
ingress
or
by
talking
to
their
API
s.
So
there's
traffic
and
song,
and
things
like
that.