►
From YouTube: Accelerating the Journey of an AI Algorithm to Production with OpenFaaS - Joost Noppen & Alex Ellis
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
Accelerating the Journey of an AI Algorithm to Production with OpenFaaS - Joost Noppen, BT PLC & Alex Ellis, OpenFaaS Ltd
At BT it used to take us 2-3 years to get from a research idea to an AI algorithm that can be consumed by an end-user in production. We needed to reduce the risk and the investment required to bring our products to market and get essential feedback. We addressed three key areas to improve: having a diverse range of developer skills amongst us researchers, a lack of modern packaging & CI/CD practice, a need for a cloud-native model to shrink-wrap and run our code in production at scale. Our journey lead us to Serverless Functions, come to our talk to hear how we implemented our pipeline for development and deployment of AI algorithms using OpenFaaS. We can now ship to production in just two months improving the rate of delivery by 90%. The talk will also cover how BT built their platform using the UNIX-like primitives made available through the OpenFaaS eco-system and include a live demo.
https://sched.co/MPeF
A
Okay,
so
we're
gonna
start
a
session
on
delivering
AI
research
at
speed
using
serverless
and
kubernetes.
I'm
joined
here
by
new
snoppen
senior
researcher
at
bt,
and
we
actually
first
got
talking
to
each
other,
probably
in
April,
2018
and
I.
Had
an
email
from
used
to
is
very
excited.
Is
that
I've
been
using
your
project?
Open-Face,
which
is
service
and
humanities
for
seven
months,
would
be
an
experimenting
with
it.
I
want
to
let
you
know
what
we've
been
doing
and
one
thing
led
to
another,
and
here
we
are
today
so
yeast.
Well,.
B
Thank
you
Alex.
Can
everyone
hear
me?
Yep
sounds
about
right.
My
name
is
Inigo
snoopin,
it's
a
Dutch
name
rhymes
on
toast.
So
if
you
don't
know
how
to
pronounce
that
call
me
anything,
bread
related
I
will
respond
to
it,
and
indeed
we
got
in
touch
with
Alex
about
April
last
year,
and
this
essentially
started
with
the
point
that
within
BT
we
have
research
departments
and
these
research
departments.
Well,
BT
does
a
lot
of
research.
If
you
would
ask
people
what
does
BT
do?
Typically
people
will
say
broadband
and
phones
right.
That's
what
we
do.
B
That's
what
we
make
our
money
with,
which
is
absolutely
fine.
That
is
true,
but
BT
research
essentially
tries
to
look
at
what
can
be
T
become
in
the
future,
and
there's
research
going
on
in
machine
learning
and
looking
at
big
data,
pretty
much
looking
at
our
customer
journeys
trying
to
find
out
the
typical
pain
points
are
where
our
networks
might
fail.
All
that
kind
of
stuff
and
some
other
topics.
Cyber
defense
can
be
automatically
detect
all
kinds
of
dangers
on
our
network.
B
Can
we
forecast
where
our
network
will
be
in
most
in
demand
during
a
particular
time
of
day
and
a
lot
of
stuff
happening,
and
all
of
this
produces
software,
and
all
our
researchers
typically
produce
some
kind
of
AI
algorithm
and
those
AI
algorithms,
then,
in
turn,
need
to
be
turns
into
products
that
can
be
used
by
our
end.
Users,
which
can
be
customers
can
be
our
own
development
teams,
can
literally
be
be
anyone
that
is
related
to
our
organization.
B
I
out
of
range:
yes,
there
we
go
now.
This
created
a
challenge
for
us
right,
and
this
was
all
pre
open,
vas
and
servlets.
The
point
was
that
we
have
our
our
researches
and
our
researches
are
typically
data
scientists
who
have
excellent
skills
in
mathematics
and
statistics
of
stuff
like
that,
but
not
necessarily
a
whole
other
skills
in
hardcore
software
engineering
and
productizing
bits
of
software.
B
We
also
had
a
bit
of
an
issue
with
inside
a
research
department
when
it
comes
to
using
CI
in
CD,
and
there
wasn't
a
lot
of
that
happening,
which
it's
not
great
and
we
increasingly
with
targeting
as
the
outputs
stuff
being
deployed
onto
an
external
cloud
environments
like
Amazon,
or
something
like
that.
So
there
was
a
lot
of
friction
here
and
that
was
combined
with.
B
B
We
have
to
have
some
level
of
enterprise
control.
We
have
to
have
some
kind
of
audit
ability
of
the
way
where
our
data
goes,
how
it
gets
deployed
and
who
gets
access.
So
those
things
made
our
life
hearts,
and
typically,
we
ended
up
with
this
kind
of
development
model
for
our
research
at
the
left
top
we
have
our
fantastically
intelligent
data
scientist
who
do
stuff
that
I
really
don't
understand.
They
come
up
with
an
algorithm
represented
by
the
Delta
that
you
can
see
up
there
and
that
algorithm
was
then
placed
into
a
proof-of-concept
tool
right.
B
It
would
effectively
be
something
that
you
can
demonstrate
to
the
management
team
that
would
create
or
demonstrate
value
and
then
convince
people
that
this
needs
to
be
taken
further,
and
that
taken
further
is
the
step
going
down.
We
would
hand
over
a
proof
of
concept
algorithm
to
a
development
team
that
development
team
would
completely
reimplementation.
B
A
B
Handed
over
excellent
question,
it
was
very,
very
hard.
The
the
cycle
we
have
here,
as
most
of
you
will
have
realized.
It
is
waterfall
effectively.
You
would
go
one
cycle
and
after
three
years,
if
the
research
didn't
said,
hang
on
I
had
an
update
to
my
algorithm.
The
cycle
would
start
again
and
the
updates-
and
she
referred
to
it-
would
take
multiple
years
to
get
into
this
new
product
if
they
would
make
it
in
at
all
so
very
much
about
tonight.
Yeah,
so
BT
was
not
happy
with
that.
B
As
you
can
imagine,
and
about
a
year
and
a
half
ago
we
started
the
journey
of
identifying
where
the
core
problem
lies
and
I've
already
mentioned
this.
We
had
a
range
of
expertise
in
our
organization,
and
this
is
quite
typical
for
big
organizations
where
you
have
people
who
specialize
in
one
area
and
then
they
have
to
collaborate
with
another
area
and
they
don't
know
all
the
specifics.
So
our
data
scientists
on
the
Left
which
we
refer
to
as
citizen
developers,
people
who
stay
job,
is
not
software
development
and
yet
they
produce
software.
B
They
would
typically
use
something
like
our
Jupiter
notebooks,
but
interactive
Python.
Some
of
them
even
might
use
Java
and
on
the
other
side
of
the
equation,
to
get
to
this
point
of
rapid
deployments
and
making
things
available
to
our
end-users
and
other
researchers,
you
would
have
our
expert
developers
who
would
use
things
like
Jenkins
and
gates,
and
all
that
kind
of
good
stuff
that
we
kind
of
take
for
granted,
and
this
skill
gap
is
considerable.
It
is
really
hard
to
convince
people
to
scale
up
when
their
day.
A
Wonder
if
we
could
ask
people
and
audience
if
you,
if
you
feel
like
you're,
identifying
more
like
you're
on
this
side
or
that
side
yeah
pretty
much
everybody.
So
you
know
it's
very
hard
for
even
for
me
to
relate,
and
perhaps
for
you
as
well
what
it
is
actually
like
to
not
know
what
keeps
ETL
or
cute
cuddle
or
whatever
it's
called,
actually
is,
or
how
to
get
a
harness
on
these
tools,
and
that's
one
of
the
things
we're
trying
to
do
with
open
fires.
A
B
And
to
be
clear,
I
identify
myself
on
that
right
side
of
the
slide
as
well,
but
given
that
I
have
to
support
the
people
on
the
left
side,
I
can't
get
away
with
I'll
just
learn
how
it
works.
How
hard
is
it
if
you're
facing
with
so
many
people?
That's
too
much
too
much
time
too
much
effort,
so
this
was
a
model
that
we
came
up
with
and
there's
nothing
shocking
here.
This
is
effectively
what
most
of
the
people
in
this
room
will
say:
yeah
that
makes
sense.
Why
didn't
you
do
that
before?
B
Our
idea
was
that,
instead
of
our
researchers
producing
a
proof
of
concept
prototype
that
lives
on
their
laptop
and
then
handed
off
to
a
development
team,
we
would
say:
write
your
AI
algorithm
and
then
deploy
it
as
a
service
function
in
microservice,
and
at
that
point
your
work
becomes
available
to
the
entire
organization
instantly
on
a
web
endpoint
and
we
can
start
building
all
kinds
of
applications
that
use
these.
These
functionalities
share
these
functionalities,
even
so
better
use
of
our
resources
and
then
create
some
web
front-ends,
and
that
will
help
speed
things
up.
B
That
was
the
plan
and
to
support
this,
we
pretty
much
instantly
move
towards
oprah's
and
as
a
solution.
It
is
a
perfect
way
of
packaging,
up
your
research,
algorithms
and
making
them
available.
It
ticks
all
those
boxes
and
the
one
problem
that
we
needed
to
solve
is
our
data
scientists
and
really
needs
to
have
a
almost
zero
touch
deployment
of
their
AI
algorithms.
So
we
came
up
with
this
particular
workflow
at
the
left
top.
We
would
ask
our
data
scientists
ooh.
You
can
use
any
language,
you
want.
B
We
honestly
don't
care
right,
we
couldn't
deploy
it
in
docker
container,
so
that
is
fine,
and
all
that
we
ask
of.
You
is
to
effectively
provide
us
with
a
textual
description.
A
Yama
file
and
this
Yama
file
contains
the
minimum
deeds
that
are
required
to
package
this
into
an
open
fire
service
function.
So
after
we
have
that
from
our
developers,
that
goes
through
a
build
pipeline
which
can
be
Jenkins
or
gate
lab
or
whatever
the
preferred
flavor
is.
B
In
that
case,
it
gets
sent
off
following
arrow
one
and
then
arrow
two
to
a
to
a
web
endpoint
that
sends
it
on
to
our
deployment
layer,
and
this
essentially
is
a
bit
of
smartness
on
our
site,
we'd
like
to
think
that
packages
everything
up
into
an
a
service
function
and
pushes
the
resulting
container
that
contains
this.
This
research
algorithm
into
the
harbor
image
registry.
So
we
have
our
research
algorithm,
neatly
packaged
up
in
a
registry,
and
the
final
bit
is
asking
our
open
vast
instance
that
you
can
so
prominently
see
here
in
the
middle.
B
A
B
You
can
see
on
the
on
this
slide.
We
have
the
very
obvious,
kubernetes
cluster
running
this.
This
is
our
own
managed
cluster
and
just
to
highlight.
We
are
a
research
team
that
pretty
much
experiments
with
bleeding-edge
kubernetes,
but
that
is
our
targets
and
that's
also
to
make
sure
that
moving
forward
to
bt
can
acquire
some
of
this
new
stuff
and
we
can
guarantee
that
it
works,
and
we
combine
that
with
metrics
collection
using
Prometheus,
that
that
would
already
be
the
absolute
basics,
the
minimum
that
we
need.
Okay,.
A
B
And
we
backed
this
with
elastic
search
and
cabana
and
all
that
kind
of
stuff
for
data
collection
to
make
sure
we
have
insight
into
what's
happening
and
also
to
report
back
and
say:
look
all
these
researches
deploy
their
own
rhythms
day,
and
this
is
how
many
uses
we
get
out
of
them.
So
the
new
life
cycle,
then
this
is
the
life
cycle
that
we
are
currently
using
as
compared
to
the
old
waterfall
model,
showed
you
before
at
the
left
top.
B
We
still
have
a
researcher
coming
up
with
their
fantastically
bright
ideas,
developing
out
on
their
local
machines
and
then
using
the
pipeline.
That
I
showed
you
on
the
previous
slide
and
that
gets
deployed
onto
the
open
fires
gateway
and
becomes
available
to
all
our
researches,
and
this
is
the
point
where
our
development
teams
now
get
involved,
but
there's
no
needs
to
re-implement
this
really
difficult
algorithm.
B
Essentially,
this
is
now
a
fully
working
deployment
that
can
be
scaled,
using
open
files,
functionality
and-
and
we
built
the
app
around
that
so
our
development
teams
built
the
app
built
a
web
front-ends
and
it
instantly
becomes
available
and
there's
a
couple
of
differences
that
are
really
important.
The
old
life
cycle
would
take
three
years
to
get
a
fully
working
application,
and
now
the
moment
a
researcher
comes
up
with
a
bright
idea,
the
reusable
components
this
research
algorithm
instantly
becomes
available
and
that
typically
can
be
done
in
the
space
of
a
couple
of
months.
B
A
B
Done
is
absolutely
true,
as
I
mentioned
on
the
old
life
cycle,
the
research
was
out
of
the
loop.
The
moment
you
handed
it
over
and
now
we
have
these
feedback
cycles,
so
our
researcher
can
instantly
feedback
on
how
they
like
the
application,
whether
the
algorithm
is
performing
correctly
and
they
can
make
contributions
and
we've
observed
when
we
apply
this
model,
that
we
started
up
skilling
researchers
because
they
saw
how
this
process
worked,
and
they
wanted
to
know
how
they
could
improve
their
own
development
practice
so
in
a
way
enabling
them
to
eat
more
easily.
B
Share,
also
made
them
appreciate
more
how
this
kind
of
process
can
help
them
out
so
yeah
absolutely
and
to
stress
that
the
main
benefit
that
we
were
after
and
that
we
got
is
this
delivery
time?
If
our
research
makes
an
update
to
the
research
algorithm,
that
will
instantly
go
into
the
store
of
introducing
the
surplus
endpoints
and
it
will
be
available
in
your
application.
B
So
that
isn't
this
three-year
lag
for
things
to
make
it
into
production,
which
is
a
massive
improvement,
actually
is
a
game-changer
for
us,
so
benefit
that
I
would
like
to
highlight
as
well
I've
already
mentioned
internally.
We
run
this
on
their
own
kubernetes
cluster
and
we're
very
happy
with
that.
But
every
now
and
again
when
we
are
developing
applications
quite
frequently.
B
Actually
we
work
with
customers
who
want
to
do
a
trial
and
the
trial
is
not
necessarily
a
full
performance
trial,
but
maybe
some
functional
feedback
just
seeing
if
the
tool
actually
works
for
them
where
they
wanted
to,
in
which
case
we
quite
typically
don't
have
access
to
an
external
kubernetes
cluster
or
even
can
justify
the
cost.
For
that-
and
this
is
where
open
vas
of
officers
that
other
additional
benefits
it
is
built
on
industry
standard
core
technologies.
It
is
all
docker
and
coordination
in
kubernetes,
okay,.
A
Much
they
have
a
bucket
image
with
port
8080.
That's
the
primitive
I'll,
explain
that
a
little
bit
later
on
and
what
that
means
is
that
used
when
he
will
deploy
this
for
a
customer.
I
can
effectively
shrink-wrap
it
and
generate
a
docker
compose
file
and
bypass
all
of
Cuba
Nettie's.
Now
there's
some
technology
like
k3s.
That
makes
it
very
easy
to
get
a
small
kubernetes
cluster
up
and
running
with.
Maybe
some
of
you
have
tried
it
already,
but
one
thing
you
also
get
here
is
pretty
much
the
portability
that
promise
of
docker
images
is
there.
B
To
production
is
fairly
straightforward
either
internally
we
get
a
production,
Nettie's
cluster,
which
MBT
has
been
working
hard
on
to
make
easily
available,
or
we
will
acquire
some
kind
of
kubernetes
instance
from
a
cloud
provider
and
then
it's
just
a
matter
of
transferring
it
across
using
production
scripts
that
we
have
for
that.
So
again,
it's
it
really
improved
our
workflow
on
this,
where
it
used
to
be
really
hard
and
I'm,
not
joking.
B
Sometimes
this
transfer
would
take
up
to
two
years
in
under
the
old
model
going
from
one
environment
to
another,
and
now
it
is
10
minutes
and
a
cup
of
coffee
effectively
which
I
like
coffee.
So
that's
definitely
good
for
me,
so
that
is
say
the
slide
where,
and
we
would
like
to
highlight
that
by
giving
you
a
demonstration
of
how
we
apply
this
model
in
active
working
research,
so
we
have
an
Innovation
Centre
in
Belfast
Ireland.
B
Quite
typically,
what
you
find,
if
particular
metrics,
are
high,
there's
a
higher
chance
that
that
code
will
contain
a
bug.
Cyclomatic
complexity
is
an
excellent
example.
If
that
goes
up,
the
code
is
harder
to
understand,
so
it
is
more
likely
to
contain
a
bug
and
because
we
collect
so
much
information
about
our
code,
we
have
git
repositories
or
subversion
repositories
and
we
have
Bugzilla,
etc.
B
We
have
all
the
label
data
that
allows
us
to
do
a
correlation
model
between
these
two
things,
the
particular
height
of
a
metric
in
the
history
of
the
project,
and
whether
a
bug
occurred
in
that
bit
of
code
for
this
particular
team
intuitively.
If
a
team
quite
regularly
has
bugs
in
class
high
cyclomatic
complexity,
it's
likely
to
happen
again.
So
that
is
the
model
there,
that
is
the
research
and
how
you
create
these
regression
models.
That
is
the
current
active
research.
The
bit
in
the
middle
was
the
first
research
contribution.
B
So
we
had
the
first
bit
of
analysis
already
in
place
that
got
handed
over
to
our
researchers
for
these
regression
models
speeding
things
up,
but
it
was
also
already
handed
over
to
our
development
teams
to
experiment
with.
So
not
three
years
three
months
and
we
got
feedback
from
the
development
team
and
the
researches
and
I'll
show
to
you
what
this
tool
currently
looks
like
Alex.
If
I
could
use
you
as
a
microphone
stand
for
a
sec.
B
As
you
can
see
here,
this
is
a
repository
as
the
thing
that
collects
all
the
metrics
and
renders
them
out
on
screen,
and
this
allows
us
to
provide
a
URL
of
any
repository.
We
want
to
analyze
with
a
username
and
password
if
we
happen
to
have
one
of
those.
So
let's
start
with
a
fairly
simple
one.
This
is
a
repository
that
contains
a
little
bit
of
gold
and
a
little
bit
of
Java.
B
A
A
B
Perhaps
more.
Interestingly,
things
like
complexity,
how
many
spaces
on
average
I
use
spaces
are
a
good
indicator
of
indentation,
the
more
indentation
you
have
in
more
levels
of
complexity,
and
there
you
go
coupling
is
an
interesting
one
as
well.
Let
me
see
if
I
can
go
down
a
little
bit,
so
the
graph
that
we
have
here
essentially
renders
out
how
often
two
elements
in
a
repository
are
committed
at
the
same
time,
so
for
every
single
element.
Here
we
calculate
a
value.
B
So
in
this
case
we
can
see
that
these
two
elements
are
committed
at
the
same
time,
11%
of
the
time.
So
not
such
a
strong
link.
If
that
number
goes
up,
if
one
has
a
bug
or
is
likely
to
have
a
bug
that
will
aggregate
very
likely
across
as
well,
so
that's
interpreting
and
the
commit
history
and
aggregating
that
into
numbers.
Ownership,
then,
is
an
interesting
one
as
well,
where
we
look
at
for
each
file,
who
is
the
most
prominent
contributor?
B
Who
is
the
owner
of
that
particular
thing,
and
that
will
help
us
to
to
work
out
risk
factors
or
non
risk
factors,
and
these
are
presumably
the
metrics
that
are
the
most
interesting
for
these
kind
of
analyses
where
you
have
things
like
method
length
right
here
or
cyclomatic
complexity
and
the
higher
this
number
is
the
more
likely
the
bugs
will
occur.
So
I.
A
B
Already
in
the
list
of
previously
analyzed
repositories,
which
is
as
good
all
right
so
when
we
run
the
analysis
and
now
it's
affected
us
exactly
the
same
thing
where
its
own
site
or
off
site,
it's
perfectly
fine-
and
you
can
see
here
when
we
look
at
cyclomatic
complexity
in
home
of
watchdog.
There
are
a
couple
of
files
that
might
need
a
bit
of
attention
and
again,
this
is
not
an
indicator
that
there
are
bugs.
This
is
just
a
case
of
it's
more
likely
to
contain
box
than
than
any
other
file.
It.
B
I
think
one
of
the
nice
things
I
want
to
highlight
as
well
is
that
this
is
a
great
example
of
how
this
continuous
updating
really
helps.
We
started
out
with
just
having
support
for
Java,
metrics
and
SVN,
because
SVN
is
what
we
T
used
to
do
and
adding
good
support
and
had
adding
goal.
Metrics
support
was
a
space
of
thinking
about
half
an
hour
before
that
made
it
from
our
own
desktop
implementing
that
to
having
it
in
the
hands
of
our
research
and
our
development
teams.
So
it's
that
kind
of
speed
of
delivery.
A
What
do
you
think
of
this?
The
readme
has
been
updated
twenty-one
times
and
the
main
go
about
19,
which
means
every
time
we're
changing
the
code.
We're
changing
significantly
enough
that
we
should
late
to
read
me
now.
This
could
be
a
tool
a
manager
could
use
the
bash
developers
over
their
head
is
changing
the
code
and
not
updating
the
documentation.
Perhaps
you
could
automate
that
and
track
that
over
time
right,
so
we
go
beyond
static
analysis
and
start
finding
these
relationships
together
and.
B
I
think
another
thing
that's
also
nice
to
see
is
that
there's
a
very
hot
and
fast
fall-off.
So
you
have
high
number
of
revisions
on
the
main
file,
which
is
your
domain
controller.
That
is
perfectly
acceptable.
All
the
others
are
fairly
nicely
isolated.
They
don't
change
very
much
because
they
already
do
what
they
need
to
do
and
they're
absolutely
fine
and
so
yeah
that
this
pretty
much
is
a
good
example
of
how
this
changed.
A
A
It's
really
really
well
done,
say:
I,
don't
know,
welcome.
Your
experience
is
like
with
surplus,
but
there's.
Actually
this
landscape
that's
been
put
together
because
there's
so
many
service
projects
they
it
got
out
of
hand
we
had
to
build
our
own
landscape.
There's
also
a
dichotomy
here
that
on
the
left-hand
side,
we
have
these
proprietary
frameworks
that
are
very
much
locked
in.
It
may
be
okay
for
you,
if
you're
an
Amazon
customer,
but
you
don't
have
much
control
on
the
other
side
of
the
screen.
Things
can
be
a
bit
harder.
A
You
have
to
set
stuff
up
yourself,
but
you
get
full
control
now.
If
we
look
into
this
a
bit
more
a
surplus,
1.0
framework
or
product,
let's
say:
if
you're
an
Amazon
customer
you're
going
to
need
to
use
lundi,
there's
just
no
other
tool
for
you.
If
you
want
to
integrate
with
the
billing
and
the
support
agreement,
you've
got
set
up,
lamda
has
its
own
set
of
limitations
and
characteristics
and
availability
regions,
its
own
timeout
I.
A
Think
we
found
that
some
people
have
heard
that
you
can
run
for
15
minutes
if
you're
using
an
event,
but
through
the
API
gateway.
Last
time
we
looked,
it
was
30
seconds
might
be
a
bit
restrictive
for
you.
The
zip
file
is
very
specific,
and
so
is
the
signature
in
a
service
working
group
of
the
CNC
F.
We
tried
to
see
if
we
could
consolidate
around
the
function,
signature
and
it
turned
out.
It
was
just
too
hard.
A
We
ended
up
creating
a
project
called
cloud
events
now,
as
a
GCP
customer
you've
got
a
completely
different
set
of
CLI
tools
at
different
I
am
different
constraints,
different
maximum
and
minimum
availability,
and
then
we
get
to
the
enterprise
where
use
comes
into
the
picture
and
he's
got
micro
services
as
well.
Now
we
know
that
we,
we
can't
just
rewrite
everything
from
scratch.
We
need
to
lift
and
shift
so
it
leaves
a
big
question
mark
for
us
service,
1.0
and
I
want
to
introduce
you
to
this
concept
of
service
2.0.
A
Please
feel
free
to
take
a
picture
of
this
I.
Think
it's
going
to
be
significant.
The
idea
is,
we
have
a
much
simpler
stack
where
it's
not
just
functions.
Micro
services
are
fair
game,
docker
is
a
packaging
format
and
we
just
exposed
traffic
on
port
8080
and
that's
all
we
need
to
do.
The
platform
is
kubernetes
and
then,
as
we
know,
kubernetes
runs
almost
on
any
cloud,
even
at
the
edge,
so
I
put
together
service
landscape
2.0
when
we
heard
Oracle
talk
about
big
tent
mentality
in
the
keynote
well.
A
I
believe
that
open
fires,
Kay
native
and
the
projects
from
Asia
are
all
pretty
much
on
the
same
playing
field.
Right
now,
where
we're
targeting
a
docker
image.
There
are
other
projects
that
that
are
in
this
space,
but
they
don't
target
a
docker
image.
First
thing
you
need
is
you
need
a
build
template?
This
takes
your
source
code
and
produces
a
docker
image
at
the
end
of
it.
There's
various
options
available.
You
then
need
somewhere
to
run.
It
just
has
picked
open
fires,
but
a
native
is
an
alternative.
A
That's
coming
out
of
Google
once
you
have
that
you
then
need
a
platform.
Kubernetes
and
OpenShift
are
pretty
much
equivalent
and
on
the
right
hand,
side.
We
have
things
are
interesting,
but
not
necessarily
essential
for
every
customer
we've
got
a
venting.
Cater
is
a
new
project
from
azure
that
allows
you
to
scale
based
upon
the
depth
of
the
queue
kind
of
an
interesting
approach
scale
from
zero.
If
you
use
something
like
a
native
right
now,
we're
looking
at
sort
of
seven
to
nine
seconds
for
a
cold
start
might
be
acceptable.
A
I,
don't
know
your
use
case
with
open
files.
Everything
kubernetes
we're
about
two
to
two
and
a
half
seconds
and
I
hope
that
we
can
get
that
down
as
a
community
as
we
continue
to
work
on
these
problems
now.
The
other
interesting
thing
about
this
is
that
there
was
that
dichotomy
have
managed
a
non
managed.
Well
now
you
can
actually
take
these
docker
images
and
run
them
or
manage
platforms
like
cloud
run,
open
files,
cloud
and
Azure
functions,
and
so
we're
really
getting
the
best
of
both
worlds
in
service
2.0.
A
A
A
A
So
this
is
from
unsplash.
We
can
paste
in
the
body
and
hit
invoke
this
will
spin
round,
and
then
we
get
a
prediction
coming
back,
that
this
is
a
tabby
cat,
and
this
took
us
zero.
This
is
like
50%
sha
took
one
second
now
we
can
also
run
this
asynchronously
in
open
sight
and
open
fires.
We're
running
it
in
the
background.
I
think
we're
here
for
35
minutes
that
correct
okay,
so
I'm
gonna.
What
I'm
gonna
do
now
is
to
show
you
the
template,
store
very
quickly.
A
You
can
find
out
about
open
files
online,
but
you
can't
find
out
so
much
about
the
bt
use
case.
It
will
focus
on
bt.
This
is
a
function
store
if
I
do
facil
I
store
list.
We
get
all
of
the
programming
languages
that
the
community
of
Bill
and
that
we're
supporting,
but
also
other
people
have
submitted
like
rust
and
rusted
very
popular
at
the
moment.
So
if
I
want
to
create
a
new
rust
function,
I
just
do
farcical
eye
template,
store,
Paul
and
type
in
rust.
A
A
A
So
pull
in
all
of
us
under
templates,
and
now
we
can
start
something
up
with
a
baka
file
and
call
it,
for
instance,
dig
like
my
example
and
then
we'll
find
in
a
dick
folder,
a
blocker
file
where
there's
a
process
that
will
run
for
every
invocation.
This
line
here
f
process
and
now
I
can
run
faster.
You
lie
up
and
I'll
have
an
endpoint
within
a
few
seconds.
A
I'll
tell
you
a
bit
about
the
open
phase
architecture
is
we
have
run
over
time
we're
running
out
of
time,
but
a
lot
of
this
information
is
available
online.
You
can
also
follow
through
our
workshop.
The
way
things
work
is:
we've
got
a
command
line
that
you
just
saw
the
UI
that
you
saw,
but
also
a
restful
api.
So
it's
programmatic.
If
you
want
to
use
a
cuban
a
CR
d,
you
can
also
do
that.
A
The
open
paths
gateway
exposes
a
crud
interface
and
invoke
so
when
you
create
a
function,
it
will
go
to
a
component
called
a
provider.
This
is
modular,
we
have
a
kubernetes
one
and
that
will
go
and
create
a
function
turns
out.
We
get
a
service
and
a
deployment
which
will
then
go
up
from
create
our
pod,
so
we
can
invoke
a
function.
Read
metrics
rate,
error
and
duration
are
collected
through
Prometheus,
and
that
allows
us
to
auto
scale
and
also
to
scale
to
zero.
If
needed.
A
This
is
one
of
the
bt
dashboards
and
you
see
all
of
the
data
bubbling
up
from
their
systems.
Now,
if
you,
if
you've
heard
of
open
puzzle
used
it
before,
you
may
know
of
the
watchdog,
that
was
the
original
component
that
I
created.
That
would
allow
us
to
take
a
HTTP
request,
read
it
into
memory
and
then
fork
a
process
and
use
standard
in
standard
out
UNIX
pipes
to
make
that
a
HTTP
server.
Without
that,
having
any
knowledge
of
that
stack,
it
could
be
25
years
old
or
older.
A
The
response
of
that
is
then
Marshall
back
now.
This
is
great
because
any
binary
works,
but
we
created
a
new
version
that
BT
are
using,
and
this
has
a
very
high
throughput.
Instead,
we
fork
your
process,
but
you
need
to
expose
HTTP
in
your
language.
Well,
that
allows
us
to
do
is
have
very,
very
fast
throughput
and
a
standard
shim
that
can
implement
all
of
the
health
checks
and
metrics
that
you
don't
need
to
care
about.
A
A
So
through
this
work,
we've
actually
gains
some
feedback.
One
of
the
ways
we
did
that
is
through
community
briefings,
so
I
would
invite
all
of
the
open
fires.
Users
any
open
fire
users
here
and
as
it
there's
quite
a
few
in
the
room.
Thank
you
for
attending.
So
you
may
have
been
on
one
of
these
zoom
calls
and
it's
great
to
see
where
people
are
at
get
introductions
and
find
out
what
problems
are
working
on
with
bTW.
We
worked
through
a
number
of
pain
points
and
they
were
things
like
we're.
A
Bt
were
putting
huge
load
into
a
function
and
cancelling
it
Midway
and
we'd
never
really
tried
that
it
turned
out.
There
was
a
problem
with
the
way
the
go
net,
HTTP
client
worked
and
we
were
able
to
optimize
that
in
a
couple
of
weeks
and
other
end,
users
benefited
from
it.
Other
ways
that
they've
got
involved
is
by
telling
us
more
about
their
project
goals
and
aims
and
being
able
to
align
where
it
made
sense
and
then
also
working
through
github
issues.
There
was
a
small
swagger
problem,
always
update
your
documentation.
A
B
For
BT,
there
was
a
significant
impact,
if
only
for
the
fact
that
this
is
one
of
the
first
times,
we've
engaged
with
an
open
source
project
in
this
way-
and
it
has
taught
us
a
lot
about
well,
first
of
all,
how
open
class
works
and
how
it
technically
all
fits
together,
but
also
how
you
practice
open
source,
how
you
engage
with
it
as
a
company
and
how
you
can
have
a
mutually
beneficial
relationship
out
of
this.
It
also
forced
us
to
rethink
how
we
deliver
software.
B
We
already
aware
that
our
CI
CD
wasn't
great,
and
only
by
engaging
with
best-in-class
you
workout.
This
is
the
the
road
ahead.
This
has
to
be
our
agenda.
I've
already
mentioned
one
of
the
things
that
actually
came
out
of
this
as
well
is
that
we
redefined
almost
the
role
of
our
citizen
developers
of
our
data.
Scientists
was
an
organizational
change
happening
because
of
engaging
with
an
open-source
project.
B
It
allowed
the
research
to
do
what
they're
good
at
and
still
get
good
software
engineering
practice
out
of
them,
and
even
that
is
still
percolating
down,
because
we
are
now
deliberately
considering
research
software
engineers
as
a
role
that
are
the
in-between.
They
are
specialists
in
data
science,
but
they
also
know
enough
of
software
engineering
to
lead
a
team
of
data
scientists
in
everything
that
they
want
to
learn
so
a
big
impact
on
the
organization.
Thank
you.