►
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
Why Data Scientists Love Kubernetes - Sophie Watson & William Benton, Red Hat
This talk will introduce the workflows and concerns of data scientists and machine learning engineers and demonstrate how to make Kubernetes a powerhouse for intelligent applications. We’ll show how community projects like Kubeflow and radanalytics.io support the entire intelligent application development lifecycle. We’ll cover several key benefits of Kubernetes for a data scientist’s workflow, from experiment design to publishing results. You’ll see how well scale-out data processing frameworks like Apache Spark work in Kubernetes. System operators will learn how Kubernetes can support data science and machine learning workflows. Application developers will learn how Kubernetes can enable intelligent applications and cross-functional collaboration. Data scientists will leave with concrete suggestions for how to use Kubernetes and open-source tools to make their work more productive.
To Learn More: https://sched.co/GrVw
A
So
you
know
everything
there
is
to
know
about
us
since,
like
all
well-prepared
conference
audiences,
you
read
our
BIOS
next
to
the
abstract.
So
let's
talk
about
you,
I
talk
is
titled.
Why
data
scientist
love
kubernetes,
but
we
appreciate
that
there's
a
few
possible
audiences
for
this
talk
so
who
here
is
a
software
developer
and
okay?
What
about
anybody?
Who
manages
infrastructure?
A
A
So
in
order
to
do
that,
we'll
start
by
talking
about
a
data
scientist
workflow.
Typically,
when
you
hear
about
a
new
application
of
artificial
intelligence
for
business,
it's
arisen
because
a
data
scientist
has
bridged
that
gap
between
domain
experts
and
machine
learning
techniques
will
focus
on
how
they
do
and
what
their
workflow
is.
For.
A
The
business
centric
example
of
customer
churn
from
there
we'll
see
the
analogies
between
the
workflows
we
use
to
develop
software
in
containers
and
the
workflows
that
data
scientists
use
to
develop
models
to
make
predictions
from
data
you'll
see
how
kubernetes
is
an
autumn
flip
for
data
scientists
and
we'll
see
that
the
things
that
you
know
about
like
continuous
integration
and
continuous
deployment
can
support
a
data.
Scientists
work
in
the
same
way
that
they
can
support
an
application.
Developers
will
also
look
at
how
qts
provides
the
foundation
for
truly
reproducible
research.
A
So
having
reproducible
research
is
of
key
importance
in
good
science
and
in
any
regulated
industry
and
Cuba
nighties
really
aids.
This
to
begin
we're
going
to
look
at
the
day
in
a
life
of
a
data
scientist
and
we'll
see
how
container
workflows
can
be
translated
into
something
useful
for
them
will
is
going
to
talk
about
how
data
scientists
can
use
kubernetes
without
becoming
Yammer
lovers
or
cube.
Experts
and
he'll
tell
us
about
some
great
communities
that
you
and
your
data
scientists
should
be
aware
of.
If
you
haven't
already
heard
a
lot
about
them
today.
A
This
is
a
common
business
model
in
telecommunications,
media
and
software
among
other
industries
within
such
companies.
It's
the
data
scientists,
one
of
the
data
scientists,
jobs
to
predict
which
customers
will
not
renew
their
contract,
so
the
data
scientist
also
has
to
find
a
way
to
identify
which
engagements
are
most
likely
to
retain
customers
and
find
a
way
to
prioritize
customers,
whilst
considering
that
impact
on
the
business
and
the
past
and
trade-offs
of
any
interventions.
A
So
hopefully,
we've
got
a
good
idea.
What
customer
churn
is,
but
in
order
to
make
progress
with
their
task,
the
data
scientist
has
to
create
a
formal
definition
of
the
problem
they
want
to
solve.
For
us,
this
is
going
to
be
given
a
customer's
behavior
over
the
last
18
months.
What
is
the
likelihood
that
the
customer
leaves
within
the
next
six,
as
well
as
defining
the
problem?
They
also
want
to
quantify
the
amount
of
loss
associated
with
churn
and
tie
back
to
underlying
business
metrics.
A
Not
all
customers
are
equal,
so
for
a
mobile
phone
provider,
a
customer
with
a
fancy
plan
giving
up
six
of
their
10
lines
may
or
may
not
be
worse
than
a
customer
with
two
lines
giving
up
both
of
them.
Similarly,
in
software,
if
you
have
a
customer
who
has
10,000
seats
and
they
give
up
half
of
them-
that's
arguably
worse
than
a
customer
with
1,000
seats
giving
up
all
of
them.
So
we
can't
just
think
about
the
impact
of
row,
numbers
or
percentages.
A
We
need
to
think
about
what's
happening
to
the
business,
so
the
data
science
probably
begins
by
trying
to
visualize
the
data
by
trying
to
find
a
way
to
map
from
the
data
we
have
about
customers
to
points
in
space.
We
can
try
and
find
some
structure.
So
maybe
we
come
across
a
visualization
that
structures
some
structure
like
this
one
here
so
here
we
can
see
that
the
churning
customers
shown
in
reds
cluster
in
that
top
left-hand
corner.
A
Fortunately,
there's
structure
in
this
data
and
we
found
it,
but
we
need
to
find
a
way
to
capture
it
and
encored
it
in
a
nice
useful
way.
This
aspect
of
a
data
scientists
work
is
known
as
feature
engineering,
so
we
need
to
encode
relevant
data
about
the
customer
in
a
numeric
vector
and
we'll
use
that
data
to
predict
customer
churn
in
practice.
Choosing
this
numeric
vector
is
complicated.
A
Furthermore,
there's
not
really
a
1
numeric
summary
fits
all
approach
so
for
each
different
business
problem
you
likely
need
a
different
set
of
numbers,
simply
cause
of
the
day
you
have
access
to
and
going
forward.
At
this
point,
you
probably
already
have
to
be
thinking
about
which
models
or
which
algorithms
you
might
want
to
implement,
because
different
algorithms
take
in
different
feature
vectors.
A
Once
we
have
our
feature
vectors,
we
can
take
some
label
data
that
we
know
about
and
use
it
to
train
a
model
so
by
label
data
I
mean
data
where
we
know
the
outcome.
So,
in
the
customer
churn
case,
this
is
gonna,
be
a
dataset
covering
two
years
of
data.
It'll
contain
some
customers
who
turned
some
who
did
not
and
will
know
which
is
which
we
take,
that
data
and
we
train
a
model
train
and
a
model
is
essentially
running
an
algorithm
to
identify
good
trade-offs
while
summarizing
the
dear.
A
Once
we've
trained
our
model,
we've
got
our
way
to
distinguish
between
customers
who
were
likely
to
churn
and
those
who
are
not
likely
to
so
in
general,
you
can
think
I've
trained
in
a
model
as
allowing
the
model
alone
that
underlying
structures
and
pattern
in
the
data.
We
could
get
perfect
performance
on
a
training
set
simply
by
memorizing
that
training
set,
but
that
wouldn't
do
us
any
good
in
real
life,
a
model
which
simply
memorizes
the
training
set
is
descriptive,
but
not
predictive.
A
If
it
doesn't
learn
those
underlying
patterns,
then
it's
not
going
to
be
able
to
make
good
predictions
when
it
sees
any
new
data,
so
in
practice
to
prevent
the
model
from
spitting
out
what
it's
just
seen
before.
We
use
the
training
and
a
validation
method.
We
take
our
data
that
we
know
the
truth
about
and
we
hold
some
back.
We
train
our
model
on
the
rest
of
the
data
and
from
there
we
can
look
at
how
the
model
performs
on
those
two
data
sets
through
some
error
metric.
A
So
in
this
case
we
have
a
curve
and
the
area
under
the
curve
represents
how
well
the
model
is
performing
the
bigger
the
area
the
better
and
that
dotted
line
represents
the
results
we'd
get
if
we
simply
used
a
point
us
to
estimate
whether
or
not
someone
is
going
to
so.
We've
got
pretty
good
performance
on
both
subsets
of
Thor's
data,
but
you
can
see
that
the
area
under
the
curve
at
the
top
is
better
that's
on
the
training
data.
So
perhaps
we've
overfit
our
data
a
bit
and
we
haven't
truly
generalized
for
for
it.
A
So
we
might
want
to
go
back
to
the
drawing
board
at
this
point
and
try
a
bit
harder
once
your
model
is
built
tuned
and
trained.
You
can
go
ahead
and
put
it
into
production
as
a
service
running
on
kubernetes.
That's
part
of
the
larger
system
or
application,
but
the
data
scientists
can't
wash
the
hands
of
it.
Yet
progress
of
the
model
needs
to
be
tracked
over
times.
Often
data
changes
the
time,
and
so
that
can
make
the
model
poorly
tuned.
Perhaps
you
need
to
retune
the
parameters
through
something
like
a
be
testing.
A
We're
also
going
to
want
to
start
tracking
new
metrics
that
are
related
to
business.
There's
many
cases
where
a
model
which
performs
perfectly
initially
doesn't
really
solve
your
business
problem.
So,
for
example,
say
we
put
a
great
model
into
production
and
are
able
to
recommend
early
customer
interventions
to
prevent
any
churn.
No
customers
turn
now
and
that's
great,
but
actually
your
sales
team
was
so
busy
preventing
customers
from
churning
that
they
didn't
sign
any
new
deals
this
year,
so
you
didn't
meet
your
growth
targets.
A
Similarly,
he
could
get
a
nearly
perfect
model
by
putting
your
top
ten
data
scientists
on
the
problem
for
the
next
few
years,
but
if
they
can't
work
on
anything
else
in
the
next
few
years
is
an
early
perfect
model
really
that
much
better
than
an
early
nearly
perfect
model.
We've
got
to
think
about
things
like
this.
A
A
You
can
define
functions,
run
them
in
line,
see
the
output
immediately
and
you
can
go
ahead
and
change
functions
and
change
things
in
there
and
the
output
updates.
Similarly,
you
can
plot
graphs
in
there,
so
those
graphs
support
in
all
of
the
main
notebook
providers-
notebook,
sorry
I'm,
very
flexible,
but
they
have
a
couple
of
serious
downsides
that
is
Portability
and
reproducibility.
A
Sharing
a
data.
Scientist
notebook
is
like
sharing
a
physical
notebook,
there's
good
stuff
in
there,
but
you've
got
to
do
some
archaeology
to
figure
out
where
it
is
you're,
essentially
getting
an
uncreated
snapshot
of
someone
else's
desk,
and
they
these
notebooks
often
have
dependencies
and
they're
built
in
bespoke
environments,
so
sending
a
notebook
to
a
colleague.
Often
one
of
two
things
will
happen:
either
they
will
get
different
results
or
the
notebook
will
just
crash.
We'll
revisit
this
problem
later
so
hope.
A
The
analogies
between
some
of
the
things
that
a
data
scientist
does
and
some
of
the
things
that
are
contemporary
software
developer
does
are
starting
to
become
clear.
You
may
already
be
thinking
of
ways
that
kubernetes
can
improve
the
data
scientist
workflow,
but
let's
start
make
some
starting
points
and
make
these
connections
a
little
bit
more
concrete.
A
The
first
advantage
brought
by
kubernetes,
is
a
workflow
advantage.
So
say
you
do
all
of
your
work
on
your
personal
computer.
This
is
convenient,
but
it
has
some
limitations.
You
can't
get
access
to
sensitive
data,
you're
limited
by
the
speed
of
your
computer
CPU
and
your
computer
probably
doesn't
have
as
much
storage
as
you'd
like
it
to
so.
You
can't
hold
all
the
data
you
want
to
work
with
at
once.
A
Similarly,
model
training
is
often
very
maths.
Heavy
and
hardware
acceleration
can
really
help,
but
not
every
data.
Scientist
laptop
has
a
GPU
that
machine
learning
workloads
can
exploit
this,
so
both
will
and
I
work
on
Macs
and
their
GPUs
enable
great
multimedia
performance,
but
they
won't
accelerate
models,
ruining
declarative
deployment
configurations
which
specify
which
services
are
connected
to
which,
but
not
a
particular
way
to
set
them
up,
make
it
possible
to
define
the
environment
that
you
want
to
use
in
a
portable
way.
A
So
you
can
take
that
environment
that
you've
got
on
your
laptop
and
transparently
move
it
somewhere
else.
When
you
want
to
scale
up
or
scale
out,
this
figure
shows
how
we've
described
the
pods
we
won
and
the
service
interfaces
they
expose
on
a
laptop.
But
we
can
take
this
and
rerun
it
anywhere.
So
we
can
start
prototyping
a
technique
anywhere
in
the
world
and
then
reproduce
it
inside.
A
Another
advantage
of
using
repeatable
deployments
in
kubernetes
is
scale
up
processing
for
model
training,
sometimes
the
technique
itself
scales
out.
So
there's
frameworks
like
Apache,
spark
and
tensor
flow,
which
support
training
models
across
multiple
cores
by
distributing
the
training
job
and
even
in
cases
where
a
single
training
job
doesn't
scale
out,
we
can
still
benefit
from
parallelism.
A
So
when
we
train
the
model,
we
might
want
to
do
like
the
parameter
sweeping
or
so
on,
and
we
can
scale
these
experiments
out
by
using
a
templated
declarative
configuration
to
run
all
of
our
training
and
evaluation
jobs
in
kubernetes,
and
then
we
can
collect
the
results
as
metrics
in
a
single
place.
A
third
advantage
is
service,
written
for
experiment
design,
so
kubernetes
allows
you
to
route
traffic
to
two
or
more
different
versions
of
the
same
service.
A
It
also
gives
you
a
lovely
failsafe
so
accidentally
putting
a
model
into
production,
which
has
problems
that
you
don't
know
about
until
you
put
it
into.
Production
is
tragically
common.
Of
course,
this
isn't
a
real
problem
in
real
software
development
right.
So
in
software
development
we
use
Green
deployment
to
roll
out
any
new
changes,
and
similarly
we
could
do
that
here.
A
If
we
have
a
new
model
or
a
service
we
want
to
deploy,
then
we
can
use
Cuban,
IPS
and
route
only
say
one
percent
of
the
traffic
to
the
new
model
and
increase
that
as
we're
going
once
the
northern
model
is
working.
Well,
we
talked
earlier
about
the
reproducible
notebook
problem.
Many
data
scientists
still
don't
use
a
lot
of
software
engineering
practices
like
source
control
or
continuous
deployment,
but
this
is
starting
to
change.
A
If
your
data
scientist
is
running
their
notebooks
and
gates,
you
can
use
cuban
at
ease
to
go
from
a
notebook
to
a
notebook
that
we
know
runs
with
all
of
its
dependencies
and
passes
any
relevant
tests.
If
it
passes
those
tests,
we
can
set
it
up
to
automatically
build
a
notebook
image
that
can
then
be
deployed
anywhere
or
even
be
deployed
straight
into
production.
A
B
So
a
lot
of
people
have
been
excited
about
containers
for
data
science
for
a
long
time,
but
a
lot
of
the
material
you
can
find
if
you
search
like
how
can
I
use
containers
for
data
science
starts
with
the
assumption
that
the
only
thing
missing
from
a
data
scientists
life
is
becoming
a
packaging
expert,
so
I
work
for
a
company
that
makes
money,
packaging,
open-source
software
I'm
a
sponsor
on
the
Fedora
project
and
I.
Don't
want
to
be
a
packaging
expert,
almost
all
of
the
time
right.
B
So
you
go
into
one
of
these
and
things
and
since
I
hate
to
get
started
using
containers
for
data
science,
you
need
to
go
through
all
of
these
command
line
invitations.
You
need
to
go
through
all
this
metadata
and
here
are
three
pages
of
a
mole
that
will
get
you
going
and
those
details
are
great
for
people
who
want
to
dive
deep
into
infrastructure
and
a
lot
of
data.
B
Scientists
are
interested
in
really
understanding
how
the
infrastructure
works,
but
not
everyone
does
and
I
think
we
can
have
a
better
story
from
the
kubernetes
community
for
it
at
a
scientist,
if
we
start
with
thinking
about
high
level
tools
that
make
their
lives
easier
and
then
sort
of
using
that
as
motivation
to
learn
more
about
sort
of
the
pages
of
vml
and
command-line
invitations.
So
let's
talk
about
a
totally
easy
way
to
get
started
on
a
problem.
B
So,
if
you
mentioned,
which
is
that
reproducible
notebook
problem,
remember
that
you
want
to
have
a
notebook,
that's
packaged
up
with
all
of
its
dependencies
that
you're
sure
that
it
you
someone
else
will
get
the
same
result
that
you
did.
My
binder
org
is
a
hosted
service
sponsored
by
project
Jupiter.
You
don't
need
to
do
anything
to
use
this
other
than
give
it
a
URL
to
a
git
repository.
You
can
also
run
it
on
Prem.
B
Let's
see
how
it
works
right
now,
so
I'm
going
to
go
to
a
git
repository
I
have
that
has
a
Jupiter
notebook
in
it
and
you
can
see
this
is
just
a
regular
git
repository
with
a
jupiter
notebook
and
our
Python
requirements,
file
I'm,
going
to
copy
the
URL
of
that
and
pass
it
into
binder.
What
binder
is
gonna
do?
B
Is
it's
gonna,
build
a
container
and
serve
that
in
a
kubernetes
cluster
with
a
route
published
to
the
world
so
that
I
can
interact
with
this
and
anyone
else
can
get
their
own
copy
of
this
spun
up
and
run
it
run,
and
we
can
see
I
click
on
my
notebook,
I'm
gonna
run
it
here.
This
is
a
recorded
demo,
so
this
is
gonna,
obviously
be
a
reproducible
notebook
because
we
recorded
it
at
once
and
play
it
back
as
many
times
as
you
want
to
see
it.
B
But
but
you
could
go
into
this
notebook
too
and
get
the
same
result
right
and
we're
just
going
to
go
through
some
examples.
There
and
that's
that's
great
binder-
is
a
really
great
service.
I.
Think
that
a
really
powerful
thing
we
can
do
to
sort
of
go
beyond
individual
services,
though,
is
the
idea
of
source
to
image
workflows
so
you've,
probably
how
many
people
in
here
views
at
a
high
level
source
to
image
builder
tool
to
make
applications,
so
any
people
use
s
to
I
draft
something
else.
B
Yeah
so
I
mean
a
lot
of
people
have
used
these
tools
but
they're,
but
they're
more
general
than
just
doing
applications
right.
So
I'll
talk
about
the
s2i
tool.
These
principles
are
really
more
general
I,
don't
care
what
tool
you
use.
S2I
is
just
the
one
that
I
know,
but
the
idea
is
that
we
have
a
builder
image
that
knows
how
to
turn
a
git
repository
of
something
source
code
or
whatever
may
be
a
model
object,
may
be
a
notebook
into
a
container
image
that
we
can
run
as
a
service
on
kubernetes.
B
In
this
example,
I'm
going
to
use
a
builder
image
that
my
colleague
Graham
developed-
and
this
is
something
that
knows
how
to
take
a
repository
of
notebooks
and
turned
it
into
a
notebook
server
container
image.
So
I
have
a
way
to
sort
of
build
an
image
that
works
exactly
like
that
binder
service
that
we
saw
earlier
and
by
using
this
I,
can
give
this
Builder
image
to
my
data
scientists
and
say
this
is
how
you
package
up
your
notebooks
in
a
container
without
becoming
a
packaging
expert.
B
Let's
see
that
in
action,
so
you
can
use
the
s2i
command-line
tool
to
build
images,
no
matter
what
kubernetes
distribution
you're,
using
it's
just
a
tool
that
will
build
an
image
from
the
Builder
image.
We
tell
it
the
Builder
image
and
the
git
repo
the
advantage
there
is
that
you
can
push
that
image
to
a
container
registry
to
skip
a
step
in
this
demo.
We're
just
going
to
use
a
build
strategy
here
with
openshift
to
sort
of
see
how
we
can
publish
this
notebook,
we're
specifying
an
environment.
B
There
we'll
watch
the
logs
here
now
and
we
can
see
that
we're
gonna
clone
that
git
repository
and
because
we
want
to
have
a
reproducible
environment,
we're
gonna
start
by
downloading
most
of
the
universe.
So
we
can
actually
run
this
Jupiter
notebook
somewhere
else,
as
this
goes.
Let's
think
a
little
bit
about
why
having
a
sort
of
framework,
this
sort
of
source
to
image
workflow
having
a
framework
to
build
services
is
really
flexible.
I
mean
there
are
a
lot
of
things.
I
can
do
to
custom
this
without
becoming
a
packaging
expert.
B
I
mean
how
many,
how
many
of
you
have
taken
a
container
recipe
file
and
modified
it
without
totally
understanding
what
it
does,
even
if
you're
a
packaging
expert.
You
do
this
right.
So
here
we
have
a.
We
have
this
service
running
now,
I'm
gonna
log
in
and
we
see
that
we
get
basically
the
same
results
we
did
on
binder,
but
I
also
could
have
pushed
this
image
to
a
registry
or
done
whatever
I
wanted
with
it
right.
B
So
that's
I
think
that's
a
really
powerful
thing
you
can
do
with
source
to
image
workflows,
but
they're,
really
more
general
than
that.
Any
task
that
involves
generating
a
container
image
from
source
files
can
be
implemented
as
a
source
image
builder.
So
one
of
the
calls
to
action
I
have
for
you
from
this
talk
is
to
be
creative
about
what
kinds
of
things
you
could
put
in
a
source
repository
and
what
kinds
of
things
you
could
do
to
those
to
turn
them
into
kubernetes
services.
B
The
Selden
project
has
a
source
to
image
builder
that
turns
a
serialized
Python
object
into
a
model
service.
We
can
actually
go
further
than
that
and
say
if
I
have
a
notebook
that
knows
how
to
train
a
model.
I
could
turn
that
into
a
model
service
as
well.
So
we'll
see
how
a
builder
would
do
something
more
involved
like
that
I'm
going
to
show
you
a
source
to
image
builder
that
operates
on
a
notebook
that
trains
a
model.
The
kind
of
model
isn't
important.
B
It's
it's
general
enough
to
work
with
just
about
anything,
but
what
it's
going
to
do
is
it's
going
to
load
that
get
repository
containing
the
notebook
that
knows
how
to
train
the
model?
It's
gonna
post
process
the
notebook
to
identify
its
dependencies
post
process,
the
notebook
to
extract
a
Python
script
to
train
the
model,
run
that
script
in
the
environment
that
the
notebook
expects
and
save
that
model
and
then
create
an
image
that
has
the
environment
the
notebook
expects
and
creates
a
rest
endpoint
to
serve
that
model.
B
So
I
hope
you
wrote
that
all
down
we're
gonna
go
through
it
now
and
and
see
what
it
does
so
again.
I'm
gonna
create
create
an
image
using
using
it
a
build
strategy
and
OpenShift.
This
is
basically
just
firing
off
a
source
to
image.
Build,
saying,
use
this
builder
image
that
I
have
on
quay
with
this
repository,
while
we
run
through
the
logs.
While
this
build
runs,
let's
see
what
the
actual
notebook
like
to
see
the
conventions
that
this
builder
is
expecting.
This
is
a
example
model
s2i
notebook.
You
can
visit
that
on
github.
B
B
So
it's
going
to
map
from
a
two-dimensional
vector
in
this
case
to
a
small
integer,
don't
need
to
worry
about
what
it's
doing
and
that's
just
what
we
should
expect
and
then
I
have
two
functions,
one
called
validate,
which
tells
me
that
I've,
given
this
model,
the
right
kind
of
input,
in
this
case
a
two-dimensional
vector
and
one
called
predict
that
actually
makes
the
prediction.
So
we've
looked
at
the
notebook
now,
the
build
is
done
over
here
and
I'm.
B
Gonna
expose
a
route
to
that
and
then
I'm
gonna
go
to
the
insomnia,
rest
client
and
start
interacting
with
this
notebook.
We
can
see
how
I
give
it
a
prediction,
as
a
JSON
array,
we're
just
passing
in
that
vector
and
I'll
get
a
result
back
if
I
give
it
a
different
vector,
I
get
a
different
result.
Now
what
should
happen
if
I
give
it
a
three
dimensional
vector?
B
So
I
get
an
error,
a
descriptive
error,
so
this
is
a
way
that
you
can
use
these
workflows,
not
only
to
publish
work
and
to
enable
collaboration,
but
also
to
sort
of
enforce
the
kinds
of
practices
you
want
to
have
in
these
services
anyway,
if
someone's
rolling
their
own
service,
it's
up
to
them.
If
you
build
a
tool
to
build
a
service
from
something
higher-level,
you
can
really
impose
policies
on
this
in
any
way.
B
So
frameworks
like
source
to
image
make
it
easy
for
developers
to
publish
applications
kubernetes,
but
as
we've
just
seen,
they're
not
just
for
applications.
They
also
let
infrastructure
experts
make
kubernetes
accessible
to
people
who
are
domain
experts,
but
not
infrastructure
experts,
but
all
the
techniques
we've
seen
so
far
have
focused
on
developing
analytic
techniques
on
that
sort
of
first
part
of
the
data
science
workflow.
You
know
when
Sophie
said
they
can't
wash
their
hands
of
it
just
yet.
B
The
point
before
you
would
want
to
wash
your
hands
anyway
right
to
talk
about
the
concerns
that
you
have
actually
taking
this
into
production.
We're
talk
a
little
bit
about
what
it
means
to
put
machine
learning
into
production.
Today,
machine
learning
isn't
always
just
a
separate
workload
that
we
run
as
a
batch
job.
You
know
once
per
quarter
or
once
per
night
use
the
results
to
inform
our
business.
Today
we
often
put
machine
learning
into
production
as
a
component
of
intelligent
applications
which
learned
from
data
to
provide
improved
functionality,
as
people
continue
to
use
them.
B
So
these
applications
need
to
collect
data
from
various
sources
and
transform
it
federated
in
order
to
continuously
train
and
serve
models
to
support
key
application
functionality.
The
machine
learning
is
not
on
the
side.
It's
in
the
heart
of
these
applications
and
these
data
scientists
aren't
going
to
work
in
a
vacuum.
They're
gonna
work
in
a
team
with
data
engineers
who
are
gonna,
publish
those
data
services
that
they're
going
to
use
the
data.
B
Scientists
are
going
to
interact
with
those
services
and
do
their
prototyping
and
identify
patterns
and
develop
techniques
to
train
models,
and,
finally,
application
developers
are
gonna
worry
about
the
second
90%
of
the
problem.
After
we
have
the
first
90%
they're
gonna.
Take
all
of
this
and
put
it
into
production,
they're
gonna
make
it
scalable,
they're
gonna
make
it
accessible
and
they're
gonna
make
it
robust.
B
Some
teams
even
have
machine
learning
engineers
who
work
with
application
developers
and
whose
job
it
is
to
manage
these
machine
learning
pipelines
at
scale,
whether
we're
scaling
out
with
more
cores
or
scaling
up
with
specialized
hardware
and
machine
learning.
Engineers
often
also
develop
tools
to
make
it
easier
to
manage
models
in
production.
B
So
in
the
past,
people
have
thought:
hey,
I've
applications
that
depend
on
machine
learning.
I
need
to
figure
out
some
way
to
coordinate
that
with
my
compute
cluster,
and
this
has
led
to
a
lot
of
clever
workarounds,
because
if
you
have
a
cluster,
that's
really
great
for
just
training
machine
learning
models.
It's
probably
not
what
you
want
to
develop
your
and
deploy
your
applications
against
and
since
we're
at
coop.
Con
I
I
have
a
pretty
good
idea
of
what
people
actually
want
to
be
developing
and
deploying
their
applications
against
yeah.
B
Fortunately
kubernetes
as
we've
seen,
a
lot
is
flexible
enough
to
say:
I
have
the
primitive.
You
know.
Flight
communities
has
the
primitives
to
support
both
application
components
and
serious
compute
and
data
intensive
machine
learning
pipelines,
and
it
makes
it
thus
simpler
to
manage
and
deploy
intelligent
applications.
We
can
actually
take
the
kinds
of
workflows
we've
talked
about
and
make
it
even
simpler.
The
same
pattern
that
we've
seen
making
data
science
development
work
easier
can
also
make
putting
these
things
into
production.
Easier.
B
A
source
to
image
builder
can
take
the
source
code
for
an
application
and
produce
not
just
an
image
deployment
configuration
for
a
scale-out
compute
cluster
that
runs
in
the
same
kubernetes
namespace
as
the
application
that
depends
on
it.
So
we're
gonna
close
by
talking
about
two
community
efforts
behind
projects
you
can
use
in
production
and
the
first
one
has
actually
a
sourced
image
builder
that
does
just
that
read.
Analytics
Co
is
a
community.
B
We
sponsored
at
Red
Hat
for
the
last
two
and
a
half
years,
or
so
it's
targeted
at
application
developers
and
provides
tooling
and
a
downstream
distribution
to
make
it
easy
to
build
intelligent
applications
on
kubernetes
from
prototype
to
production.
There's
a
containerized
Apache
spark
distribution
for
skaila
data
processing
and
compute
a
spark
operator
and
a
spark
management,
interface
and
Jupiter
notebook
images
and
source
damage.
Builders
for
Jupiter.
B
The
second
community
I
want
to
tell
you
about
is
coop
flow.
If
you've
been
in
this
room
all
day,
you've
already
heard
a
lot
about
coop
flow.
If
you
didn't
see,
David
and
Jays
talk
immediately
before
this
one
catch.
The
video
there
have
been
a
lot
of
great
talks
about
coop
flow
at
coop
con,
so
far,
I
will
encourage
you
to
watch
the
videos.
B
It
really
easy
to
deploy
on
kubernetes
and
a
real
strength
is
that
it
makes
it
easy
to
stand
up
these
reproducible
environments
for
machine
learning,
workloads
in
in
any
kubernetes
environment
so
again,
I
hope,
you've
caught
those
talks
and
and
we'll
catch
that
ketchup
on
the
ones
you've
missed.
I'll
call
out
my
friend,
Pete
MacKinnon's
talk
on
the
coop
flow
community
tomorrow
at
2:35,
but
I'd
say
if
you
see
anything
on
the
schedule
that
has
coop
flow
in
it,
it's
going
to
be
worth
watching.
B
So,
let's
close
just
sort
of
by
talking
about
what
we've
covered
today
and
and
where
we're
going
from
here.
So
if
he
introduced
the
data,
science
workflow,
a
pattern
of
techniques
to
identify
and
exploit
patterns-
and
we
saw
analogies
to
contemporary
software
development
workflows-
and
we
hope
you're
already
thinking
about
how
you
can
help
data
scientists
or,
if
you're,
a
data
scientist
how
you
can
use
your
infrastructure
more
effectively
to
to
do
this
workflow.
B
We
saw
some
high
level
tools
based
on
image,
building
pipelines
to
facilitate
making
notebooks
reproducible,
publishing
models
from
notebooks
and
putting
machine
intelligence
into
production
and
I
hope.
You
have
some
ideas
for
building
tools
like
this,
using
your
kubernetes
expertise
to
make
it
accessible
to
data
scientists
as
well.
After
seeing
the
advantages
of
kubernetes
for
data
science
development,
we
looked
at
two
communities
that
make
it
easier
to
put
machine
learning
and
intelligent
applications
into
production.
We
looked
at
the
read
analytics
community
and
at
the
coop
flow
community.
B
So
with
that,
here's
how
you
can
get
in
touch
with
us.
You
know
we'd
love
to
hear
about
your
ideas
for
taking
kubernetes
and
using
it
to
for
machine
learning
and
data
science.
Those
are
our
email
addresses
and
both
github
and
twitter
handles
for
both
of
us
and
that's
the
link
for
the
read
analytics
community
that
we
mentioned
earlier.
B
B
So
the
question
is:
have
we
seen
friction?
You
know
as
a
sort
of
data
science
team
at
a
company
that
does
a
lot
of
stuff
with
containers.
You
know
just
for
context
in
using
containers
for
the
whole
data
science
workflow,
even
though
that
leads
to
sort
of
a
longer
build
cycle,
and
it's
not
as
immediate
as
just
sort
of
setting
up
your
notebook
and
going
from
there
on.
B
You
know:
we've
both
sort
of
done
things
the
easy
way
right
at
times
and
it's
I
think
a
real
advantage
for
me
is
always
the
reproducibility,
even
Portability
and
I
think.
Once
someone
has
been
bitten
by
that
you
know
of
having
a
notebook
that
you
then
have
to
take
extra
steps
to
make
it
reproducible
when
you
put
it
in
a
container,
it's
much
easier
to
sell
start
in
the
container
from
experience
there.
B
So
the
so
the
question
is:
if,
if,
if
a
notebook
depends
on
SPARC,
how
do
we
spin
it
up
and
spin
it
out
so
in
notebooks?
Is
we
should
we
should
talk?
Send
me
an
email.
We
should
talk
about
this
offline
because
notebooks
and
SPARC
is
actually
an
interesting
special
case.
The
application
source
to
image
builder
that
I
mentioned
will
spin
up
the
spark
cluster
and
when
the
application
terminates,
it
will
tear
down
the
spark
cluster,
because
a
notebook
doesn't
have
a
natural
teardown
point.
C
C
B
B
B
B
Okay,
so
I'm
not
you
know,
I'm,
not
gonna,
repeat
the
whole
question,
but
the
question
is
that
with
to
get
started
with
Kubb
flow,
you
have
to
use
interact
with
case
on
it
which,
which
not
everyone
is
yeah.
So
so
that
is
I,
think
I
think
the
thing
is
David
and
Jays
talk.
That
was
immediately
before
this
that
I
that
I've
recommended
already
the
coop
flow
community
has
done
a
lot
to
make
it
easier
to
use
so
that
you
actually
can
spin
up
coop
flow
without
interacting
with
case
on
it.