►
From YouTube: Automating Research Workflows at BlackRock - Matthew Magaldi & Vaibhav Page, BlackRock
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
Automating Research Workflows at BlackRock - Matthew Magaldi & Vaibhav Page, BlackRock
BlackRock’s Data Science Platform enables investors and users across the firm to access a wealth of financial data using research models. Event-based workflows play an integral role in data driven modeling. In this presentation, the speakers will give an overview of BlackRock’s Data Science Platform, talk about the transition from vanilla Kubernetes Cron jobs to more complex sensor-driven research workflows. They will discuss how these workflows powered by Argo Events, an open source event-based dependency manager for Kubernetes, form a core component of the platform. They will also review the challenges of building automated financial models and look forward to the class of problems this framework solves.
To learn more: https://sched.co/GrS4
A
A
For
those
of
you
who
don't
know,
Blackrock
is
the
largest
asset
manager
in
the
world,
and
our
company
is
heavily
invested
in
building
out
technology
for
our
Aladin
platform.
So
Aladdin
is
black.
Rocks
core
operating
system
facilitates
investment
managers,
connection
to
data
information,
people
and
technology.
A
A
The
fact
is-
and
we
all
know
kubernetes
hasn't
been
around
for
30
years.
The
fact
is
that
Blackrock
has
been
investing
in
deriving
value
from
data
science
for
the
better
part
of
our
existence.
In
fact,
you
know:
we've
been
successful,
based
on
the
optimizations
that
we've
applied
to
financial
portfolios
and
to
modeling
find
out
those
financial
portfolios
risk.
So
this
background
story
isn't
going
to
cover
all
that.
It's
going
to
cover
more
around
how
we
brought
kubernetes
into
the
picture
right.
So,
let's
begin
with
why?
A
A
So
we
wanted
a
highly
available
toolset
for
our
researchers,
analysts
and
scientists
to
use
we
wanted
to
give
them
the
compute
and
resources
they
needed
when
they
needed
them,
and
we
wanted
them
to
be
able
to
use
the
tools
they
were
proficient
working
with
and
they
were
used
to
working
with
all
while
building
on
top
of
a
more
powerful
platform
and,
more
most
importantly,
as
a
regulated
financial
firm.
We
needed
to
enforce
you
know
strict
isolation
between
our
users
and
their
information
to
ensure
intellectual
property
and
data
privacy
barriers.
A
So
how
did
we
build
this
platform?
We
started.
You
know
building
the
kubernetes
data
science
platform
around
two
years
ago
and,
as
we've
alluded
to
kubernetes
is
at
the
core
scheduling
you
know,
gives
us
on-demand
resources
and
compute
with
little
downtime
containers
gives
us
configurable
and
isolated
environments.
A
A
So
since
its
first
deployment,
the
data
science
platform
has
gained
traction
across
many
Blackrock
teams,
so
I
won't
go
through
all
the
uses
that
I
have
here,
but
I'm
going
to
touch
on
a
couple
highlights.
For
example,
our
scientific,
active
equity
teams
builds
ESG
or
environmental,
social
and
government
governance
alerts
for
a
fund's
positioning.
So
for
those
of
you
who
don't
know
these,
are
it's
a
score
from
1
to
10
for
a
fund
based
on
you
know
various
criteria
and
rankings
in
a
environmental
say,
you
know
owning
you,
know
tobacco
stocks
or
stuff
like
that.
A
We
also
have
business
operation,
teams,
building
quality
control
processes
for
our
analytics,
and
you
know
to
validate
them
and
ensure
accuracy,
and
you
know
preciseness,
and
we
also
have
our
portfolio
modeling
team.
You
know
modeling
our
complex
financial,
securities
and
instruments
on
this
platform,
so
really,
overall,
the
platform
has
been
transformative
for
three
major
reasons:
first,
it's
really
augmented
the
technology
available
to
these
investment
teams.
A
A
So,
despite
the
successes
of
the
platform
to
date,
you
know
as
developers
of
the
core
infrastructure,
you
know
we've
gotten
a
lot
of
feedback
around
how
to
make
it
better
and
we've
heard
things
like
okay,
you
know
this
is
awesome,
but
I
want
to
build.
You
know
real-time
solution
or
something
that's
automated,
so
I
can
use
the
latest
data
and,
as
soon
as
it
becomes
available
well,
I
just
want
to
automatically
kick
off
this
workflow
I.
Don't
want
to
have
to
do
it.
A
You
know
manually
at
the
end
of
each
financial
quarter,
so
basically
users
wanted
to
be
able
to
like
schedule
things
they
were
doing
in
their
Jupiter
notebooks.
They
didn't
want
to
have
to
manually
kick
off
these
jobs.
They
just
want
it
to
be
like
notified
when
it
was
all
done
so
now.
Timing
is
an
easy
thing
to
to
do
and
most
platforms
support
this
and
kubernetes
even
has
their
core.
You
know
batch
cron
jobs,
but
scheduling
is
actually
really
difficult.
A
We
needed
to
think
you
know
not
just
about
a
simple
time
time
trigger,
or
you
know,
a
simple
cron
expression,
but
we
actually
needed
to
take
into
account
a
lot
of
things
like
file
transfers,
object,
crud
operations,
you
know
streaming
messages
and
complex
holiday
calendars.
So
you
remember
how
I
said
like
time
was
easy
well
in
finance.
It's
not
Thanksgiving,
for
example,
is
a
u.s.
holiday,
but
the
LIBOR
Market,
which
is
basically
a
market
for
between
you,
know,
London
banks
to
exchange
funds.
A
That
market
is
still
open,
so
you
know
and
finance
a
concept
like
accrued
interest
becomes
crucially
important.
So
after
we
kind
of
digested
all
this
feedback,
we
condensed
it
down
into
the
problem
statement
that
you
see
up
here.
You
know
how
do
we
automate
the
scheduling,
manage
the
exceptions
that
always
arise
and
provide
transparency
into
these
complex?
You
know
batch
processes
now.
This
is
definitely
a
lot
to
consider.
A
I
mean
and
exceeds
the
scope
of
even
kind
of
data
science
of
where
we
started,
but
really
when
we
boil
it
down
are
essentially
our
goal
was
to
just
make
it
easy
to
build
and
specify
workflows
that
cross
band,
multiple
teams
and
multiple
domains,
so
I
just
want
to
clarify
for
a
second.
What
a
workflow
is
right,
a
set
of
tasks
that
you
can
put
into
separate.
You
know
isolated
parts
break
it
down.
A
So
you
know
for
the
first
two
weeks
of
starting
on
this
project,
velvet
and
I
started
by
researching
existing
open
source
platforms
that
we
could
leverage
as
a
starting
point
for
kind
of
the
orchestration
and
composing
these
workflows.
And
as
of
the
start
of
this
project,
nearly
at
the
beginning
of
the
year,
we
found
a
number
of
existing
technologies
at
our
disposal.
So
I
just
want
to
highlight
a
couple
that
we
found
one
of
the
first
ones
that
we
found
was
a
project
called
air
flow.
A
Now
air
flow
is
an
Apache
incubating
project
and
they
define
their
workflows
in
Python
and
they
have
a
number
of
pluggable
operators
that
you
know
allow
a
degree
of
customizations
around.
Your
workflows,
the
second
project
we
found,
was
a
project
called
Brigade.
Now
Brigade
is
developed
at
Microsoft
and
they're
part
of
the
helm
ecosystem
and
they
use
they
kind
of
introduced
a
terminal
like
scripting
or
pipes
for
building
these
containerized
tasks
on
kubernetes
and
lastly,
we
found
a
project
called
Argo.
Now
Argo
was
different
because
they
define
their
workflows
as
custom
resources.
A
They
were
extending
the
core
kubernetes
api
to
build
workflow
object
in
the
kubernetes
api,
so
I
don't
want
to
talk
about
in
our
whole
story
of
how
each
came
to
an
open.
You
know
decision,
but
ultimately
we
decided
to
pursue
our
go
for
really
three
main
reasons.
You
know.
First,
it
was
very
powerful.
We
you
know,
spend
a
couple
weeks
walking
through
the
examples,
and
you
know
we
were
amazed
that
what
we
could
do
with
this.
A
So,
during
the
next
couple
weeks,
you
know
we
read
tons
of
documentation
about
building
our
code
workflows
and
we're
playing
around
with
the
platform
building
our
own,
and
we,
you
know,
during
one
of
our
many
impromptu
brainstorming
sessions,
which
we
had
a
lot
of.
We
started
by
drawing
something
like
you
see
here
up
on
the
board.
A
You
know
very
simple,
straightforward
linear
process
and
after
a
couple
hours,
you
know
we
put
together
all
of
our
thoughts
and
various
use
cases,
and
we
ended
up
with
something
like
this,
which
was
a
complete
disaster
and
we
were
like
laughing
it
about
it
to
each
other.
We
were,
like
you
know,
thinking
about
presenting
us
to
our
DevOps
team
and
telling
them
hey.
You
know,
can
we
do
this
and
yeah?
That
was
a
no-go.
We
needed
a
better
solution,
we
needed
something
that
could
span
multiple
teams
and
multiple
domains.
A
So
we
started
by
you
know
breaking
apart
this
big
puzzle
and
you
can
think
of
it
kind
of
like
this
complex
monolithic
workflow,
which
we
termed
kind
of
their
uber
workflow,
which
was
like
this
huge
workflow
cross
banning
our
entire
company.
That
would
like,
from
you
know,
early
in
the
morning,
would
generate
our
analytics
and
then,
at
the
end
of
the
day,
we
have
a
nice
report
with
you
know
all
of
our
ready
information
for
our
clients.
A
Now
we
separated
these
components,
you
know
by
natural
API
boundaries
and
data
layer
access,
because
we
knew
kind
of
like
different
teams,
wouldn't
want
to
be
working
on
the
same
workflows
with
teams
that
they
didn't.
You
know
really
quote
like
you
know,
work
that
on
the
same
stuff
with
so
we
ended
up
kinda
with
something
like
this.
We
had
workflows
inside
of
workflows,
we
had
the
compositions
and
workflows
and
we
really
needed
something
to
tie
these
pieces
together
right.
A
So
this
is
kind
of
my
transition
into
you
know
why
we
started
to
develop
this
eventing
platform
that
we
open
sourced
and,
in
addition
to
connecting
these
pieces
together.
What's
important
is
that
it's
come
into
a
map
of
dependencies.
So
you
know
you
can
not
just
have
a
linear
process,
but
you
have
task
1
task
two
and
task
3,
but
you
also
have
tasks
for
which
you
know
task
2
is
you
know
dependent
on
as
well
as
one?
A
So
you
know
you
have
a
map
of
essentially
dependencies
at
a
higher
level
than
just
a
simple
workflow.
So
you
know
this
is
really
the
motivation
for
our
event.
Framework
are
going
to
we
open
source
to
the
argo
community
and
to
the
entire
open
source
community,
and
so
now
I'm
gonna
hand
it
off
to
my
colleague
to
introduce
the
solution.
B
Thanks
man
so
yeah,
this
saw
that
we
need
a
framework.
That's
pretty
much
an
event-driven
workflow
system,
so
I'm
going
to
talk
about
arguments
and
what
exactly
it
has
to
offer.
So
first
question
is:
what
is
archived
events
was
kubernetes
native
event-driven
dependency
manager.
So
let's
break
that
definition
into
parts,
it's
good
when
it
is
native,
because
all
the
components
that
make
up
the
system
or
the
framework
are
implemented
as
custom
resources
from
ground
up
its
event,
even
though
whole
go
behind.
B
This
project
was
like
react
on
events,
so
this
framework
offers
a
component
called
gateway
which
essentially
listens
to
events
from
external
or
internal
event
sources.
But
that's
not
enough
consuming
events
is
one
part,
but
what
we
really
need
here
is
a
dependency
manager
that
can
manage
these
different
events.
So
that's
where
sensors
come
into
picture,
so
sensors
are
essentially
components
that
manage
this
event
dependences
for
you.
So
to
summarize
quickly
the
gateways,
the
listen
to
events
from
external
event,
sources,
transform
these
events,
make
them
into
cloud
events,
specification
compliant
and
forwards
them
to
sensors
sensors.
B
B
It
can
be
a
standard
kubernetes
resource
like
pod
or
deployment,
or
it
can
be
any
custom
resource.
You
can
have
these
things
as
a
triggers,
so
yeah
we
are
going
to
see
our
governments
in
action.
So
I'm
going
to
explain
what
we
are
going
to
do
here.
We
will
set
up
a
simple
image,
processing
pipeline
and
we
will
set
up
a
gateway
for
s3
and
we
will
have
some
sensors
and
some
triggers
running
man.
B
B
All
right,
okay,
so
we
just
install
couple
of
C
IDs
and
the
controllers,
and
we
are
using
s3
to
store
our
input
and
output
image.
So
what
we
are
going
to
do
is
where
we
are
going
to
like
put
an
image
on
s3
bucket
and
as
soon
as
we
put
that
on
s3,
the
system
is
going
to
trigger
an
hour
ago,
workflow
and
we
are
going
to
convert
the
image
into
grayscale
and
put
it
back
on
to
s3
and
that
will
again
trigger
another
workflow.
B
It
will
print
a
simple
message
saying
that
the
event
pipeline
is
complete,
so
the
next
thing
is
to
speed
up
a
gateway.
So
here
is
an
s3
gateway.
This
is
a
spec,
it's
very
straightforward.
It
has
a
couple
of
things
like
the
deploy
spec,
which
is
essentially
your
pod
pod
spec,
and
then
it
has
a
type
I'll
go
into
details
for
the
exact.
What
exactly
type
is,
but
for
now
it's
just
it's
a
shitty
bit
of
ash
atiba
gateway-
and
there
are
a
couple
of
watches
so
watches-
are
nothing
but
the
sensors.
B
So
the
gateways
part
is
up
and
running.
So
next
thing
is
to
configure
this
gateway
with
different
event
sources.
Now
the
event
source
in
the
in
this
case
is
input
bucket
and
the
output
bucket
that's
stored
on
the
s3.
So
this
is
how
the
event
sauce
looks
like
it's
pretty
simple.
We
are
just
mentioning
that
we
are
interested
listening,
SNS
notifications
from
input
and
output
buckets,
and
we
should
get
the
event
only
when
there
is
an
object.
Put
and
event
sources
are
configured
using
kubernetes
config
map.
B
So
so
that
way
you
can
essentially
add
or
remove
any
event
source.
You
want
on
fly,
you
don't
have
to
like.
You,
don't
have
any
downtime
for
gateway,
yet
we
can
continue
to
keep
on
running
and
you
can
essentially
add
the
event
source
anytime
X.
So
the
next
thing
is
to
set
up
the
sensors,
so
we
will
have
couple
of
sensors.
The
first
one
will
be
the
input
sensor
and
the
second
will
be
the
output
sensor.
The
sensor
spec
is
also
a
pretty
much
straightforward.
B
It
has
a
signal
which
is
basically
it's
specifying
from
which
Gateway
we
should.
This
sensor
should
get
an
event.
The
Gateway
name
is
s3
and
from
which
exact
particular
event
source
the
event
sources
input.
So
as
soon
as
this
sensor
receives
an
event
from
s3,
Gateway
and
event
event
source
called
input,
it
will
trigger
an
Ergo
workflow.
B
So
in
the
source
you
will
see
that
there
is
a
our
go.
Workflow
that's
describes
in
line
or
go
workflow.
This
example
has
in
line
or
go
workflow,
but
you
can
basically
store
your
workflows
on
s3
buckets.
You
can
store
it
on
gate
and
you
can
reference
those
workflows
in
the
spec
I
guess.
The
sensor
part
is
up.
We
need
to
create
one
more
sensor
for
the
output
bucket.
B
B
B
B
Just
juice-
and
we
have
our
cluster
set
up
on
the
Google
cloud
right
now
for
the
Draper
so
and
we
have
an
s3
beam,
yure
server
running.
There
is
a
single
instance
mini
server,
I
guess
so.
On
the
right
side,
you
can
see
that
couple
of
workflows
that
got
triggered
the
first
one
was
the
workflow
that
actually
converted
the
input
image
into
grayscale.
It
put
it
back
onto
s3
and
that
triggered
another
workflow
and
that
just
simply
printed
like
message
saying,
the
pipeline
is
complete.
A
A
B
Are
out
put
them,
and
there
is
our
pretty
much
it
so
this
is
Rhea
I'm
in
this
is
how
simple
it
is
to
use
our
go
events
and
to
like
chain
your
events,
basically
or
original,
that
that
was
our
original
Madea.
So,
basically,
you
can
have
multiple
gateways
and
sensors,
and
you
can
change
these
gateways
and
sensors
and
have
your
events
flow
from
end
to
end
and
set
up
this
whole
the
workflow
pipeline.
B
So
next
thing
is
I
want
to
like
go
over
a
couple
of
features
that
this
framework
has
to
offer.
So
the
important
one
is
it's
a
lightweight,
so
you
saw
that
we
just
needed
couple
of
CRTs
to
get
started
with
our
events
and
also
we
like
package
everything
using
containers
so,
depending
upon
the
implementation
of
your
gateway,
your
container
sizes
can
be
as
small
as
few
megabytes,
so
it's
very
lightweight
framework
and
very
much
focused
on
inventing
it's
easily
extensible.
B
So
when
we
started
writing
this
project,
which
shows
go
as
our
programming
language,
but
we
don't
expect
users
of
this
framework
to
write
their
code
and
go
to
implement
a
custom
gateway.
So
the
Gateway
is
divided
into
components
such
that
each
component
can
talk
to
other
component
over
go
channels,
HTTP
or
G
RPC.
So
as
long
as
your
implementation
can
or
your
programming
language
supports,
HTTP
RPC,
you
can
essentially
write
a
custom
gateway
and
it
is
configurable
at
runtime,
so
you
can
add
or
remove
event
source
anytime.
B
You
wish
there
is
no
downtime
for
the
gateway.
So
let's
talk
about
a
couple
of
use
cases
that
we
have
at
Blackrock.
So
Blackrock
as
being
financial
firm,
we
run
a
lot
of
financial
models
which
Android
many
reports
for
our
portfolios
for
our
funds,
but
some
of
these
processes
they
need
our
data
from
some
third-party
financial
vendors,
and
so
we
use
this
platform
called
data
source
in
platform.
It's
which
essentially
acquires
financial
data
from
different
vendors,
validate
validate
that
data
process
it
and
then
feed
it
to
downstream
applications.
B
Now
the
constraint
on
this
system
is,
we
expect
data
fields
from
vendors
to
be
present
at
a
certain
time
in
a
day,
so
we
use
a
gateway
called
file,
watch
our
gateway
whenever
there
is
a
new
data
feed
available
from
vendor,
so
the
file
watch
our
gateway.
It
generates
an
event
whenever
there
is
a
new
vendor
file
and
to
make
sure
that
these
vendor
files
arrive
at
a
certain
time.
In
a
day
we
use
calendar
gateway.
B
So
once
we
get
this
files
in
Blackrock,
which
River
some
80
overflows,
which
transforms
these
data
fields
into
internal
representation
and
stoled
on
s3,
and
once
we
have
this
date
on
s3.
Basically,
we
consume
the
SNS
notification
using
is-3
gateway,
and
then
we
trigger
the
spark
jobs.
I
won't
go
into
detail
what
this
part
ops,
but
they
help
generate
financial
models.
B
Now
we
got
the
data
from
our
vendors
now.
The
next
thing
is
to
make
sure
that
we
make
that
data
available
to
our
internal
financial,
analysts
and
researchers.
So
that's
where
our
data
science
platform
comes
into
picture.
It
of
the
data
sense
platform
offers
a
variety
of
Jupiter
notebooks
that
a
user
can
spin
up
on
the
fly
and
run
their
research
on
flows.
One
of
that
one
of
such
TripIt
are
notebooks
is
fixed
income
notebook,
so
this
fixed
income
notebook
basically
helps
deliver.
B
Different
teams
generate
alpha,
which
is
market
leading
performance
for
different
portfolios
to
their
clients.
Now
it
has.
Some
couple
of
minute:
has
some
complex
algorithms
like
risk
killing
transformation,
and
it
runs
optimization
on
the
final
of
financial
models,
so
it
has
pretty
complex,
mathematical
computation
and
this
whole
process
takes
time.
So
users
of
this
are
not
they
I
mean,
although
they
can
run
this
notebook
on
fly,
they
don't
want
it.
They
want
this
particular
notebook
to
run
on
a
specific
business
state
using
a
very
specific
financial
calendar
and
only
when
market
closes.
B
B
So
we
also
like
configure
these
gateways
with
some
offsets
so
that
take
care
of
the
failure
scenarios
and
once
the
schedule
completes,
we
use
our
gopher
flows
to
deploy
this
Jupiter
notebooks,
and
these
use
cases
are
just
like
tip
of
iceberg
because
at
the
end
of
the
day,
if
we
still
have
something
like
this
at
Blackrock,
we
have
so
many
different
teams
trying
to
coordinate
with
each
other
run
their
workflows.
But
what
the
census
and
gateways
provider
says
this
clear
sense
of
responsibility
of
like
consuming
events
and
then
different
actions.
B
A
A
So
even
in
the
you
know,
the
last
year
we've
seen
a
number
of
new
projects.
You
know
tackling
similar
solutions,
but
you
know
focused
on
different
use
cases
pop
up
in
the
ecosystem.
You
know
we
mentioned
the
project's
earlier
in
the
presentation
things
like
air
flow
and
Brigade,
and
you
know,
and
and
also
you
know,
new
platforms
even
coming
up.
You
know
here
being
at
cube
con
and
hearing
some
of
those
as
well.
A
So
another
interesting
area
that
we
that
we
were
watching
was
the
kubernetes
api
space,
and
so
since
the
adoption
of
the
kubernetes
customer
resources,
you
know,
since
they
were
released
in
one
point:
seven,
you
know
going
with
a
project
like
argo
and
building
upon
that.
With
you
know,
custom
resources
really
confirmed
our
decision
to
choose
argo
as
the
workflow
solution
and
I
really
believe.
You
know
a
simpler
unifying
eventing
platform
using
just
cut
using
customer
resources
built
upon
kubernetes.
A
It
is
a
way
forward
for
us,
and
you
know
personally
I
think
I
speak
for
both
of
us
like
a
year
ago,
I
didn't
know
anything
about
kubernetes
and
now
we're
here
presenting
to
you
guys
so
simply
having
the
opportunity
to
work
on
you
know
an
externally.
Open
source
project
has
been
really,
you
know,
awesome
experience
and
we
came.
You
know
to
appreciate
the
real
fast-paced
nature
of
development
in
the
open
source
community
and
you
know
being
able
to
quickly
adapt
to
you
know
the
ever
shifting
landscape
so
internally
are
go.
A
Immense,
has
already
kind
of
exceeded
its
initial
scope.
You
know,
as
web
of
showed
you
guys,
you
know
we're
using
it
for
the
data
science
platform,
but
we're
also
exploring
it
for
other
solutions,
as
I
hinted
to
before
we
have.
You
know
a
heavy
bachelor
in
that
process
at
Blackrock
and
automating.
This
you
know
today,
you
know
on
our
monolithic
kind
of
legacy
system
using
something
distributed
and
on
kubernetes
and
containerized
is
a
very
attractive
solution
for
us.
So
you
know
we're
currently
evaluating
using
it,
as
you
know,
an
operational
tool
integrating
it.
A
You
know
with
the
rest
of
the
agro
projects,
including
the
Argos
CD
project,
it
you
know
as
a
DevOps
kind
of
full
suite
solution
and
and
lastly,
you
know
personally
I
think
you
know-
we've
gotten
tons
of
exposure
to
working
on
this
project
and
collaborating
with
companies
across
the
United
States
and
learning
really
new
and
exciting
things.
So
you
know
we're
really
excited
to
share
the
story
and
share
the
project
that
we
built.
A
You
know
we
really
want
to
continue
to
develop
and
you
know
new
tools
for
the
future
of
kubernetes
based
automation,
and
we
urge
anyone
interested
to
you
know,
don't
hesitate,
reach
out
to
us,
we'll
be
we'll
be
here
after
check
out
the
argo
project
online
and
big
shout
out
to
the
r-dog
folks
for
being
very
receptive
for
kind
of
welcoming
us
into
the
community
along
the
way
so
yeah.
Thank
you
very
much
and
we'll
now
open
it
up
for
a
question.
B
B
So
this
one
right,
okay,
so
we're
out
of
box,
provide
like
some
core
gateways
for
webhooks,
has
three
SS
notifications
like
calendar
gateways,
even
messaging
cues
like
cough
contacts,
and
even
you
can
have
kubernetes
resource
as
an
event
source,
so
in
it
any
updates
to
any
kubernetes
resource,
standard
or
custom.
You
can
watch
those
events
basically,
so
these
are
like
provided
out
of
box,
but
then
you
can
write
your
own
implementation
of
a
gateway
and
that's
that
implementation.
You
can
write
it
in
any
language.
B
Basically,
and
you
don't
have
to
worry
about
like
different
components
of
like
handling
what
happens
when
a
new
event
source
got,
gets
added
or
removed.
You
don't
have
to
worry
about
all
unit
to
provide
the
implementation
is
just
what
you
vent
source.
You
are
you
try
to
listen
to
you
and
how
you
want
to
consume
that
event?
B
A
A
That's
a
great
question:
you
would
contribute
to
the
Argo
events,
repo,
the
Argo
project.
The
workflows
are
kind
of
agnostic
to
the
events
happening
right,
we're
just
trying
to
trigger.
Oh
sorry,
to
repeat
the
question
was:
if
you
know
he,
we
were
going
to
build
a
custom
gateway
say
for
as
your
walk
blob
blob
storage,
you
know
which
repo
would
I
contribute
to
which
wish
so
it
would
be
the
Argo
events,
repo,
the
REO
events,
kind
of
integrates.
You
know
the
implementations
of
each
of
the
event
sources.
You
can
implement
an
interface.
B
So,
as
far
as
like
the
what
the
agro
workflow
so
as
it
triggers,
we
run
our
go
over
flows
right,
so
the
sensors
and
gateways
are
continuously
like
long
running.
Oh
sorry,
sorry
trigger.
So
the
question
is:
how
do
we
maintain
like
long-running
processes
like
how
we
mint
and
like
longer
flows
or
how
we
even
monitor
them
right?
So
yeah,
sensors
gateways
are
continuously
long-running,
but
the
workflows
are.
Group
team
provides
a
new
Y
that
you
can
like
monitor
your
workflows,
but
it's
not
exactly
part
of
our
go
event.
B
A
And
because
there
are
just
resources
on
kubernetes
right,
they
follow
the
same
paradigm
between
you
know,
controller,
so
an
object,
you
know
any
P
I
object.
So
in
speaking
for
the
are
go
workflows
right,
you
create
a
workflow.
You
know
the
the
kubernetes
system.
Will
you
know
ensure
that
your
desired
state
matches
your
or
your
actual
States
as
it
matches
your
desired
state?
So.