►
From YouTube: Ouch! What I Learned From Being Hit by a Serverless, Ruby Boomerang! - Ewan Slater, Oracle
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
Ouch! What I Learned From Being Hit by a Serverless, Ruby Boomerang! - Ewan Slater, Oracle
Have you ever done something that's come back and bitten you? I have (frequently). Asking an open source project to put more effort into supporting your favourite language (Ruby in my case) is asking to be hit by your own boomerang - "that's a great idea, why don't you get started?" In this talk I'll describe how I got hit by my own Ruby boomerang and wound up maintaining the Ruby FDK for the Fn project (not my day job). I'll cover: - why I believe we need open source serverless - the Fn project - the Ruby FDK (Function Development Kit) - my experience of contributing to open source - why I still want to be involved - how I've encouraged others to start - why you might want to get involved
https://sched.co/MPed
A
A
So
my
day,
job
is
not
working
on
the
FN
project.
My
day,
job
is
I'm,
a
cloud
architect
at
Oracle,
which
means
I
work
with
our
partners
and
our
customers
to
help
them
design,
build,
deploy
and
run
their
applications
on
top
of
Oracle
cloud
I'm
also
I'm,
also
an
accidental
rubyist.
Now
how
does
one
become
an
accidental
rubyist?
A
Well,
it
starts
with
putting
on
a
set
of
blinkers,
so
I
started
out
programming
in
Fortran
and
then
I
moved
on
to
C
and
in
Java
and
a
bit
of
I
fall
and
I
acquired
this
prejudice
that
dynamically
typed
languages
were
fundamentally
unsafe.
They
should
not
be
used
and
if
they
were
used
ever
in
a
production
system,
the
world
would
come
to
an
end
and
then,
a
few
years
ago,
Oracle
acquired
Sun,
and
shortly
after
that,
I
found
myself
on
an
email
thread
where
a
very
senior
guy
very
smart.
A
You
know
two
PhDs
in
engineering
wrote
this
email.
He
said
it
is
not
possible
to
run
and
build
mission.
Critical
systems
on
x86
and
Linux.
I
thought
that's
a
bit
strange
because
all
of
the
mission
critical
systems
that
I
work
with
are
written.
You
know
they
run
on
top
of
x86
and
Linux
and
I
thought
am.
I
have
about
blinkered
and
I
thought.
A
You
know
what
I
am
because
I
have
this
viewpoint,
that
dynamic
languages
are
unsafe
and
you
can't
use
them
and
actually,
if
I
look
out
into
the
world
with
my
blinkers
off,
I
can
see.
There's
plenty
of
people
running
Python,
Django
or
Rebbie
on
Rails,
so
I
decided
that
I
should
give
dynamically
typed
languages.
Another
chance
and
I
should
learn
one
now
at
the
time.
A
lot
of
my
friends
and
colleagues
were
starting
to
get
into
Python
in
a
big
way,
but
I'm
slightly
oppositional.
A
The
village,
where
I
grew
up
90%
of
the
people
supported,
switch
town
and
the
other
10
percent
support
Norwich,
which
meant
that
I
automatically
became
a
Norwich
City
supporter.
It's
not
that
smart
to
move
at
school,
but
you
know
it
is
what
it
is.
So
I
decided
that
I
would
learn
Ruby,
so
I
got
booked
on
Ruby
and
then
I
started.
Making
myself
use
Ruby
where
otherwise,
I
would
use
Java.
And
we
get
to
the
point
today
where
it's
my
go-to
programming
language
and
then
having
taken
off
one
set
of
blinkers.
A
I
thought
should
be
improved
about
it,
so
I
went
and
I
spoke
to
one
of
the
guys
on
you
and
I
said
this
is
great,
but
I
think
you
should
do
this
and
this
and
this
and
this
and
this
and
he
was
like
yeah
yeah.
But
those
are
really
good
ideas.
You
and
but
we've
got
limited
bandwidth.
You
know
Ruby,
so
why?
Don't
you
roll
your
sleeves
up
and
do
the
job
which
wasn't
what
I'd
meant
at
all
I
was
like?
A
No,
no,
no
okay
and
then
you've
got
a
moral
dilemma
because
either
you
have
to
start
contributing
or
you've
really
got
very
little
authority
when
you
try
and
get
people
to
do
other
stuff.
If
you're
not
prepared
to
do
it
yourself
so
FN,
what
is
FN
FN
is
serverless.
Now
the
CN
CF
definition
of
service
is
as
follows.
Serverless
computing
refers
to
the
concept
of
building
running
applications
that
do
not
require
a
server
management.
A
It
describes
a
finer-grained
deployment
model
where
applications
bundled
as
one
or
more
functions
are
uploaded
to
a
platform
and
then
executed
scale
build
in
response.
The
exact
demand
needed
at
the
moment.
That's
the
formal
definition.
I,
actually
think
it's
really
like
this
yeah.
We
want
the
good
stuff
we
want
to
have
the
nice
burger
on
our
plate,
but
we
don't
want
to
see
the
somewhat
unpleasant
process
that
got
it
to
our
plate.
A
So
when
we're
writing
for
function
as
a
service,
what
we
do
is
we
write
small
functions
because
they're,
small
and
short,
they
should
be
quick
to
write.
They
should
be
easy
to
get
right.
They
should
do
one
thing
well,
they
should
be
easy
for
other
people
to
understand
when
they
come
to
look
at
the
code,
including
ourselves
in
six
months
time,
they
should
be
easier
to
maintain
and
we
then
run
them
on
our
service
platform
and
only
pay
for
the
resources
we
consume
at
runtime.
A
It
also
avoids
this
scenario,
which
I've
certainly
encountered
where
the
business
ask
you
to
go
and
do
something:
there's
a
bunch
of
setup
work
that
you
have
to
do
beforehand,
but
as
far
as
they're
concerned
you're
just
wasting
their
time
and
money.
Can
you
not
get
on
with
writing
the
thing
I
wanted
you
to
write
with
serverless
all
that
goes
away
because
that's
been
taken
care
of
in
the
butcher's
shop
and
we're
just
to
focusing
on
giving
them
the
nice
burger
so
upsides
to
service.
It
should
make
development
easier.
It
should
improve
developer
productivity.
A
It
should
increase
our
agility
as
developers
which
should
help
us
make
the
business
more
agile,
and
it
should
allow
us
to
reduce
our
costs
in
terms
of
development
and
operations.
And
if
you
look
at
the
University
of
Berkeley
report
that
came
out
in
March,
they
again
highlighted
improved
program
of
productivity
and
cost
savings
are
two
of
the
benefits
of
service.
Now,
if
there
are
upsides,
there
must
be
downsides.
B
A
Had
loads
of
service
talks
here
at
this
conference
everybody
wants
to
do
stuff,
that's
surveil
us,
and
it's
going
to
rapidly
get
to
the
point
that
people
put
on
a
new
set
of
blinkers
and
say
the
only
way
to
do
anything
is
service
and
then
they'll
miss,
apply
it
and
then
they'll
say
well,
it's
not
very
good.
I
think
you
miss
applied
it
that's
the
problem.
The
other
thing
is
that
you
have
the
opportunity
to
really
snooker
yourself,
even
better
than
you
could
with
microservices.
A
A
The
other
issue
is
around
locking,
so
you
can't
necessarily
take
something
that
was
built
on
one
service
platform
and
just
go
and
run
it
on
another
platform.
You
may
also
find
that
your
choice
is
restricted,
for
example,
in
terms
of
languages,
that
you
can
write
your
functions
in
or
where
you
can
run
your
functions
and
in
some
cases
you
may
just
find
that
the
platform
or
framework
is
too
prescriptive
or
too
opinionated.
A
So,
in
my
view,
when
you're
choosing
a
service
platform
you're
actually
choosing
a
gilded
cage,
it
might
be
a
very
nice
cage,
but
I
think
you
need
to
be
sure
that
that
cage
has
got
enough
freedom
for
you
before
you
get
into
it.
You
also
ought
to
work
out
how
much
effort
is
going
to
be
to
get
out
of
it.
If
you
decide
you
don't
like
being
in
it,
so
people
say
yeah
our
lock-in
you're
really
just
talking
about
switching
costs.
A
Well,
yes,
we
are
but
the
switching
cost
in
terms
of
and
they're
switching
costs
in
terms
of
money
and
if
you've
only
written
one
function
on
a
platform,
then
the
switching
cost
is
going
to
be
low
and
the
time
is
going
to
be
short.
And
if
you
go
and
write
a
lot
of
stuff
and
then
try
and
move
it
you're
going
to
pay
a
high
cost
and
there's
going
to
be
a
lot
of
time
taken.
So
in
a
way,
what
we're
talking
about
is
risk
and
I
see.
A
The
degree
of
lock-in
that
you
have
is
a
combination
of,
what's
my
cost
in
time
and
money
to
switch
and
what's
the
risk
that
I'm
going
to
have
to
switch
the
most
common
locking
scenario
that
people
talk
about
is
that
your
service
provider
decides
you
having
put
all
your
stuff
on
there,
that
they're
going
to
jack
up
the
price
by
a
million
percent
or
something
I'm,
not
sure.
That's
actually
that
big
a
risk,
particularly
given
that
all
the
cloud
providers
tend
to
have
a
history
of
cutting
their
prices
rather
than
jacking
them
up.
A
So
it's
a
risk,
but
maybe
a
low
one.
I
think
this
is
a
bigger
risk.
Your
cloud
provider
gets
jealous
of
your
success
and
you
go
into
work
one
day
and
whatever
it
is,
you
do
as
a
business.
They
announced
that
they're
moving
into
the
same
business.
Now,
how
happy
do
you
feel
about
running
on
their
platform?
A
Vendor
independence,
I
know
people
either
personally
or
the
organizations
they
work
for,
have
the
scars
from
being
dependent
on
a
particular
vendor,
and
then
that
relationship
goes
bad
and
it's
been
difficult
for
them
to
get
away,
and
it's
just
been
generally
unpleasant
portability.
Do
you
want
to
be
able
to
move
your
stuff
from
one
cloud
to
another
to
on-premises,
or
do
you
want
to
run
with
some
kind
of
decentralized
model
where
you
have
multiple
clouds
at
a
time,
or
are
you
doing
stuff
where
privacy
is
a
particular
concern
for
you?
A
So
these
freedoms
matter
to
people
and
the
ultimate
freedom
that
people
have
is
or
want?
Is
the
freedoms,
if
necessary,
take
that
platform
and
make
it
their
own
or
create
their
own
version
of
it?
And
all
of
this
leads
people
to
open-source
service,
and
there
are
a
number
of
open
source
service
projects
out
there
I'm
going
to
talk
about
FN,
because
that's
the
one
that
I've
worked
with
most
and
contributed
to
and
ultimately
the
freedoms
that
you
want
come
from
open
source
now
for.
B
A
Freedom
that
really
mattered
was
language
because
the
situation
is
better
today.
But
if
you
look
back
eighteen
months,
two
years,
none
of
the
cloud
providers
function
as
a
service
platform
supported,
Ruby
or
rust,
or
Erlang
or
Fortran
people
do
still
write
in
Fortran
and
they
want
to
be
able
to
use
service.
A
So
I
was
really
pleased
when
I
found
out
about
the
FM
project.
So
it
is
an
open
source
service,
compute
platform,
it's
language,
agnostic.
You
can
run
it
on
any
cloud.
You
can
run
it
on
premises,
basically
anywhere
that
docker
will
run.
There's
a
large
team
there's
over
75
contributors,
including
me.
We
have
support
for
cloud
events,
we're
backed
by
Oracle
but
independently
governed
with
representation
at
CN
CF,
and
we
have
a
promises
based
orchestration
mechanism
to
orchestrate
your
functions
together
called
flow.
A
A
When
we
do
a
deploy,
you've
got
your
code,
then
we
do
a
multi-stage
build
of
the
container.
The
yam
l
file
contains
a
version,
so
we
bump
that
we
push.
The
container
to
the
registry
could
be
docker
hub,
could
be
a
private
registry,
you
own,
and
then
we
create
or
update
function
endpoints
as
appropriate
in
terms
of
the
endpoints
FN
deploy,
creates
a
single
default
in
endpoint
that
is
used
internally
by
the
CLI.
A
As
you
can
see,
it's
not
necessarily
the
most
friendly
URL,
almost
memorable,
and
you
only
get
one
for
function
deployment,
so
we
also
have
a
way
of
creating
more
human-friendly
URLs.
This
is
called
triggers
and
you
can
have
multiple
endpoints
or
multiple
triggers
for
the
same
functions,
so
you
could,
for
example,
give
internal
people
a
different
URL
to
external
ones
and
protect
those
URLs
differently.
A
You
can
create
triggers
on
the
fly
using
the
CLI
or
you
can
declare
them
in
the
func
Gamal
there's
also
the
concept
of
the
FN
server,
which
is
like
our
API
gateway.
So
this
manages
apps
and
functions
and
for
the
purposes
of
FN
and
app
is
a
group
of
functions.
It's
basically
a
name
face,
FN
server
handles
are
functioning,
vacations
itself
runs
as
a
container,
so
it
runs
anywhere.
Dhaka
does
and
it
hosts
the
function
containers
using
docker
in
docker
as
we
use
docker
in
docker.
A
We
don't
have
to
worry
so
much
about
what
the
external
version
is
of
docker
versus
the
internal
version,
and
the
request
process
goes
something
like
this:
in
production,
you're
going
to
have
a
load,
balancer
and
a
you
know,
an
array
of
FN
servers,
but
basically
the
requests
going
to
come
in
and
the
FN
server
will
say.
Do
I
already
have
a
running
instance
of
this
function
container.
If
I
do,
then
let
me
send
the
request
there.
If
I,
don't
I'll
spin
up
a
new
one,
I'll
execute
the
request.
A
So
one
of
the
things
that
your
function
development
kit
has
to
handle
is
the
scenario
where
you
get
multiple
invitations.
F
decays
make
it
a
lot
easier
to
write
the
function.
So
as
a
developer,
you
include
the
package
or
library
or
gem
or
whatever
your
language
calls
that
kind
of
thing.
You
write
your
function
to
the
F
DK's
interface
and
the
F
decayed
takes
care
of
parsing,
HTTP
stream,
providing
the
input
data
to
your
function
and
writing
the
output
in
errors.
We
have
F
decays
for
Python
Ruby
Java
go
node
and
dotnet
core.
A
If
you
don't
have
an
FD
K
for
your
particular
language,
you
can
also
you
know
you
can
use
either
bring
your
own
docker
file
or
you
can
bring
your
own
docker
image
and
build
a
function
around
that.
So
here's
the
anatomy
of
a
function.
This
is
hello
world
in
Ruby,
so
at
the
top
you've
got
require
the
fdk.
A
Then
we
create
the
function,
and
in
this
case
it
just
says:
have
you
got
a
name
field
in
the
input,
hello
name,
if
not
hello
world,
and
then
we
call
the
handle
method
of
the
FD
K,
so
the
Ruby
FD
K,
which
is
what
I
work
on
works
as
follows,
but
all
of
the
F
decays
will
follow
this
path.
So
the
container
comes
up.
We
open
a
socket
inside
the
function
container.
The
FN
server
then
connects
to
that
socket
and
sends
the
payload
over
it.
A
A
The
first
thing
I
had
to
figure
out
and
really
understand,
was
how
it
works
and
I
would
do
the
same
again
if
I
was
working
with
another
open
source
project
and
how
it
works
is
an
interesting
one.
So
you
start
out
with
I
can
use
this
thing.
Yes,
you
can
you've
learned
enough
to
be
a
user,
but
to
actually
start
working
on
the
project.
You
have
to
understand
where
all
the
bits
are
and
how
they
relate
to
each
other
and
what
caused
what
so?
A
A
You
also
have
to
understand
how
the
project
is
structured,
how
it's
laid
out
in
terms
of
the
git
repositories
and
how
the
things
in
there
relate
to
each
other.
So
if
you
change
something
over
here,
whether
there's
going
to
be
a
knock-on
effect
on
something
over
there,
that
you've
got
to
either
go
and
update
yourself
or
ask
somebody
to
go
and
update.
A
If
your
project
has
contribution
guidelines,
I
recommend
that
a
you
read
them
be
that
you
do
what
they
say,
because
the
people
who
have
set
the
project
up
have
thought
of
ways
that
they
want
people
to
contribute,
and
it
helps
if
you
follow
those
guidelines,
otherwise,
you're
not
really
contributing
you're,
hindering
part
of
that
is
understanding
what
the
communication
channels
are
for
the
project.
So
in
FN
we
have
two
principal
communication
channels.
One
is
slack
on
the
slack
workspace.
Most
things
happen
around
that
and
there's
also
the
comments
and
reviews
around
pull
requests.
A
A
You
also
need
to
be
aware
of
what
time
zones
those
people
are
in,
for
instance,
there's
no
point
sending
a
message
at
nine
o'clock
in
the
morning
in
the
UK
to
somebody
who
lives
on
the
east
coast
of
the
US,
and
you
also
need
to
get
your
head
around.
What
are
the
processes
and
practices
that
we
follow
in
that
project
when
somebody
makes
the
change
or
makes
a
proposal?
How
do
we
get
that
through
into
the
build
and
what
are
the
individual
things
that
have
to
be
built?
So
for
the
fdk?
A
So
that's
kind
of
what
I
had
to
get
my
head
round.
What
I've
actually
done.
The
first
issue
that
needed
fixing
from
my
point
of
view,
was
to
do
with
Jason.
Now,
at
the
time
we
didn't
use
HTTP
stream.
At
the
time
we
actually
took
our
input
on
standard
in
and
we
sent
back
on
standard
out
and
you
could
specify
the
format
type
that
was
coming
in
and
one
of
the
issues
was
if
JSON
format
was
specified
and
two
JSON
documents
were
sent
in
the
payload.
The
FD
key
K
didn't
cope
with
that.
A
Well,
so
that
was
my
first
issue
to
solve
I
fixed
that
then
we
had
some
additional
formats
that
we
needed
to
support
so
added
support
for
those-
and
this
was
kind
of
quite
a
sort
of
reactive
exercise,
a
a
learning
getting
to
know
the
guy
who
had
been
maintaining
the
fdk.
Previously
then
I
got
to
the
point
where
I
actually
wanted
to
start
making
changes,
and
this
is
where
you
start
to
get
into
negotiating
with
the
other
person
and
how
yeah
you
have
to
be
diplomatic.
A
You
don't
want
to
say
something
someone's
gonna
feel
that
you're
dissing
their
work,
one
of
the
things
was
around
coding
standards.
So
the
code
we
had
at
the
time
didn't
follow
the
Ruby
style
guide
and
it
helps
if
you
can
reference
the
community
at
this
point,
so
actually
go
and
say.
Well,
really
we
should
be
looking
at
stuff.
A
That's
in
the
style
guide,
and
we
should
probably
include
robocop-
is
part
of
the
build
process,
because
that'll
ensure
that
there's
an
automatic
check
that
we
follow
the
style
guide
and
where
we
want
to
deviate
from
it
will
actually
explicitly
document
that
so
that
was
one
negotiation
went
okay
in
the
end,
slightly
more
tricky
was
modernizing
some
of
the
syntax,
so
with
modern
Ruby,
certainly
with
stuff.
That's
externally
facing
the
received
best
practices
you
should
be
using
named
parameters.
A
We
had
an
API
change
that
was
being
made
at
the
same
time,
so
I
managed
to
sleep
that
one
in
there
again,
partly
by
referencing
some
of
the
experts
within
the
Ruby
community,
who
very
kindly
responded
to
private
emails.
So
I
got
that
negotiated
through
and
in
fact
that's
documentation
and
yeah.
If
you
want
to
get
involved
in
an
open
source
project
and
Bri
appreciated
really
quickly
offer
to
write
the
documentation
because
everybody
wants
to
write
code,
but
nobody
wants
to
write
documentation.
A
A
Remember
this
isn't
my
day
job
and
then
I
went
on
holiday,
yeah,
that's
another
top
tip,
never
go
on
holiday
if
you're
on
an
open-source
project,
because
I
got
back
and
had
been
a
major
change
to
the
API
while
I'd
been
away
so
we'd
moved
away
from
standard
in
standard
out,
we
moved
to
http
stream
and
we
did
introduce
the
concept
of
triggers
okay.
That
means
that
the
fdk
now
no
longer
works,
and
so
it
needs
fixing.
A
Unfortunately,
my
boss
had
a
month
of
work
lined
up
for
me,
which
meant
that
I
wasn't
going
to
be
able
to
do
this,
and
this
caused
me
a
bit
of
personal
anxiety,
because
I
really
wanted
to
do
that.
But
I
couldn't
I
just
didn't
have
the
time-
and
you
have
to
be
honest
about
that.
So
my
day,
job
created
somebody
else's
rush
job.
The
guy
who
did
the
rush
job
was
a
go
programmer,
so
we
went
up
with
a
big
sort
of
slab
of
Ruby
as
go,
but
it
worked.
A
That
was
the
key
thing
it
worked.
We
had
a
working
fdk
that
honored
the
contract
I
might
not
have
been
particularly
happy
with
the
code,
but
it
worked
and
what
that
did
was
buy
me
time.
So,
when
I
got
back
from
doing
the
month
of
stuff,
my
boss
had
lined
up
for
me
and
I
could
get
some
time
to
work
on.
This
I
was
able
to
refactor
it
into
more
idiomatic
Ruby.
A
What
I
want
to
do
going
forward,
because
there's
always
stuff
to
do
I,
want
to
improve
the
test.
Suite
I
prefer
a
sort
of
spec
based
testing
approach,
and
so
I
want
to
switch
it
to
our
spec
flow
I
mentioned
that
FN
has
a
promises
based
orchestration
mechanism.
At
the
moment.
That's
not
part
of
the
F
of
the
Ruby
fdk
and
there's
a
separate
library
with
the
other
F
decays
as
well.
So
I
want
to
create
a
ruby
library
to
support
float.
I
also
want
to
have
the
option
of
using
truffle
Ruby
as
a
runtime.
A
Truffle
Ruby
is
the
Ruby
implementation
on
top
of
the
growl
VM
and
it's
considerably
faster
than
MRI
Ruby.
So
I
want
to
do
that
as
well,
and
I
know
this
kind
of
by
definition,
isn't
Ruby,
but
I
like
programming
languages.
That
start
with
our
I
want
to
implement
a
rust
fdk,
because
at
the
moment
you've
got
to
do
that
as
bring
your
own
docker
file.
A
What
I've
learned
the
the
first
thing
and
it
shouldn't
need
saying
but
I'm
gonna
say
it
anyway,
is
you
should
be
polite,
you're
joining
you're
joining
somebody
else's
project.
You
should
be
polite,
you
should
not
sort
of
go
in
with
a
sort
of
bull
in
the
china
shop
approach,
and
you
should
remember
that
you're
going
to
have
a
steep
learning
curve,
because
you're
going
to
have
to
learn
this
project
in
a
lot
more
detail
than
when
you
were
simply
a
user.
A
Sometimes
you
might
look
at
the
code,
you
might
look
at
the
documentation
and
you
might
think
I'm
not
sure
about
this.
It's
always
better.
In
my
view.
At
that
point
to
actually
ask
for
clarification,
the
question
might
make
you
look
a
bit
dumb.
You
might
feel
a
bit
dumb
asking
it,
but
you
won't
feel
anything
like
as
dumb
as
if
you've
gone
and
worked
for
two
weeks
on
the
wrong
assumption.
A
In
fact,
I've
found,
certainly
with
the
f-m
project.
People
have
been
incredibly
helpful
and
I
think
you
should
try
to
be
as
helpful
yourself
when
you
know
an
answer.
That's
on
the
slack
channel.
You
should
give
the
answer,
and
that
saves
somebody
else
from
having
to
waste
their
time,
and
you
can't
be
possessive
about
the
code
by
definition.
You've
donated
it
to
the
community.
A
It's
not
yours,
and
you
know
the
thing
with
the
API
change
and
me
not
being
able
to
do
it.
I
really
wanted
to
do
it,
but
you
just
have
to
go.
Actually
it's
more
important
for
the
project.
We
have
a
working
fdk.
Then
my
ego
gets
buttered
up
and
you
need
to
focus
on
what
you
bring
to
the
project.
Some
people
bring
domain
knowledge.
A
You
might
bring
a
particular
piece
of
technical
knowledge,
but
focus
on
that
and
focus
on
making
the
maximum
contribution
or
out
that
the
other
thing
I
think
is
really
important
is
to
respect
other
projects.
As
I
said,
there's
a
number
of
open-source
service
projects
out
there
I
know
people
who
work
with
open
fairs
have
been
some
talks
about
that
here.
I
know
people
who
work
on
open
wisk.
They
have
never
been
anything
other
than
really
friendly
towards
me.
A
I
hope
they
would
say
the
same
back
and
I
think
what
we
should
do
is
share
exchange
ideas,
because
that's
how
we
make
progress
time
time
is
critical.
You
really
need
to
manage
your
time
carefully.
My
suggested
prioritization
is
as
follows.
First
of
all,
your
family,
your
kids,
are
never
going
to
remember
your
pull
requests.
Second
work.
A
You
know,
if
you're
not
being
paid
to
do
this
the
day
job
is
kind
of
really
important
for
paying
the
bill,
and
you
you
know,
you're
not
going
to
with
the
best
will
in
the
world,
spend
all
weekend
coding,
particularly
if
you
have
kids
and
other
things
that
you
need
to
do
so.
I
think
you
need
to
be
responsive
to
the
requests
of
your
team,
but
you
need
to
be
honest.
It's
set
realistic
expectations.
A
If
you're
not
going
to
be
able
to
do
that
thing
for
a
week
or
a
month,
you
need
to
tell
people
quickly
when
they
ask,
and
then
they
can
plan
around
that,
and
you
also
need
to
be
honest
with
yourself.
You
know,
as
I
say,
you're
not
going
to
be
able
to
set
aside
three
days
and
code
all
night
on
those
three
days
and
if
you
do
get
any
opportunity
to
align
what
you
do
with
the
day,
job
then
take
it,
because
you
can
kill
two
birds
with
one
stone:
I
try
to
get
others
involved.
A
I
talked
at
meetups
I
took
conferences
like
this
slack
seems
to
be
our
gateway,
job,
our
gateway
drug,
so
people
who
join
the
slack
workspace
tend
to
become
users,
and
then
afterwards
they
tend
to
become
pushers,
either
in
the
get
sense
or
the
promotion
sense,
or
both
that's
how
we
got
the
dotnet
core
fdk.
It
was
a
community
fdk,
not
officially
part
the
project.
A
Why
get
involved
Oh
fun
I've
actually
really
enjoyed
doing
this
hard,
as
it
has
been
at
times.
I've
got
a
real
sense
of
achievement.
Out
of
it.
I've
learned
a
lot
and
also
there's
a
question
of
what
I
see
is
moral
debt,
so
everybody
in
this
room
uses
and
has
a
huge
debt
to
open-source
software.
This
is
Stone
Soup.
By
the
way
yeah
you
put
the
stone
in
the
water
and
then,
if
everybody
contributes
a
bit
a
bit
of
me
a
bit
of
edge,
we
wind
up
with
a
great
soup.
A
If
nobody
contributes
anything,
we've
got
a
stone
in
a
ball
of
hot
water
and
that's
how
I
see
open-source.
If
we
all
contribute
where
we
can,
we
will
all
have
this
rich
environment
of
open-source
software.
That
we
can
use
to
better
ourselves
if
you
want
to
get
involved
and
I
hope
you
do.
You
can
learn
more
at
project
IO.
You
can
join
the
slack
workspace,
you
can
follow
us
on
Twitter
and
you
can
focus
and
contribute
at
github
comm
FN
project.
A
Takeaways
serverless
is
an
abstraction.
It's
an
abstraction
that
enables
us
to
prove
improve
our
productivity.
Our
agility,
the
scalability
and
the
economics
of
what
we
do.
Fn
is
an
open-source
service
platform.
It's
docker
based
it's
portable,
it's
language,
agnostic,
but
there
are
multiple
F
decays
to
help
with
some
languages.
A
Open-Source
really
matters,
I,
think
open
source
service
really
matters
from
the
point
of
view
of
freedom,
and
if
you
care
about
that,
then
I
think
you
should
act
like
it.
You
should
contribute
and
you
should
help
others
where
you
can.
Thank
you,
I'm
yoon
slater
and
if
you
want
to
get
in
touch
with
me,
that's
the
easiest
way.
A
C
Before
you
mentioned
that,
if
you
put
all
their
eggs
in
one
basket-
and
you
put
all
your
service
functions
in
code
on
one
provider
and
you
become
successful,
they
can
steal
your
business
that
that's
the
greatest
risk.
So
the
question
is:
do
they
have
access
to
your
code
and
if
so,
did
they
can
actually
rip
off
your
code
and
use
it
so.
A
I
wasn't
thinking
so
much
of
them
ripping
off
your
code
as
just
taking
your
business.
So
a
few
years
ago,
I
did
a
project
with
a
British
Building
Society,
so
like
a
mortgage
bank
and
part
of
the
project
was
because
they
had
noticed
that
other
banks
yeah
they
gave
the
mortgage.
There
was
a
direct
debit
to
collect
the
mortgage,
that
other
banks
had
been
looking
at.
The
direct
debits
and
being
are
they've
got
a
mortgage
with
X
and
they've
had
that
for
about
two
years
right.
Let's
go
and
use
the
financial
information.
A
We
have
to
try
and
steal
their
mortgage
business,
so
they
were
actually
now
having
to
offer
current
accounts
in
in
retaliation
which
they'd
never
wanted
to
do
before.
There
are
other
instances,
I'm
afraid
of
unethical
behavior
I'm,
not
saying
that
anybody
would
I'm
saying
it's
perceived
risk
and
if
you
look
at
say
pivotal,
you
know
why.
Why
are
some
of
the
banks
using
pivotal
because
they
also
want
to
be
able
to
to
have
that
option
of
being
able
to
move
their
paths
from
a
particular
cloud
provider
to
somewhere
else?
A
As
I
said,
I
don't
want
to
be
negative
about
anybody,
so
I
will
only
talk
about
positives,
that
people
have
said
about
FN
projects,
so
automate
her
here
and
gave
a
lightning
tool
yesterday
and
said
they
regard
flow
as
rocket
fuel.
For
what
they've
done,
the
orchestration
mechanism
that
they've
been
able
to
use
as
a
guy
called
Christopher
woods,
Bristol
University
has
done
some
great
talks.
You
can
see
on
YouTube
and
he
said
you
know
he
feels
the
maturity
of
FN
and
the
portability
that
he
gives.