►
From YouTube: Natural Language Code Search for GitHub Using Kubeflow - Jeremy Lewi, Google & Hamel Husain, GitHub
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
Natural Language Code Search for GitHub Using Kubeflow - Jeremy Lewi, Google & Hamel Husain, GitHub
Turning ML into magical products often requires complex, distributed systems that bring with them a unique, ML specific set of infrastructure problems. A year ago, we started building Kubeflow to leverage Kubernetes to solve these problems. In this talk, we will use the example of a search engine for code using natural language (http://bit.ly/gh-kf-search) to illustrate how Kubeflow and Kubernetes can be used to deploy and manage ML products.
To learn more: https://sched.co/GrVn
A
B
A
So
here's
the
agenda
for
for
today,
so
the
key
point
that
we
want
to
try
to
get
across
today
is
that
going
from
an
idea
for
an
ml
product
into
into
production
takes
way
too
much
time
and
so
with
coop
flow.
We're
trying
to
build
a
platform.
That's
really
going
to
help
you
accelerate
getting
your
ideas
into
production,
and
so
to
tell
that
story.
Hamill's
going
to
talk
about
his
experience
at
github,
working
on
a
natural
language
code
search
engine
and
some
of
the
challenges
that
he
faced.
A
Getting
that
idea
into
production
and
we're
going
to
use
that
as
motivation
to
sort
of
highlight
the
types
of
problems
that
we
were
creating
cube
flow
to
solve,
and
so
we'll
explain
what
we
mean
by
cube
flow.
In
terms
of
you
know,
a
kubernetes
need
a
platform
for
machine
learning
and
then
we're
gonna
do
basically
a
walkthrough
we're
gonna
we're
gonna
go
through
step
by
steps.
The
process
that
Hamill
went
through
to
build
this
natural
language
code
search,
but
we're
gonna.
A
B
Thanks
Jeremy,
so,
like
Jeremy
said,
we
want
to
ground
this
talk
in
coop
flow,
with
a
sort
of
real
life
example,
and
so
one
of
the
things
I'm
working
on
at
github
is
trying
to
create
new
ways
to
search
code
that
are
not
available
today.
So
one
example
of
that
is
being
able
to
search
code
with
natural
language
queries.
B
So
today,
when
you
try
to
search
for
code,
its
keyword
search,
so
you
got,
you
have
to
know
what
the
syntax
is,
that
you're
looking
for
or
you
have
to
try
to
figure
out
what
keyword
might
be
in
the
code.
But
what,
if
you
could
just
search
for
code
using
natural
language
in
a
very
human
way
and
not
really
worry
about
what
the
syntax
is
and
retrieve
the
code
that
you're
looking
for?
That
sounds
like
science
fiction,
but
actually
the
reality
is
probably
a
lot
closer
than
you
think,
and
so
what
we
have
is
we.
B
B
Set
from
a
real
data
product-
and
we
show
that
there
are
some
exciting
results
that
you
can
replicate
yourself
and
then
also
this
is
actually
inside
the
coop
flow
repository
and
one
of
the
canonical
examples
that
they
have
of
how
to
wrestle
a
somewhat
complex
machine
learning
problem
with
coop
flow
I'm
not
going
to
go
in
depth
about
the
model
and
the
data
science
behind
it.
But
there's
a
blog
post
that
you
can
find
and
you
can
reference
on
the
slides
when
you
get
a
chance
later.
B
So
one
of
the
main
I
just
want
to
talk
about
sort
of
some
misperceptions
about
machine
learning,
about
launching
machine
learning,
products,
scaling
machine
learning
products
and
how
that's
relevant
goop
flow.
So
so
you
might
think
so.
It
might
strike
you
that
this
natural
language,
semantic
code
search,
is
very
complex
and
it
might
take
a
long
time
to
build,
which
is
is
true,
but
I
want
to
break
that
down
a
little
bit
so
our
first
prototype
of
natural
language
code
search.
B
Three
months
later,
we
stood
up
a
site
called
experiments
github.com,
where
we
kind
of
serve
this
at
a
larger
scale,
to
the
public
and
sort
of
productionize
this
model
on
a
micro
site.
So
this
is
really
profound.
It
took
two
weeks
to
build
a
model,
and
then,
three
months
later
after
working
really
hard
every
day,
we
launched
it
into
production
on
a
microsite,
not
even
on
github.com
if
it
were
lodged
on
github.com-
and
I
might
take
two
years
with
the
current
workflow
that
we
had.
So
this
is
really
interesting.
B
Why
does
it
take
two
weeks
to
make
the
thing,
and
may
you
know
three
months
to
to
launch
the
thing
that
might
be
surprising,
so
I
want
to
talk
about
that.
So
there's
a
perception
in
the
industry
today
that
data
products,
these
machine
learning
products
are
mostly
about
machine
learning.
That's
where
there's
a
perception
that
you
need
to
pour
all
your
resources
into
machine
learning
that
you
need
tons
of
data
scientists
and
if
you
throw
lots
of
data
scientists
out
the
problem,
then
you
can
launch
these
these
amazing
products.
B
However,
this
is
a
misperception
and
you
see
that
teams
are
often
resourced
in
this
way.
So
I've
worked
at
github
and
Airbnb,
and
several
other
tech
companies
and
I
will
say
that
a
lot
of
times
it's
a
very
it's
a
very
tends
to
be
lopsided.
So
you'll
have
ten
machine
learning
engineers,
and
maybe
one
data
engineer
or
one
software
engineer
paired
with
those
ten
data
scientists
and
that's
really
interesting,
because
the
the
perception
in
people's
minds
is
the
product
is
mostly
about
machine
learning
and
really
all
this
other
stuff.
B
B
You
know
that
is
kind
of
what
a
real
machine
learning
product
is
about,
and
actually
this
this
graphic
is
from
a
paper
that
they
may
have
seen
from
Google
that
hidden
technical
debt
and
machine
learning
systems
which
I
encourage
you
to
read,
and
this
actually
reflects
reality
very
well
and
what
happens
is
there's
often
a
chicken-and-egg
problem.
Where
organizations
hire
a
bunch
of
machine
learning,
experts
or
data
scientists,
and
when
they
land
they
say
hey,
we
actually
need
support
from
engineering
or
DevOps,
and
the
answer
is
that
you
know
you:
can
you
show
some
value?
B
First
often
the
data
scientists
they're
able
to
show
the
value
without
launching
something
so
it's
kind
of
chicken
and
egg
problem.
It's
a
frustration
in
the
industry
and
one
one
really
interesting
point
here
is
there's
a
perception
in
the
industry
that
there's
a
shortage
of
data
scientists
there's
a
lot
of
buzz
about
the
shortage
of
machine
learning
engineers.
A
shortage
of
of
this
skill,
but
I
would
actually
like
to
challenge
you
to
say.
B
If
you
know
what
data
scientists
or,
if
you
know,
machine
learning,
engineer,
ask
them
what
their
biggest
bottleneck
is
and
I
will
guess
that
very
few
people
will
say
we
need
more
data
scientists.
What
you
often
hear
is
any
better
tools,
better
infrastructure,
more
cross-functional
support
and
so
I
would
say
the
shortage.
The
real
demand
for
unlocking
machine
learning
is
all
of
this.
B
Tooling
is
often
all
this
tooling
and
that's
something
that's
not
talked
about
and
if
you're
sitting
in
this
room
and
you're
building
these
skills,
I
think
that
is
really
exciting
and
you'll
see
some
companies
recently
that
have
become
savvy
to
this.
So
uber,
with
Michelangelo
Airbnb,
with
bighead
Facebook
with
Facebook,
learn:
lyft,
learn
creating
this
in-house
machine
learning
infrastructure.
B
A
Thank
you
very
much.
I
think
that
is
a
great
motivator,
so,
like
I
said
before,
you
know
we're
trying
with
kupo
to
build
a
kubernetes
native
platform
for
building
ml
products,
and
the
idea
here
is
to
leverage
containers
in
kubernetes
to
solve
the
same
sorts
of
DevOps
challenges
that
we
see
in
non
ml
products
and
bring
those
those
those
same
solutions
to
data
scientists
and
the
ML
community.
So,
to
give
you
a
concrete
example,
when
I
talk
to
Hamel-
and
we
started
this
discussion
about
this
collaboration,
I
asked
him,
you
know
how.
A
How
are
you
doing
your
training?
Where
are
you
running
your
models
and
he
told
me
what
he
was
doing
was
he
was
spitting
up
VMs
on
the
cloud,
and
so
in
this
regard
he
was
actually
you
know
ahead
of
where
we
see
most
data
scientists,
because
most
data
scientists
tell
us
that
they're
just
running
either
on
their
little
laptop
or
maybe
like
a
heavy
ba.
A
That's
yes
right,
and
so
this
created
a
lot
of
toil
for
him
in
terms
of
you
know,
managing
these
different
VMs,
and
so
it's
in
particular.
You
know.
I'm
training
models
can
be
a
very
long
running
process.
So
you
know
he
would
spin
up
one
VM,
let
one
model
train
and
then
spin
up
another
VM
SSA
chain
and
spin
up.
You
know
it's
launched
something
else.
Let
that
train
and
then
manually
tear
these
things
up
and
down
right.
A
So
that's
a
lot
of
toil
and
that's
precisely
the
kinds
of
problems
that
we're
solving
with
kubernetes
right,
we're
taking
advantage
of
things
like
our
back
in
namespaces
to
isolate
people,
eight
resources
and
create
secure
environments.
You
know
where
we
were
there's
work
from
like
IBM
and
others
to
create
batch
schedulers
to
make
it
easy
to
provision
resources.
So
we
really
wanted
to
take
advantage
of
kubernetes
to
build
this
machine
learning
platform
and
there's
a
couple
of
reasons.
We
picked
kubernetes
the
first.
A
Hopefully
this
is
not
a
controversial
statement
in
this
conference,
but
you
know
we
think
kubernetes
has
won
so
increasingly
we
either
see
customers
have
either
adopted
kubernetes
or
they're
just
strongly
thinking
about
moving
to
kubernetes
and
it's
mostly
a
question
of
how
to
migrate
their
infrastructure.
The
second
thing
is:
we.
We
increasingly
see
our
customers
asking
for
hybrid
solutions.
They
want
to
be
able
to
run
both
on
Prem
and
in
the
cloud,
and
so
we
can
take
advantage
of
kubernetes
to
deliver
that
because
kubernetes
already
runs
everywhere.
It
runs
on
prem
and
in
the
cloud.
A
So
if
we,
if
we
build
the
platform
on
top
of
kubernetes,
then
we
automatically
create
a
platform
which
is,
which
is
you
know,
hybrid
and
runs
everywhere.
The
second
thing
is,
you
know,
as
Hamill
mentioned
a
lot
of
times
at
organizations,
we
see
this
split
between
the
data,
scientists
teams
and
the
infrastructure
teams,
and
they
have
sort
of
different
nomenclature
and
different
stats.
A
So
we
think
that
if
we
can
get
everybody
sort
of
using
kubernetes
and
sort
of
get
that
in
kubernetes
to
be
a
natural
choice
for
data
scientists
and
ml
engineers,
we
think
we
can
make
it
a
lot
easier
to
move
infrastructure
from
the
idea
or
experimentation
phase
into
production,
because
you
won't
have
to
rewrite
or
we
do
a
lot
of
your
infrastructure
all
be
already
be
there
and
then
finally,
the
last
piece
I
just
want
to
mention
you
know:
coop
flow
is
entirely
open.
So,
there's
a
couple
reasons
for
doing
that.
A
First,
we
increasingly
seeing
customers
asking
for
solutions
that
don't
provide
lock-in.
They
care
a
lot
about
that.
The
second
thing
is:
we've
seen
from
the
kubernetes
community
that
building
an
open-source
ecosystem
is
really
a
great
way
to
build
a
complex
platform,
and
so
we
really
wanted
to
try
to
build
a
community,
and
you
leverage
that
to
build
the
platform
rather
than
trying
to
build
it
all
ourselves.
A
So
the
first
thing
that
we're
really
trying
to
do
with
coop
flow
is:
we
want
to
provide
components
for
every
stage
of
ml
life's
ml
development.
We
are
a
long
way
from
there,
but
we
already
have
a
lot
of
components
that
solve
different
problems
in
the
ml
lifecycle.
In
fact,
we
have
so
many
that
I
can't
talk
about
all
of
them
today,
but
I
did
want
to
give
you
examples
for
every
for
various
stages
of
what
what
exists
today.
A
So
the
first
first
step
in
sort
of
the
ml
lifecycle
development
development
lifecycle
is,
you
have
to
do
experimentation
and
data
exploration
right,
and
so
for
that
you
know
our
data
scientists
want
Jupiter.
They
want
notebooks
for
interactive
data
scientist
environments,
so
we've
taken
advantage
of
Jupiter
and
Jupiter
hub
to
run
and
provision
notebooks
on
kubernetes
and
so
they've
done
a
lot
of
great
work
in
the
Jupiter
community
to
run
on
kubernetes
and
we're
just
taking
advantage
of
that.
A
The
next
step
in
development
is
you
actually
have
to
train
your
models
so
for
this,
what
we've
done
is:
we've
started
developing
custom
resources
in
kubernetes,
so
we
have
custom
resources,
for
you
know
tensorflow
and
pi
torch,
and
some
of
the
other
frameworks
as
well,
and
these
custom
resources
make
it
really
easy
to
run
distributed
training
on
kubernetes.
So
this
allows
you
to
train
large
models
on
kubernetes
and
scale
out
horizontally.
A
We
also
provide
catted,
which
is
a
hyper
parameter
tuning
system,
which
makes
it
easy
to
optimize
the
parameters
of
your
model,
and
you
can
take
advantage
of
the
algorithms
built
in
cat
into
cat
Abe
and
define
hyper
parameter
tuning
jobs
declaratively
without
writing
them
in
code.
The
next
step
is,
of
course,
inference
and
so
for
inference.
We
providing
beam,
transforms
for
doing
batch
inference.
So
beam
is
an
etl
framework
similar
to
spark.
A
That's
going
to
make
it
easy
to
scale
out
and
run
batch
inference
on
very
large
data
sets
and
we're
going
to
take
advantage
of
that
in
the
natural
language
code
search
example.
We're
also
working
on
providing
cloud
native
integrations
for
various
model
servers,
so
10
0
serving
is
a
very
popular
model
server
for
the
tensorflow
community.
We
went
ahead
and
added
to
that
Prometheus
integrations.
So
you
can
begin
to
export
your
metrics
like
application.
Metrics
such
as
model
load
times
to
Prometheus.
A
Another
big
problem
in
ml
is
that
you
often
have
complex
workflows
for
training
your
models.
So
maybe
you
have
to
pre-process
some
data
and
then
train
your
model
or
for
deploying
your
model.
Maybe
you
have
to
again
pre-process
the
data
and
then
do
batch
inference,
and
so
we
we
wanted
to
provide
a
solution
for
expressing
these
complex
workflows,
and
so
that's
why
we've
recently
introduced
coop
flow
pipelines
and
then,
finally,
what
we've
seen
is
a
big
problem
is
getting
the
data
to
feed
your
models.
A
So
a
feature
store
is
very
important,
so
gojek
has
been
working
on
a
feature
store
for
their
own
internal
use.
They've
I
think
just
recently
open
sourced
it
and
I
think
they're
going
to
submit
a
proposal
pretty
soon
to
add
that
to
coop
flow,
so
we're
very
excited
about
that
as
well.
So
so
one
of
the
problems
is
it's
not
just
enough
to
have
all
these
different
components.
A
We
really
want
to
organize
these
components
into
a
cohesive
platform,
and
so
that's
why,
in
the
coop
flow
community,
we've
been
spending
a
lot
of
time
on
providing
simple
solutions,
a
one
click
or
one
command
solution
for
deploying
coop
flow
right,
and
so
this
diagram
on
the
right
gives
you
a
little
bit
of
the
product
example
of
the
problem
right.
So
this
is
for
two
paterno
books.
So
when
we
deploy
Jupiter,
we
don't
just
want
to
run
the
jupiter
pods
and
spin
up
the
jupiter
notebooks.
A
We
want
to
provision
the
appropriate
credentials
in
terms
of
our
back
for
isolating
accessing
kubernetes
resources
and
also
service
accounts
for
accessing
cloud
resources
like
object
store,
so
you
can
access
your
data
stores
from
your
notebooks
and
then,
since
it's
a
web
service,
we
have
to
provide
a
good
ingress
story
and
so
that
people
can
access
their
notebooks
from
outside
the
cluster.
So
when
they're
running
on
their
local
laptop,
so
that
means
we
have
to
set
up
ingress
and
think
about
things
like
certificates
and
types
of
security
measures
right.
A
So
those
are
the
types
of
things
we
take
care
of
them.
We
deploy
coop
flow,
and
so
we
have
a
command
line
tool
as
well
as
a
web
app
and
then,
as
I
mentioned
pipelines,
is
one
of
the
newest
additions
to
coop
flow,
and
so
basically,
what
pipelines
does
is
it
allows
you
to
define
complex
ml
workflows
in
Python,
so
it's
very
natural
for
data
scientists
and
ml
engineers.
A
So
we're
just
specifying
the
doctor
image
room
on
a
run
and
the
command
we
want
to
run,
and
then
we
have
some
simple
Python
syntax
that
specifies
the
order
in
which
the
steps
should
be
executed
and
the
only
reason
we
have
to
explicitly
specify
the
order
is
if
the
order
can't
be
implicitly
determined
from
the
data
dependencies.
So
a
lot
of
times
in
ml,
workflows,
there's
data
dependencies,
so
the
output
of
one
step
is
the
input
to
the
next
step.
A
And
if
you
have
such
a
pipeline,
then
pipelines
will
automatically
infer
the
graph
for
you
and
you
don't
have
to
explicitly
construct
the
graph
and
then
we
have
a
UI
that
makes
it
very
easy
to
visualize
all
in
all
your
runs
and
track
all
your
runs,
and
you
can
take
advantage
of
pipelines
to
run
your
pipeline
schedule,
your
pipelines
to
run
regularly.
So
you
can
take
advantage
of
that
to
update
your
models
and
then
under
the
hood.
A
This
is
being
powered
by
Argo,
so
we're
very
grateful
to
the
Argo
community
for
all
the
work
they've
done
there
and
then
the
next
piece.
That's
going
to
be
critical
to
our
to
our
story
for
natural
language
code
surgeons,
we're
going
to
take
advantage
of
Argo
CD,
so
Argo
CD
is
a
continuous
delivery
system
for
kubernetes
and
we're
going
to
take
advantage
of
this
stuff
to
continuously
push
our
latest
model
into
production.
So
the
what
Argo
CD
does.
A
Is
it's
basically
an
agent
that
you
run
on
your
kubernetes
cluster
and
you
point
it
at
a
git
repo,
and
this
is
the
git
repo,
where
you
store
the
manifests
for
all
of
your
kubernetes
resources
that
comprise
your
application
and
what
Argos
CD
will
do
is
it
will
continually
monitor,
what's
actually
deployed
in
your
coop
Flo
cluster
I'm,
sorry
in
your
kubernetes
cluster,
and
if
it
detects
that
what
you
have
deployed
is
out
of
with
what
your?
What's
in
your
manifests,
it
will
update
what
you
have
running
in
production
to
match.
A
What's,
in
the
end,
the
manifests,
so
this
creates
a
very
simple
way
to
begin
automating,
your
your
delivery,
because
now
all
you
have
to
do
is
push
a
commit
that
changes
the
parameters
or
of
your
server
or
whatever,
and
then
our
go.
Cd
will
take
care
of
rolling
that
out.
So
now,
I
wanted
to
come
back
to
the
process
of
how
we
actually
use
coop
flow,
taking
advantage
of
the
example
of
natural
language
code
search.
So
here's
the
schematic
of
the
high-level
process
that
that
Hamel
went
through.
So
he
started
off
by
identifying
a
problem.
A
A
So
we're
going
to
go
through
that
process
now
with
coop
flow
and
a
couple
of
things
to
sort
of
look
out,
for
it
is
the
fact
that
we
have
a
multiple
steps
involved
in
building
the
model
and
then
a
lot
of
these
steps
have
different
resources
that
have
different
resource
requirements
right.
So
it's
a
perfect
problem
for
taking
advantage
of
kubernetes
and
letting
kubernetes
take
advantage
of
take
care
of
resource
management
so
switching
over.
So
this
is
our
click
to
deploy
app,
and
so
this
is
what
we're
building.
A
You
know
cloud
so
in
this
case,
all
you
would
have
to
do
is
specify
the
the
project
where
he
wants
to
deploy
his
infrastructure,
as
well
as
the
name
of
the
deployment
that
he
wants
to
assign
his
deployment
and
then
you
can
click
deploy
and
all
those
resources
would
go
and
get
deployed
after
he
spins
up
coop
flow.
He
can
come
to
what
we
call
our
central
navigation
dashboard
and
from
here
we
can
see
all
the
different
services
we
have
running
in
our
coop
flow
cluster.
A
So
we
have
the
handy
link
to
our
Doc's,
because
those
are
always
helpful,
but
you
can
also
from
here
navigate
to
Jupiter
hubs.
So
we
can
begin
spinning
up
books
to
do
is
model
development.
We
provide
a
convenient
dashboard
for
monitoring
your
tensorflow
jobs.
Cat
tip
is
again
our
hyper
parameter
tuning
system.
It's
grayed
out
here,
because
I
haven't
deployed
it
in
this
particular
instance
and
then
finally,
we
have
a
link
to
our
pipeline's
product.
A
So
if
we
went
to
Jupiter
hub,
this
is
the
spawner
UI,
and
this
is
our
latest
spawner
UI,
which
will
be
available
in
our
next
release.
At
the
end
of
this
month
and
a
huge
thanks
to
a
ripto
for
investing
and
cleaning
up
the
UI
and
making
it
much
prettier
and
so
from
here,
what
what
they
can
do
is
we
provide
a
bunch
of
canned
Jupiter
images,
docker
images
that
have
different
libraries
installed
for
different
versions
of
tensorflow
for
CPU
as
well
as
GPUs.
A
A
And
then
you
can
just
enter
the
URL
of
your
document
here
and
if
you
click
on
advanced,
we
can
scroll
down
and
we
can
see
a
bunch
of
different
options
to
specify
the
resources
we
want
to
give
to
our
notebook
and
so
from
here
we
can
specify
CPU,
RAM
or
GPUs
and
also
again
thanks
to
ripto,
and
our
next
release
will
actually
be
able
to
attach
persistent
volume
claims.
So
you
can
add
volumes
for
either
reading
with
data
or
writing
data
and
from
there
you
can
actually
go
ahead
and
click
spawn.
A
So
the
idea
here
is
we're
trying
to
make
it
super
easy
for
data
scientists
to
get
real,
get
started
running
on
kubernetes
at
the
beginning
of
their
workflow
and
start
taking
advantage
of
it
without
having
to
climb
that
mountain
of
learning
kubernetes
and
installing
the
tool
train
like
Cupido
or
case
Anette
or
anything
else.
So
after
that,
we
can
dump
them
into
a
notebook
and
from
here
they
can
begin
developing
their
notebook
at
their
model
and
doing
their
data
analysis
just
like
they
would
normally.
A
But
one
of
the
things
we
want
to
do
is
we
want
to
give
them
the
abandoned
the
ability
to
take
advantage
of
kubernetes.
So,
as
we
mentioned,
you
know,
Hamill
was
MANET
managing
a
lot
of
VMs
to
run
the
different
parts
of
his
his
workflow.
So
after
he
prototyped
his
initial
model,
he
would
then
want
to
run
some
long-running
job
to
actually
train
that
model
overnight.
So
this
is
a
great
way
opportunity
to
take
advantage
of
kubernetes,
but
one
of
the
barriers
is
to
go
from
a
notebook
to
actually
a
job
runner
in
kubernetes.
A
It's
a
multi-step
process,
so
you
have
to
convert
that
notebook
to
Python
code.
You
then
have
to
build
the
docker
image.
You
then
have
to
build
the
yamo
file
to
actually
launch
that
resource
on
kubernetes.
So
if
you're
a
kubernetes
if
you're
familiar
with
kubernetes,
that
may
not
seem
like
a
whole
lot.
But
if
you're,
a
data
scientist
you
it's
in
you're
new
to
kubernetes,
that's
going
to
trip
you
up
and
that's
going
to
become
a
barrier
so
to
solve
that
we
were
with
our
next
release.
A
A
So
here's
how
this
works
in
our
notebook,
we're
just
gonna
import,
the
faring
library,
it's
a
normal
Python
library
and
then
in
our
next
cell,
we're
basically
going
to
define
a
couple
of
variables
to
configure
the
faring
library
and
the
most
important
one
is
all
we're
just
going
to
specify
the
registry
where
we
want
our
docker
images
to
be
published
down
here.
We
can
basically
define
our
normal
Python
code
for
training
our
model,
so
this
is
the
tensorflow
code
for
training
amnesty.
A
So
this
is
what
this
example
was
a
little
bit
new,
so
we
didn't
have
time
to
update
it
to
use
code
search,
so
it's
using
M
mist,
but
the
only
changes
we've
made
to
this
this
this
code
is
we've
organized
it
into
a
class
and
put
it
into
a
method
name
to
training
and
the
only
way
we
reason
we
did.
That
is
so.
We
have
a
way
of
identifying
which
code
to
actually
invoke
in
the
notebook,
and
then
we
added
an
annotation
to
this
class
that
specifies
how
we
want
to
run
it.
A
So
here
we
just
added
this
annotation
that
specifies
the
number
of
workers
and
the
number
of
parameter
servers.
We
want
to
run
and
then
down
here
we
instantiate
the
class
just
like
we
would
normally,
and
then
we
invoke
the
Train
method
just
like
we
would
normally
if
we
were
running
the
code
inside
our
notebook,
but
because
of
the
fairing
and
the
annotation
we
added
what's
actually
happening
is
under
the
hood.
A
We're
going
to
convert
this
notebook
to
a
Python
file,
build
the
docker
image
and
then
launch
a
kubernetes
resource,
a
tensorflow
distributed
training
job,
which
is
our
custom
resource
on
kubernetes
and
then
down
here,
we're
just
printing
out
the
logs
for
convenience.
So
here
we're
enabling
our
data
scientists
to
get
on
board
with
kubernetes
without
having
to
you
know,
learn
climb
the
mountain
of
learning
kubernetes.
A
So
the
next
step,
for
this
particular
example,
is
we
actually
pulled
up.
So
the
way
this
solution
is
architected,
we
actually
have
to
build
an
index
that
has
the
predictions
for
all
of
the
code
in
github
and
the
reason
we
have
to
build
an
index
is
because,
if
we
tried
to
compute
this
online
at
serving
time,
it
would
take
way
too
long.
So
we
have
to
periodically
build
this
index
and
then
push
this
into
production.
A
So
the
way
we
do
this
is
we're
going
to
build
a
coop
flow
pipeline,
and
this
coop
flow
pipeline
is
going
to
consist
of
three
steps.
The
first
step
is
going
to
basically
be
running
a
data,
Philip
job
or
beam
job.
That's
going
to
compute
the
predictions
for
all
of
the
code
in
github,
so
there's
about
two
hundred
several
hundred
million
files
in
github,
which
is
about
two,
several
terabytes
worth
of
data.
A
So
if
we
didn't
use
an
ETL
framework
to
like
be
more
SPARC
to
scale
out
the
inference,
it
would
take
a
really
long
time.
So
in
this
case
it
would
take
about
three
hundred
and
fifty
CPU
hours.
But
by
taking
advantage
of
an
ETL
framework,
we
can
scale
out
horizontally
and
we
can
run
that
in
about
an
hour
by
by
take
advantage
of
more
machines.
A
And
so
what
we
do
is
we
have
a
a
simple
script
that
we're
gonna
run,
which
is
basically
going
to
create
a
commit
to
our
repository
and
it's
going
to
update
the
command
line,
arguments
of
our
server
to
point
to
the
latest
index
and
one
of
the
problems,
our
DevOps
challenges
is,
you
know,
code
is
constantly
being
uploaded
to
github.
So
if
we
don't
compare
eaat
eclis
recompute
these
this
index
and
deploy
it
into
production,
predictions
are
going
to
get
stale
and
the
quality
is
going
to
go
down.
A
So
here
we
can
take
advantage
of
coop
flow
pipelines
to
easily
schedule
a
periodic
run.
So
if
we
click
through,
if
we
click
through
to
our
experiment
from
here,
we
can
through
the
UI
we
can
click
start
our
recurring
run
so
from
here.
We
basically
just
select
the
pipeline.
We
specify
a
name
and
down
here.
We
can
specify
the
trigger
schedule,
so
we
can
either
specify
it.
A
You
can
run
periodically
or
we
can
run
on
like
a
cron
schedule
and
then,
if
we
go
back
to
the
UI,
we
can
see
all
the
different
runs
that
we
have.
So
it's
running
every
six
hours
and
pushing
out
that
commit
then
to
actually
roll
out
that
commit.
We
rely
on
our
go
CD,
so
this
is
this
is
the
UI
for
our
go
CD,
so
you
can
basically
see
from
here
that
it's
showing
all
the
infrastructure
we
have
deployed,
so
we
have
basically
two
different
servers
and
it's
showing
that
it's
actually
been
synchronized
with.
A
What's
in
the
git
repository
so
down
here,
what
we're
showing
through
the
UI
is
we're
seeing
a
diff
between
what's
actually
deployed
in
for
in
production
and
the
manifest
that's
this
checked
in
to
get
the
git
repository.
So
in
this
case
everything
is
synchronized
and
up-to-date.
So
there's
no
diff,
and
so
that's
how
we
can
continually
push
out
our
our
model
into
production
right.
So
we've
spent
a
lot
of
time
walking
through
a
bunch
of
different
steps.
You
know
and
going
through
a
bunch
of
different
infrastructure.
A
But
what
we
didn't
talk
about
was
you
know
the
model
or
show
any
complicated,
math
or
algorithms
right,
and
that's
because
most
of
the
time
and
energy
ends
up
getting
spent
on
all
the
infrastructure
that
you
have
to
build
to
keep
your
models
up-to-date,
and
so
with
that
I'm
going
to
hand
it
back
to
Hamill.
For
some
some
concluding
remarks.
B
Thanks
Jeremy
I
just
want
to
kind
of
conclude
really
fast
to
leave
enough
time
for
questions,
but
just
want
to
again
repeat
the
point
that-
and
this
is
for
especially
any
folks
from
the
data
science,
industry
or
data
side,
specialty
watching
or
machine
learning
managers.
But
you
know
if,
if
you're
struggling
to
get
value
out
of
machine
learning-
and
you
already
have
a
data
scientist
then
I
would
challenge
you
know.
I
would
argue
that
you
probably
don't
need
another
data
scientists.
B
What
you
probably
need
is
infrastructure,
help,
invest
in
tooling,
and
things
like
that
because
of
the
gap
between
the
perception
and
reality
that
I
discussed
earlier.
This
pyramid
right
here
is
Monica
or
goddess
higher
data
science
hierarchy
of
needs
widely
used
in
data
science
circles.
As
a
talking
point
of
how
there's
a
hierarchy
of
needs-
and
you
know
at
the
bottom
layer
you
have
instrumentation
logging
collecting
data,
then
you
have
you
know,
pipelines,
ETL,
cleaning,
your
data,
and
it's
only
when
you
get
to
the
top
of
the
pyramid.
B
You
know
so
I
would
say
the
firt
the
last
three
layers
of
what
you
would
typically
maybe
consider:
data
science
and
at
the
very
top,
is
AI
deep
learning,
machine
learning
and
it's
it
for
some
reason.
This
the
way
that
people
invest
in
machine
learning,
they
invert
this
pyramid,
which
is
amazing
and
that's
why
I
think
goo
flow
is
a
really
good
tool
that
would
help
Assad.
A
And
just
briefly,
there
was
a
bunch
of
different
people
that
helped
out
with
this
demo
and
putting
everything
together.
We
just
wanted
to
give
them
a
huge.
Thank
you,
then,
there's
a
bunch
of
different
talks
and
booths
for
related
to
cube,
though
so,
if
curiouser
have
time,
definitely
check
them
out.
Thank
you
very
much.
A
A
So
the
question
was:
how
does
fairing
compared
to
tender
for
serving
and
deployment
so
they're
complementary?
So
the
point
of
fairing
is
to
make
it
possible
to
go
from
your
code
being
in
a
docker
image
to
you
know,
sorry
from
being
in
a
notebook
to
a
docker
image,
then
once
you
have
that
docker
image
you
can
deploy
that,
let's
say
with
Selden.