►
Description
A roundtable discussion on containers, platform as a service (PaaS) and the future of application development featuring Lauren Cooney, Cisco; Craig McLuckie, Google; Steve Pousty, Red Hat; Sam Ramji, Cloud Foundry and Stephen O'Grady, Red Monk (Moderator). From Collaboration Summit 2015 in Santa Rosa, CA.
B
A
Wow,
actually
it
was
much
easier
when
I
standing
up
before
they
like
keep
blinding
right
now,
so,
as
Jim
said,
I'm
Stephen
O'grady,
some
of
you
may
talk
this
morning
as
an
analyst
firm
again,
you
know,
most
of
you
are
familiar
with.
What
we
do.
This
is
a
the
topic
of
this
particular
panel
is
one
that's
sort
of
near
and
dear
to
my
heart.
We
spent
a
lot
of
time
trying
to
you
know,
containers
platforms
VMs.
How
do
all
these
things
fit
together?
What
do
these
changes
mean
and
to
help
answer
that
question?
A
D
D
D
E
Name
is
Craig
mcluckie
on
the
product
guy
at
Google
responsible
for
our
cloud
computing
product
portfolio,
so
compute
engine
app
engine
and
the
emerging
container
engine
portfolio
I
was
the
founder
of
the
Cooper
Nettie's
project.
What
one
of
the
fun
is
the
company's
project,
which
is
which
brings
Google
style
orchestration
to
the
Linux
application
container
world
prior
to
that
I
grew
up
at
Microsoft.
B
B
B
I
two
caveats
I
usually
play
the
saucy
person
on
the
panel
I'm
getting
kind
of
tired
of
that
role,
because
then
everybody
argues
with
me
and
I'm,
just
not
feeling
up
to
it,
but
I
may
still
go
saucy
and
if
I
go
saucy,
that
means
I'm
arguing
just
so
that
we
have
a
fun
panel,
not
necessarily
because
I
strongly
believe
it.
So
don't
hunt
me
down
later
and
second
I'm
from
New
York.
So
if
I
use
the
word
guys,
it's
not
a
gender
specific
term
guys
is
gender-neutral.
A
Actually,
really
don't
care
where
we
start
with
this
question,
but
one
of
the
one
of
the
questions
that
we
get
all
the
time
as
analysts
is
pretty
simple.
You
know.
Obviously
pass
is
evolved
to
offer.
You
know
essentially
a
set
of
platform
services
depending
on
how
you
define
that,
on
top
of
you
know,
some
infrastructure,
substrate
containers
have
made
a
huge
jump.
You
know,
certainly
in
last
12
to
18
months.
You
know
we
like
to
tell
people
we've
been
doing
this.
A
red
monk.
A
You
know,
since
2002
and
docker
in
particular,
is
one
of
the
fastest-growing
projects
we've
ever
seen
from
a
visibility
standpoint.
So
how
do
these
things
fit
together?
You
know,
how
do
they
not
I
mean
is?
Are
they
competitive?
Did
they
overlap
and
I
think
said
that
I
wasn't
going
starting
where
I
guess
else?
Where
was
it.
D
D
All
stack
up
right
but
I
think,
ultimately
it's
about
projecting
user
space
across
the
data
center.
A
lot
of
data
center
technologies
exist
that
make
it
easier
to
render
the
data
center
as
api's
to
be
able
to
work
with
all
the
different
resources.
Different
instantiations,
but
your
your
typical
app
developer
does
not
and
never
wants
to
understand
those
they
want
to
be
able
to
place.
You
know
basically
say
you
know,
as
we
all
learned,
get
push
heroku
master
right.
D
You
just
want
to
be
able
to
say
here's
my
code,
please
operate
it
within
an
SLA,
that's
going
to
make
everybody
happy
and
the
less
details.
I
need
to
know
about
that.
The
better
so
I
think
the
focus
that
Cloud
Foundry
is
taking
is.
Can
we
have
a
massively
distributed
ecosystem
where
we've
got
consistency
and
a
lot
of
app
developers
both
building
core
apps
within
enterprises
bespoke
applications,
and
can
we
create
a
really
powerful
is
V?
D
You
know
independent
software
vendor
marketplace
where
you
know,
companies
like
Sugar,
CRM
or
documentum
or
brand
new
companies
are
building
small
apps
for
the
enterprise
that
enables
us
to
have
an
Internet
like
experience
in
the
enterprise.
If
you're,
if
you
work
in
a
large
company
today,
you
can't
imagine
the
misery
that
you
experience
with
internal
apps,
the
compared
to
the
delight
of
being
average
user,
not
even
a
super
user
on
the
internet,
yeah.
E
D
A
C
Think
it's
containers
versus
past
I
actually
see
containers.
As
you
know,
a
component
that
can
work
inside
of
a
past
environment,
but
containers
can
also
work
inside
of,
for
example,
and
infrastructure
as
a
service
environment
right.
So
you
know
a
lot
of
what
sometimes
we
look
at
is
we're
building
out.
You
know,
new
network
services
that
are
virtualized
right.
How
do
we
container
eyes
those
so
that
they
can
run
across
multiple
VMs,
for
example,
raise
so
they're
not
dependent
upon
one
vm?
C
Are
the
vm
things
along
those
lines,
so
I
don't
see
them
as
competing
I,
see
them
as
actually
complementary
in
certain
situations,
but
I
also
see
them
as
growing
extremely
fast
docker.
You
mentioned,
you
know,
is
not
only
growing
but
also
being
used.
Inside
of
you
know,
other
projects
like
shippable
and
stuff,
like
that
I
think
that's
really
important
to
look
at
a
degree.
E
I
tend
to
think
about
I
think
these
things
are
very
uniquely
aligned,
I
think
what
what
doctors
already
given
us
is
a
very
elegant
way
to
solve
a
packaging
and
deployment
problem.
That's
existed
since
forever
and
I
think
it's
it's
catching
on
like
wildfire,
because
it's
created
this
incredibly
powerful,
hermetically
sealed
Adam
of
deployment.
So
it's
solved
one
of
several
problems
that
pass
was
looking
to
address
and
solved
it
incredibly
well.
I
think
if
you
look
more
broadly
there's
still
a
lot
of
things
that
you
need
to
to
run
a
modern,
enlightened
application.
E
So
you
can
log
and
monitor
and
deal
with
it
and
then
there's
the
final
piece
to
this,
which
I
think
you
know
we
haven't
seen
as
much
sort
of
immediate
traction
on
buy
things
and
be
very
important,
which
is
the
actual
sort
of
application
environment,
the
curated
pieces,
the
dependency
management,
the
package
management
pieces
that
that
your
code
depends
on
and
I.
Think
if
you,
if
you
pull
that
whole
thing
together,
that
represents
that
the
promise
that
passes
had.
E
B
B
Well,
I
hope
and
switch
the
order.
Second,
let
me
hide
I
mean
they
all
said
the
same
things
I
was
going
to
say,
but
they
said
them
first
I
think
the
only
thing
that
I
would
say
is
I
think
almost
all
the
passes
that
I
know
have
been
using
containers
to
start
with
it.
Just
wasn't
docker
and
so,
like
you
said,
the
great
part
about
dr.
was.
It
was
a
nice
specification
that
we
could
all
come
to
agree
on
and
kudos
to
them.
Also
for
making
a
very
open
process
right.
B
E
B
B
Well,
I
saw
most
of
people
in
the
audience,
and
most
of
you
are
at
least
my
age
or
around
my
age,
and
when
you
were
growing
up,
writing
developer
soft.
When
you
are
developing
software,
it's
like
I
need
a
box.
Don't
you
put
any
vm
on
my
machine?
I,
don't
want
you
cohabitating
other
things
on
my
machine.
There
was
a
lot
of
cultural
resistance
to
VMS
and
I
think
what's
happened
is
the
vm
for
the
ice
breaker
for
containers.
People
got
used
to
running
on
virtualized
hardware,
and
so
what
containers
are?
What?
B
B
I
was
actually
not
very
excited
about
docker,
just
to
be
honest,
but
that's
because
I'd
use
a
pass
before
because
viet
to
me,
a
container
is
no
more
than
a
vm
just
with
better
specifications
and
lighter
weight
right
for
my
developer
experience
from
a
sysadmin
experience
and
other
experiences.
I
agree.
It
brings
a
lot
of
other
things,
but
as
a
developer.
B
You
know
how
often
do
you
instantiate
a
vm
as
a
developer
yeah.
That's
once
a
day
right,
you
boot
your
machine,
you
boot
your
vm
and
off
you
go
it.
Doesn't
I
still
had
to
like
manage
that?
Can
I
start
to
manage
the
container
right
like
I
start
to
install
the
software
into
the
container.
I
have
to
start.
E
B
B
B
I
agree
about,
but
my
point
is
a
vm
can
beat
my
IT
department
could
make
a
set
of
the
end
blessed
VMs
with
all
the
software
I
needed
and
I
booted
up
once
for
the
day
I
to
me
as
a
developer.
Containers
don't
get
me
much,
except
when
they're
put
with
things
that
make
them
more
exciting,
like
I.
Actually
fine
shocker
as
the
guy
who
works
on
red
hat
spass
a
pass
a
lot
more
exciting,
because
I
give
one
command
and
I've
got
my
whole
environment.
Yeah.
D
B
And
I
can
deploy
to
the
cloud.
I'll
have
to
worry
about
all
that
other
stuff
and
whether
it's
Cloud
Foundry,
whether
it's
ours,
whether
it's
her
Roku.
That
was
the
exciting
thing
as
a
developer
container,
but
the
one
thing
that
goes
come
back
way
home,
I
gotta,
give
it
I
got
to
give
one
thing
back
to
containers
and
I
think
this
is
the
part
where
we're
all
kind
of
pushing
right
now
and
I'm
really
hoping
this
comes
with
our
next
version
of
open
shift.
B
Is
I
can
take
my
same
containers
that
I'm
running
on
my
machine
dev
there
and
then
push
that
straight
to
the
to
the
cloud
and
have
that
work.
So
I
have
a
seamless,
desktop,
I
think
the
thing
that
all
of
us
have
missed
all
of
us,
including
Heroku
who's,
probably
done
the
best
job.
So
far,
is
it
seamless
desktop
to
cloud
deployment,
and
I
hope.
A
I
got
fifty
under
solvent.
Well,
we'll
come
back
to
that.
One
of
the
questions
I
wanted
to
actually
start
with
Lauren
on
to
get
the
perspective
you
know,
particularly
for
somebody
who's
coming
at
it
from
a
systems
perspective
is,
you
know,
has
this
changed
sort
of
our
fundamental
notion
of
what
the
atomic
unit
of
computing
it's
right
so
to
your
point,
Steve?
In
other
words,
one
of
the
things
that
you
know,
I've
talked
about
lots
of
people
talked
about
stood
for
is
for
most
of
us
coming
up.
You
know.
A
The
atomic
unit
was
a
server
if
I
wanted
to
build
something.
If
I
want
to
run
a
database,
something
I
needed
a
server
to
basis
on
VMS
were
sort
of
the
next
step.
You
know,
okay,
you
know,
hey
I,
have
this
sort
of
interim
virtual
sort
of
representation
of
this.
You
know.
Containers
are
not.
You
know,
sort
of
the
quantum
leap
that
necessarily
that
VMS
were
but
obviously
introduce
some
changes
in
terms
of
weight,
speed.
A
You
know
shared
infrastructure
and
so
on
so
to
warren
and
we'll
come
back
the
rest
of
panelists.
You
know
when
you
look
at
it
from
a
systems.
Perspective,
have
containers
in
particular
change
the
way
that
you
view
you
know
what
is
sort
of
the
most
basic.
You
know,
component
of
how
we
put
together
an
application.
C
C
Containers
are
pretty
exciting
because
maybe
they're
not
as
a
you
know,
say
sophisticated
as
developers
you
are
great,
and
so
they
allow
a
lot
of
things
to
occur,
that
they
traditionally
would
not
be
able
to
do
right,
and
so
we
have
to
look
at
the
developer
skill
set
when
you're
looking
at
actually
what
you're
going
to
be
using
now
from
a
systems
perspective.
What
we
have
is
a
lot
of
folks
that
were
used
to
kind
of
like
command-line
interface,
or
you
know,
like
server
administrators
things
like
that.
They're
really
excited
because
they
can
take.
C
C
These
stacks
are
flattening
right,
so
you
have
kind
of
like
your
app
server,
not
flattened,
to
be
kind
of
like
a
platform
as
a
service.
We've
got
your
infrastructure
flatten.
Your
server
storage
and
compute
right
be
infrastructure
as
a
service.
Now
so
you
have
to
look
at
you
know
when
you're
looking
at
pass
and
infrastructure
service.
Do
you
want
those
tightly
coupled
or
more
loosely,
coupled
so.
A
E
Of
I
think
it's
I
think
it
has
fundamentally
changed
the
way
that
people
experience
and
consume
software.
I'm
going
to
look
back
on
my
experience.
I
did
compute
engine
before
we
did
container
engine
and
it
was
pretty
jarring
the
the
sort
of
the
difference
in
experiences
between
someone
who's
coming
into
this
VM
based
product.
So
we
were
very
proud.
You
know
a
young
team
just
got
our
first
production
users
and
we
started
looking
at
what
people
were
doing
with
it.
E
It
just
didn't
make
any
sense,
because
we
were
Google
guys,
like
everything's,
in
containers,
a
google
or
I'd
like
everything
was
there
we
looked
at
the
we
look
at
the
efficiency
levels
that
folks
were
getting
out
of
these
contain
out
of
out
of
the
the
vm
based
offerings.
We
looked
at
the
atom
of
deployment,
the
set
of
tools
they
were
using.
It
looked
nothing
like
what
we
were
used
to
and
I
think
that
you
know
one
of
the
things
that
this
container
revolution
is
bringing
to
bear
is
it's
changing
the
basic
atom
of
software
consumption.
E
E
Think
that's
to
me
personally
the
most
exciting
thing
about
this.
You
know
we've
been
doing
it
for
years
inside
Google
and
now
we're
able
to
really
start
seeing
ways
that
people
outside
of
Google
can
can
run
these
these
these
much
more
enlightened
applications.
As
a
result
of
this
new
Adam
of
software
deployment,
consumption,
everything.
D
So
looking
at
it
from
the
developer
down
from
the
app
developer
down
rather
than
from
the
systems
engineer
or
the
sysadmin
up,
containers
are
nice
for
separating
the
concerns
of
modern
applications.
Right
you're
going
to
you
need
a
place
to
put
all
of
your
stateless
code
that
you're
going
to
do
your
fire
hose
type
io
with
and
then
you've
got
services
which
you
know
are
not
going
to
be
in
your
container
they're,
going
to
be
system
level
services
that
you
can
depend
on
where's
my
Redis
right
where's,
my
wearing
my
network
interface.
D
What
are
the
other
things
that
I
need
to
rely
on
some
of
the
feedback
that
I've
heard
in
the
last
month?
It's
actually
exactly
28
days
in
my
new
job,
so
it's
important
to
listen
the
things
that
I
keep
hearing
or
where's
my
SLA
for
the
services
below
the
container
level.
We
know
that
we
need
to
depend
on
on
storage
on.
You
know,
image
transformation
on
all
sorts
of
things
that
we
don't
want
to
do
with.
So.
For
me,
the
big
revolution
is
microservices.
D
The
idea
that,
as
an
app
developer,
you're
now
having
a
consistent
concentric
ring
approach
to
architecture
containers
are
one
of
a
number
of
technologies
that
make
it
by
temecula
nicer
to
build
microservices,
know,
you'll,
have
a
stable
environment
and
know
that
you
can
depend
on
the
systems,
engineers
and
those
who
are
implementing
a
lot
of
this
hard
stuff
right.
The
path
and
infrastructure
layers
to
know
that
you'll
have
a
reliable
fabric
to
deploy
on
right,
so
r1
elasticity
is
developer.
B
B
B
I
think
containers
are
actually
pretty
awesome
when
they're
combined
with
other
technology
right.
So
that's
the
part,
that's
exciting
for
me,
so
I
and
Steve.
You
actually
brought
this
up
once
on
a
analyst
call
where
we
were
talking
about
open
shift
and
you're
like
oh,
it's
nothing
like
my.
What
was
the
you
were
comparing
it
to
so
it's
not
like
my
hosted
Linux
thing,
and
this
is
a
big
hurdle
for
me,
and
so
this
is
back
to
what
you
were
saying.
B
I
think
a
lot
of
developers
when
they
came
to
Google,
App
Engine
or
when
they
come
to
a
pass
and
to
start
with
they
think
of
I.
Have
a
vm
or
I.
Have
a
machine
and
I
need
to
develop
that
same
way
and
I
think
there
is
a
mind
shift
and
then
containers
make
it
nicer
and
easier
to
make
that
mind
ship,
where
you
can
just
give
a
command
and
have
your
whole
infrastructure
up.
It's
cost
me
nothing
in
terms
of
like
to
spin
up
EAP
jboss
EAP,
for
me
is
one
command.
B
I,
don't
have
to
play
with
in
any
configuration
files.
I
don't
have
to
play
with
an
XML
and
if
I
want
my
system
and
can
set
it
up
exactly
the
way
our
company
sets
it
up.
So
what
it
frees
me
is
I
don't
have
to
devops
anymore.
I
could
just
be
deaf
and
I
can
spin
up
things
quickly
and
fast
and
say:
oh,
that,
like
I,
won't
try,
no
okay,
there's
no
I'll
that
really
sucked
delete
it
and
it's
gone
so
there's
this
agility
that
I
get
and
that's
ties
right
into
the
microservices
thing.
B
We're
not
waking.
20
I
want
six
copies
of
Redis
running
go
and
it
just
doesn't
like
before.
That
would
have
been
like
forget
it
just
forget
it.
I
wouldn't
have
done
it.
I
wouldn't
have
taken
that
the
cost
to
get
up
that
hill
unless
I
had
a
whole
bunch
of
other
Linux
people
with
me
would
have
been
I'm
just
not
doing
reddits
back
to
my
sequel,
and
you
know
tom
cat,
and
here
I
get
to
experiment
and
play
and
build
really
interesting.
A
A
Pass
in
the
future
of
application
development,
so
you
know,
is
either
containers
pass
or
both
you
know.
As
far
as
sort
of
you
know,
your
experience,
certainly
as
a
developer
today,
you
know
talking
to
developers,
what's
the
single
most
important
thing
that
either
or
both
of
those
has
changed
in
terms
of
developing
applications
moving
forward,
so
you
wanted
to
go
first,
I.
B
B
I
think
passes
had
the
biggest
impact
because,
as
allowed
developers
to
stop
thinking
about
how
am
I
going
to
install
this,
how
am
I
going
to
get
this
running?
It's
made
a
very
clear
line
of
separation.
Might
like
my
therapist
says.
If
you
see
any
my
talks,
like
my
therapist,
says
clear
boundaries,
infinite
possibilities,
right
and
so
ya
know.
B
If
you
stuck
some
more
deep
introspection,
I'll
take
it,
but
if
you
actually
want
to
inspect
the
objects,
yeah
yeah,
so
I
think,
though,
that
if
you
think
about
at
first
I
was
like
what
are
you
talking
about
that
sounds.
That
sounds
like
no
relationship
at
all
in
any
relationship.
She
was
saying
this
about
any
relationship
and,
if
you
think
about
it,
though,
if
everything
is,
if
we
have
very
clearly
delineated
boundaries,
then
I
know
I'm
on
this
side
and
I
can
do
anything.
I
want
on
this
side.
B
I
don't
have
to
you
every
single
time
and
the
way
we
do
app
development
without
this
kind
of
stuff.
Now
is
well
I
kind
of
do
some
system
and
stuff
and
Oh
sis
admit
I
need
to
change
this
config
while
I
know
you
didn't
set
that
up
and
then
so.
There's
all
this
back
and
forth
between
the
developer
in
the
system
in
and
they
have
to
wear
too
many
hats.
But.
E
B
D
There's
a
reason
for
that.
So
when
we
talk
about
the
feature
of
application,
development,
I
think
the
most
interesting
thing
is
that
every
Enterprise
is
becoming
a
software
company
right.
So
everybody's
heard
and
recent
software
is
eating
the
world.
You
know
you
could
take
that
a
step
further
and
say
if
you're
not
available
in
the
cloud
right.
D
The
demand
is
exploding,
there's
always
going
to
be
a
limited
supply
of
systems,
engineers
and
sis
admin's
we're
going
to
have
more
and
more
app
developers
who
have
less
and
less
time
to
write
more
and
more
code,
so
the
more
that
we
can
simplify
their
life,
the
better
off
we
are
so.
The
future
of
application
development
is
that
the
enterprise
boundary
not
just
all
the
junk
apps
that
you
have
to
run
HR
internally,
but
the
definition
of
does
the
enterprise
exist
or
not
is
going
to
be
defined.
C
I,
so
that's
that's,
I,
think
we're
adding
to
what
Sam
and
to
what
Sam
said.
You
know
just
really
looking
at
how
people
build
today,
too
right,
like
people,
aren't
really
building
applications
from
scratch
as
much
as
they
were
in
the
past.
C
You
know
I
think
that,
looking
at
the
number
of
developers
that
are
actually
building
versus
the
number
that
are
assembling
you're,
looking
at
massively
different
skill
sets
right
and
so
being
able
to
have
passed
environments
with
you
know,
multiple
choices
for
language
like
you're,
saying,
oh,
you
know,
node
I,
don't
want
to
use
that,
let's
throw
it
away,
let's
go
back
to
what
I
know
right
like
the
ability
to
do.
That
is
just
phenomenal.
So.
E
It's
I
think
the
folks
will
be
touching
on
a
pretty
well
here.
We're
going
to
see
this.
This
specialization
of
the
operations,
function
and
I
think
that's
an
incredibly
important
and
powerful
thing.
So
you
can
have
a
small
number
of
specialized
people
that
exist
in
an
environment
that
provides.
You
know,
infrastructure,
provisioning.
A
set
of
you
know
a
clustered
environment
instead
of
common
services,
the
set
of
things
that
the
everyday
developer
needs
to
do
their
work
and
those
are
going
to
be
specialized
functions
and
they're
going
to
be.
E
You
know,
people
that
understand
the
systems
and
they
curate
manager
systems,
they're,
going
to
be
few
and
they're
going
to
be
effective
and
of
great
tools
and
then
I
think
we're
going
to
start
to
see
a
much
stronger
alignment
of
the
individual
technologists
with
the
business
and
I
think
a
lot
of
what
we're
doing
here
and
a
lot
of
a
lot
of
these
texts.
Capabilities
and
technologies
are
going
to
kind
of
reduce
the
tyranny
of
centralized
IT.
So
you
can
actually
have
tools
where
it's
safe
for
a
technologist
to
be
embedded
in
a
business
department.
E
On
top
of
this,
because
everything's
running
in
these
very
introspective
all
principles
controllable,
atoms
that
lets
things
that
have
to
be
centralized,
like
governance,
risk
management,
compliance,
etc,
be
centralized.
I
think
this
is
really
going
to
be
pulled
together
by
you
know
these
new
container
technologies
I
can't
personally
separate
container
and
pass
any
more
like
it's.
It's
almost
a
nonsensical
separation.
You
know
past
was
always
container
based.
What
we
just
have
is
more
principled
technologies
that
are
more
accessible
these
days
and.
C
A
A
B
So
I
think
one
of
the
things
that
I've
seen
most
with
customers
is,
nobody
is
at
the
same
place,
I
mean
and
that's
pretty
simple
to
say,
but
what
that
means
is
I.
Think
anyone
who
says
this
is
the
way
you
have
to
do.
It
is
selling
you
something
and
not
in
a
good
way,
and
because
some
people
say
like
even
we
get
people
can't
you
do
use
ansible
and
chef
to
do
what
your
PA's
does
yeah.
You
could
probably
pretty
much
do
the
same
thing.
I
mean
it's
not.
B
It
takes
more
work
and
it's
more
customization,
but
there's
nothing.
That's
there's
many
different
ways
to
get
to
this
same
point.
Right
and
I.
Think
some
of
it
is
people
are
scared.
People
are
excited
and
scared
about
the
cloud
at
the
same
time
right
because
it's
a
completely
new
way
of
doing
things
yep.
B
So
you
already
have
some
real
machines,
just
throw
it
on
there
and
see
how
that
works
for
your
company,
so
I.
And
then,
whenever
I
ask
developers,
it
shows
how
many
of
you
know
what
infrastructure
is
a
service
versus
platforms
of
services.
I
don't
have
the
nice
graphs
that
James
has
because
I
don't
have
a
straight
feed
out
of
my
head,
but
I
would
say.
The
graph
looks
something
in
terms
of
those
who
actually
know
the
distinction.
It
looks
something
like
we
still
have
a
long
way
to
go
well,.
B
See
I
think,
okay,
so
that
Laura
and
I
had
a
Twitter
battling
with
us
over
the
other
day.
I
actually
think
I
actually
think
the
distinction
between
infrastructure,
reservist
in
the
platform's
of
service
and
I
don't
think
platform
as
a
service
is
a
nonsensical
term
first
and
then
second
I
actually
think
it's
a
very
good
distinction,
because
it
actually
sets
up
with
that
clear
line
of
separation
that
you
were
talking
about
before
infrastructure.
B
As
a
service
to
me
is
you
deal
with
infrastructure
like
you
are
dealing
with
provisioning
machines
and
all
that
kind
of
stuff
and
platform
as
a
service
I'm,
an
application
developer.
I,
don't
want
to
think
about.
The
machines
may
be
a
bit
from
the
application
developers
perspective.
It
is
a
big
distinction
may
be
from
the
company's
perspective.
It's
not,
but
as
an
application,
developer,
I
don't
want
to
work
with
infrastructure
as
a
service.
That
gets
me
right
back
into
I
have
to
admit
linux.
Machine.
C
E
I
see
this
as
a
as
a
pretty
artificial
dichotomy
and
and
the
reality
of
most
real-world
deployments
I
see,
is
they
don't
fit
nicely
into
either?
And
you
know
we've.
You
know
I'm
I'm
sort
of
involved
in
the
evolution
of
App
Engine,
which
is
a
traditional
paths,
I'm
involved
in
the
evolution
of
compute
engine
and
everything
in
between,
and
you
know
a
lot
of
our
customers.
You
know
they
hit
this
artificial,
cliff
with
the
past.
E
So
it's
you
know
the
way
the
people
have
defined
past
to
date
it
offers
you
know
you
trade
off
flexibility
for
opinionation',
and
it
works
very
well
to
a
certain
point
and
then
suddenly
hit
this
list.
Experiential
cliff
and
you
tend
to
have
to
do
something
else
and
the
problem
with
that.
You
know
I
tend
to
think
about
this
and
my
experience
with
it
has
been
it's
like
a
little
hole,
water
balloon
right,
the
minute
you
you
have
this
artificial.
E
You
know
cliff
that
exists
between
the
platform
and
the
infrastructure
pieces
you're,
forcing
the
developers
to
you
know,
step
outside
of
the
past
and
do
something
else,
and
while
it
might
still
be
easier
to
do
in
the
past,
they
have
to
invest
in
an
infrastructure,
provisioning
story,
puppet
or
share
for
ansible
assault
stack
to
actually
do
the
management
they
have
to
start.
You
know
dealing
with
that
and
eventually
they
like
well.
E
Why
would
I
do
this
when
I
can
just
do
this
and
so
I
think
it's
really
important
to
start
thinking
about
a
more
natural
continuum
that
exists
between
these.
You
do
have
infrastructure
as
a
service,
and
you
do
have
people
that
have
PMS
and
ya.
Folks
are
always
going
to
have
this
highly
optimized
kernel,
something
to
support
the
specific
workload
that
they
want
to
run
in
this
appliance
like
environment.
E
You
know
precisely
one
container
on
you
know
one
machine
and
I.
Don't
I,
don't
want
you
to
tell
me
what
development
environment
need
to
run
out.
I!
Don't
want
you
to
tell
me,
you
know
what
storage
it
backs
onto
and
so
I
think
it
is
not
official
dichotomy,
I
think
what
you're
going
to
start,
seeing
as
as
our
as
these
technologies
evolve
is
ISM
as
a
series
of
paths
through
the
stack
rather
than
a
set
of
sort
of
striated
layers.
E
C
I
got
it
when
the
package,
I
think
I
think
you
know
just
kind
of
to
chime
in.
I
think
that
this
that's
a
perfect
example
right
here.
Both
of
you
guys,
you
know
kind
of
providing
both
your
perspectives.
I
mean
the
technology
is
evolving.
You
know,
I,
think
that
you
know
what
you're
talking
about
is
totally
feasible
right,
but
the
organizations
have
to
catch
up.
C
You
know
a
lot
of
times
what
I
find
walking
into
customers
is
that
I
work
with
one
group
of
customers
and
a
large
enterprise
company
and
I
work
with
another
group
of
customers
in
the
same
enterprise
company
right
and
they
sit
inside
different
departments,
and
they
want
to
use
you.
No
one
wants
to
use.
One
sort
of
you
know
pass
platform.
Another
wants
to
use
another
one,
and
that's
great,
that's
fine
by
me.
It's
really
what
the
skill
set.
C
You
know
what
they
want
in
that
box
in
that
container,
with
those
tools
right
to
make
them
successful
my
jobs,
to
enable
that
great
I
think
that
organizationally
we
have
to
start
looking
at.
You
know,
as
you
know,
we
were
talking
about
how
technology
is
going
to
transform
and
there's
these
more
kind
of
POD
like
structures
that
are
tied
together
with
you
know
specific
parameters,
yet
they
all
kind
of
fit
together.
You
know
we're
not
there
as
an
organization,
yet
organizations
aren't
there
period
and
there
may
happen
they're
massive
silos
across
the
board.
C
When
you
look
at
you
know,
networking
and
storage
and
compute,
and
you
know
then
up
the
stack
to
active,
even
an
app
dev
and
then
we're
to
security
fit
in
right.
I
mean
you,
have
it's
not
just
like.
Oh
I
can
use
a
pass
platform
and
it's
magic
great,
there's
all
this
underlying
stuff
that
has
to
go
into
it,
and
people
don't
recognize
that
which.
A
Leases
actually,
who
you
know,
I,
think
the
next
question,
which
is
1,
I'm
actually
very
curious
to
hear
the
response
is
on
bigoted.
We
all
spend
so
much
time
whether
its
infrastructure
platform,
containers
and
sort
of
all
these
wonderful
things.
You
know,
particularly
given
the
days
when
I
was
developing
things
like.
A
A
D
In
many
ways
my
first
program
job
was
the
easiest
and
most
satisfying,
because
I
had
an
environment
where
I
could
hit
f5
and
it
ran
right.
It
was
local
on
my
box,
there
wasn't
the
whole,
you
know.
Oh,
it
works
on
my
machine
right.
It
was
just.
It
was
just
very
simple.
So
as
we
get
these
very
large
scale
problems,
how
do
you
do
application
development
and
deployment
in
the
data
center?
Not
really
a
problem
that
most
developers
have
right?
You
care
about
design
you
care
about.
Affordances,
you
care
about
modeling,
the
problem
domain
correctly.
D
Appropriate
representation
of
the
users
concerns
matching
that
into
the
data
center
is
kind
of
rough,
so
things
like
lattice
is
a
new
project
within
the
cloud
foundry
umbrella
say
how
do
we
solve
this
problem
down
to
a
small
scale
so
that
you
have
the
equivalent
of
deploying
to
a
data
center?
But
it's
just
right
on
your
laptop
I.
Think
Steve
was
saying
you
know
similar
things
happening
in
an
open
shift.
It's
just
logical
because
you
got
to
take
these
galactic
scale
problems
and
solve
them
on
your
desktop.
D
A
C
The
one
that
I
see
is
one
when
you're
taking
things
like
you
know,
past
and
infrastructure
as
a
service
right,
the
ability
to
let's
say
you're,
building
an
application,
and
it's
not
you
know
giving
you
the
optimal
performance
that
you
want.
It's
actually
the
visibility
down
to
the
layer
that
you
need
to
get
it
down
to
in
order
to
tweak
that
you
know
for
those
three
lines
of
note
or
whatever
on
your
website.
You
know
that
could
be.
C
You
know
something
that's
actually
happening
in
a
router
great
in
terms
of
you
know
the
effectiveness,
you
know,
and
it's
affecting
the
speed
of
your
website
when
you
get
to
the
large-scale
websites,
it's
millions
and
millions
of
dollars
per
millisecond
right,
and
so
you
want
that
to
run.
The
lack
of
that
visibility
is,
is
definitely
a
problem
classy
across
the
board
and
the
inability
of
application
developers
to
have
access
to
that
or
even
speak
the
same
languages.
You
know
that
work
administrators
to
even
fix
those
problems.
C
E
So
I'm
torn
there's
just
these
two
things
are
going
to
talk
about
one.
The
one
challenge
that
endlessly
frustrates
me
is:
is
this
dichotomy?
This
is
just
personal,
but
dichotomy
that
exists
between
the
world
inside
group
in
the
world
outside
who
the
one
inside
Google
is.
It
has
moon,
lasers,
and
you
know
insane
technology,
that's
incredibly
complicated
and
hard
to
use
like
it's.
It's
it's!
It's!
It's
phenomenally
powerful!
It's
bit
spectacularly
awesome.
E
The
world
outside
Google
is
a
relatively
simple
set
of
tools
that
are
much
easier
to
use,
and
so
the
thing
that's
kind
of
endlessly
interesting
and
treating
to
me
is
to
did
you
try
to
bring
those
tools
together
like
create?
You
know,
you
know,
moon
laser.
You
know
self-regulating
AI,
driven
management
experiences
in
in
a
world,
that's
accessible
Delta.
They
actually
wanted
to
say
that
what
was
it
going
to
be
an
actual
answer
here?
Is
it's
so
hard
to
reuse
software
and
in
a
in
a
reliable,
trustworthy
way?
E
B
So
I've
started
building
microservice
apps
now
so
first
up
it
would
have
been
Sam
stuff,
but
Sam
said
it
first,
so
I'm
going
to
do
an
addendum
and
the
addendum
is
it's
the
paradox
of
choice
stuff,
which
is
I've,
started
right,
making
microservices
apps
great
I
get
this.
How
do
I
wire
this
together?
What's
the
best
practices?
I've
got
all
these
little
micro
services,
where
all
my
log
files
going?
How
do
I
monitor
this?
How
do
I
load
test
this
and
then
the
other
thing
is
just
exactly
what
you
said.
B
So
it's
great
when
Facebook
Google
get
up
and
talk
about
how
they
solve
these
things,
but
for
most
developers
their
scales,
not
Google
into
Facebook
and
the
novel
of
engineering,
talent
and
numbers
that
they
have
are
not
the
same.
So
I
can't
just
say:
hey
I'll,
take
five
people
off
of
this
team
and
did
build
a
distributed
logging
system.
It's
not
it's
different
right.
A
D
Even
then
right
the
myth
of
isolation
right
creeps
in
oh,
we
can
use
services
that
are
just
in
our
own
enterprise,
Oh
baloney,
right,
you're,
going
to
use
some
services
or
come
off
of
Dropbox,
then
we'll
come
up
with
other
parts
of
the
public
internet,
so
I
think
we
can
all
agree
distributed
debugging
as
a
disaster.
It's
always
been
a
disaster.
Does
it
always
have
to
be
a
disaster?
We
don't
know
right.
There
was
you
know.
D
A
It's
been,
it's
been
interesting
because
it's
one
of
those
you
know
we
talked
to
audiences
and
even
people,
people
assume
because
the
you
know
the
cloud
has
grown
so
rapidly
that
the
development
experiences
is
great.
If
you're
like
you,
actually
try
to
develop
an
application,
it's
actually
it's
much
much
harder
than
it
needs
to
be.
The
tooling
you
know,
I
would
certainly
agree
is
not
there.
You
know,
nor
is
the
debugging
experience.
We
are
running
out
of
time.
So
last
question
for
the
panel
and
I
guess:
I'll
start
with
Steve
since
likes
being
first.
C
A
B
So
this
one's
kind
of
an
easy
one
there
it
is
only
open
source
I
mean
if
you
look
except
for
Heroku
but
I,
think
that's
because
they
got
first
mover
advantage,
but
then
they
also
benefit
all
the
open
source
that
was
there
ever
since
Heroku
it's
been
all
there
is
nothing
that
I
can
think
of
in
our
ecosystem.
Right
now,
can
you
name
aprenda,
whoo-hoo
I
know
who
a
friend
it
is,
but
their
market
share
and
the
amount
of
traction
they
have.
Is
they
like
to
pretend?
B
Other
than
aprenda
and
staccato,
those
are
the
tube,
but
even
staccato
is
boast
based
off
a
clown.
Foundry
I
mean
there
isn't,
like
you
said
before,
because
of
the
economies
of
scale.
Here
it
has
to
be
open
source
because
of
the
like
we're
now
we
in
our
next
version
we're
just
using
Cooper
Nettie's
right,
so
we're
going
to
use
dot,
containers,
either
docker
or
rocket
whichever
container
comes
around
and
then
we're
using
crew
benetti's
and
then
we're
putting
a
layer
on
an
open
source
layer.
E
You
know
our
friends
at
core
OS,
our
friends
at
darker,
like
we
could
not
do
that
in
a
proprietary
software
way,
I
think
anyone
who's
trying
to
build
a
mainstream
service
or
a
mainstream
product
as
proprietary
is
going
to
get
a
massive
competitive
disadvantage.
The
open
source
community.
It's
just
it's
a
simple
factor
of
economics
and
agility,
born.
C
Yeah
I
would
agree
with
everything
that
said.
I
mean
I.
Think
that
you
know
when
you
look
at
kind
of
you
know.
Open
source
is
absolutely
critical,
but
we
have
to
talk
about
interoperability
with
existing
systems
to
right.
We
can't
leave
that
out.
You
know
so.
Interoperability
with
those
systems
is
going
to
be
extremely
important,
with
open
source
to
make
sure
that
there's
the
right,
you
know
plugins
or
drivers,
or
things
like
that
can
enable
you
know,
applications
to
run
across
multiple
different
environments
and
also
support
multiple
task
platforms.
Fair.
D
So
one
of
the
reasons
that
inner
tell
interstellar
space
travel
is
science
fiction
is
not
just
because
the
technologies
have
been
invented
yet,
but
because
it's
going
to
require
so
many
resources
that
you
have
to
have
a
global
government.
Somehow
all
of
us
have
to
get
along
paths
and
data
center
operating
systems
are
so
complicated
that
no
one
company
can
build
it.
So
the
economics
just
push
us
to
have
it
be
the
equivalent
of
the
International
Space
Station
right.
It's
got
to
be
many.