►
From YouTube: OpenShift Commons Briefing #18: Handling Asynchronous Workloads on OpenShift with Iron.io
Description
In this OpenShift Commons Briefing, Ivan Dwyer from Iron.io gives an overview of Asynchronous tasks and walks us through how to use IronWorker and IronMQ to easily manage and scale asynchronous workloads on OpenShift.
For the latest information on OpenShift 3 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally. The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org.
A
So
welcome
everybody
to
this
openshift
Collins
briefing.
We
are
really
pleased
to
have
with
us,
Ivan
dwyer
from
iron
I,
oh,
and
we're
going
to
talk
about
running
and
handling
asynchronous
workloads
and
open
ship
today,
and
we're
very
pleased
to
have
one
of
our
open
shift.
Commons
members
and
one
of
the
newer
ones
and
a
longtime
partner
with
open
shift
to
be
doing
a
session.
So
I'm
going
to
let
Ivan
take
it
away
and
introduced
himself
and
well
QA
after
the
presentations
and
the
short
demo
is
done
and
the
recording
will
be
available
after
it.
B
Excellent
well,
thank
you,
diane
and
thank
you
to
everyone
who's
on
the
line
joining
for
the
session.
This
ship's
comments,
briefing
on
handling
a
cigarettes,
workloads
and
open
shift
with
ir
AO.
What
that
really
means
is
it's
a
new
fairly
new
concept
of
event-driven
computing,
this
kind
of
modern
cloud
era
I'll,
introduce
myself
real
quick.
My
name
is
Ivan
Dwyer
I
head
up
the
business
development
unit
with
ir
Gotye,
oh
and
primarily,
work
with
our
partners
and
both
the
cloud
technologies
and
developer
services.
Ecosystems,
build-outs.
B
You
know
where
the
meaningful
integrations
that
solve
complex
business
problems
across
a
wide
range
of
industries-
and
you
know,
red
hat
over
the
years-
has
been
a
great
partner
to
us
as
a
growing
company,
and
it's
really
exciting
to
watch
and
be
part
of
the
open
ship
developments
and
where
things
have
been
going
and
where
things
you
know,
the
v3
would
release
the
red
has
somewhat
a
few
weeks
ago.
So
it's
all
very
exciting
stuff
and
we're
happy
to
be
part
of
it.
B
A
B
That
means
for
developers,
then
we'll
kind
of
get
into
this
adventure
of
and
computing
pattern,
and
it's
really
the
meat
of
the
session.
We're
talking
you
quickly
about
what
you
know.
Iron
and
I
oh
does
and
where
we
fit
in
this
world,
I'll
give
an
actual
live
demo
and
then
we'll
talk
about
how
iron,
I/o
and
open
shifts
are
integrated,
both
of
the
public
cloud
and
private
cause
of
pumps.
B
Now
it
really
is
just
an
exciting
time
to
be
part
of
this
ecosystem
and
even
more
exciting
time
to
be
developers.
You
know,
companies
of
all
kinds
would
really
recognize
the
importance
of
developers
to
the
business
and
providing
the
support
and
resources
to
really
make
great
things
happens.
Now
with
this,
you
know
this
is
kind
of
endless
possibilities
for
innovation.
If
the
cloud
has
really
come
a
long
way
to
make
that
possible.
B
We
added
more
servers
and
more
and
more
always,
involving
IT
applications
were
packaged
as
a
single
entity
and
had
to
scale
as
such
deployments
were
done,
and
all
the
major
releases
onlys
and
those
happen
very
frequently
due
to
the
catalog
testing
cycles
and
having
to
reach
milestones
in
kind
of
waterfall
model,
and
as
it
relates
to
this
topic,
any
handling
based
synchronous
workloads
had
to
be
built
by
hand.
There
was
just
no
tools
around
around
it
and
you
know
all
of
this
led
to
you
know
a
lot
of
waste
and
inefficiency.
B
It's
you
know,
but
it
was
all
we
knew
and
then
the
cloud
came
and
changed
everything
you
know:
infrastructure
became
virtualized
applications
were
broken.
Apart
into
more
logical
tears,
software
could
be
updated
a
little
better
and
in
our
world
you
know
some
toolkits,
you
know
came
about,
and
middleware
components
came
about
to
kind
of
build
these
things
out
more
effectively.
You
know
all
of
these
things
were
definitely
a
step
in
the
right
direction,
but
there
was
a
lot
more
left
to
be
desired,
that's
kind
of
where
we
are
in
this
motor
club.
Now
you
know.
B
Software
is
continually
updated
behind
the
scenes,
and
you
know
these
a
singer's
workloads
become
API,
tripping
kind
of
without
the
need
for
in
addition
of
work,
or
you
know,
software
definitions
or
custom
application
development,
and
this
kind
of
modern
era
is
we're
both
red
hat
and
iron.
I
Oh
cinch
is
why
it's
really
exciting
to
be
a
partner
with
red
hat
government
shift
world.
B
Now
this
is
the
very
familiar
you
know
modern
CloudStack,
and
it
was
first
born
as
a
way
to
provide
on-demand
compute
storage
and
networking
resources
so
that
applications
and
API
is
could
be
built
and
deployed
easily.
But
we
found
that
you
know
the
I
ass
and
sass
were
just
not
enough
in
those
cases
just
given
the
complexity
of
managing
configuring
applications,
deployments
and
services
and
so
forth,
and
so
this
is
really
where
the
past
layer
is
coming
to
play
in
the
middle
recent
years.
B
You
know
in
both
the
public
and
private
cloud
platform
with
the
battle-tested
red
hat
enterprise
linux,
under
the
hood
really
believe
it
open
shift
is
unique
in
its
offering
really
has
a
great
place
in
the
ecosystem
and
being
able
to
extend.
You
know
working
with
partners
and
ISPs
such
as
ourselves
right.
It
really
gives
developers
everything
you
know
they
would
need
to
innovate
and
that's
what
it's
really
all
about.
B
You
know
empowering
developers
so
that
they
can
do
their
jobs
in
a
bit
so
that
they
can
kind
of
really
focus
on
the
business
logic
and
end-use
solutions
and
not
have
to
worry
about.
What's
working.
So
with
that,
you
know,
developers
want
an
abstraction
they
want,
they
don't
won't,
have
to
worry
about
dealing
with
infrastructure.
You
know
they
want
to
be
able
to
get
up
and
running
themselves.
You
know
without
involving
IT,
and
they
you
know,
want
the
freedom
to
use
the
languages
and
tools.
Therefore,
most
familiar.
A
B
B
So
that's
really
where
we
are
now
in
this
kind
of
application
world,
and
this
modern
CloudStack
really
provides
developers
everything
needed
to
build,
deployed
and
scale
applications,
but
as
it
relates
to
this
conversation,
what
about
the
workloads
that
happen
in
the
background?
Do
they
kind
of
follow
the
same
model?
Can
we
apply
the
same
principles
and
technologies?
B
Yes,
and
no,
but
we'll
dig
in
a
bit
further
here
and
just
for
a
point
of
reference.
Github
once
said
that
they
were
fifty
percent
background
work,
meaning
that
everything
that
happens
on
github
half
of
that
is
happening
behind
the
scenes
away
from
the
user
interface.
So
they've
done
a
great
job
of
building
out
a
lot
of
this
asynchronous
functionality
and
that's
kind
of
what
we
do
here
at
iron.
A
oh
and
what
we
want
to
talk
about
about
today.
B
Did
you
kind
of
said
there's
this
new
theme
of
adventure
and
computing-
and
it
often
is,
is
in
these
cases
the
patterns
have
been
around
for
some
time,
but
this
kind
of
fresh
principles
to
go
along
with
with
the
current
landscape
and
no
given
the
proliferation
of
IOT
on
vacations
and
kind
of
rise
of
popularity
of
micro
services
and
more
and
more
workloads
are
happening
in
synchronously,
triggered
by
some
event.
That
event
can
be
an
actual
real
world
event
could
be
an
application.
B
It
could
be
a
user
on
mobile
machine
there's,
all
sorts
of
things
happen,
and
it's
really
important
for
applications
to
be
able
to
you
know
reacts
accordingly.
That's
really
what
we
are
talking
about
here,
but
before
I
really
get
into
the
actual
pattern.
I
want
to
make
a
distinction
between
applications
and
tasks.
So
we
really
understand
why
there's
a
need
for
a
different
type
of
kind
of
platform
environment
for
this
type
of
work.
On
the
application
side
you
know,
they're
hosted,
have
to
be
highly
available.
B
The
traffic
is
distributed
by
load,
balancers
and
capacity
is
adjusted.
You
know
by
adding
booking
instances
the
kind
of
elastic
you
know
promise
of
the
cloud
you
know.
On
the
other
hand,
tasks
only
really
need
the
runtime
available
for
the
duration
of
the
process
itself.
You
know
they're
they're,
not,
you
know,
load
balance
there.
The
traffic
is
handled
by
queuing
up
jobs
and
scaling
is
done
by
adding
or
concurrent
processes
within
the
same
resources
instead
of
having
to
scale
up
and
down
the
instances.
B
Also,
you
know
when
looking
at
where
to
make
the
kind
of
distinction
within
your
own
applications.
It
often
comes
down
to
what's
real
time
user
facing
and
then
what's
asynchronous
and
in
the
background,
and
that's
really
where
we
start
to
kind
of
look
at
our
applications
as
a
collection
of
components,
and
you
know,
features
and
processes
where,
where
we
can
kind
of
make
the
distinctions,
so
you
know
when
you're
building
out
these
kinds
of
applications.
It's
it's.
You
know
all
about
kind
of
identifying
the
right
pieces.
B
What's
what's
part
of
my
core
application
and
what
is
asynchronous
task
and
as
we've
kind
of
seen,
microservices
come
about.
You
know
a
lot
of
these
tasks
actually
follow
the
same
principle.
So
when,
when
I
talk
about
microservices,
I
tend
to
be
talking
more
about
micro
tasks
actually
and
I
think
that's
kind
of
the
logical
evolution
of
of
where
that
kind
of
pattern
is
coming,
and
you
know
in
the
characteristics
and
processes
of
you
know
of
the
processes
are
very
similar
to
that
in
micro
services.
B
They
should
be
independently,
developed
and
deployed
and
follow
a
single
responsibility.
It
should
be
stateless,
very
easily
to
be
interchangeable.
You
know
minimal
dependencies
and,
of
course,
asynchronous
no,
but
from
a
functionality
perspective,
it's
kind
of
the
processes
that
fall
outside
of
the
use
of
response
that
you
know
that
could
be
calls
to
third-party
services.
B
You
know
things
that
are
very
long
running
some
coding,
many
kind
of
transaction
billing
process
and
anything
that
needs
to
really
scale
out
at
first,
you
know
doing
is
doing
something
a
million
times
you
know
very
young,
randomly
I'm
going
to
put
anything
is
scheduled.
So
if
you
look
at
kind
of
cron
jobs,
those
are
those
are
being
basically
just
tasks
that
happening
synchronously.
B
So
you
know
when
we
talk
to
our
customers,
you
know
we
kind
of
do
these
reviews
of
their
applications
and
we
identify
the
right
kind
of
pieces
within
that
to
kind
of
make
sense
in
this
kind
of
task.
Centric
model,
you
know
over
kind
of
app
centric
model
a
little
more
specific.
You
know
we
see
a
wide
range
of
use
cases
over
here
at
iron,
a
oh
and
just
a
few
of
the
more
common
occurrences.
You
know
sent
sending
emails
and
notifications,
you
know
individually
and
bulk
really
makes
sense
to
be
done.
B
Asynchronously
would
you
know
who
might
be
connecting
to
SendGrid
using
SendGrid
as
a
service
or
twilio
as
a
service,
and
you
might
have
to
send
a
million
emails
at
once
and
those
those
are
very
small
processes,
but
need
to
scale
out
in
a
very
large
and
time
sensitive
manner.
No,
so
that's
a
good
fit.
We
see
a
lot
of
multimedia
encoding.
These
can
be
you
know
very
memory
or
CPU
intensive
tasks.
You
know
they
take
a
lump.
B
It
can
take
a
very
long
time
if
you're
dealing
with
satellite
imagery-
or
even
you
know,
medical
imaging
these.
These
things
have
required
a
lot
of
heavy
lifting
and
require
the
right.
You
know,
resources
for
that
job
itself
and
there
they
all
have
any
synchronously
behind
the
scenes.
Cuz,
you
know
no
one's
waiting
for
twin
turbine
image
to
be
encoded,
so
it's
outside
of
that
kind,
user,
loop,
again,
transaction
processing,
so
billing-
and
always
an
example-
is
when
you
buy
something
on
amazon.
B
They
give
you
the
confirmation
right
away,
but
behind
the
scenes
they
might
kick
off,
you
know
a
variety
of
jobs,
sweet
processing,
the
credit
card
and
writing
to
a
database
adjusting
inventory.
All
those
things
are
happening
asynchronously
and
they
don't
make
you
as
the
user.
Wait
for
all
that
to
happen.
You
know
before
giving
you
the
kind
of
next
step.
So
all
of
those
things
that
happen
in
the
background
kind
of
fit
this
task
model
crawling
the
web
is
a
good
example
of
this.
You
know
scheduled
job.
You
know
you
might
daily.
B
You
know
shopping
sites,
my
daily
crawl
comparison
sites,
my
daily
for
all
a
bunch
of
shopping
sites,
so
pull
out.
Then
you
know
the
latest
data.
Those
kind
of
things
you
know
happened
behind
the
scenes
and
did
this
kind
of
asynchronous
model
and
as
it
relates
to
you,
know,
just
the
general
transfer
and
kind
of
processing
of
data.
We
see
a
lot
of
this
in
IOT
world.
You
know
pass
some
data
from
source
to
destination.
B
You
know
collecting
data
from
sensors,
delivering
that,
to
you,
know,
data
warehouses,
back-end
systems
and
doing
any
of
the
processing
in
between
that's
those
are
all
you
know,
asynchronous
kind
of
use
cases
in
there
might
be
some
third-party
services
that
you're
connecting
to
I
mentioned
SendGrid
and
twilio.
Those
are
great
examples
and
then
anything,
that's
scheduled.
You
might
have
a
daily
email
blast.
I
mean
you
don't
want
to
think
about
that
as
part
of
your
application,
it's
just
kind
of
as
a
synchronous
task
and
so
we're
I
into
all
of
these.
B
We
see
a
lot
more,
but
I
would
pick
these
is
probably
the
most
common.
They
fit
our
platform
which
will
kind
of
get
into,
but
but
thinking
from
of
it.
From
like
a
workflow
perspective,
I
mean
how
do
all
these
things
kind
of
work
together
and
what
does
enter?
Then
really
mean
you
know.
Essentially
it
means
you
know,
responding
and
reacting
to
an
event
trigger
automatically
and
then
executing
a
process
or
chain
of
processes
accordingly,
and
so
those
triggers
can
happen
in
a
variety
of
ways.
B
Web
hooks
is
a
great
example
when
you
update
your
repo
on
github,
it
generates
a
web
hook,
and
you
can
then
send
that
in
to
you,
no
slack
and
notify
your
entire
team.
Those
those
web
hooks
are
triggers
that
can
then
kind
of
kick
off
a
variety
of
workflows
and
things
call
back
same
thing.
This
is
within
your
within
your
kind
of
your
code.
B
Direct
API
call
so
I
mean
within
your
application.
You
can
just
you
know,
hit
the
task
and
the
task
as
an
endpoint.
So
it's
just
a
you
know:
simple
API
call
to
trigger
a
workflow,
so
when
you're
dealing
with
phenome
IOT
devices,
maybe
this
the
sensor,
it's
a
it's
an
API
endpoint
when
it
triggers
so
it
captures
an
image
or
something
you
know.
Stream
processing
is
another
interesting
one
streams
TDM
just
didn't
kick
off
a
continual
workflow
of
processes,
just
kind
of
as
it
goes
through.
B
Now
these
triggers,
you
know,
check
out
processes,
but
they
all
generally
will
need
to
end
up
somewhere.
So
those
are
kind
of
the
destination
might
be
a
database
or
analytic
system.
It
could
be
another
API,
so
you
could
be
using
these
adventure
but
workflows
to
build
out
your
application
api's
that,
then,
you
know
extend
to
the
developers
in
your
ecosystem.
So
an
IOT,
you
know,
platform
provider.
Might
you
know,
expose
an
API
and
they
have
all
these
adventures
and
workflows
behind
the
scenes
that
actually,
you
know,
generates
the
data
that
builds
that
API.
B
A
B
You
can
send
all
the
stuff
two
logs
I
mean
this.
Is
so
much
data
being
generated
these
days,
but
one
thing
that's
really
kind
of
important.
Is
this
this
execution
component,
of
course,
and
that's
really
where
this
task
centric
platform
comes
into
play
now,
AWS
calls
it
lambda
functions,
we
call
them
workers,
you
know
it's
really
just
kind
of
a
matter
of
taste-
and
you
know,
essentially,
is
what
we
just
talked
about
briefly.
This
is
what
these
patterns
are.
B
What
is
the
single
single
piece
of
code
that
does
one
job
and
then
the
platform
provider-
and
this
is
what
we
do-
is
we
abstract
away
all
of
the
thinking
around
operations
and
infrastructure
and
choreographing
those
those
tasks?
We
just
run
them
so
these
these
things
in
this
adventure
of
a
workflow.
B
These
tasks
just
need
to
be
executed
automatically
developers
never
have
to
worry
about
spinning
up
infrastructure
to
run
them,
and
that's
really
why
it's
kind
of
such
an
exciting
thing
to
be
doing
and
why
it's
a
little
different
than
you
know,
deploying
in
scaling
applications
even
in
the
platform
is
a
service
layer
now.
Another
thing
that's
really
important
to
keep
in
mind
when
I'm
kind
of
building
out
these
workflows
is
the
importance
of
leveraging
and
message
queue
with
in
the
pipeline
from
the
triggers
to
the
execution
of
areas
to
the
destinations.
B
B
You
know
you're
dealing
with
a
lot
of
data
in
transit,
and
you
know
it's
just
it's
really
important
to
keep
that
cued
and
persisted
so
that
you're
not
losing
anything
as
part
of
the
workflow
and
maybe
if
one
of
the
tasks
fails
or
an
input,
one
of
the
result
endpoints
can
be
reached.
You
know
you
still
have
that
state
persisted
so
you're,
not
losing
data
and
you're
not
losing
the
kind
of
execution
path
along
the
way.
B
So
that's
really
really
important
and
something
that
we
promote
to
all
of
our
our
customers
is
to
make
sure
that
everything
is
queued.
We're
dealing
with
asynchronous
work
here,
so
the
queues
is
a
key
key
piece
to
that
and
we'll
talk
about
how
we
we
saw
that
with
our
message:
queue:
okay,
so
moving
along.
So
with
these
kind
of
new
patterns
around,
you
know
eventually
workflows
and
tasks
tasks
instead
of
applications.
B
B
But
we
want
to
do
all
of
this
without
having
to
manage
infrastructure
developers,
don't
want
to
have
to
deal
with
with
infrastructure
they
don't
because
it's
event-driven,
we
don't
have
the
best
idea
of
capacity.
You
know
it
could
be
very,
very
unpredictable.
I,
don't
want
to
have
to
worry
about.
Having
enough,
you
know,
VMs
and
servers
up
and
running
to
handle
the
scale
I
just
kind
of
want
to
know
that
the
I
can
run
these
ssds
without
having
to
worry
about
that.
B
B
You
know
want
a
tool
or
platform
that
does
this
for
task
as
well,
and
you
know
just
being
able
to
deflect
and
transform
and
deliver
all
this
data
very
seamlessly,
having
these
pipelines
and
workflows
just
kind
of
connect
and
not
have
to
do
bunch
of
translations
or
work
with
proprietary
formats,
and
then
all
of
these
components
that
handle
these
kind
of
task,
centric
workloads.
You
know
we
want
those
to
be
integrated
within
Erika
than
our
application
platform.
We
don't
want
to
have
to
maintain
two
different
systems
for
our
applications
and
our
tasks.
B
Now,
of
course,
these
goals
introduced
a
whole
new
set
of
challenges,
just
just
as
anything
else
with
a
new
pattern,
and
you
know
I
found
this.
This
is
funny
tweet
when
I
was
looking
into
microservices
a
little
more.
You
know
we
found
over
the
years,
of
course,
is
a
key
to
what
we
do
that
building
functionality
for
asynchronous
concurrency
is
extremely
complex.
It's
just
a
lot
of
moving
parts,
a
lot
of
components
and
there's
a
lot
of
things
to
deal
with
it.
B
A
B
Is
really
key
to
what
we
aim
to
solve?
You
know
that
there
is
this
kind
of
need
for
a
task
centric
platform
to
handle
these
workloads
and
that
task
centric
platform
needs
to
be
very
tightly
integrated
with
the
app
center
platform,
and
that's
really
where
we
see
open
shift
and
iron
I/o
coming
together
to
form
this.
So
this
is
comprehensive,
developer,
oriented
platform.
B
Okay,
so
where
do
we
fit
in
this
world?
And
you
know
what
do
we
do
in
the
context
of
event
driven
computing
and
in
this
kind
of
asynchronous
workloads?
And
that's
always
been
our
focus?
You
know
we
build.
We
build
technology
for
power,
asynchronous
workloads,
you
know
meant
for
distributed,
applications
of
all
kinds,
mobile
web
and
kind
of
IOT-
and
we
do
this
through
variety
of
services,
including
an
iron
mq,
an
iron
worker
and
so
iron
of
Q
is
a
message,
queue
service
and
then
iron
worker
is
this
task:
centric
environment.
B
So
from
a
developer
perspective,
working
with
iron
iOS
meant
to
be
very
simple.
Much
like
it
is
with
an
open
shift,
so
developers
can
really
focus
on
writing
code
in
without
the
hassle
of
having
to
deal
with
the
rest.
So
our
process
is,
you
know,
just
like
any
kind
of
development
platform
is
start
with
the
builds.
You
know
you
build
your
tasks,
use
any
language.
We
have
native
SDKs
for
most
every
language
and
then
you
can
container
eyes
them
even
with
docker.
B
That's
kind
of
where
we're
moving
is
full
native
chakra
support,
and
then
you,
once
you
have
your
task
code
built.
You
know
you
upload
it
instead
of
kind
of
think
of
deploy,
so
it
you
upload
it
to
our
environment
and
committed
to
your
repo
and
package
it
and
upload
it
to
us,
and
then
that
becomes
what's
in
our
world
is
code
package.
B
Neco
package
is
then
ready
to
run
at
any
given
time.
It's,
then,
is
your
responsibility.
It's
just
set
the
event
triggers
what
is
going
to
kick
this
thing
off
and
is
it
a
schedule
or
is
it?
Is
it
some
web
hook?
What
is
it
you
know
or
do
I
just
want
to
run
them
on
demand,
but
you
don't
have
to
worry
about
is
is
spinning
up
any
infrastructure
to
run
it?
B
It
just
is
there
available
to
run
because
it's
been
uploaded
to
us,
we
handle
it
and
then
it
scales-
and
you
don't
have
to
really
think
about
that
you
all
you
have
to
do
is
set
the
concurrency
level.
I
want
this
pass
a
to
be
able
to
run
a
hundred
times
concurrently
and
then,
and
then
we
distribute
that
workload
accordingly
on
demand
based
on
the
incoming
volumes
and
there's
no
provisioning
needed
on
your
end.
So
we
see
this
is
very
simple
and
the
task
centric
development
workflow
and
its
really
really
user-friendly.
B
We
have
a
very
easy
to
use
simple
rest
api
to
do
all
of
this.
So
you
know
in
our
world
we
have
a
number
of
concepts.
A
number
of
kind
of
keywords
that
I
thought
was
worth
kind
of
going
over
just
because
it's
a
little,
maybe
a
little
different
than
application
platform
environment
though
them
mentioned,
we
call
these
unit
workers,
so
that
is
the
task
code
and
what
we
call
is
a
kind
of
unit
of
container
as
compute.
We
have
what's
called
runners
and
that's
basically,
the
runtime
agent
that
spins
up
containers
and
processes.
B
The
workloads
dax
are
the
kind
of
base
language
and
library
dependencies
that
are
drop
images.
So
if
I
want
to
run
Ruby
21
its
to
choose
the
Ruby,
21
stack
and
queue
is
again.
This
is
how
we
dispatch
the
workloads
through
through
our
message
to
service
schedule
is
pretty
straightforward.
Much
like
prom
but
managed,
and
in
the
cloud,
so
you
don't
actually
have
to
maintain
their
concurrency
is,
is
how
we
deal
with
scale.
So
it's
hot
number
of
tasks
when
at
the
same
time,
this
isn't
parallel
processing.
This
is
concurrent
processing
and
meaning
running.
B
B
Okay,
let's
quickly,
gotta
get
under
the
hood.
You
know,
as
I
mentioned,
that
building
this
stuff
out
is
fairly
fairly
complex
and
just
from
the
the
work
that
we've
done
over
the
years
and
the
feature
set
that
we've
developed,
you
know
that
we
definitely
know
the
challenges,
but
we
also
know
what
what
needs
to
be
done.
Ain't,
no,
not
just
from
this
kind
of
choreographing
of
task
based
work,
but
also
from
like
a
management
security
perspective.
B
So
starting
at
the
top,
and
we
have
our
native
libraries
for
the
major
popular
languages.
That's
really
all
the
developers
need
to
interface
with,
because
those
natively
interface
with
our
API
and
then
the
API
handles
you
know
all
the
features
and
so
from
you
know,
code
management
perspective
for
management
perspective.
You
know
we
do.
You
know
code
history,
code
versioning,
so
you
can
very
much
like
how
checking
in
your
ear
application
code.
B
We
have
a
dashboard
and
various
monitoring
features
along
with
it
now
so
that
you
actually
can
manage
and
maintain
your
tasks
or
schedules
and
your
cues
within
the
actual
choreographing
of
the
workloads,
you
know
mention
the
queue
we
also
set
priorities,
so
some
jobs
might
be
more
important
than
others
and
schedules,
of
course,
and
an
interesting
thing-
and
this
goes
back
to
the
difference
between
application
tasks-
you
can
just
auto
retries.
So
something
fails.
You
know
it
doesn't
go
down.
You
know
you're,
not
dealing
with
downtown
you're
just
dealing
with
okay.
B
This
job
is
persisted,
let's
retry
retry
it
until
it
succeeds
or
will
notice
that
it's
just
never
going
to
work,
because
the
code
is
wrong,
but
we
can
use
the
dashboard
and
monitoring
tools
to
figure
that
out
and
then
we,
you
know
we
handle
security.
You
know
multi-tenant
service
in
a
cable
encrypt,
a
lot
of
the
data
in
transit,
the
code
packages
themselves
and
we
provide
various
logging
integrations
to
kind
of
see.
What's
what's
happening,
getting
into
the
components
under
the
hood,
you
know
we
have.
B
We
maintain
a
you
know,
fairly
complex
environment
under
the
hood
again
abstracted
away
from
the
developers,
but
moving
from
left
to
right.
You
know
we
kind
of
have
these.
These
two
components
that
manage
the
priorities
and
the
schedules
of
jobs,
jobs
get
placed
into
a
task
queue
and
that
Q
is
iron
and
Q.
And
then
what
really
happens
here
is
from
a
developer.
Spective
I've
uploaded
my
customer
code
and
that
code
is
matched
to
a
doctorate
image.
B
Another
docker
container
that
merges
the
customer
code
with
the
base
docker
image,
execute
the
task
and
then
kills
that
container
and
that's
a
continually
running
agent
on
the
runners
server
and
that's
just
pulling
jobs,
porn
jobs,
running
running
jobs,
and
this
is
just
spinning
up
and
down
and
all
happening
concurrently
and
what's
important
to
note
is
we
can
deploy
that
runner
in
the
public
cloud
or
on
print,
and
so
the
workloads
you
can
choose
where
you
want
two
different
workloads
to
be
processed.
So
it's
really
flexible
in
its
deployment.
B
And,
of
course,
you
know
when,
when
is
when
you
want
to
use
this,
and
so
we
hit
all
of
the
the
major
themes
of
the
modern
cloud,
you
know
microservices,
obviously
a
hot
hot
term,
but
you
know
that
you
kind
of
makes
sense
to
think
of
these
independent
services
as
tasks
same
with
me
on
mobile,
you
know
running
a
server
list
back
in
your.
Not
here
is
a
mobile
developer.
You
want
to
have
to
think
about
infrastructure,
so
we
provide
kind
of
a
mobile
backend.
It
doesn't
interfere
with
the
user
experience.
B
Seeing
a
lot
of
really
interesting
things
in
the
IOT
world,
I
mean
it's
very
close
fit.
You
know
asynchronous
in
nature
since
we're
the
very
close
pic
with
us,
so
you
can
kind
of
Korra
graph.
These
workloads,
you
know
using
both
r
cube
for
passing
data
and
then
obviously
the
task,
centric
kind
of
platform,
then
again
hybrid,
some
deploying
you
know
your
workloads
and
public
and
private
cloud
environments
and
where
I
think
we're
unique
is
in
this
hybrid
world.
B
Is
that
it's
a
really
easy
way
because
we're
dealing
with
tasks
and
not
large,
you
know
large
applications.
It's
it's
really
easy
to
offload
individual
workloads
to
the
cloud.
So
if
you're
in
a
large
enterprise
that
has
you
know
a
lot
of
sensitive
data,
there's
you
know
you
might
have
some
workloads
that
you
want
to
offload
it
out
on
others.
You
want
to
keep
in
house,
you
know
we
make
it
really
easy
to
pick
and
choose
by
breaking
apart
of
things
into
individual
tasks.
B
B
B
Imagine
structure,
of
course,
there's
no
such
thing
as
a
server
list
environment,
but
from
a
developer
perspective,
it's
entirely
service
and
that's
that's
a
theme
that
we've
been
you
know
really
talking
about
from
from
years
now
and
it's
kind
of
starting
to
make
sense
to
developers,
and
so
it's
pretty
exciting
to
see
people
you
know
build
out
some
really
really
crazy
scale,
high
scale
tasks
and
what
the
first
thing
they
always
talk
about
is
how
awesome
is
that
they
don't
have
to
worry
about
it
structure
again.
So
that
means
no
ops.
B
Managing
infrastructure-
and
you
know
scaling
it-
this
kind
of
work
load
level.
So
you
know,
we've
shrunk
the
unit
of
scale
to
a
task
running
inside
a
container
with
very
minimal
dependencies,
and
so
that
makes
for
more
effective
scalability
again
we
have
a
very
developer
friendly
API
and
who
the
client
libraries
across
all
major
languages.
B
You
know
this
entire
environment
makes
it
really
easy
to
get
up
and
running
in
minutes,
and
we
integrate
closely
with
the
platforms
again
we
can,
we
can
deploy
Denny
cloud,
public
or
private
I.
Think
I'm
going
a
bit
over
time,
so
I'm
going
I'm
going
to
power
through
some
of
the
the
case.
Studies
here,
you're,
real,
quick,
just
to
kind
of
you
know
back
up.
You
know
what
we
do
and
why
choose
us,
but
Bleacher
Report's
a
great
example
and
have
it
one
week
next
story
in
the
brakes.
B
You
know
they
have
a
mailing
list
of
feeding
over
subscribers
and
millions
and
they
need
to
hit
those
subscribers
very
time-sensitive
play
with
that
new
story
before
it
becomes.
You
know
old
news,
so
anytime
is
an
event.
It
triggers
this
kind
of
master
worker.
The
goes
to
the
database
and
spins
up
then
thousands
of
tasks
within
I'm
worker
and
that
each
one
of
those
runs
concurrently
to
send
thousands
of
push
notifications
because
they
broke
that
apart.
B
They
can
send
millions
of
push
notifications,
another
minute,
so
they're
really
distributed
load
through
us
and
they
never
have
to
worry
about
having
the
infrastructure
ready
for
handling
that
load,
because
they
know
that
we
just
we
scale
it
out
on
demand
that
when
that
event
happens,
so
that's
a
really
really
common
in
great
use
case
for
us
hotelTonight,
another
popular
mobile,
app
use
us
to
build
a
pretty
complex,
etl
pipeline.
You
know
collecting
data
from
a
variety
of
sources
and
passing
it
through
this.
B
This
workflow
that
doesn't
various
filtering
before
you
know,
delivering
to
its
end
destination
in
each
step
in
that
pipeline
is
done
through
iron
worker
and
that's
just
running
twenty-four
seven
and
they
never
have
to
think
about.
You
know
the
what's
working
with
the
inner
workings
under
the
hood.
They
just
know
that
it's
always
happening.
They
get
updated
through
monitoring
tools
that
we
provide.
So
they
can
be
really
confident
that
the
data
is
getting
from
source
to
destination
effectively
using
iron.
B
In
a
great
example
of
a
mobile
backend
users
untapped
a
very
popular
apps
like
Foursquare
for
beer,
it's
just
one
guy
who's
been
he's
been
working
on.
It
is
in
spare
time
so
he
obviously
doesn't
want
to
have
to
you
know
power
we're
back
end
or
worry
about
infrastructure,
but
every
time
someone
checks
in
you
know
that
kicks
off
texting
of
up
to
ten
different
transactions,
whether
it's
right
to
a
database
post
to
social
media.
So
each
one
those
tasks
runs
concurrently
and
then
refreshes
with
the
results.
B
So
just
a
few
quotes
from
those
who
those
use
cases.
You
know
again
it
we
talked
about
this-
how
people
are
really
really
really
into
the
idea
of
not
having
to
worry
about
infrastructure,
so
they
can
just
really
focus
on
building
out.
You
know
features,
and
you
know
worrying
about
business
logic,
and
so
that's
why
we're
pretty
excited
and
seeing
the
number
of
customers
and
use
cases
continue
to
grow
within
our
platform.
B
Ok,
we're
going
to
give
a
quick
live
demo
I'm,
going
to
remind
everyone
of
my
job
title
before
I
give
this
demo,
so
it's
just
going
to
be
very
simple
kind
of
hello
world
in
an
iron
worker
and
how
that
scales
and
then
we'll
walk
your
dashboard,
real,
quick,
ok,
maybe
no
wings
going!
Ok,
ok,
oh
so
a
little
bit
bit
all
right,
so
we're
just
going
to
look
at
a
quick,
routine
task
here.
B
Be
ok
so
we're
actually
yay,
that's
pretty
pretty
exciting,
ok,
but
now,
let's
package
at
the
iron
worker.
So
what
does
that
mean?
I've
taken
this
code?
This
is
the
meat
of
my
code.
That's
my
task!
So
what
we
have!
We
have
what's
called
a
worker
file,
and
this
is
our
kind
of
packaging
format
and
for
this
very
simple
job,
I
just
select
the
run
time
and
I
say
exec,
hello,
RB
and
that's
all.
It
really
needs
for
more
complex
example.
B
I
might
have
some
gems
that
I
need
to
include
for
a
config
file
that
includes
a
keys
for
a
service
that
I'm
using,
but
for
this
one
and
it's
pretty
basic,
oh,
how
do
we
run
this
just
let's
kind
of
talk
about
local
development,
so
we've
done
a
lot
of
work
to
make
a
kind
of
docker
native.
So
let's
say
all
right:
let's
kill
that!
B
Let's
look
at
this,
so
what
we're
doing
here
now
is
we're
using
docker
locally
to
to
run
this
task
and
we're
choosing
the
same
stack
is
it
would
run
in
our
environment?
This
is
a
very
good
way
to
run
what
you've
run
locally
on.
Knowing
that
that's
the
exact
same
environment,
abduction,
so
for
more
complex
examples
with
different
dependencies,
this
is
a
very
important
to
ensure
assistant
environment.
So
we'll
run
that
in
a
this-
and
so
this
is
actually
running
inside
of
a
docker
container.
B
Okay,
again,
not
that
exciting,
but
still
kind
of
shows
just
the
workflow
there.
Okay.
So
how
do
we
run
this
entire?
First?
Let's
look
at
a
couple
of
steps
here.
We
want
to
package
it
so
will
zip
it
up
and
then
we'll
kind
of
upload
this
an
ironworker
upload.
Is
it's
how
you
do
that's
our
reporters
are
as
our
CIS.
This
is
a
ruby
CLI
and
then
we'll
q.
It
so
just
put
those
in.
B
A
B
Okay,
this
has
been
uploaded
and
be
cute.
It
and
ran
it.
So,
let's,
let's
go
to
our
dashboard
here,
so
this
is
our
dashboard.
So
what
is
run?
This
is
my
task.
Oh
I
just
was
completed.
If
you
look
at
this,
this
was
the
time
that
was
started.
It
took
24
their
kids
and
it
ended
gear
and
our
vision
is
the
my
third
revision
of
this
code,
because
I
had
to
update
that
helped
world
script
so
many
times.
B
B
B
B
These
are
interesting
so,
but
if
I
want,
sir
top
stew
be
able
to
scale
out
more
than
others,
because
we
a
lot
a
certain
amount
of
concurrency,
I
can
say
I
had
you.
I
want,
is
to
be
able
to
run
10
times
concurrently,
I
want
to
retry
only
three
times
and
just
end
it.
Why
well
I
think
we
can
do
with
the
code
level
as
well
and
then
we're
kind
of
watching
our
you
know,
usage
over
time,
I'm
kind
of
say
and
two
tasks
or
22
tasks.
B
B
That's
just
running
a
headless,
not
much
usage
here,
but
this
does
this
desire.
Our
dashboard
now
is
voiced
openshift,
but
I've
got
my
openshift
application
here.
This
is
my
god.
I
said
this
up.
I
added
iron
iron
of
cute,
an
iron
worker,
so
this
dashboard
is
what
I
would
get
if
I
click
this
link,
so
it's
very
integrated
and
the
way
I
get
these
services
is
I,
go
to
the
marketplace,
so
both
iron
worker
and
iron
and
cubes
are
available
here.
B
So
within
a
very
simple
rails
application,
and
I
have
a
controller
action
and
might
say
10
times,
let's
run
this
iron
worker
task,
so
I'll
use
just
include
our
gem
and
then
you
know
just
create
the
task
right
ten
times,
and
so
in
my
front
and
application
which
is
about
is
boring
as
a
guest.
I
will
just
do
this
hello,
world
worker
and
LOL
how
openshift
work
or
trigger,
and
then
I
go
back
to
I
dashboard
you'll
actually
see
fixed.
Are
running
right
now.
B
We're
running
running
running
completely,
these
are
running
you
can
see.
The
status
is
running,
let's
still
go,
click
complete
completing,
so
I
just
ran
that
10
10
concurrently.
Imagine
a
much
more
complicated
use
case
than
that.
I'm
going
to
log
same
process
all
that
running,
so
you
can
kind
of
see
how
easy
it
is
to
kind
of
get
jobs
up
and
running
within
my
area
and
also
how
quickly
you
can
just
bind
the
service
to
your
applications
with
an
open
shift
online
and
then
you
know,
integrate
the
iron
api
within
those
applications.
B
B
B
You
know
we've
started
at
a
public
cloud
business
but
through
popular
demand,
start
attuned
to
do
on-prem
deployments
and
then
in
the
middle
you
know
we
found
this
kind
of
sweet
spot
for
her
enterprises
and
businesses
who
wanted
all
of
the
benefits
of
the
cloud
have
wanted
it
in
their
own
environment,
those
dedicated
to
vent.
It's
the
same
multi-tenant
service.
B
It's
the
same
public
cloud
scalability,
it's
everything
about
that
except
it's
their
dedicated
public
cloud,
and
so
we
crossed
you
know
pure
public
to
you
know,
verities,
you
know
deep
secure
systems
behind
the
firewall,
and
so
both
of
those
all
are
all
of
those
employments
fit
within
openers
deployment
models.
We
want
just
show
the
online
integration
very
simple,
just
add
us
through
the
marketplace
and
then
openshift
enterprise,
which
is
kind
of
more
I,
would
cloud
remnants.
B
So
here's
some
us
in
the
marketplace
we
just
saw
that,
but
how
do
we
enter,
provide
an
integrated
with
openshift
enterprise,
and
one
of
the
huge
reasons
why
I'm
super
excited
about
it,
which
should
be
three
is,
is,
is
the
how
it
fits
within
our
own
deployment
and
packaging
models?
So
you
know,
opt
opting
Kuber
Nettie's,
you
know
under
the
hood,
and
actually
Dockers
is
the
way
to
pack
pension
deploy
these
services
fixed
with
how
we
do
it
as
well.
B
So
both
iron
imbue
and
iron
worker
can
be
managed
by
a
docker
containers,
so
that
makes
it
easy
to
integrate
deploy.
We
went
through
the
Red
Hat
Cerdic,
eight
containers,
turf
occasion,
process
for
iron
mq
already
so
that's
fun
and
doing
the
same
for
iron
worker
as
for
actually
deploying
it.
You
know
using
Cooper
Nettie's
on
the
hood
further
highly
available
service
deployment.
We
can
play
our
mq
that
riverside
of
workers
the
service
as
pods.
B
You
can
scale
out
accordingly
and
also
this
past
runtime
be
deployed
as
pots
as
well,
and
that's
where
things
get
really
interesting
is
we
can
scale
out
the
runners
in
our
environment
within
within
this
Cuban
at
ease
pod
go
find,
let's
say:
I
need
100,
concurrent
workers
available
to
me.
I
can
I,
can
spin
up
the
pods
or
spin
up
the
runners
as
I
pots
and
then
just
throw
Dobbs
at
the
runtime
and
it
all
fits
within
though,
and
shift
enterprise
server
model.
B
Then
you
know,
as
you
would
buy
it
any
other
service
to
scale
by
the
replication
controller.
I'll
just
add
notes
and
that's
another
thing
that
makes
a
open
should
be
free,
so
easy,
it's
really
easy
to
scale
up
and
down.
So
you
can
do
that
both
for
the
service
instance.
It
is
so
if
I
want
to
scale
up
iron.
B
Mq
I
want
to
make
sure
I
have
enough
notes
to
a
j
mq
again,
add
any
more
notes
for
work
load
capacity,
and
so
that's
where
the
runners
kind
of
come
into
class
is
being
able
to
scale
out
the
task
century.
Work
runtime
using
the
same
scale
model
as
you
boil
services,
and
that's
that's
huge-
that
gives
the
operators
to
openshift
enterprise
a
really
easy
way
to
add
more
capacity
in
the
same
way.
B
Past
is
the
same
way
that
would
services
and
applications,
and
then
we
work
together
with
with
customer
and
and
with
the
opposite
of
team,
to
do
the
service
broker.
So
you
know
similar
to
the
online
bottle,
we're
buying
the
application
to
your
account
or
pride
of
service
to
ramifications,
and
then
provision
accounts.
Accordingly.
In
the
same
thing,
the
enterprise
world
and
again
iron
I/o,
is
multi-tenant
put
sign.
We
can
make
that
multi-tenancy.
You
know
second
dent
into
the
organization
for
the
stowing
enterprise
deployment.
B
B
Ok,
I
will
end
things
with
a
quote
that
just
basically
perfectly
frames
this
deployment
model
for
both
a
open
shift
and
iron
I.
Oh
I,
found
this
through
IDC
is
that
this
concept
of
kind
of
public
and
private
pass
in
this
hybrid
world
is
where
workloads
can
be
directed
to
either
public
or
private
instances,
depending
on
how
enterprises
application
policy.
So
that
is
exactly
what
we
talked
about:
distributing
workloads
in
different
environments
based
on
where
they
went
where
they
should
be.
B
You
know
some
are
secure
on
friends,
I'm,
less
secure
to
be
done,
public
cloud,
but
being
able
to
direct
those
very
easily
is
going
to
be
super
portable
for
building
out
these
kind
of
hybrid
cloud
solutions,
and
you
know
both
open
shift
and
I.
Don't
I
are
all
about
being
flexible
and
are
all
about
being.
You
know
integrated
nicely
to
work
together,
and
so
that's
gonna.
Do
it
far
as
next
steps?
B
You
know
we're
here
at
iron
toyota,
you
can
find
out
more
one
thing,
we'd
like
to
do
with
some
of
our
you
know,
people
who
are
interested
in
learning
more
about
it
is
set
up
a
pair
programming
session,
or
we
can
actually
give
you
a
hands-on
walkthrough
of
a
platform
and
give
you
a
much
deeper
demo
on
the
hello
world.
One
I
gave
we
can
do
architecture
reviews,
and
this
is
where
we
get
into
the
kind
of
identifying
where
its
tasks
tasks
a
trick.
B
A
Right
well,
Ivan.
Thank
you
very
much
on
for
this.
It
was
certainly
an
eye-opener
for
myself.
I
didn't
realize
how
easy
it
was
to
embed
a
synchronous
into
you.
You
know
is
a
pretty
simple.
Semel
of
the
hello
world
is
pretty
awesome
deceive.
You
know
one
line
of
code,
basically
being
able
to
have
anything
to
mix
fast-forwards
what
women
really
an
eye
on
the
commandment
I'm
always
excited
to
see
hair
part
program
over
a
menu
beginning,
that's
a
great
way
to
learn
all
code
talk.
A
We
haven't
had
any
at
all
questions
as
fat
for
that
coming
means
you've
had
answered.
You
know
street,
look
like
jeans!
Well,
I'm,
just
unmute
everybody
there's
anyone
who
has
a
question
you're
welcome
glass,
but
otherwise
I'd
like
to
thank
you
again,
very
much
for
sharing
mix
and
just
let
everyone
else
go.
Give
it
a
try
on
over
cookie
and
give
us
your
feedback
on
it.