►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Function Composition in a Serverless World - Erwin van Eyk & Timirah James, Platform9 (Intermediate Skill Level)
As serverless applications grow more complex, function _composition_, or the ability for functions to call each other, becomes important. This talk will dive into three different approaches to compose FaaS functions together to form large applications: _Coordinating Functions_ are functions that manage the execution of other functions by calling them directly. _Event-driven Composition_ uses functions emitting and reacting to events on message queue topics. _Workflows_ introduce a mechanism for expressing a graph of function interactions and having a new runtime to manage the execution of these functions. We'll give examples and live demos for each approach, and compare then on the basis of expressiveness, performance, and fault-tolerance; and also on the basis of operational concerns, such as the ease of doing upgrades, and monitoring the overall application's performance.
About Erwin
Erwin is a software engineer at Platform9 Inc, where he works on a workflow engine for Fission, a FaaS on top of Kubernetes. At the same time, he is a researcher investigating “Function Composition in FaaS Deployments” in the International Research Team @large, from his office at the Delft University of Technology in the Netherlands. Additionally, he leads the industry and academia combined FaaS research effort at the SPEC Cloud Research Group.
About Timirah
Timirah James is a Developer Advocate for Platform9 Systems’ FaaS, Fission, which is built on top of Kubernetes. She is best known for being a thought leader in the Los Angeles and Silicon Beach tech community, her active roles in the hackathon realm, as well as mentoring through her meetup (TechniGal LA) for women exploring the world of STEM. Fun Fact: She is also a noted singer-songwriter, and recently released a song about her love for technology and innovation called “Coderitis”, which can be found on Soundcloud and Spotify!
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.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
We'll
talk
a
little
bit
more
about
that
later
on
in
the
talk,
but
today's
topic
is
function,
composition
in
a
serverless
world
right,
so
throughout
this
talk
will
of
course
go
over
what
function?
Composition,
actually
is
why
it
even
matters
and
then
we're
going
to
give
a
couple
of
examples
of
a
few
composition,
styles
and
some
benefits
and
takeaways
for
each
first,
just
just
as
a
protocol
I'm
just
going
to
go
over
what
fast
is
fast.
A
Of
course,
this
functions
as
a
service
and
fast
frameworks
allow
developers
to
deploy
individual
parts
of
an
application
on
an
as-needed
basis.
Alright.
So
there
are
a
couple
of
benefits
here,
one
that
it's
super
developer
friendly
and
the
way
that
it
strips
the
obligation
of
having
to
manage
or
maintain
servers.
Also,
it's
pretty
great
Billee
billing
model,
as
you
only
pay
for
the
resources
that
you
actually
consume
and
also
when
you're
using
faz
frameworks.
Scaling
is
simplified.
A
Now
the
way
you
compose
functions
actually
plays
a
key
role
in
just
how
your
functions
are
deployed
right
in
terms
of
latency
in
terms
of
resource
usage.
In
terms
of,
of
course,
resource
usage
ultimately
results
in
cost
and
overall,
just
the
responsibility
that
you
have
as
a
developer
as
it
pertains
to
the
success
or
the
failure
of
your
functions
overall.
A
A
So
there's
split
into
two
functions,
but
can
we
combine
both
functions
into
one
service?
And
the
answer
is
just
simple,
of
course.
Of
course
we
can
do
this,
so
the
next
section
of
this
talk
is
pretty
much
going
to
go
over
how
we
can
do
that
right.
So
there's
several
ways
that
we
can
go
about
it
I'm
just
going
to
go
into
several
of
those
styles
and
some
why
you
might
want
to
go
into
those
styles
and
why
not
the
rundown
we've
got
manual,
compilation,
direct
or
chaining
coordinator
functions,
event-driven
and
workflows.
A
So
just
diving
right
in
probably
the
easiest
way
to
combine
functions
is
to
just
do
it
on
a
source
code.
Excuse
me
a
source
code
level
now,
but
when
you
do
this,
and
you
use
a
fast
framework
that
fast
framework
is
going
to
recognize
those
functions
as
one
big
task
right,
so
it's
not
going
to
recognize
them
as
they're
separate
tasks
that
they
should
be.
It's
going
to
recognize
them
as
one
I'm
going
to
point
out
why
that
might
be
a
problem.
A
This
is
just
in
perspective
on
the
right.
You
just
have
some
pseudo
code
over
there
and
we
have
our
two
functions,
which
is
you
know,
the
image,
recognition
and
then
the
translation
of
the
text,
and
then
we
have
function
at
the
bottom.
That
just
calls
both
at
once
right,
pretty
simple
pros
of
this
again,
you
can
do
this
at
a
source
code
level.
You
really
actually
don't
need
fast
framework
to
do
this.
There's
no
serialization
overhead.
A
This
is
this
is
just
more
so
as
a
caution
right.
So,
even
though
you've
merged
these
functions
together,
there's
still
two
individual
tests,
so
each
functions
there
they're
still
using
X
amount,
their
own
amount
of
resources,
their
own
amount
of
memory,
own
amount
of
CPU,
and
so,
when
you're
thinking
about
a
case
in
which
you
want
to
there's
a
request
being
made.
A
That
only
requires
one
of
these
functions
or
a
part,
a
portion
of
the
functionality,
because
the
fast
framework
recognizes
it
both
of
these
functions
as
one
you're
kind
of
you're
kind
of
defeating
the
purpose
of
the
main
benefit
of
faz.
Is
that
you,
you
only
you're
only
supposed
to
pay
for
what
you
consume
and
so
you're
consuming
double
the
resources.
A
The
next
one
is
direct
or
chaining.
You
may
or
may
not
have
seen
this.
This
is
pretty
common,
and
basically
this
is
where
you
just
combine
your
functions
in
the
form
of
a
chain,
so
the
functions
are
kind
of
nested
within
each
other.
Each
task
is
a
separate,
fast
function,
but
they're
in
there
completely
aware
of
what
comes
before
and
after
it
just
in
perspective.
We
have
our
code
and
you
see
they're
separate,
and
the
only
difference
here
is
that
there's
an
HTTP
call
being
made
to
the
next
function.
Right.
A
If
we
look
over
to
the
left
function,
a
is
making
that
HTTP
request
to
function,
be
it's
sitting
there.
It
has
to
wait
for
the
response
and
then
once
it
gets
the
response,
then
it
actually
ends
and
then
sends
a
response
back
to
the
client
pros
of
this.
You
can
do
this
yourself,
you
really
don't
need
any
external
components,
no
serialization
overhead,
but
the
cons
cons
can
be
a
little
bit
costly
depending
upon
your
project.
Each
function
waits
for
the
next
function
right,
so
it
could
be
wasting
time.
A
It
could
be
wasting
resources,
wasting
money
and
also
another
con
is
what
Aaron
likes
to
call
operational
complexity
right.
So
now
you
become
responsible,
you
have
to
think
about.
You
know
things
like
handling
failures.
Things
like
you
know,
fallbacks
retries.
All
of
that
kind
of
falls
back
onto
you,
which
leads
me
to
the
next
con,
which
is
the
pain
of
having
to
update
an
individual
function.
A
The
next
one
is
coordinator
functions,
so
this
is
where
you
create
an
additional
function
that
essentially
acts
as
a
director
or
a
coordinator,
and
has
this
omniscient
ability
to
kind
of
know
the
full
sequence
of
functions
right,
so
it
manages
the
full
execution
flow.
So
this
is
similar
to
direct
functions
except
each
function
is
unaware,
so
direct
functions,
hey
I,
know
what's
coming
after
it
makes
the
call
automatically
each
function
within
this
flow
is
unaware.
It
just
comes
when
it's
called,
so
this
is
essentially
what
it
looks
like
conceptually.
A
A
A
Cons
of
this
you
have
to
create
the
additional
function
right,
so
it's
little
bit
cost.
Also.
You
have
to
think
about
the
fact
that
okay,
so
the
coordinator
functions,
we
going
back
to
the
sequence
here.
So
the
coordinator
function
is
like
I
said,
making
a
request
waiting
for
the
response,
making
another
request
waiting
for
a
response
here.
We
only
have
two
functions,
so
might
not
be
too
long
right.
That
depends,
but
suppose
you
had
ten
functions.
A
B
It
works
so
DS
lost.
I'm
gonna
tell
you
about
the
last
two
approaches
which
are
basically
different
from
the
rest,
because
they
require
some
component
in
infrastructure
to
use
for
this
composition,
so
the
first
one
is,
first
of
all,
basically
already
covered
a
lot
by
the
last
talk.
So
idea
of
these
event-driven
function
compositions
and
the
idea
is
here.
Basically,
you
have
these
these
functions.
B
These
events
functions
trigger
on
events
and
if
events
come
from
message,
message:
queues,
pops
up
brokers
like
Kafka
and
that's
already,
even
the
event
gateway,
but
and
then,
basically,
when
is
this
functional
trigger,
they
execute
they
complete
and
it
emit
again
the
event
which
this
and
this
event
can
in
turn
trigger
a
functions.
So
the
main
there's
also
immediately
the
main
difference
between
this
approach
and
all
the
other
approaches,
whereas
in
the
other
approaches
you
really
specify
the
order
of
your
of
your
composition
of
your
of
your
functions
explicity.
B
B
If
this
exactly
event
triggers
the
second
function,
because
it
is
triggered
on
that
specific
function
that
function
a
publishes,
so
the
process
is
basically
here.
We
get
all
the
luxuries
of
message.
Queues
like
these
are
well
test
as
well
proven
systems,
and
it
also
saves
you
from
all
having
to
implement
all
this
read
all
this
logic
yourself.
You
intended
to
implement
the
retrying
logic,
all
the
communication
logic,
that's
associated
with
delivering
messages
from
A
to
B
and
also
the
other
part.
Basically,
you
dick
up
with
the
functions
by
I,
think
that
depends
on
the
data.
B
So
these
function
don't
know
anymore
or
don't
know
anymore
and
don't
need
to
know
anymore.
Who
or
what
is
creating
these
events.
They
just
wait
for
you
for
this
data
and,
finally,
it's
maybe
a
bit
of
a
catch-22,
but
this
this
approach
is
already
very
popular.
Well
lost
stories
show
this,
but
it's
it's
well
proven
architecture
for
different
dooms,
orchestration
of
cloud
services,
both
server
lists
and
well
server
fool,
and
so
you
they're
well
they're,
they're.
Good
answers
to
re
to
these
questions
are
like
what,
when
should
I
use
this?
B
What
are
the
trade-offs
that
you're
making
these
are
things
that
we
already
know
the
cons?
It's
basically
also
exactly
this
implicit
dependency,
because
it's
nice
to
show
in
that
simple
examples
as
you
that
you
can
make
this
change
and
they
depend
each
other.
You
can
understand
the
structure,
but
once
you
get
into
actual
system
that
the
production
system,
you
have
tens
hundreds,
maybe
thousands
of
functions
all
having
all
these
implicit
conversation
competitions
in
between
them.
B
And
finally,
it
also
may
it's
very
difficult
to
make
more
complex
control
flow,
so
this
training
is
easy.
Maybe
the
fanning
out
that
loss
talk
showed
a
nice
example
of
this.
But
how
do
you
actually
model
things
like
conditional,
branching
or
functions
that
are
triggered
when
other
functions
fail
and
exactly?
B
So
this
looks
in
our
example.
It
looks
series
one
we
now
instead
of
the
message
you
have
a
workflow
engine
or
a
workflow
framework,
and
the
client
doesn't
actually
talk
to
directly
two
functions
or
I
message
you.
It
will
submit
a
job
to
you,
workflow
engine
and
then
basically,
the
worker
engine
takes
his
job
and
combines
it
with
the
work.
B
For
definition,
it
has
to
figure
out
which
functions
to
execute
in
which
order-
and
here
you
can
yeah
well
in
the
sim,
for
example,
just
a
first
aid
and
be
but
workflows
are
not
any
special
concept.
I
didn't
think
of
myself,
it's
a
very
common
notion
and
there
are
basically
everywhere
so
I
love
the
mains
from
business
processing
to
death
of
optimization
and
also
a
lot
of
systems
that
actually
are
implementing
workflows
in
this
kind
of
these
kinds
of
domains.
B
So
to
highlight
two
of
them
are
go
and
Brigade
brigades
are
both
newer
work
for
engines
that
are
communities
native.
So
it's
also
I
think
they
are
around
here
on
the
conference
also
serve,
and
but
the
reason
why
there
are
so
many
workflows,
workflow
systems
here
is
because
these
remains
widely
ferry.
So
these
all
these
domains
have
different
characteristics,
different
users,
different
workloads
and
different
requirements.
So
these
systems
basically
are
built
tailored
to
this.
These
kinds
of
domains
and
used
to
adhere
to
the
requirements
and
to
optimize
the
performance
for
the
specific
domain.
B
So
and
with
the
very
specific
model
of
functional
service,
they
also
get
a
new
kind
of
workflow.
So
this
is
where
we
go
fast,
focused
workflows
or
service
workflows,
which
is
basically
differ
from
the
other
workflows,
because
they
first
need
to
be
fast.
So
they
need
to
be
limited.
Their
overhead,
which
is
not
the
case
in
some
other
domains.
B
Just
so
just
do
dive
bit
into
fission
workflows,
it's
a
basic
elesif,
it's
a
workflow
engine
that
deploys
and
communities
and
it
uses
fishing
as
its
function
is
a
service
platform
it
well
to
keep
it
very
short.
They're
basically
has
two
main
concepts
that
the
utilizes
so
one
hand
event
sourcing
and
the
other
hand
control
ferry.
So
for
the
event
sourcing,
it
does
not
store
the
state
of
actual
work
for
executions,
but
it
stores
the
all.
The
events
are
related
to
the
workflow
and
they
work
these
workflow
executions.
B
So
you
could
say
that
this,
like
the
lost
dog,
talked
about
this,
that
these
are
event-driven
workflows,
but
these
work,
these
events,
basically
folded
into
the
current
state
of
workflow
executions,
and
the
controller
constantly
keeps
track
of
these.
Of
OD
of
the
state
of
these
work
for
executions
and,
together
with
the
scheduler,
decide,
decides
which
tasks
or
functions
to
execute
next.
B
Its
I
have
no
hand
no
more
than
two
hands
so
I
made
it
like
only
hit
enter
okay,
so
we
have
this
directory
and
we
have
basically
two
functions.
The
first
one
is
a
fortune
function
which
basically
does
makes
a
basic
heat
output
sort
of
some
saying
so
it
now
something
and
the
second
function
is
basically
a
will
that
wraps
around
the
input.
It
gets
so
stuff
like
this.
So
now,
of
course,
the
nice
thing
about
work
files.
You
can
compose
these
functions
without
actually
editing
these
functions
themselves.
So
we
can
do.
B
Is
we
specify
a
work
for
a
workflow
definition?
We
currently
use
a
Jamo
format,
so
these
rescues
you
specified
in
them
the
task.
So
you
have
two
tasks,
your
input
or
a
fortune
and
we'll
say
input
or
fortune,
especially
it's
a
function
called
if
which
is
a
what
we
call
a
dynamic
task
which
can
alter
the
control
flow
over
workflow.
B
So
in
this
case,
basically
checks.
If
the
main
input
of
the
of
the
request
is
it's
empty
or
not.
If
it's
not
empty,
it's
not
entity
will
just
buy
through
the
the
input
and,
if
it's,
if
it's
empty,
it
will
use
the
fortune
function
to
actually
to
actually
create
saying
and
I'll
put
that
as
it's
a
result
and
then
the
website
you
can
see
it
requires
this
input
or
fortune
does
to
be
completed
and
it
uses
the
output
of
this
input
of
real
fortune
to
in
its
for
its
input.
B
Okay,
so
that's
the
quick
name
if
questions
come
visit
our
booth
and
asked
me
about
it.
So
the
pros
about
this,
this
approach
is
really
the
single
most
important
benefit
of
this
I
think
is
the
centralized
all
the
logic
related
to
this
to
this
composition.
So
you
have
all
the
blogging
vegetation
monitoring
for
this
accomplishes
together,
and
this
also
allows
you
to
really
make
these
functions
loosely
coupled
because
you
completely
separate
the
composition
from
the
actual
functions
that
underlie
these
with
our
actual
implant
functions
and
then,
finally,
you
also
famously
like
the
message
view.
B
These
work
for
the
finishes
that
you
could
see
are
very
high
level
very
abstract,
so
you
only
define
relationships.
You
define
where
the
data
should
go
should
should
be
at
some
point
and
all
the
other
things
like
the
messaging,
the
ensure
that
the
data
is
on
the
right
place,
the
right
time,
all
done
by
the
work
for
engine
itself
so,
and
that,
if
you
draw
even
further,
then
it
comes
very
interesting
because
you
can
now
you
have
full
control
over
this
work,
this
composition
as
the
workflow
engine
and
you
can
rescue.
B
For
example,
you
can
already
prematurely
start
functions
to
avoid
cold
starts
when
you
have
a
chain
of
functions,
for
example,
the
main
the
main
downside
of
this
is
basically
that
the
infrastructure
does
get
complex
right
like
a
workflow
engine
is
pretty
complex
piece
of
software,
so
it's
there.
There
might
be
issues
there
and
but
the
other,
the
most
important
downside
is
that
you
need
some
way
to
actually
express
these
kinds
of
workflow
compositions
in
some
language,
be
it's
like
this
in
a
jumbo
format
or
our
DSL
in
go
or
JavaScript.
A
All
right,
all
right
so
just
to
recap:
these
are
the
approaches
that
we
went
over
today.
So
just
to
kind
of
sum
it
up,
you
can.
A
great
approach
is
hey.
Just
do
it
source
code
level.
You
actually
may
not
need
a
fast
framework
at
all
or
you
can
nest
your
functions
within
one
another
and
having
them
kind
of
call
on
each
other
via
HTTP
request,
but
be
mindful
of
the
dependent
the
dependability
between
them.
A
A
It
depends
write
all
of
these
different
composition,
styles,
that
we
presented
today.
They
come
with
their
different
benefits
and
their
different
downsides,
and
it
really
just
depends
on
what
you're
willing
to
risk
how
big
and
complex
your
actual
application
is,
and
we
actually
have
a
repo
that
we
just
put
up
on
our
vision,
github
account,
and
so
that's
the
link
to
go
and
check
out
and
try
out
some
of
these
composition
styles
and
see.
Try
amount
on
different
use
cases.