►
From YouTube: Extending the Reach of Cloud Foundry: A New Stack and Supported OS - Cornelius Schumacher
Description
Extending the Reach of Cloud Foundry: A New Stack and Supported OS - Cornelius Schumacher & Mario Manno, SUSE
In this talk the presenters will walk you through the different layers that make up a running Cloud Foundry deployment: hosts, stemcells and application stacks.
This is the first top-to-bottom alternative to Ubuntu in the Cloud Foundry arena, and it's all supported by SUSE.
With the new stemcell builder repo it's now easier than ever to create a custom stemcell. We added openSUSE as a completely new OS to the builder, but it can also be used to just modify existing stemcells.
A demo of a highly-available deployment SCF will show the product in action. The talk will also walk the audience through the changes that were required to support the new stack and the benefits that come with it.
About Mario Manno
Mario works as software specialist in the cloud and systems management department at SUSE Linux. After visiting the Pivotal Dojo he joined the BOSH OpenStack CPI team. In his free time Mario contributes to several open source projects and helps bringing video recordings of community conferences online. In the past he’s been giving talks in Germany about different topics, like IT security, Open Source and software development.
About Cornelius Schumacher
Cornelius is a distinguished engineer and engineering manager at SUSE Linux. He works on SUSE's Cloud Foundry product and the technology around it. Passionate about open source and community Cornelius is a long time contributor to many open source projects for more than a decade, such as KDE, openSUSE, the Open Build Service, or BOSH. Cornelius is a regular speaker at international Linux and open source events.
A
Yeah,
hello:
we
want
to
talk
about
yeah
we're
in
the
extension
tract
and
we
want
to
talk
about
one
particular
extension
point,
which
is
the
operating
system
in
Cloud
Foundry.
So
we
add
those
as
an
operating
system
and,
of
course,
have
a
specific
interest
in
that
and
also
specific
knowledge.
So
we
want
to
talk
about
the
role
of
the
operating
system
within
cloud
foundry
and
how
you
can
extend
that
how
you
can
go
to
another
operating
system
and
just
use
that?
Where
are
we
so?
A
My
name
is
Cornelius
ramappa
I'm,
a
distinguished
engineer
at
Sousa
I
have
done
the
dojo
in
the
Bosch
team
last
year
and
have
worked
in
the
OpenStack
CPI
team
for
almost
a
year
and
nowadays
I'm
mostly
managing
the
European
part
of
the
engineering
team
working
on
our
crowdfunding
product
at
Sousa.
Ok,.
A
A
That's
a
beautiful
platform
that
you
don't
have
to
do
that
and
if
we
look
into
the
architecture
of
cloud
foundry
in
a
very
simplified
form
from
a
user's
point
of
view
from
an
application
developers
point
of
view,
the
user
application
is
running
somewhere
on
the
platform,
there's
Cloud
Foundry
to
interact
with.
Why
are
the
API?
Why
are
the
command
line?
Client?
A
There
are
services
which
can
be
brought
in
and
this
is
running
on
some
infrastructure
as
a
developer,
I
don't
really
care
how
this
happens,
but
if
we
look
a
little
bit
deeper,
what
actually
is
in
there
and
that's
more
going
into
the
operators
perspective?
Then
we
actually
see
that
there
are
certain
components
required,
so
the
user
application
is
running
in
containers.
A
They
need
a
stack,
a
language
time
to
run
on,
which
is
provided
by
the
billet
packs,
and
this
has
to
run
on
something
in
the
container
which
is
providing
the
root
filesystem,
which
is
an
operating
system.
So
that's
one
green
box,
where
we
have
an
operating
system
in
cloud
foundry
and
recall
that
the
stack
if
we
look
at
the
infrastructure,
this
is
usually
running
on
virtual
machines
and
each
virtual
machine
of
course
needs
an
operating
system.
So
it
can
run
the
containers
or
the
services.
A
The
cloud
foundry
which
are
required,
and
this
operating
system
is
the
second
part
where
cloud
foundry
has
the
spit
in
operating
system
and
that's
what
we
usually
call
the
stem
cell,
where
we
are
coming
there
from
from
Zuza
from
the
zuzo
point
of
view
why
we
are
interested
in
that,
so
those
are
just
celebrated
its
25th
birthday.
This
is
one
one
of
the
birthday
cakes.
A
A
couple
of
our
engineers
created
I,
don't
know
how
tasty
they
were,
but
they
at
least
look
beautiful,
and
these
25
years
are
actually
after
doing
Linux
operating
systems,
building
operating
system,
distributing
operating
systems
and
extending
to
two
other
products.
As
well
as
cloud
foundry
now
so
for
us,
we
do
a
distribution
for
the
community,
a
community
driven
distribution
openSUSE
which
is
feeding
into
our
enterprise
distribution,
zou
linux,
enterprise,
and
there
that's
the
two
variants.
A
We
provide
to
the
community,
to
customers
to
users
and
where
we
also
then
add
our
enterprise
support
for
the
enterprise
version.
For
example,
where
we
have
people
working
upstream,
we
have
kernel
developers.
We
are
able
to
fix
a
lot
of
problems
there
and
we
know
how
to
build
this
stuff,
and
so
that's
where
our
natural
interest,
of
course,
to
extend
the
reach
of
Cloud
Foundry
to
our
customers.
Who
expect
that
it's
running
on
those
that
we
are
putting
those
into
Cloud
Foundry
yeah?
A
B
The
stem
cell
arm
is
basically
what's
posh
using
to
put
on
the
VMS
and
on
the
second
part
of
the
talk,
we
will
also
talk
about
how
we
put
the
root
filesystem
layer
for
the
files
on
stem
cell.
We
have
for
the
Sousa
Cloud
Foundry
product,
but
so
this
is
classic
partial
and
here
and
infrastructure
at
the
bottom,
and
on
top
of
that
you
have
your
operating
system,
and
so
the
operating
system
is
very
much
here
and
but
is
very
much
designed
to
have
different
kinds
of
stem
cells.
B
For
example,
if
you
look
at
the
bottle
home
page,
we
have
the
Ubuntu
trusty
base.
Stem
cells.
Ubuntu
trusty
is
like
three
years
old
by
now
and
will
be
supported
for
I,
don't
know
one
of
the
half
year
when
you
will
have
chips,
which
is
something
to
get
security
updates,
and
there
are
also
two
other
kinds
of
stem
cells.
It's
a
Windows
stem
cell
and
the
central
stem
cell.
I.
B
B
This
is
a
separate
repository,
I
think
since
the
beginning
of
this
year,
which
made
development
so
much
easier.
So
should
not
have
it
all
in
one
big
posh
repository,
but
you
have
like
a
separate
repository
for
that.
So
this
is
where
you
have
stages
which
are
used
to
create
an
image
of
your
operating
system,
and
there
are
several
stages
here,
like
their
stages,
which
are
used
to
create
the
US
base
image
layer,
which
is
basically
on
just
to
watch
the
bootstrap
produces
for
you.
B
If
you're
running
Ubuntu
a
DB
on
like
a
change
route
able,
filesystem
or
if
you're,
using
openSUSE,
it
would
be
done
by
MTV,
and
on
top
of
that
you
have
a
stem
cell
layer
and
the
stages
are
not
so
aligned
to
these
layers.
There's
some
mix
up
in
there,
but
there's
stuff
here,
for
example,
to
harden
it.
She
locked
down
user
accounts
and
install
arm
drivers
for
your
infrastructure,
like
paravirtualization
drivers
or
into
the
network
interface
drivers.
B
So
this
is
all
done
here
and
the
stem
cell
layer,
and
this
is
where
we
put
in
pv
pv
arm.
I
think
you
will
talk
about
TV
later
also,
but
it's
really
need
you
give
it
an
XML
file.
At
the
end,
the
XML
is
being
passed
into
some
specification
of
your
operating
system
and
it
goes
and
installs
all
the
packages
and
Titus's
up,
and
you
end
up
with
the
tab
wall.
We
also
added
a
custom
kernel
in
here
on
because
we
need.
B
We
still
need
our
fares
to
run
a
lot
of
them
like
conkers
or
I.
Don't
know
some
of
the
releases
require
all
of
us,
so
we
had
to
put
it
in.
We
also
have
run
it
here
on
to
start
processors,
and
we
also
remove
some
stuff
like
there's,
no
Just
In
and
the
justices
standard
management
tool
of
Sousa
and
it's
removed
here
from
the
images.
So
you
would
have
to
buy
your.
You
would
have
to
build
your
own
image
to
get
stuff
back
in
there
and
it's
not
really
hard
and
the
questioning
stem-cell
builder.
B
You
have
this
file
stage
collection
and
it's
a
huge
file
and
just
combined
stages
into
these
methods,
which
are
then
called
for
the
platform
or
they
call
each
other
like
here
was
the
Boche
step
stage
and
just
as
an
example,
this
file
is
really
long
and
these
stages
are
just
shared
scripts,
which
I
executed
on
the
change
route.
So
in
these
shell
scripts
you
can
just
start
changing
stuff
in
the
other
image
and
afterwards
it's
all
gates,
it's
all
getting
packaged.
B
So
the
first
package
that's
being
created
the
COS
image,
and
then
you
take
the
US
image
in
a
second
yep
and
he
creates
like
the
actual
stems,
which
is
some
kind
of
an
image.
Whatever
the
infrastructure
needs,
it
might
be
a
raw
disk
image.
It
might
just
be
at
our
top
five
system
like
it
is
on
OpenStack,
so
you
can.
Actually,
if
you
have
OpenStack
stem
cell,
you
can
actually
unpack
it.
It's
just
two
tables
changed
something
and
pack
it
back
together.
B
So
yeah,
that's
that's
all
what
we
have
to
do
and
if
you
want
to
use
it,
it's
just
as
easy.
As
that
you
take
your
deployment
manifest,
for
example,
here
with
zookeeper,
and
you
exchange
the
Virgin
and
I
approach
it.
So
that's
that's
really
easy,
but
you
might
run
into
trouble
into
problems
with
the
releases
because
releases
do
all
kinds
of
stuff
on
the
operating
system
they
might
expect
certificates
to
be
in
a
certain
place.
They
might
expect
binaries
to
be
in
a
certain
place.
Opensuse
has
a
different
binary
structure.
B
Networking
is
a
little
bit
different,
so
there
are
a
lot
of
small
differences
from
below,
for
especially
with
software
versions,
because
we
are
currently
working
in
openSUSE
leap,
we're
also
working
on
SUSE
Linux
Enterprise,
which
is
a
little
bit
more
conservative
regarding
versions.
But
leap
has
very
new
software.
That
means
we
have
a
new
kernel.
We
are
system
D
based
which
changes
a
lot
and
a
lot
of
the
tools
like
for
partitioning.
They
have
any
command-line
interface,
it
might
not
integrate
without
patching
bosh
agent
and
the
boss
needs
them
server.
B
So
I'm
Sookie
on
Susan
I'm
not
going
to
do
a
demo,
because
it's
really
easy.
If
you
look
at
the
stem
cells,
you
just
have,
for
example,
a
warden
stems
and
you
can
just
deploy
with
it
and
if
you
would
look
into
one
of
these
boxes
with
SSH,
you
could
see
that
the
kernel
running
there
is
actually
out
into
the
kernel
and
the
process
list.
It's
yeah
kind
of
what
you
expect,
like
the
bush
agents,
they're
running
with
the
openSUSE
platform
and
yeah.
B
If
you
want
to
try
these
stem
cells,
we
are,
we
are
still
in
the
process
of
building
them,
so
I
think.
Currently
we
only
the
AWS
and
the
open
stem
cell
up
there.
The
tests
are
not
all
green,
yet
we
are
still
working
on
the
pipelines,
but
this
would
be
the
URL
to
download
them
in
the
future.
Ok
I
think
you
want
to
talk
about
the
stacking.
A
Exactly
so
that
was
the
stem
cell
one
part,
the
other
part
is
the
stack
and
that
that's
how
we
stack
at
Zeus's,
so
we
have
got
stack,
chameleons
I
might
want
to
get
the
small
one
or
that
so
the
stack
in
Cloud
Foundry.
That's
that's
the
part
which
is
used
in
the
containers
running
the
zoo
user
applications,
so
I
showed
the
architecture
before
so
we
have
the
user
application
running
on
a
language
stack
which
is
provided
by
the
bit
pack
and
then
running
on
a
root
filesystem
representing
the
operating
system
in
the
container
so
running.
A
A
A
That's
where
cloud
family
provides
the
yeah
options
in
the
command
line
to
actually
specify
the
stack
you
want
to
run,
but
you
need
to
provide
that
and
that's
what
we
are
doing
as
an
operating
system
and
we
are
putting
our
operating
system
into
the
into
that,
and
we
I
will
talk
about
how
we
actually
do
that
in
a
minute.
On
top
of
that,
we
need
the
bed
pack,
which
provides
all
the
binaries
the
runtime
for
languages,
what
the
user
application
actually
requires.
So
you've
also
heard
about
that.
There
are
many
many
different
build
packs.
A
There
are
lots
of
binaries
and
they
are
upstream
pipelines
to
build
that
and
to
construct
that-
and
we
mostly
use
the
upstream
pipelines
there
to
actually
construct
the
build
path
with
a
binary
which
fit
the
sewer
operating
system
image.
There's
a
lot
of
compiling
involved
there.
It's
a
lot
of
code,
it's
also
different
pipelines.
So
this
is
actually
one
of
the
more
challenging
parts
where
also
the
structure
is
not
always
really
meant
to
be
used
in
four
different
operating
systems.
A
How
do
we
build
this
base
image
and
Mary
already
mentioned
TV,
so
we
have
tools
we
use
to
build
our
distribution
and
to
build
all
the
packages
for
the
distribution
also
bid
containers-
and
we
are
talking
mostly
about
two
tools
here.
One
is
keavy,
which
is
our
more
less
universal
image
building
tool.
A
These
packages
and
where
they
are
coming
from
and
you
can
specify
the
configuration,
so
you
really
have
a
definitive
description
and
definition
of
what
the
image
is,
and
you
can
put
that
under
version
control
and
then
run
Kiwi
on
it
and
Kiwi
will
always
create
the
same
image
of
that.
It's
like
some
else.
A
Oh
sorry,
for
not
having
a
yummy
file
here,
but
Kiwi
I
think
predates
at
the
time
when
Yama
really
became
a
walk
and
takes
a
mile
is
a
fine
description
for
that
Kiwi
is,
you
can
run
Kiwi
standalone,
but
the
more
interesting
part
actually
is
running
it
within
the
open
page
service
and
the
open
bit
service
is
our
build
automation
tool.
That's
where
we
put
all
the
components
of
the
distribution
in
all
the
components
which
are
required
to
build
packages
to
build
containers
and
the
open,
build
service
takes
care
of
the
automation.
A
It
takes
care
of
dependency,
tracking
of
automatic
rebuilds
of
dependencies
dependencies
change
of
having
the
version
history
of
being
able
to
reproduce
births.
So,
within
with
the
open,
build
service
or
the
spill
chain
becomes
small
as
ethic
and
really
very
well
specified,
and
you
can
be
sure
that
you
get
the
same
results
at
the
same
time
and
you
are
up
to
date.
A
You
have
security
updates
within
the
images
and
the
dependencies
are
automatically
resolved
and
reboots
are
done
so
so
that
that
we
can
actually
be
sure
that
we
provide
exactly
the
images
we
want
in
the
way
we
want
them
with
the
security
updates.
We
want
to
have
them
and
can
then
use
them
for
all
kinds
of
other
things
like
in
this
case,
our
use
cases,
the
the
stack
for
Cloud,
Foundry,
good,
there's
one
more
component-
and
we
already
mentioned
that
because
we
have
another
flavor
of
stem
cell.
Actually
we
talked
about
the
containerization
of
Cloud
Foundry.
A
We
do
for
our
cloud
phone
your
product
and
there
is
a
it
looks
a
little
bit
different.
So
this
is
the
architecture
diagram
I
showed
before,
with
the
virtual
machines
running
an
operating
system
and
then
running
Cloud
Foundry.
On
top
of
that,
what
we
do
in
in
our
zukar
foundry
variant,
we
put
cloud
foundry
the
cloud
foundry
services
into
containers
as
well
and
run
them
on
queue
bonitas.
That
means
the
operating
system.
A
Layer
moves
one
step
up
and
it's
not
required
in
a
virtual
machine
anymore,
but
it
has
to
become
a
root
filesystem
in
a
container
so
that
we
have
the
base
there
as
well,
and
it
should
correspond
to
the
to
what
the
stem
cell
has
been
and
thank
you.
Benitez
can
run
on
whatever
infrastructure
is
below
that,
but
we
do
need
to
create
this
equivalent
to
a
stem
cell
in
the
container
space.
A
So
we
call
that
a
fissile
stem
cell,
because
fissile
is
the
tool
we
use
to
containerized
cloud
foundry.
So
you
heard
probably
other
presentations
about
how
that
works.
What
was
talking
about
that
before?
So
we
take
the
cloud
foundry
release
the
bottle,
release
and
convert
that
into
container
images
using
Fissel,
and
these
container
images
naturally
need
a
base
image
and
that's
what
we
call
the
fissile
stem
cell
container
image,
which
we
extract
from
the
wash
stem
cell.
So
we
use
one
source
of
truth.
A
There
so
that
the
watch
stem
cell
we
provide
to
the
community
we
provide
for
both
users.
We
extract
the
base
layer
for
our
containerized
versions
from
that
using
just
the
same
bit
pipeline.
So
it's
just
a
small
modification
to
how
this
thing
is
built
to
also
extract
the
container
image,
which
then
contains
the
same
packages,
the
same
base
as
the
bottom
side,
yeah,
and
that's
how
it
runs.
So
we
have
those
three
components,
and
we
do
want
to
show
this-
how
this
actually
behaves.
So
we
do
have
a
small
demo
here
of
the
stacks
okay.
A
A
Almost
there
perfect
so
so
our
configuration
is
already
there.
So
we
have
the
stand
at
the
default.
Cf
Linux
efforts
to
that
and
we
have
in
addition
our
openSUSE
42.
So
that's
our
stack
built
on
there
based
on
openSUSE
42.
So
that's
the
community
version
we
provide
to
the
community
yeah
and
now,
if
we
push
an
application,
it
will
actually
use
this.
The
stack.
A
A
So
you
all
know
that
it
will
look
at
the
build
pax,
don't
know
what
it
needs
figure
out,
what
the
peg
to
use
and
then
do
all
this
logic
we
described
before
with
staging
the
container
building
the
the
required
binaries
with
putting
that
into
into
the
container,
which
is
then
run
by
the
crowdfunding
runtime
yeah.
So
this
takes
a
little
bit
figuring
out
all
the
different.
A
A
B
C
A
A
A
A
Yeah
we
have
to,
we
have
done
the
demo.
So
what's
next
we're
working
on
that,
we
will
do
continuously
update
the
the
boss
times.
The
fizzle
stems
the
operate,
the
stack
of
course.
So
this
is
the
work
which
is
going
on
and
it
will
of
course
continue
to
go
on.
We
use
openSUSE
as
the
community
version.
So
that's
that's
what
we
published
that's
what
we
provide
upstream.
We
use
zuly
SUSE,
Linux
Enterprise
for
our
product.
So
as
a
customer,
you
get
the
the
Enterprise
version,
which
code
wise
is
almost
it
identical.
A
A
We
are
working
there,
so
we
want
to
extend
the
reach
of
Cloud
Foundry
there
make
make
it
work
with
people
who
want
to
use
Sousa
just
as
well
as
with
any
other
operating
system
and
I
mentioned
that
the
same
size
I
think
that
that
works
nicely,
there's
not
too
much
to
do
there
other
than
adding
support
for
our
operating
system
for
the
build
packs.
We
ran
into
a
little
bit
more
trouble.
So
this
is
an
area
where
we
in
the
future.
A
We
might
want
to
look
into
how
we
can
actually
streamline
how
we
build
them,
because
a
lot
of
the
binaries
which
are
built
a
lot
of
the
compiling
which
is
happening
there
stuff.
We
would
do
anyway
for
the
packages
for
the
distribution,
so
maybe
leveraging
our
build
system.
We
can
have
a
more
efficient
and
nicer
process,
maybe
also
contributing
things
upstream
to
and
generally
improve
the
bit
process
there
yeah.
So
that's
what
we
wanted
to
tell
you
about:
the
user,
spec
and
the
zuzu
stem
cells
and
yeah.
We
are
open
to
questions.
D
One
question
you
mentioned
that
you
had
to
introduce
fissile
in
the
pipeline.
Can
you
point
out
if
you
had
to
exchange
the
digger
with
the
app
runtime
application
runtime
by
fissile,
or
was
it
only
necessary
to
move
the
the
Cloud
Foundry
services
like
the
cloud
controller
and
so
on
more
in
a
lightweight
situation,
or
was
it
to
make
the
deployment
of
the
Cloud
Foundry
and
smaller,
or
it
makes
a
very
yeah.
A
So
we
are
still
using
Diego,
so
we
are
using
the
certified
set
of
components.
So
Diego
is
part
of
that
and
we
use
that
which
is
running
in
inner
container.
So
we
have
this
container
in
a
container
which
isn't
a
big
deal,
but
we
use
the
certified
components
so
the
crowdfunding
services
they
are
running,
containerized,
that's
different
to
the
standard,
crowdfunder
distribution
and
that
actually
makes
it
possible
to
run
them
in
a
much
more
compact
form
so
like
like
being
able
to
run
it
on
a
laptop.
That's
that's
not
possible.
A
C
So
this
is
great
one
thing:
I
have
a
question
about,
is:
did
you
guys
get
a
chance
to
test
like
the
scalability
of
the
that
solution?
In
terms
of
now,
you
have
a
Cloud
Foundry?
How
does
that
compare
to
when
you
do
it
on
top
of
VMs?
In
terms
of
you
know
how
many
apps
can
I
push,
and
so
on
things
like
that,
yeah.
A
So
at
the
moment
we
had
an
early
stage,
so
our
first
product
release
will
be
end
of
the
year,
so
we
haven't
gotten
much
really
work
deployments
yet
so
the
scaling
test
I
think
we
are,
it's
probably
something
Troy
can
answer
in
a
better
way,
so
we
have
inherited
a
lot
of
the
code
and
the
experience
from
from
the
HP
people
and
it
was
a
product
before
so
so
there
is
some
experience
there
with
our
new
product.
At
the
moment
we
are,
we
are
not
yet
at
a
stage.
E
Don't
my
answer
is:
no,
we
haven't
done
it
yet,
but
we
we
have
been
asked
to
give
a
performance
comparison
between
a
regular,
because
we
can
do
it
with
our.
So
what
I
want
to
point
out
is
all
of
this
work
works
with
standard
Bosch
deployment
as
well.
So
when
we
do
that
performance
test,
we're
going
to
do
it
with
the
opens
openSUSE
stem
cell
in
a
regular
Bosch
deployment
against
one-
that's
been
fissile
eyes
and
running
on
kubernetes,
so
we
can
do
them.
Apples
to
apples
comparison.
F
I
was
wondering
we
just
learned
yesterday
that
Kubo
will
become
a
container
runtime
as
part
of
Cloud
Foundry
and
now
you're
telling
me
that
you
put
Cloud
Foundry
on
a
containerized
environment.
This
seems
redundant
so
I'm
wondering
if
I
write
an
application
as
a
container.
What
benefit
do
I
get
putting
it
on
a
Cloud
Foundry
running
on
a
container
runtime
instead
of
putting
it
on
the
container
runtime
directly.
A
It's
I
think
there
are
different
use
cases
and
we
are
talking
here
about
what
we
have
done
for
Cloud
Foundry.
We
are
running
on
top
of
queue
bonitas.
It
doesn't
really
matter
where
this
kubernetes
is
coming
from,
so
it
could
be
one
deployed
by
Cuba.
It
could
be
something
deployed
through
into
another
product
like
our
product
as
well,
but
then
there
is,
of
course,
some
overlap
and
redundancy,
maybe,
but
that's
something
which
is
probably
out
of
the
scope
of
what
we
are
discussing
here,
but
yeah.
G
I,
don't
think
this
actually
so
I
think
the
question
you're
asking
is:
why
would
I
deploy
in
cloud
foundry
instead
of
kubernetes
I?
Think
that's
present
whether
or
not
this
work
exists
at
all.
You
know.
That's
just
a
you
know
what
user
experience
do
I
want.
What
developer
experience
do
I
want.
You
know
deploying
Cloud
Foundry
on
top
of
kubernetes.
You
know
the
fact.
That's
on
top
of
kubernetes
I
would
think
that
should
be
invisible
to
the
developer.
You
know
just
that's
just
a
nice
layer
there
they
don't
shouldn't
nowhere
care
about
that.
A
Yeah
for
the
developer,
the
story
is
run
it
in
the
cloud
for
me:
I
don't
care
how
but
one
operator,
of
course
it
makes
a
difference,
what
what
you
are
running
and
if
you
have
AQ
Benitez,
and
you
want
to
run
code
funny
on
top
of
that,
then
you
are
in
the
situation
where
you
probably
want
to
go
a
road
like
this.
If
you
are
using
Bosch
to
deploy
your
Cloud
Foundry,
then
you
probably
wouldn't
look
into
that.