►
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
Panel: Enterprise-grade, On-prem Kubeflow in the Financial Sector - Laura Schornack, JPMorgan Chase; Jeff Fogarty, US Bank; Josh Bottum, Arrikto; & Thea Lamkin, Google
This presentation will explore the journeys of two ML architects from JPMorgan Chase and US Bank, who have deployed Kubeflow into their on-premise environments. These subject matter experts will review their pre-installation checklists, their software architectures, and their operating expectations. They will pinpoint the critical features for an enterprise-grade deployment like authentication and authorization, data management, credentials management, and support for air gapped environments. They will also discuss their collaboration with the Kubeflow code contributors to define requirements and develop new functionality. The talk will include a review of planned Kubeflow enhancements, and a roadmap for those deliveries by code contributors to the Kubeflow On-Prem Special Interest Group (SIG).
https://sched.co/UaYA
A
Great
I
think
we're
gonna
get
started
will
was
telling
me
that
I
have
to
speak
loudly
and
I
come
from
a
family
of
six,
so
I
speak
loudly,
so
this
is
cube
flow
in
the
financial
sector.
We
really
do
appreciate
everybody
coming
and
joining
us
here
today,
along
with
myself,
Josh
bottom
from
a
Rick
toe
I'm,
also,
a
cube
flow
community
product
manager.
I
have
Laura
Shore
knack
from
JPMorgan
Chase
in
jeopardy,
from
US
bank
and
tail
lamp
Lampkin
from
Google.
A
The
cube
flow
summit
that
was
held
last
month
at
Google,
where
all
the
queue
flow
contributors
came
together
and
many
of
the
users
was
to
use
this
summit
analogy
of
climbing
a
mountain,
and
if
all
of
you
are
familiar
with
climbing
a
mountain,
you
can't
just
go
from
the
bottom
to
the
top
right.
You
have
to
usually
come
up
to
Basecamp
one
acclimate
before
you
go
up
to
the
to
the
next
phase
or
the
next
Basecamp,
and
we
use
this
analogy
in
two
different
ways:
both
for
users
and
for
contributors.
A
So
when
I
look
at
the
experience
of
law,
the
users
that
are
in
working
with
queue
flow,
we
typically
see
an
architect
show
up
and
maybe
an
m/l
engineer
and
then
a
data
scientist.
But
then
the
team
gets
a
little
bit
bigger.
Maybe
a
data
engineer
shows
up
and
then
a
product
manager
and
end
user.
Typically,
you
need
kind
of
that
group
of
folks
organized
in
a
cohesive
manner
to
really
start
to
see
the
values
of
cube
flow.
A
So
that's
one
piece
of
getting
to
the
summit
is
not
just
getting
your
architect
or
your
ml
engineers
up
there.
You
need
to
bring
the
best
the
rest
of
your
team.
The
other
part,
is
from
the
contributors.
Do
it
actually
providing
the
pieces
of
cube
flow,
so
cube
flows,
composable,
there's
a
lot
of
different
pieces.
Some
of
them
are
in
different
state
of
maturity,
so
you'll
see
as
we
go
towards
Q
flow,
one
dot
o,
which
is
really
our
eighth
release
of
cube
flow,
which
will
be
in
the
first
quarter
of
next
year.
A
Several
of
the
pieces,
the
notebooks,
the
KF
cuddle,
the
the
operators
for
training,
the
ml
operators.
All
those
are
been
maturing
around
for
quite
some
time,
and
many
of
the
other
pieces
are
starting
to
mature
they
either
in
beta
phase
or
going
towards
one
dot.
Oh
we're
lucky
because
we
have
Michelle
here
who
actually
designed
our
application
review
our
design.
Spec
for
one
dot-
oh
so
that's
been
a
community
effort
to
get
to
a1
dot,
o
definition
for
the
the
pieces
of
cube
flow.
A
So
it's
a
journey
right,
that's
been
over
three
years
in
the
making
and
another
piece
that
I
think
is
interesting
of
having
a
community
is
looking
at
the
early
investors
into
ml
and
into
Q
flow
and
how
algorithmic
innovation
has
changed.
So
many
of
the
businesses
that
are
out
there
this
book,
the
four
it's
one
of
the
things
that
I
got
from
my
daughter's
education
is
SMU.
A
She
gave
it
to
me
and
one
of
her
professors
gave
it
to
her
I,
don't
know
if
she
read
it,
but
it
was
marked
up
a
little
bit,
but
it
was
interesting.
There's
a
lot
of
statistics
in
it.
It's
a
decent
read.
One
of
the
statistics
was
comparing
the
market
cap
per
employee
of
General
Motors
to
Facebook
and
General.
Motors
has
a
very
nice
market
cap,
her
employees
$300,000,
but
Facebook's
almost
40
times
more
at
12
million
dollars
per
employee.
A
There
is
that
machine
learning,
increases
productivity,
increases
margin,
revenue
and
market
cap
right,
and
if
you
look
at
the
the
kind
of
the
early
adopters
behind
Apple
and
Facebook
and
and
Google
in
Amazon,
you'll
see
that
folks,
like
LinkedIn,
that
came
in
and
spoke
to
the
community
in
March
of
last
year,
talking
about
their
cute
flow
experience,
their
visionary
view
of
they
were
building
ml
on
their
own.
They
were
building
a
platform
on
their
own.
Then
they
looked
around
said
hey.
This
is
really
hard.
A
Maybe
I
want
to
join
a
community
and
they
did,
and
they
start
to
see
the
benefits
over
the
year
that
they
that
they
started
from
2017
the
end
of
17
to
18.
They
actually
came
back
to
the
community
said
hey.
This
was
what
our
vision
is,
and
this
is
what
we're
working
from.
If
you
guys
know
how
hard
it
is
to
get
an
ml
engineer,
that's
one
thing.
The
other
thing
is
they
cost
a
lot,
so
doubling
their
productivity
is
a
good
thing.
The
other
is
a
lot
of
you
probably
seen
Spotify
presentation.
A
They
did
this
at
the
cue
flow
7
summit.
I
thought
it
was
very
impressive
that
70%
of
their
models
get
productized
within
12
weeks.
The
fact
that
they
can
do
that
actually
get
them
productized,
but
also
track
it
I
thought
was
impressive
and
then
just
to
circle
back
to
General,
Motors
General
Motors
in
2016
bought
a
self-driving
startup
company
called
cruise
automation.
They
presented
here
for
a
billion
dollars.
I
thought
that
was
a
lot
of
money.
This
year,
cruise
automation
was
valued
at
19
billion
dollars.
A
Ok,
so
I
haven't
met
a
you
know,
an
engineer,
yet
that
doesn't
want
to
be
part
of
a
unicorn
or
a
start-up.
You
know
this
type
of
thing
where
you're,
seeing
this
type
of
value
increase
is
just
remarkable
and
I
read
on
Motley
Fool
that
cruise
automation
might
be
worth
40
billion
dollars.
It's
incredible
because
GM's
total
valuation
is
only
52
billion
dollars.
A
Anyway,
we've
all
heard
that
software
may
be
the
new
oil
I
would
say
that
machine
learning
software
is
the
new
gasoline,
it's
refined
in
a
premium
value
of
oil,
that's
worth
more
money,
so
why
is
cube
flow
coming
to
a
fin
tech
near
you?
Well,
first,
building
and
maintaining
an
ml
stack
is
hard
right.
There's
a
lot
of
documentation
to
that
and
the
growth
of
cube
flow
is
following
other
successful.
A
Let's
call
mountain
climbs
right,
kubernetes
in
tensorflow
and
leveraging
a
community
gives
you
a
good
options
from
support,
but
it
also
allows
you
to
attract
the
best
and
brightest
to
bring
their
work
with
them
in
the
open-source
community.
And
finally,
you
see
the
financial
leaders
already
there
at
the
cube
flow
summit,
sharing
their
stories
right,
whether
it's
Bloomberg
or
Intuit,
or
JP,
Morgan,
Visa
or
aunt.
A
We're
seeing
a
lot
of
good
interaction
from
a
community
standpoint
and
to
that
point
we're
seeing
this
growth,
both
in
the
number
of
PRS
that
are
being
issued,
as
well
as
the
individual
contributors,
but
specifically
from
contributions
from
the
FinTech
area.
You'll
see
Bloomberg
is
doing
a
tremendous
job.
Danceon
has
done
so
many.
A
So
much
on
this
and
building
KF
serving
with
Ellis
from
from
Google,
and
you
also
see
folks
from
NGO
Jack,
who
are
doing
and
contributing
the
feast,
which
is
the
feature
store,
which
is
probably
a
second
level
of
where
more
sophisticated
queue
flow
users
will
be
understanding
how
feast
fits
in
and
then
with
ant.
They
did
a
good
presentation
comparing
running
XG
boost
on
queue,
flow
versus
SPARC.
A
These
type
of
stories,
this
type
of
collaboration
I,
think,
is
dis,
fantastic
in
helping
all
folks
that
use
cube
flow
and
then
what
we're
also
seeing
is
that
these
contribute.
These
contributors
are
actually
following
kind
of
that
same
kubernetes
space,
where
we're
seeing
other
people's
besides
Google
being
more
dominant
now,
in
the
amount
of
contributions
that
are
happening.
This
includes
the
folks
in
the
in
the
financial
sector,
but
implementing
queue
flow
in
the
find
in
the
FinTech
is
not
easy
right,
because
high
security
often
doesn't
equal
rapid,
internet'
innovation.
A
So
if
you're
talking
about
things
about
firewalls
or
proxy
or
authentication,
or
even
authorization,
right,
sandboxing,
air-gap
being
able
to
get
to
certain
data,
sets
being
able
to
move
data
sets
from
on-prem
to
to
the
cloud
very
difficult,
having
rude
access
being
able
to
do
valid,
secure
container
scans
as
well
as
build
them
from
scratch,
or
some
of
the
things
that
we've
heard
and
then.
But
what
we
do
see
is
in
almost
all
sectors,
especially
in
the
the
FinTech
is
that
a
ml
platform
for
self-service
for
the
data
scientist
does
equal.
A
Some
form
of
rapid
innovation
so
being
able
to
deploy,
secure,
notebooks
and
data
sets
with
isolation,
tends
to
be
a
requirement.
Shared
ACL,
protected
versions
of
models
and
data
sets,
so
I
want
to
be
able
to
share
it
across
two
different
clouds
or
share
it
with
various
different
teams
and
then
building
pipelines
without
having
to
know
kubernetes
and
not
having
to
build
amyl
files
or
run
coop
cuddle
commands
and
not
having
to
learn
the
pipeline.
Dsl.
To
be
able
to
build
train
and
deploy
an
ml
pipeline
tends
to
be
things
that
we're
hearing.
A
One
of
the
pieces
is
like
you're,
like
who's
a
Rick
tow
right.
We
know
these
other
three,
but
why
is
erecto
here
so
we're
a
leading
queue
flow
contributor,
so
we
nin
beliar
able
to
to
either
do
feature
development
configuration
or
work
for
with
folks,
because
right
out
of
the
box,
qo
probably
is
not
going
to
work
right
for
you
right
and
we
provide
a
consistent
local
disk
architecture,
local
disk
architecture
that
simplifies
operations.
So
what
is
what
are
some
of
the
things
that
we
provide?
In
that
simplification?
A
We
simplify
if
you're
familiar
with
running
on
local
disk
is
the
first
the
set
up
of
and
then
the
ability
to
have
provisioning
and
then
durability
and
portability.
So,
first
from
setup,
we
help
you
set
up
the
local
node
that
prepares
all
those
local
disks.
We
also
give
you
the
ability
to
create
a
storage
class
that
can
be
used
by
the
container
storage
interface.
A
The
second
part
from
we
provide
dynamic,
local,
local
disk
or
excuse
me
dynamic,
persistent
volume
provisioning,
you
might
say
that's
a
lot
of
words,
but
actually
it's
really
good
for
the
end
user,
because
they
can
get
a
local
did.
They
can
get
a
persistent
volume
very
easily
on
their
own.
It's
dynamically
provisioned
by
the
by
the
end
user.
The
last
two
pieces
be
able
to
have
durability.
Is
the
ability
to
take
a
snapshot
of
your
local
disc
and
put
that
volume
onto
an
object
store
and
have
that
be
content
addressable,
and
what
that
also
provide?
A
You
is
portability,
which
means
that
I
can
pull
up
a
clone
of
that
snapshot
and
run
it
on
any
node
in
any
cluster.
That's
running
our
daemon
set.
So
all
of
these
basic
primitives
really
do
impact
the
ability
to
run
ml
pipelines
and
make
those
workflows
faster
and
just
to
give
you
an
example
of
what
we
did
in
six
months.
This
is
the
tf-x
example.
One
of
them's
called
the
Chicago
taxicab
to
run
this
on-prem
about
a
year
ago,
took
26
steps
right
and
14
of
them
required.
Coupe
cut
all
and
yamo
files.
A
So
basically,
you
had
to
have
a
data
scientist
wait
for
an
ml
engineer
to
do
some
of
the
work
in
order
to
get
that
pipeline
to
build
train
and
deploy
so
in
in
less
than
six
months
in
queue
plus
0.6.
We
cut
that
down
to
12
steps,
0
steps
with
any
type
of
kubernetes
expertise
required.
So
basically
a
data
scientist
could
do
this
on
their
own,
so
this
type
of
productivity
enhancement.
B
Like
all
interesting
stories,
this
started
with
a
team
that
had
a
problem.
What
was
our
problem?
We
noticed
in
our
agile
team
that
our
machine
learning
stories
had
a
much
longer
duration
than
our
other
stories,
like
our
Python
stories
or
our
Java
stories,
and
because
we
were
all
in
the
same
team,
we
could
easily
make
this
comparison.
Why
does
it
take
so
much
longer
to
deliver
a
machine
learning
model
within
the
same
team?
For
the
same?
You
know
for
the
same
application
and
we
realized
it
was
because
we
didn't
have
a
common
toolset.
B
We
didn't
have
the
same
sophistication
of
toolset
in
process
that
we
had
for
Java
for
Python
for
angular.
This
started
a
partnership
between
our
team
and
the
engineering
team,
and
we
went
to
the
engineering
team
and
asked
them
for
a
better
toolset,
and
this.
This
resulted
in
two
really
great
outcomes.
One
are
our
indoor
skydiving
trip
and
two
at
the
end
of
at
the
end
of
our
POC,
we
were
able
to
have
the
same
sort
of
flow
that
we
had
with
with
our
other
tooling.
B
How
did
we
get
here?
How
did
we
get
to
cube
flow?
Why
not
just
stick
with
kubernetes?
We
already
had
cuban
eTI's
kubernetes?
Is
you
know
just
for
orchestration
of
clusters?
It
doesn't
it
doesn't
help
you
with
the
orchestration
of
machine
learning,
it
does
let
you
run
up
a
bunch
of
instances
and
you
can
throw
more
computing
power
at
your
problem,
but
it
doesn't
automatically
know
what
type
of
instances
you
need
and
when
to
shut
them
down,
and
you
do
not
want
to
leave
expensive
GPU
running
when
you
don't
need
it.
B
If
that
hits
your
cost
center,
people
get
upset
so,
and
we
also
didn't
have
any
luck
with
data
sharing
and
in
a
very
easy,
automated
way,
data
transferring
and
security
with
cuber
everything
starts
open,
the
notebooks
start
open
the
models
start
open
network
traffic
is
unencrypted
by
default,
and
this
is
a
problem.
Any
security
problems
are
showstoppers
for
a
FinTech
or
any
environment.
B
That
is,
that
has
confidential
data.
Our
first
attempt
and
installing
cube
flow
was
with
our
internal
cloud.
Our
internal
cloud
had
a
couple
a
couple
issues
when
we
tried
to
bring
cube
flow
on
and
so
with
the
help
of
a
Ric
toe
we
we
stepped
through.
All
these
issues
we
recorded
them
and-
and
we
learned
a
little
bit
each
time.
Our
first
issue
that
we
encountered
was
our
internal
docker
repo
that
we
have,
because
we
need
to
scan
everything
we're
a
bank.
B
We
need
to
make
sure
that
everything
is
approved
before
we
put
it
out
in
production,
is,
is
different
in
its
hierarchy
and
different
in
the
types
of
versions
that
it
has
and
that
that
didn't
work
well
for
our
installs,
our
kubera
Nettie's
implementation
didn't
allow
us
to
run
his
route.
We
could
not
run
cube
flow
as
route
and
the
containers
were
having
by
default.
You
know
issues
with
communicating
between
each
other
and
then
you
know,
and
then
also
to
do
the
install
itself.
We
didn't
have
admin
access
I.
B
So
we
abandon
our
first
attempt
and
started
to
work
with
our
external
cloud.
We
took
an
ami,
an
Amazon
machine
instance
from
Errico,
which
I
was
very
great.
It
started
up
easily
and
it
it
ran,
but
we
were
not
able
to
connect
to
it.
We
kept
trying
to
it
to
connect,
but
we
were
getting
burnt
by
our
internet
proxy
when
we
went
from
internal
on
Prem
developer,
desktops
out
to
our
firewall
and
we
even
tried
sending
you
know
insecure
traffic
as
secure,
but
of
course
that
didn't
work,
and
we
really
wanted
this
to
work.
B
So
we
being
in
the
ami
briefly
and
tried
to
do
a
brand
new,
install
hoping
that
maybe
the
ami
was
the
issue
we
use
system
manager.
We
did
a
brand
new
install
on
a
bare-metal
ec2
and
we
ran
vagrant,
but
we
kept
getting
virtual
airs
over
two
years,
so
our
our
bare
metal
instance
wasn't
really
bare
metal
after
all,
and
you
can't
have
a
virtual
on
top
of
a
virtual.
So
this
this
also
failed
bringing
us
back
to
our
AMI.
B
At
this
point
we
had
to
make
this
work.
How
can
we
connect?
We
know
we
can
connect
from
our
internal
developer
desktops
to
our
our
data
center.
We
can
connect
to
a
simple
Python
server,
so
we,
if
we
generate
the
ami
in
the
same
way
with
those
same
ec2
network
settings,
we
should
be
able
to
connect.
We
changed
our
the
way
we
connect
by
instead
of
using
IP
address
using
the
external
DNS.
B
We
use
certificates,
stop
trying
to
send
insecure
traffic
as
secure,
and
we,
you
know
we
use
port
forwarding
from
the
desktop
as
well
as
you
know,
as
well
as
using
the
token
that
was
generated
and
installed,
and
so
now
we
can
connect.
We
can.
We
can
use
what
we
we
put
out
there
and
there
were
a
lot
of
a
lot
of
really
great
features,
as
Josh
was
talking
about.
B
One
of
the
best
features
is
that
you
can
cut
out
40%
of
your
coding,
any
coding,
that's
not
ml
coding
that
just
deals
with
the
pipeline
can
be
done
with
a
click
of
a
button,
so
you
can
have
your
ml
engineers
not
have
any.
You
not
have
any
realization
of
what's
going
on
in
the
background,
they
don't
have
to
write
pipeline
code
anymore.
B
This
journey
started
with
us
wanting
to
have
a
better
developer
experience,
a
better
CI
CD
experience
to
have
this.
You
have
to
have
versioning,
not
just
versioning
of
data
but
of
your
models
and
of
your
your
snapshots.
When
you
can
do
this,
when
you
can
take
everything
that
you've
done
in
your
dev
environment
version
it
and
then
put
it
back
up
and
put
it
back
up
in
integration
and
put
it
back
up
in
prod,
then
you
have
a
true
CI
see
the
experience,
which
is
what
we
were
looking
for.
C
C
C
So
as
I
mentioned,
that
at
this
self-service
platform
is
a
main
goal
that
but
to
achieve
this
goal,
these
notebook
servers
and
these
pipelines
need
to
be
isolated
so,
but
kubernetes
doesn't
provide
this
out
of
the
box,
but
what
kubernetes
does
provide
is
a
building
blocks
where
you
can
have
a
higher
level
of
abstraction.
So
if
you
see
this
this
slide,
we
have
here
we
have
James
and
Sarah.
C
So
let's
take
a
look
at
the
architecture.
So
again
we
have
this
ingress
that
I
just
mentioned,
and
then
we
have
all
these
namespaces
where
this
process
happened,
you
have
notebooks
and
then
the
pipelines
and
eventually
we'll
have
all
of
these.
The
community
will
have
all
of
these
in
their
own
namespace,
but
from
a
non-prime
perspective.
There's
something
missing
and
that's
storage.
C
C
C
So
how
are
we
going
to
do
it?
Unless
you
keep,
you
don't
keep
the
data,
so
the
the
the
Rick
dos
software
provides.
These
snapshots
provide
versioning.
So
what's
all
the
next
steps
that
I
see,
we
need
to
explore
so
archiving
of
storage,
not
just
code
models,
but
also
the
data.
So
it's
if
you
keep
all
that
all
that
those
snapshots
on
your
production
called
production,
coupe
flow
environment,
that's
kind
of
expensive,
you're
you're,
taking
up
resources
that
could
be
used
for
more
processing.
C
C
C
D
Okay,
hi
I'm
Taylor
am
Ken,
I
am
an
open-source
strategist
at
Google,
and
one
of
the
projects
that
I
work
with
on
is
coop
flow
and
I've
been
kind
of
working
with
the
coop
logic
community.
To
make
sure
that
the
way
we
do
open
development
really
incorporates
all
of
the
user
feedback
that
we're
hearing
on
that
individual
contributors
are
hearing
from
the
clients
they
work
with
on
the
ground.
D
So
Eric
dough
is
really
a
fantastic
example
of
that
working
very
well
and,
having
you
know,
Josh
represented
on
our
product
management
working
group,
is
an
excellent
way
to
get.
You
know:
user
feedback
directly
from
the
FinTech
customers.
He
works
with
to
inform
the
product
development
and
priorities
as
we
build
each
release
and
so
I'm
here,
basically
to
kind
of
use.
D
Some
of
the
user
survey
did
data
that
we
collected
as
a
kind
of
experiment
through
the
product
management
working
group
and
to
facilitate
some
extra
conversations
around
how
we're
seeing
early
people
using
coop
flow
today
and
how
that
tracks,
with
the
FinTech
experiences
that
both
Laura
and
Jeff
represent,
and
so
just
a
little
bit
of
background
on
the
community
surveys.
We've
been
running
and
we
started
this
as
like.
D
So,
as
we
were
looking
the
first
couple
of
surveys
we
found
were
really
informative
and
then,
as
we
got
to
1.0,
we
wanted
to
build
kind
of
the
the
most
deep
survey.
I'm
representing,
like
very
specific
technical
questions
that
we
wanted
to
inform
some
of
the
product
decisions
we
were
making
on
as
we
thought
about.
What's
the
most
important
future
functionality
to
deliver
in
0.7
as
our
beta
for
1.0,
and
here
I'm
excited
to
share
the
results
from
some
of
these
responses.
D
We
got
I
think
we
had
about
75
respondents
to
the
survey
and
a
vast
majority
of
those
were
already
using
Kukla.
So
when
this
slide
represents
a
question
we
had
that
is
kind
of
at
the
forefront
of
our
community
discussions.
Who
really
is
using
coop
flow
from
a
role
perspective
and,
as
you
see,
we
have
like
the
data
science
and
the
ML
engineer
emerging
is
the
two
main
users
of
cupola,
which
presents
an
interesting
quandary
for
us
like.
B
C
Yeah
I
see
the
same,
but
I
think
when
the
as
the
environment,
matures
and
people
get
more
comfortable
using
coop
flow
I
think
some
of
these
might
change.
Some
of
these
might
flop
around.
You
may
see
more
data
scientists
and
also
depends
on
the
industry
too.
So,
but
yeah
I
could,
especially
in
in
my
experience
that
the
ml
engineers
will
be
the
most
ones
using
coop
flow.
C
D
Think
the
super
helpful
so
another
slide
here
represents
one
of
the
questions
that
was
most
interesting
to
us
on
how
people
are
using
coop
low.
So
this
is
a
breakdown
of
how
which
components
were
used
for
survey
respondents
and
what
was
most
notable
for
me
here
was
that
pipelines
no
surprise
to
us
that
pipelines
is
one
of
the
most
popular
components
in
coop
flow.
Also,
we
see
notebooks
being
very
popular
with
you
know,
a
little
bit
of
an
even
spread
across
serving
which
is
pretty
new
and
hyper
parameter.
Tuning
and
metadata.
C
D
Just
a
note
that
I've
I've,
you
know
experienced
in
my
conversations
with
people
a
lot
of
people
see
pipelines
is
one
of
the
access
points
to
many
of
the
other
components
within
coop
flow.
So
it's
not
surprising
that
they're
also
who
must
use
components-
and
this
is
a
great
slide.
We
put
together
a
mishmash
of
four
different
questions
that
I
thought
were
getting
at
the
same
like
set
of
you
know,
usage
patterns
that
we
wanted
to
explore,
and
so
this
is
looking
at
the
infrastructure
and
environments.
People
are
using
coop
flow
within
and
also
like.
D
Are
they
running
coop,
flow-on,
CPUs
or
GPUs?
Are
they
using
ISTE,
oh
and
who
are
these
aim
for
identity
providers?
So,
first
from
from
an
environment
standpoint,
on-premise
cue
flow
is
very
exciting
to
people
I'm
sure
that
Laura
and
Jeff.
You
know
heartily
agree
with
that.
Do
you
think
that
on-premise
acute
flow
delivers
more
value
than
in
other
environments,
for.
B
A
FinTech
definitely
on-prem
is
very
important.
We
have
a
lot
of
security
concerns
and,
as
far
as
GPU
versus
you
know,
as
opposed
to
other
usage,
the
first
question
we're
always
asked
is:
can
I
get
GPU?
Can
this?
Can
this
make
me
go
faster
and
the
second
question
is
around
security.
I
think
the
first.
The
first
question
should
be
around
security,
though
yeah.
C
B
C
D
B
So
security
and
installation
have
been
blockers
for
us
initially
and
and
as
far
as
security,
we
were
finding
that
this
integrates
well
with
what
we
have
and
as
far
as
the
installation
was
to
get
over,
that
initial
hump,
then
I
don't
see
why
we
should
have
any
blockers
after
that,
each
release
gets
better
and
better
right.
Yeah.
C
The
the
deployment
yet
so
I
started
with
was
like
I
mentioned,
I
start
with
0.3,
and
that
was
extremely
painful,
but
it's
expected
because
it's
open
source-
and
it's
really
really
really
new,
so
high
I
accepted
that
it
was
I'm,
an
innovation
team
and
that's
what
we
do.
I
think
the
education
piece
is
pretty
important
to
it.
So
why
do
we?
Why
do
I
want
to
use
coop
flow
from
from
a
business
line
perspective?
Why
do
I
want
to
use
good
flow?
Is
what
I
hear
a
lot.