►
From YouTube: Flyte: Cloud Native Machine Learning & Data Processing Platform - Ketan Umare & Haytham AbuelFutuh
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
Flyte: Cloud Native Machine Learning & Data Processing Platform - Ketan Umare & Haytham AbuelFutuh, Lyft
Flyte is the backbone for large-scale Machine Learning and Data Processing (ETL) pipelines at Lyft. It is used across business critical applications ranging from ETA, Pricing, Mapping, Autonomous, etc. At its core is a Kubernetes native workflow engine that executes 10M+ containers per month as part of thousands of workflows. The talk will focus on, - Architecture of Flyte and its specification language to orchestrate compute and manage data flow across disparate systems like Spark, Flink, Tensorflow, Hive, etc. - Deploying highly scalable and fault tolerant Kubernetes Operators - Learnings from operating Flyte across multiple Kubernetes clusters and using other CNCF technologies like gRPC, Envoy, FluentD, Kustomize and Prometheus. - Use-cases where Flyte can be leveraged The talk will conclude with a demo of a machine learning pipeline built using the open source version of Flyte.
https://sched.co/UaYY
A
A
A
Probably
has
you
have
these
kind
of
goals
and
there
will
introduce
flight
itself
in
like,
along
with
the
concepts,
a
brief
overview
of
the
architecture
and
the
various
features
that
it
has
offers
and
the
most
important
thing
after
that
we
will
do
a
demo,
the
brave
soul
here,
Haytham
my
create,
will
do
the
demo
and
it's
gonna
be
a
live
demo.
Hopefully,
if
everything
goes
well
and
we'll
conclude
with
just
like
the
remaining,
we
will
try
to
get
through
the
remaining
slides.
A
If
we
can
so
we
have
a
lot
of
content,
I
I
would
like
if
we
go
through
the
entire
session
and
we
keep
the
questions
to
the
end.
I
promise
you
we
will
hang
out
here
and
the
entire
flight
team
is
your
big
shout
out,
so
they
should
be
hanging
around
and
answering
any
questions
that
you
have
and
we
can
dive
as
much
deeper
as
you
want
after
the
session.
A
Thank
you
so
I
think
this
flight
started
about
in
in
2016
and
of
2016
early
2017
and
I
was
reading
a
product,
machine
learning,
pipelines
team
and
at
that
point
lives.
Infrastructure
was
not
the
best
we
had
on
why
so
he
shot
out
like
services
were
great,
but
anything
that
is
stateful
and
would
run
constantly
for
a
long
time,
but
not
really
work
away.
A
Well,
so
we
hacked
around,
we
did
some
stuff
and
we
got
things
running
and
it
was
fine,
but
usually
when
the
company
is
moving
so
fast,
we
would
you
would
have
to
deliver
new
models
every
quarter,
all
the
time
and
we
train
and
the
biggest
lead
time
usually
versity
was
the
infrastructure
the
infrastructure
would
just
take.
So
much
time
that
many
times
you
would
slip
on
our
deliverables
and
as
a
lead,
that
became
a
big
problem
right,
like
I,
had
to
answer
many
times
a
question.
A
The
other
problem
was-
and
this
is
actually
an
anecdotal
I-
was
just
telling
somebody
here
said
one
of
the
data
scientists
build
a
cool
model
in
my
team
and
he
left
the
company
and
we
just
weren't
able
to
rebuild
that
model,
because
I
think
the
model
one
is
was
on
his
laptop.
It's
not
even
checked
in
anywhere,
and
we
were
like
how
do
we
do
this
again
and
at
that
point
we
resolved
that
this
should
never
happen
right.
A
We
should
have
a
way
to
share
models
between
and
a
good
working
like
a
good
UPS
or
some
sort
of
ML
ops
that
we
call
nowadays
between
machine
learning,
engineers
and
software
engineers
and
the
people
who
manage
the
pipelines
and
the
people
who
write
the
models
many
times
so
overall.
Also.
The
other
thing
that
we
realize
is
that
data
and
machine
learning
are
arbitrarily
separated
today
in
the
world
and
I
and
I
actually
don't
understand
why?
A
Because,
most
of
the
times
to
build
a
machine
learning
model,
you
have
to
have
data,
and
if
your
data
systems
are
not
as
good
as
the
machine
learning
frameworks,
then
you
will
not
be
able
to
build
great
models.
So
we
wanted
to
build
one
platform
that
manages
both
data
and
machine
learning
for
live
and
specifically
from
a
computer
standpoint
at
that
point,
and
so
that's
where
flight
comes
in.
A
But
another
point
that
we
realize
is
that
machine
learning
models
like
it's
very
buzz
buzz
word
e
today
when
we
talk
about
machine
learning
models,
everybody's
like
oh,
actually,
it's
G,
booster,
tensorflow
and
pi
torch.
Those
are
amazing
frameworks
to
write
models
and
they're
very
important
and
they
do
a
great
job.
But
that's
not
it.
You
have
like
a
lot
of
things
that
you
need
to
do
just
to
make
the
models
work
in
production
like
they
need
to
be
repeatable.
They
need
to
be
run
durably.
You
need
to
store
the
data.
A
There
needs
to
be
some
audit.
That
needs
to
happen
right
and
and
if
you
just
get
a
model
built
by
a
research
scientist
and
thrown
over
the
wall,
you
incur
a
lot
of
technical
debt,
and
so
we
wanted
to
somehow
reduce
that
debt
and
get
into
a
more
of
the
things
that
we
have
learned
in
software
engineering
across
so
many
years
of
how
to
build,
really
reliable,
scalable
and
and
and
a
proper.
You
know
model
to
actually
deliver
consistent
quality
software.
A
We
have
actually
forgotten
that
when
we
are
doing
machine
learning,
so
we
were
like
how
do
we
get
that
back?
So
at
that
point
we
we
like
about
in
2017
I,
want
to
say
somewhere
around
May.
We
got
our
first
workflow
running
on
flight
and
this
diagram
basically
shows
a
bunch
of
use
cases
that
lift
and
actually,
if
you
look
at
them,
they
are
ranging
in
wide
variety.
It's
not
a
comprehensive
diagram.
A
It's
only
like
a
view,
let's
say
like
it
zoomed
in
into
some
part
of
it,
so
we
do
computations
of
estimated
time
of
arrival,
which
actually
feeds
from
the
map
that
we
generate
and
that
feeds
from
actually
cars
that
are
driving
around
and
capturing
video,
and
then
that
feeds
into
an
AV
simulation
framework
and
it
builds
AV
maps
and,
and
then
all
of
this
gets
somehow
builds
like
PTL
data
and
so
on
right.
It's
lots
and
lots
of
these
things.
A
So
there
are
these
complex
data
transformations
that
are
happening
within
the
company,
and
many
of
them
are
actually
building
machine
learning
models,
but
machine
learning
models
I.
This
is
actually
a
simplification.
Each
of
these
boxes
in
turn
have
as
many
complex
interactions
as
I've
shown
in
in
the
slide,
so
so
to
get
to
build
these
models
actually
many
times.
One
of
the
boxes
just
builds
the
data
set,
while
the
next
box
builds
the
on
it.
So
these
complex
interactions
is
what
define
lift
in
the
back
and
amazingly,
just
a
just
a
point
here.
A
All
of
these
interactions
today
at
lift
are
powered
by
flight
in
some
way
or
the
other.
Like,
for
example,
we
are,
we
have
about
3500
and
more
unique
workflows,
running
on
flight,
more
than
millions
of
containers,
10
million
containers
per
month,
and
and
it's
just
growing
every
day.
So
with
that,
we,
as
we
were
working
with
all
of
these
teams.
A
We
went
through
couple
iterations
of
flight,
literally
like
in
the
last
two
and
a
half
years,
and
now
what
you
see
is
the
actual
second
iteration
of
flight
and
while
working,
we
decided
to
come
up
with
some
tenets
of
what
flight
wants
to
be
and
in
those
tenets
like
two
of
the
most
important
ones.
That
we
want
to
focus
on
is
that
everybody
wants
orchestration
of
ml
and
data
pipelines.
A
So
that
needs
to
be
done
really
really
well
and
the
second
one
is
we
wanted
to
make
it
really
easy
to
collaborate,
reuse
and
and
perform
ml
ops,
and
that's
how
we
come
to
flight.
So
what
what
does?
What
are
our
goals?
We'll
fly?
It
like?
We
wanted
flight
to
be
a
hosted,
scalable
and
a
serverless
orchestration
platform,
very
bus
worthy
and
we'll
talk
about
what
sort
of
alessio
really
means
we
wanted
it
to
be.
The
fabric
that
connects
multiple
compute
frameworks,
there
are
lots
of
compute
frameworks
out
there
would
that
do
a
fantastic
job.
A
Many
cases
hives,
great
for
doing
queries
me
and
the
other
case.
It's
marks
great
for
doing
data
processing
in
memory
or
in
other
cases
you
probably
don't
want
to
use
either.
You
want
to
run
like
a
distributed
tensor
for
computation,
and
then
we
also
wanted
it
to
be
extensible
observable.
Both
of
these
things
are
because
we
learned
over
a
period
like
observability
is
just
so
that
you
can
keep
it
running
all
the
time.
Keep
the
lights
on
and
extensibility
is
because,
yes
to
tomorrow,
something
new
comes
about.
A
You
want
to
quickly
adapt
to
it
and
let
the
company
evolve
and
use
that
as
soon
as
possible,
but
we
also
did
not
want
to
reinvent
the
wheel.
So
if
there
is
something
out
there,
that
is
great
and
amazing.
Let's
integrate
that
into
the
let's
make
that
easy,
and
while
doing
all
of
this
remember
we
last
the
model
once
when
the
engineer
left
the
company.
We
didn't
want
that
to
happen
again,
so
it
should
be
auditable,
repeatable
and
and
secure
so
to
in
to
continue
with
the
introduction.
A
We
have
to
first
understand
a
couple
concepts
in
flight.
The
first
concept
is
a
task.
A
task
is
the
smallest
or
the
most
indivisible
part
of
the
system.
It's
it's
an
atomic
unit
of
execution,
essentially
from
our
point
of
view.
In
the
simplest
case,
it
could
be
a
container
in
the
most
complex
case
it
could
be
a
distributed
sparc
execution,
so
it's
an
entire
cluster
with
the
execution
and
with
the
driver
and
the
executors
or
it
could
also
be
a
query.
A
That's
running
on
a
remote
hosted,
yarn
cluster
and
one
of
the
defining
characteristics
of
a
task
is
the
interface.
A
task
is
like
a
function,
a
pure
function
in
many
cases,
which
takes
in
a
bunch
of
input,
data,
transforms
it
and
produces
an
output
and
and
and
having
having
a
strongly
typed
interface
gives
you
lots
of
advantages,
as
we
will
see
in
the
future,
but
on
the
right
hand,
side
I'm
shown
couple
examples.
A
One
on
the
right
shows
like
it's
a
spark
task,
and
it's
showing
how
this
is
our
Python
SDK
we
saw
flight
comes
with
a
Python
flight
kit
modeled,
so
that
you
can
easily
write,
workflows
and
and
task
definitions.
So
on
the
right
one
of
the
first
one
is
a
spark
task.
It
has
a
spark
configuration,
that's
how
the
users
say
that
I
want
10
spark
executors
or
excise
driver,
and
it
automatically
creates
a
cluster
and
runs
it
automatically,
and
the
second
example
is
running
an
arbitrary
container.
A
It
could,
which
could
be
an
arbitrary
command
which
has
a
bunch
of
data
as
input
and
produces
some
output.
Once
you
have
these
tasks,
you
can
string
them
along
together
into
a
dag,
a
directed
acyclic
graph,
and
we
call
them
as
workflows.
Workflows
are
also
strongly
typed.
They
have
an
interface,
they
have
inputs,
they
produce
outputs,
but
they
are
purely
in
specification.
Tasks
are
in
specification
with
a
container,
but
workflows
are
also
purely
in
specification,
and
both
of
these
are
specified
using
photographs
and
we'll
go
into
more
details
in
when
we
demo
this.
A
They
are
versioned
explicitly
and
they
are.
They
are
decorated
using
photo
buffs
one
of
the
other
interesting
things.
If
you
are
aware
of
many
other
workflow
frameworks,
as
the
scheduling
is
very
coupled
to
the
actual
workflow
in
flight,
they
are
disparate
entities,
a
workflow
is
created
and
it's
it's
recorded
and
stored
in
the
inventory
system.
A
A
A
A
You
only
worry
about
the
business
logic
and
you
write
the
code
and
you
version
it
and
it
runs,
but
to
make
it
truly
server
less
it
needs
to
be
multi
tenant
and
the
multi-tenancy
should
not
be
obvious
to
the
user.
So,
for
example,
what
that
means
is
I
go
and
I'm
running
this
huge
workload.
Somebody
else
comes
along
and
runs
this
hit
big
workload.
He
should
not
get
affected
by
this
one
person
and
that
so
that
was
a
big
problem.
A
Initially,
when
we
started
off
like
noisy,
neighbors
and
I
know,
there's
a
big
sig
in
kubernetes,
4
multi-tenancy,
so
we've
we
have
been
working
on
this
quite
a
bit
with
in-flight.
The
other
portion
is
we
wanted
like
because
we
were
extensible.
We
wanted
to
allow
users
to
use
services
that
are
not
within
kubernetes,
so
like
hosted
services
if
they
are
the
best
at
what
they
do,
but
these
services
oftentimes
have
resource
limits
in
some
cases
and
how
do
you
enforce
this
resource
limit?
So
flight
comes
with
some
resource
pooling
and
a
resource
limiting
system.
A
Okay,
so
to
achieve
this,
it's
the
month,
the
serverless
portion
is
just
powered
by
kubernetes
flight
is
essentially
a
cloud
native
architecture.
It's
simply
divided
into
three
parts:
oh
there's,
a
user
plane
we'll
talk
about
it
in
a
little
bit,
there's
a
control,
plane
and
there's
a
data
plane.
The
data
plane
is
essentially
kubernetes
and
a
bunch
of
operators
that
work
together
to
make
the
magic
happen
and
the
control
plane
is
the
admin
service.
So
it's
a
it's
a
rest.
G
RPC
service,
which,
with
with
the
console
the
console,
is
a
UI
console.
A
We
will
see
in
the
demo
and
the
user
plane.
We
have
a
bunch
of
libraries
because
we
have
a
rest,
G
RPC
service
which
entered
a
bunch
of
clients,
but
we
give
a
first-class
client
for
Python
and
we
also
provide
a
flight
kit,
which
is
the
programming
model,
to
write,
workflows
and
and
and
DAGs
and
tasks
all
of
that
in
in
Python.
A
But
most
of
you
guys,
I've
used.
Look
at
this
architecture
is
a
it's
a
single
kubernetes
cluster
and
it
works
beautifully
up
to
a
scale
but
sorry
I
timer
check,
but
it
works
beautifully
up
to
a
scale,
but
at
lift.
We
quickly
ran
over
that
scale,
so
we
had
to
you,
know
it
and
the
way
because
of
the
architecture,
we
could
easily
split
out
the
data
where
the
data
layer
into
multiple
kubernetes
clusters.
A
The
good
part,
is
that
now
that
flight
is
open-source,
it
comes
out
of
the
like
multi
cluster
support
comes
out
of
the
box
and
also
we
don't
have
much
time
to
go
or
the
architecture
so
I'm
going
to
continue
with
on
talk
more
in
details
afterwards
to
make
it
truly
multi-tenant,
we
have
to
introduce
two
other
concepts.
One
concept
is
projects,
so
projects
are
a
logical
grouping,
primitive
in
the
system.
A
They
allow
you
to
group
for
flows
and
tasks
into
a
project,
and
this
is
like
think
about
it,
like
a
team
or
a
project
that
you're
doing
within
the
company
could
be
an
experiment,
for
example,
and
the
other
concept
is
domains,
domains
are
especially
at
lift.
We
offer
domains
and
either
system
configured.
We
offer
domains
like
services
think
like
development
staging
in
production,
it's
used
to
provide
CI
CD
like
semantics
to
the
workflows
and
we'll
demo,
some
of
it
in
the
demos.
A
The
projects
and
domains
also
help
in
sharing
and
are
used
for
billing
right.
Like
me,
I
think
there
was
a
talk
yesterday
about
infraspinous
entually,
using
interest
friend
to
show
the
the
cost
used
by
one
project
and
so
that
the
owners
of
that
project
know
like
how
much
they're
spending
on
a
daily
basis
on
a
monthly
basis
and
so
on.
A
This
is
sharing
and
it
comes
with
flight.
One
other
concept
that
we
realize
is
the
expect,
once
you
start
composing
these
workflows,
dynamically
or
statically,
as
we
saw
what
happened
during
an
execution
if
one
of
the
downstream
workflows
fail.
So,
let's
take
an
example
on
the
right
like
w1
is
a
work
flow
and
w2
w3,
it's
composed
of
w2
and
w3.
You
execute
w1.
W2
works.
Fine,
but
w1
fails
because
of
w3
is
failure
when
you
now
what
you
go
and
you
fix
the
bug
in
task
H.
A
Do
we?
What
do
we
do
in
this
case?
After
we
fix
the
bug?
Do
we
read
trigger
w1
and
pay
the
cost
of
running
w2?
You
don't
have
to
do
that
with
flight,
because
if
you
have,
we
used
one
a
feature
called
of
cashing
it.
It
generates
a
unique
signature
for
every
execution
and
cashes
all
the
data
as
it's
being
generated.
So
if
you
read
trigger
the
work
flows,
you
will
know
that
hey
I
have
run
this
in
the
past
and
the
data
is
you've
marked
it
as
caching.
A
That
means
there
are
no
side
effects,
so
we
should
be
able
to
just
substitute
the
outputs
and
that's
part
of
the
data
catalog
there's
another
advantage
of
doing
this.
There's
a
causal
dependency
graph
that
we
get
as
the
data
is
generated
through
the
system
and
that's
useful
in
like
artifact
lineage
or
even
model
lineage,
as
we
were
doing.
This
also
I
said
that
we
wanted
to
be
absolutely
keep
the
lights
on
for
us
and
for
the
users.
A
But
if
you
wanted
specific
alerts
in
cases,
let's
say
the
workflow
fails
at
some
point,
so
you
can
just
annotate
your
workflow
saying
that
hey
I
want
to
patch
these
your
duty
notification.
If
this
thing
goes
south,
it
just
sends
you
a
visit
duty
notification
or
an
email
or
a
slack
alert,
and
this
comes
built
in
we
are,
we
are
working
and
it
couldn't
come
soon.
A
A
Then
last
bit
that
I
wanted
to
cover
and
it's
about
almost
time
so
flight
is
extremely
extensible,
and
we
learned
this
over,
like
as
we
as
we
were
working
with
flight.
Our
users
wanted
to
extend
the
capabilities
all
the
time,
so
one
of
the
we
offer
extensibility
across
the
layers.
One
of
the
easiest
way
to
extend
flight
is
to
go
and
write
everything
in
flight,
get
it
it's
opaque,
because
it's
a
container
from
from
flight
point
of
view,
it's
executing
a
container
which
has
flight
get
in
it,
but
you
can
easily
extend
with
Python.
A
It
gives
you
like,
for
example,
on
the
right
hand,
side.
We
show
sensor
tasks
like
an
airflow
or
notebook
tasks,
so
this
notebook
tasks
are
essentially
executing
a
notebook,
as
is
with
specific
inputs
and
producing
output,
without
changing
it,
the
user's
notebook.
There
are
problems
with
this,
so
that
it's
opaque
from
the
actions
point
of
view.
A
So
if
there
are
any
side
effects
that
are
created
by
this
a
container
execution
and
if
the
user
robots,
we
might
cause
a
resource
leak
and
sometimes
in
our
case
also,
we
have
cost
hundreds
of
thousands
of
dollars
of
Lisa's
leaks
just
because
we
couldn't
clean
it
up,
because
if
they
user
created
a
side-effect
so
to
solve
that
problem,
flight
comes
extensible
in
the
back
into.
You
can
actually
go
and
add
new
capabilities
to
the
flight
back-end.
A
For
example,
if
you
have
a
new
cool
operator
like
the
MPI
operator
or
you
have,
somebody
was
here
was
saying:
that's
a
cooperator.
You
can
go
and
make
flight
learn
how
to
run
task
or
MPI,
and
that
becomes
a
platform
level
capabilities
and
we
provide
a
nice
calling
interface
to
go
and
implement
that
it's
hopefully
just
riding
how
to
build
your
CR
D
and
it
works.
A
B
A
B
Wait
all
right
well,
as
Kieran
said
earlier,
I
am
going
to
attempt
to
do
a
live
demo
and
we'll
go
through
the
Wi-Fi
system
that
all
of
you
are
connected
to
through
VPN
all
the
way
to
our
AWS
clusters,
because
you
know
what
can
possibly
go
wrong
and
with
that
I.
Can
you
give
me
a
second
I
need
to
enter
my
password
I
want
to
share
that
on
here.
B
A
B
B
Was
going
to
give
you
try
to
give
you
a
hypothetical
example,
but
then
yesterday
on
our
lift
to
the
conference,
the
driver
make
it
all
real.
So
here's
the
background
the
the
demo
is
is
about
the
hypothetical
example.
Was
you
know
you
are
driving
you're
in
a
lyft
car.
You
get
dropped
off.
You
know,
then,
later
on,
you
realize
you
dropped
your
cellphone
or
your
wallet
or
something
like
that.
But
then
the
driver
yesterday
was
telling
us
is
somebody
from
this
conference.
He
was
dropping
off
and
he
forgot
his
passport.
B
He
made
it
all
real
to
us.
I
want
to
thank
chang
hong
from
the
flight
team
for
authoring
the
demo.
He
had
the
idea
and
he
worked
really
hard
on.
It.
I
hope
it
works,
but
before
I
get
the
demo,
we
are
required
to
say
that
lift
is
not
and
has
never
used
this
in
any
lyft
car.
So
don't
worry
and
yeah.
So
for
the
demo,
Chang
Hong
recorded
a
bunch
of
videos
for
the
backseat
of
his
car.
B
B
B
Maybe
you
know
different
people
will
own
different
parts
of
that
system
and
you
will
maybe
want
to
run
the
pre-processing
as
part
of
like
your
in
just
type
line.
So
every
time
you
get
a
new
video
recorded,
you
will
run
the
pre-processing,
but
not
necessary
the
entire
pipeline,
and
for
that
we
flight
offers
that
the
like
you,
because
flight
workflows
are
composable.
You
can
build
a
workflow
for
each
part.
Here
is
each
block
essentially
in
this
diagram
and
then
build
like
a
bigger
workflow
that
can
orchestrate
the
entire
pipeline,
for
when
you
are
ready
to.
B
You
know,
make
a
big
run.
So
let
me
switch
to
our
favorite
ml
tool
Jupiter
here
and
we
wrote
the
we
choose
to
write
the
word
flow
in
Jupiter,
because
I
hope
most
data
scientists
are
familiar
with
that,
but
we
then
lift
we
do
encourage
people
to
check
in
all
the
whole
of
their
versions
of
like
each
iteration
of
these
workflows.
B
But
even
if
you
don't
there
is
the
the
system
does
keep
the
registered
version
and
immutable.
So
you
cannot
edit
any
versions
if
we
find
you
update
your
workflow
you're,
just
a
new
version.
Always
go
back
in
time
to
like
the
good
version
that
ran
before
and
I'm
gonna
go
through
this
workflow
really
quickly.
Flight
kit
is
our
Python
SDK.
B
If
you
are
using
Python,
you
will
import
all
the
types
from
flight
kit
and
it
is
more
or
less
a
rich
SDK,
a
rich
wrapper
to
our
underlying
protobuf
model
for
the
the
spec
language
where
the
flight
uses.
Then
we
have
the
your
class
that
you
present
the
workflow
and
that
any
workflow
has
basically
three
sections.
It
defines
your
inputs
and
the
inputs
are
strongly
typed.
We
do
support
primitive
types
like
strings
array
of
strings
and
so
on,
but
also
more
complex
types
like
the
generic
type
is
any
decent
serializable
object.
B
We
also
support
schemas
that
are
strongly
typed
schemas.
You
can
read
and
write
data
frames
banded
when
the
data
frames,
and
then
this
next
section
comes.
Is
your
steps,
your
workflow
steps?
This
is
where
you
define.
Will
you
start
calling
tasks
to
you
know
perform
actions
on
the
inputs.
In
this
case
we
are
calling
another
workflow,
the
data
prep
or
flow.
We
pass
on
the
raw
data
and
that
builds
us
a
node
in
the
graph
we'll
see
that
later,
when
we
switch
to
flight
UI.
B
The
next
step
comes
is
the
train
and
the
Train
consumes
the
data
from
some
some
inputs
from
generated
by
the
previous
step,
some
inputs
from
the
workflow
from
the
training
algorithm,
and
then
we
call
this
function
just
to
show
that
you
can
you
call
workflows
or
tasks
exactly
the
same
way.
It
shows
you
that
all
the
basic
units
in
flight
have
consistent
interface,
they're
all
strongly
typed
and
you
can
interact
with
them
exactly
the
same
way.
Last
step
here
is
the
evaluate
workflow
and
then
last.
B
The
last
section
in
the
workflow
is
is
the
outputs,
so
you
define
outputs
again
strongly
typed.
There
is
like
a
lot
of
emphasis
on
having
and
everything
is
typed.
We
always
enforce
the
compatibility
between
tasks
and
between
workflows
when
it
comes
to
types
and
then
you
bind
these
outputs
to
specific
help
us
from
the
prior
steps.
B
Last
thing
I
do
here
in
this
cell
is
register
the
workflow,
and
let's
do
that,
since
the
registration
is
idempotent
and
the
each
spec
is
immutable,
you
can
keep
registering
the
same
exact
goal
flow
over
over
again.
That
does
not
result
in
creating
new
versions,
because
they
all
exactly
are
the
same.
B
Then
in
this
node
I
do
execute
that
workflow
passing
inputs
here
to
the
workflow
and
it
launched
successfully
giving
me
the
unique
identifier
for
this
execution
at
this
point.
This
is
when
the
control
clean
admin
that
kitten
was
talking
about
would
create
a
seer,
the
old
few
CRD
in
the
corresponding
or
the
chosen
kubernetes
cluster,
and
then
things
you
know
really
get
started
to
work.
I
will
run
this
cell
get
back
to
it.
Slightly
later,
I
will
switch
to
the
flight.
B
You
are
to
show
you
the
execution
while
it's
working,
so
this
is
the
home
page
of
flight,
and
it
shows
you
a
list
of
projects.
You
know
split
by
domains
and
the
domains
are
configurable
in
the
system
and
they
give
you
like
similar
to
CIC
the
semantics
for
your
own
workflows.
So
you
can
move
workflows
that
you
are
still
working
on
it
from
development
to
staging
as
they
mature
and
you
get
more
confident
in
their
executions.
B
For
this
demo,
we
registered
two
projects:
q,
con
demo
and
metrics-
just
make
a
mental
note
here
about
the
metric
project
we'll
get
back
to
it
later.
The
workflow
we
launched
is
in
the
demo
projects
so
open
that
up
in
development,
so
opening
any
project
will
give
you
this
list
workflows
that
you
have
a
registered
in
the
project.
You
have
descriptions
and
you
can
search
for
them
and
the
list
of
tasks
the
workflow
we
registered.
Is
this
ok
straight
to
workflow,
and
it
has
been
running.
B
You
can
see.
I
want
that,
one
of
times
just
to
make
sure
that
them
works,
and
you
know,
as
we
were
talking,
we,
it
already
went
through
a
few
steps
here,
and
that
is
because
I
kind
of
cheated
I
leveraged
the
caching
capability
that
flight
offers.
So
all
of
the
tasks
I
have
are
marked
as
cast
so
the
the
very
first
time
I
ran
this
wolf.
B
No,
it
took
some
time
to
run,
but
then
every
subsequent
run
just
takes
a
couple
of
minutes
just
to
go
through
the
existing
tasks
and
discover
that
they
ran
before,
because
the
inputs
are
the
same
and
the
the
task
signature
hasn't
changed,
which
you
know
tells
the
system
that
the
output
should
not
have
changed.
It's
another
thing.
We
we
strongly
believe
in
that
any
code
you
write
in
a
task.
Rule
flow
should
be
repeatable,
you
shouldn't
have
any
randomness
in
any
irregularities
or
any
dependencies
on
like
global
variables
or
things
like
that.
B
Any
thing
that
affects
the
logic
or
the
output
of
a
task
should
be
included
as
an
input
of
a
task.
This,
the
the
prepare
workflow,
ran
these
three
tasks,
but,
as
I
said,
they
are
all
discoverable,
they
haven't
really
done
any
work.
If
we
I
want
to
show
you
the
the
workflow
that
I
ran
originally,
that
actually
did
the
work,
and
you
can
see
it
took
an
hour
to
run
just
to
show
a
few
things
here.
B
This,
for
example.
This
is
a
dynamic
task
and
hidden
whoa.
Sorry
about
the
the
one
of
the
things
that
is
supported
by
flight
is
dynamic
nodes,
so
the
lymph
nodes
lets
you
give
you
some
flexibility
or
ability
to
generate
further
great
apps,
based
on
maybe
based
on
the
inputs
that
it
will
discover
during
execution.
B
Okay,
thank
you.
So
one
of
the
things
the
trend
here
is
this
array
tasks,
a
size,
50
or
so,
and
already
tasks
you
can
think
of
as
like
a
map
function
on
a
bunch
of
inputs
runs
massively
parallel
tasks
we
in
with
in
flight.
We
run
these
on
AWS,
so
great,
just
to
show
that
we
run
multiple
different
types
of
tasks.
B
B
Oh
yeah.
Well,
sorry
that
isn't
oh
yeah
well
yeah!
So
next
we
are
one
of
the
things
we
ran
in
that
workflow.
Is
this
confusion,
matrix
task
that
looked
that
you
know
evaluated
the
model
and
output
the
coefficient
matrix?
You
can
visualize
that
in
interpreter
in
any
other
system,
because
again,
the
outputs
are
described
as
protobufs
all
right.
Okay,
right
link
going
back
here,
just
just
a
quick
recap
of
what
we
covered
in
the
demo.
So
flight
is
using
a
protocol
based
language,
and
that
gives
you
flexibility
of
building
different
kinds
of
SDKs.
B
Different
types
of
you
know,
target
languages
and
very
easily
the
the
interface
tasks
and
workflows
have
interfaces
and
they
are
strongly
typed.
Tasks
are
shareable.
Port
flows
are
shareable
and
discoverable
through
the
you
or
api's.
What
those
are
composable,
wicked,
old
flow
of
other
workflows.
The
tasks
can
be
cast
and
excuse
turns,
are
repeatable.
I
do
not
have
time
to
go
through
the
registration
and
decision
process,
but
they
are
here.
You
can
go
back
to
the
slides,
just
a
quick.
We
have
a
lot
of
extensibility
points.
B
As
we
said,
we
have
some
built-in
plugins
parts
part
this
to
show
CR.
These
are
an
accessibility
point.
We
have
cubile
service
plugins
and
you
can
build
way
more
and
what
is
coming
next.
We
are
yeah.
We
covered
that
a
bit
of
that
earlier,
but
some
of
these
are
in
design
phases
phases
and
we
are
looking
for
your
input
on
what
like
how
to
prioritize
this
or
contributions
here
and
lastly,
I
want
to
thank
everyone
for
attending.
We
know
it's
a
very
long
day,
but
you
made
it
we're
almost
there.