►
From YouTube: OpenShift Commons Gathering Seattle 2016 : State of Container Ecosystem - Kelsey Hightower (Google)
Description
OpenShift Commons Gathering in Seattle on Nov 7, 2016 afternoon keynote by Google's Kelsey Hightower on the State of the Container Ecosystem
C
B
B
C
B
B
You
guys
looked
at
me
like
I'm,
crazy,
like
why?
Would
you
even
talk
about
virtual
machines
right
now,
right,
because
no
one
sees
value
in
the
individual
virtual
machine
right.
The
value
that
you'd
arrive
at
a
virtual
machine
usually
comes
from
some
platform
or
cloud
provider
or
OpenStack
or
VMware.
No
one
thinks
about
a
virtual
machine,
yet
we're
talking
about
the
container
ecosystem
and
as
equally
as
crazy
right.
B
Why
do
we
want
to
adopt
containers?
There
has
to
be
reason.
It
can't
just
be
going
from
one
application
distribution
platform
to
another.
We
need
a
reason
why
we're
doing
these
things
so
containers
to
me
are
definitely
not
the
most
interesting
thing
to
be
talking
about.
At
best.
It's
an
implementation
detail
right.
B
It
happens
to
be
the
thing
that
we've
chosen
to
agree
on
today
for
sharing
applications
with
the
various
platforms
that
we
want
to
run
on,
and
this
to
me
is
the
biggest
source
of
confusion,
because
some
people
are
saying
I'm
moving
out
of
the
cloud
and
I'm
moving
to
containers.
Oh
my
wow.
That's
going
to
be
fun.
B
B
B
Anyone
here
want
to
use
containers
boom,
one
you
you
raise
your
hand,
leave
it
up,
don't
be
trying
to
flash
it
right.
There
automatically
true,
doesn't
matter
how
small
the
percentages.
This
is
also
true.
Some
percentage
of
organizations
are
using
containers
Brandon,
you
still
in
here
at
least
Brandon
fields
from
from
core
OS.
If
you
work
at
Red,
Hat,
you're,
probably
using
containers,
if
not
boy,
you're
selling
snake
oil
right.
So
this
is
also
true,
but
this
is
the
metric
that
is
probably
the
most
true.
B
B
You,
like
underplay,
will
come
back
to
work
and
say:
hey
here's,
this
blog
post,
saying
that
this
works
not
sure
what
you're
doing
right-
and
this
is
the
state
of
things
honestly.
This
is
the
state
of
the
wet
people
are
thinking
about.
So
when
we
start
to
have
this
conversation,
no
one
is
really
addressing
this
particular
thing.
What
is
it
going
to
take
to
move
that
percentage
number
of
people
using
containers
to
get
the
other
people
off
the
sidelines
right?
B
This
happened
to
virtualization,
remember
people
that
will
adopt
virtualization
in
five
years
and
then
the
cloud
came.
Is
that
what
that's
different
than
being
where
we
set
the
clock
will
do
cloud
and
five
years
once
and
up
there's
this
container
thing
will
do
containers
in
so
it's
nonstop
right.
So
we
need
to
figure
this
out
this
formula.
This
is
the
thing.
That's
the
most
important
thing
to
figure
out.
B
If
you
really
want
to
understand
the
state
of
things,
so
we
are
going
to
talk
about
containers,
because
we
need
to
understand
and
have
the
right
vocabulary
and
terminology
to
talk
to
each
other
and
people
that
are
interested
in
the
technology.
We
cannot
keep
waving
our
hands
about
what
containers
are,
if
you're,
in
the
process
of
developing
a
container
strategy.
B
Stop
you
don't
really
need
one.
You
need
to
figure
something
out.
That's
much
broader,
much
bigger
than
just
putting
your
app
in
a
different
tarball.
How
many
people
know
that
the
jar
file
like
a
zip
file
right,
you
believe
your
minds
like
not
just
unzip
it.
It's
like
unzip
jars,
like
things
came
out
of
it.
B
B
So,
but
we
need
to
all
be
educated
on
these
things,
so
here's
the
harsh
reality
for
some
people,
dr.,
is
the
de
facto
standard
container,
runtime
and
image
format
for
linux
and
windows
for
most
people,
and
we
ask
ourselves
why
why
do
they
hold
this
dominance
over
this
idea
of
application
containers
we're
not
talking
about
all
types
of
containers,
we're
talking
about
application,
containers
and
number
one?
Is
they
nailed
the
developer
experience
people
attempt
to
come
in
and
compete
with
doctor
and
where
do
they
fail?
You
try
the
solution
you
get
on
your
laptop.
B
Doesn't
work
done,
go
back
to
what
you
were
using.
So
if
you
want
to
understand
what
the
de
facto
standard
is
its
docker,
because
they
give
you
all
the
tools
to
do
it
into
n,
is
it
perfect
not
really
not
all
the
way,
they've
done
a
lot
of
things
well
and
the
parts
where
it
isn't
perfect?
That's
where
you
see
the
opportunity.
So
if
you
want
to
understand
the
container
ecosystem
find
out
what
dr.
B
doesn't
do
well
and
that's
where
you
see
the
new
company
spring
up
they
spring
in
they
spring
up
to
fill
in
the
gaps
of
where
people
are
filling
pain
with
docker
and
it's
very
strategic.
Everyone
isn't
rushing
out
to
build
a
new
container
runtime,
that's
pretty
decent.
A
lot
of
people
aren't
running
out
to
build
a
build
system
for
container
images,
that's
pretty
decent,
but
the
things
you
do
in
production
around
container.
So
that's
not
a
soft
problem.
So
that's
where
the
innovation
for
containers
come
from.
B
So
if
you
want
to
pay
attention
to
the
trends,
you
don't
need
to
wait
for
the
news
outlets
just
go
and
use
doctor
and
figure
out
where
it's
weak.
That's
where
you
see
the
next
things
come
from
it's
a
very
simple
formula:
there
are
other
container
runtimes
most
people
forget.
This
rocket
is
a
really
really
great
container
runtime
and
it
actually
came
out
in
a
way
that
addresses
the
concerns
that
most
people
need.
B
When
you
decide
to
adopt
a
platform
on
top
of
the
container
runtime,
because
you
need
less
from
the
runtime,
you
don't
desire
to
interact
with
the
runtime
directly
anymore.
So
in
that
case
you
like
well
I
just
need
something
that
can
simply
download
and
execute
my
application.
I
do
not
need
a
contar
workflow
for
my
production
use
case,
so
we
have
things
like
a
rocket.
How
many
people
know
where
CRI
dash
ovis?
You
were
here
a
hat
okay.
B
So
this
is
the.
This
is
a
runtime
implementation
of
a
lot
of
the
work.
That's
going
on
in
the
open
container
initiative,
OCR
to
build
a
container
runtime
that
implements
the
cooper,
Nettie's
container
interface,
so
the
cooper
Nettie's
world
we
act
like
Switzerland
like
we're,
neutral
ground
we're.
So
you
know
what
dr.
rocket
doesn't
matter.
It's
never
going
to
end
based
on
experience
everyone's
going
to
have
a
reason
why
they
need
the
container
1
times
they
need.
B
So
now
we're
going
to
do
we're
going
to
make
most
of
the
logic
that
Cooper
Nettie's
needs,
we're
just
going
to
bake
it
right
in
Cooper
neighs,
where
it
lives
today
and
we're
going
to
make
a
well-defined
contract
to
say
hey.
If
you
have
a
container
on
time,
you
implement
this
small
interface.
However,
you
want
to
do
it,
you'll
be
compatible
with
Cooper
natives.
B
That's
it
we're
done
we're
not
going
to
play
favorites
there's
no
need
to
play
favorites
because
in
the
case
of
core
OS
rocket
might
be
the
best
container
runtime
for
you
be
well
integrated
into
the
OS.
It
may
have
other
things
that
you
need
no
worries.
Cooper
neighs
will
be
there
for
that
and
in
other
operating
systems.
We'll
just
have
other
ways
of
doing
things
that
are
native
to
that
Colonel
that
you
may
not
be
able
to
put
a
runtime
too,
so
it
just
makes
sense
to
take
this
into
consideration.
B
Some
people
are
actually
waiting
for
these
container
one
time
to
consolidate.
People
actually
believe
that
there
will
be
one
container
runtime
that
will
actually
win
and
dominate.
Never
is
going
to
happen
if
you
were
waiting
on
that.
If
that
was
part
of
your
container
initiative,
mr.
stop,
but
it's
never
going
to
happen
because
it
can't
no
single
container
runtime
will
be
willing
to
do
all
the
work
necessary
to
deeply
integrate
to
every
kernel.
B
That's
out
there
that
provides
this
kind
of
capability,
so
I
can
I
think
it
will
continue
to
expand
as
new
platforms
or
hardware
devices
come
out.
You
probably
want
to
see
things
that
are
built
to
be
platform
specific,
but
this
won't
be
a
problem
because
you
should
be
designed
to
higher
level
api's
these
low-level
details.
That's
not
what
you
should
build
your
whole
company.
On
top
of
you
need
to
do
it,
you
need
to
go
a
little
higher,
but
we
are
going
to
come
out
with
some
things
that
will
give
good
reference
and
starting
points.
B
You
know
like
the
emer
spec
right,
even
though
the
runtimes,
maybe
the
verse,
but
we
can
all
move
around
these
root
file
systems
with
their
applications
deeply
packed.
That
makes
total
sense.
There's
no
reason
to
try
to
come
out
and
redefine
your
own
image
format.
So
we
have
the
image
spec
and
the
in
respect
is
taken
from
da
curvy
to
its
popular.
It
works.
It's
pretty
well
defined,
there's
multiple
implementations
of
being
able
to
pull
it
and
run
them.
B
So
we
start
there
and
the
container
runtime
spec
will
attempt
to
write
down
the
things
that
we're
already
doing
in
the
way
that
they
can
be
implemented
by
other
people,
so
we're
making
good
progress
and
we're
starting
to
share
the
knowledge
and
understand
this.
So
if
you
want
more
details
check
out
the
work,
that's
going
there
and
I
think
both
of
those
specs
are
reaching
10
fairly
quickly
here
and
I.
Think
you're
going
to
see
this
kind
of
be
the
standard
that
most
people
that
want
to
participate
in
these
communities
will
adopt.
B
B
You
do
the
whole
boot
process
and
the
goal
there
is
to
kind
of
give
you
this
lightweight
virtual
machine,
we're
talking
about
application
containers,
so
application
containers,
just
hopefully
that
will
get
rid
of
this
deployment
process,
how
we
package,
how
we
get
it
on
the
box
like
moving
bits
on
this
that
is
so
solved.
Problem
I
can't
believe
we're
still
spending
this
much
time,
trying
to
figure
out
how
to
get
an
app
on
a
server.
B
What
the
hell
are
we
doing
this
to
me
is
really
sad
that
in
tech
we
spend
this
much
time
trying
to
reinvent
the
wheel,
every
organization,
because
we
believe
that
we're
so
special,
not
really
I,
think
mobile
did
a
great
job.
Imagine
if
we
try
to
pour
all
of
our
tools
of
mobile,
imagine
using
my
puppet
or
chef
or
ansible
on
your
mobile
phone
to
install
an
app
battery
life
just
what
makes
sense
so
here's
the
these
are
some
of
the
real
things
you
need
to
actually
worry
about
what
you
actually
get
successful
containers.
B
This
is
the
next
set
of
questions.
Hey,
it
turns
out,
everyone
can
log
into
the
app.
That
is
a
bad
idea.
No
logging
performance,
API
compatibility.
This
is
the
biggest
one
people
just
like
man.
We
got
this
continuous
pipeline.
We
just
rolled
changes
and
all
the
other
teams,
like
I
hate
that
team,
the
only
runners,
TPI
compatibility,
it
breaks
every
10
minutes.
That
stuff
is
important
and
containers
don't
address
this.
Hopefully
they
allow
you
to
focus
on
it.
These
are
the
other
things
like
data
locality.
B
So
some
of
these
platforms
allow
us
to
figure
out
how
to
get
our
data
or
application
closer
to
the
data
and
people
like.
Oh.
Why
would
you
want
to
do
that?
Everyone
believes
that
you
own
all
the
data.
Some
people
do
not
produce
the
data
that
they
need
to
compute
on,
so
you
have
no
choice
but
to
move
the
compute
to
where
the
data
is
that's
the
new
world
and
in
that
world
you're
going
to
need
a
system.
That
knows
how
to
do
that
or
going
to
be
manually
doing
that.
B
So
containers
allows
us
to
focus
on
some
of
these
harder
problems
and
for
some
unique
people
in
the
room
you
actually
have
customers
that
generate
revenue.
What's
the
point
of
shipping
your
app
in
the
container,
if
you
have
no
customers,
you
should
stop
that
immediately.
You
should
abandon
ship
on
all
initiatives
until
you
find
the
customer,
even
if
it's
an
employee
that
works
there,
give
them
a
credit
card
and
buy
the
product
until
you
can
do
that.
These
are
your
real
problems
that
you
have
to
deal
with.
B
Everything
else
is
almost
an
implementation
detail,
so
we
need
a
platform
to
help
us
manage
those
things
so
in
the
container
ecosystem,
we
stopped
talking
about
container
so
much
I've.
Actually
in
the
last
year.
Don't
really
think
about
containers
I,
look
at
them
as
a
necessary
evil.
In
order
to
use
the
platform
of
my
choice,
I'm
no
longer
excited
about
the
container
I.
B
So
one
thing
we
need
to
be
clear
on
containers
do
have
value
right.
We
stop
talking
about
python,
vs,
Ruby
versus
jar
for
our
purposes,
war,
ear
man,
the
enterprise
got
screwed
over
on
that
one
right:
jar,
war
and
ear
files,
which
one
do
you
use
and
why
I
don't
know
so.
Containers
now
become
this
common
unit
of
compute
that
we
can
move
across
these
three
primary
things.
I
want
to
make
sure
we
understand
the
difference
between
these
three
things.
B
I
think
this
is
the
source
of
confusion
where
we
are
now
we're
seeing
these
application
management
platforms
come
out
and
we're
not
sure
what
we're
being
offered
so
I
have
these
three
categories,
and
these
are
just
all
my
opinions
if
you
haven't
noticed
by
the
way
frameworks
container
as
a
service,
how
many
people
have
heard
of
Kaz
people
just
like
saying
these
thing
anything
with
as
on
it
just
Kaz
and
then
peplum
as
a
service.
Now
no
one
wants
to
be
caught
up
has
any
more.
B
It's
a
very
dirty
word
passes,
failed
in
one
big
regard.
They
had
too
many
opinions
and
when
they
those
opinions,
there
was
no
way
to
back
out
of
them.
It
was
all
or
nothing
either
you're,
all
in
or
you're
out,
and
most
of
them
didn't
provide.
Any
AP
is
for
you
to
build
anything
on
the
side
and
still
have
some
first-class
access
to
the
rest
of
the
past
and
all
the
features
that
provided
so
we're
going
to
have
a
redo,
so
application
management
frameworks.
B
These
are
application
management
frameworks,
Kuber
Nettie's,
which
is
being
steward
and
governed
by
the
cnc
f,
so
started
out
as
a
google
project.
But
it's
now
a
much
bigger
project,
much
involvement,
especially
by
companies
like
Red,
Hat,
core
OS
and
a
slew
of
others.
We
have
mace
oaths,
which
is
one
of
the
more
may,
be
mature
and
been
out
there
for
Wow
application
management
frameworks.
People
build
other
things
on
top
the
whole
two-part
scheduler
deal,
then
we
have
no
Matt
from
hachey
core
kind
of
a
new
up-and-comer
and
swarm
kit
from
docker
swarm.
B
Kid
is
probably
the
newest
of
the
field.
It's
this
idea
that
we
want
to
provide
things
that
have
AP.
Is
that
really
focus
on
the
application?
So
you
start
to
see
these
things
ship
with
things
like
in
the
case
is
formed.
This
app
bundle
right,
right,
they're,
talking
about
app
bundles
and
that
container
bundles,
because
now
you're
starting
to
address
the
application
itself,
and
the
same
is
true
for
the
rest
of
those
things.
Application
frameworks
tend
to
get
mature
and
then
they're
offered
as
a
service.
B
B
On
your
own,
but
remember,
I,
think
the
cavs
is
different
from
a
framework,
because
the
cavs
is
usually
tightly
integrated
into
the
platform
where
you're
actually
targeting
your
application.
That's
the
big
difference
between
the
frameworks
and
the
cavs.
So
a
lot
of
people
are
confused
because
they
go
and
download
the
framework
and
find
out
they
have
a
lot
of
work
to
do
to
integrate
it
well
into
their
own
environment
and
they're.
Looking
for
something
like
this,
the
last
phase
is
this
application
management
platform,
the
platform
as
a
service.
B
So
this
is
where
all
the
opinions
come
in
right
in
the
Heroku
world,
you're
going
to
build
a
12
factor
application,
which
means
you're
not
going
to
be
able
to
store
any
data
from
your
app
you're,
going
to
take
your
configuration
through
environment
variables.
These
are
our
opinions
and,
if
you,
if
you're
willing
to
abide
by
our
opinions
and
you
get
to
run
in
Heroku-
and
you
get
to
inherit
all
the
things
that
come
with
that
thing
in
cloud
foundry-
how
many
people
here
are
making
that
digital
transformation
right?
B
That's
the
best
of
mantra
that
they
have,
because
in
order
to
adopt
cloud
foundry,
you
need
to
re-architect
your
app
in
a
way
that
will
work
based
on
the
appearance
from
Cloud
Foundry,
and
it's
not
that
they're
bad
opinions,
but
they
are
opinions
and
their
strong
meaning.
If
you
don't
conform,
you're
going
to
have
a
bad
time,
if
you
do,
life
gets
really
ban
tastic.
There
are
a
lot
of
successful
larger
companies.
Snapchat
is
one
of
them
that
use
App
Engine,
and
so
you
know
what
those
opinions
work
and
we're
going.
B
Only
focus
on
our
business
not
deal
with
infrastructure,
but
then
you
get
this
new
hybrid
thing
open
shifts,
right,
open
shift,
v3
says:
hey
people
want
this
hybrid
model
of.
We
still
want
two
strong
opinions:
I
have
some
developers
and
some
people
on
the
staff
they
just
want
to
ship.
The
application
get
billed
get
check
in
and
get
push
my
applications
build.
Who
cares
about
this
container
thing
it's
up
and
running
and
we'll
take
the
opinions,
and
usually
the
opinions
are
based
on
best
practices.
People
aren't
just
making
these
opinions
up.
B
The
best
way
of
doing
it
based
on
what
we
know
and
that's
what
you
get
but
does
hi
Brit
models
like
what,
if
you
want
to
do
something
that
it
doesn't
support?
Well,
the
container
framework
is
still
underneath
there.
You
still
can
actually
go
behind
it
and
create
your
objects
natively
in
the
framework
that
is
built
on
top
of
and
I
think
this
pattern
will
hold,
because
this
gives
the
vendor
a
lot
of
leeway
and
figuring
out
what
the
actual
best
patterns
are.
B
B
You
guys
can't
yes
set
it
up
for,
like
no
I
can't
disagree,
it's
going
to
call
me
out
because
I
know
that
next
slide
is
going
to
kill
me.
Maybe,
but
honestly,
this
world
attempts
to.
You
know
what
some
application
changes.
You
can
adapt
these
platforms,
but
we
do
so
much
work
to
support
the
lift
and
ship.
How
many
of
you
have
heard
of
the
lift
and
shift
how
many
people
are
actually
doing
that
right
now
doesn't
work
out
well
at
all,
you
can
get
everybody's
level
is
working
and
then
sec
fault.
B
So
what
the
hell
was
that
doesn't
work
she
got
to
do
something
else.
I
think
the
app
has
to
actually
get
intelligent.
No
one
wants
to
hear
this.
You
are
going
to
have
to
write
some
new
code
to
take
full
advantage
of
these
platforms.
That's
the
reality,
and
I
think
we're
getting
closer
to
that.
So
the
new
stated
things
is
now
is
back
on
you.
The
application
developer
you're
going
to
have
to
do
something.
B
So
this
is
what's
now
the
directed
that
we're
seeing
where
there's
server
lists
or
whatever
you
want
to
call
it,
but
a
lot
of
times
is
what's
happening:
either
we're
reducing
the
interface
that
you
have
to
implement
or
your
application
will
need
to
be
smarter
and
here's
a
set
of
libraries
that
helps
your
application,
be
a
bit
smarter.
So
if
you
haven't
heard
of
these
libraries
like
spring
boot
or
sprint
boot
route,
this
should
be
spring.
B
Boot
link
your
d
g
RPC
and
go
kit
all
of
these
attempt
to
bring
things
like
service
discovery,
client,
side,
load,
balancing,
metrics,
monitoring,
all
those
things
closer
to
your
app,
so
your
app
can
actually
leverage
the
benefits
that
you
get
from.
Some
of
these
platforms
that
you're
running
on
so
to
solve
it
all
up
contains
only
solve
a
small
part
of
the
problem
while
creating
new
ones.
B
B
Yeah,
so
so
all
right,
if
you
didn't
see
your
favorite
runtime
on
the
sly,
so
the
question
was
LXD.
I
didn't
see
it
on
the
flight.
If
you
didn't
see
your
favorite
runtime
or
project
on
the
slide,
I
only
had
four
lines
all
right
and
they
were
sorted
in
alphabetical
order
and
there
were
no
logos.
There.
I
have
gotten
an
email
before
it's
like
hey.
My
logo
was
smaller
than
another
logo,
but
there's
nothing
wrong
with
lxd
I.
B
Think
all
of
those
things
are
to
me,
though,
they're
going
to
be
implementation
details
because
most
people
at
the
very
high
levels
when
using
these
application
management
platform,
you
can
care
less
of
as
lxd
lxc,
docker
or
rocket,
because
this
is
the
level
that
you
want
to
operate
at.
If
you
find
yourself
way
down
here,
then
you're
either
a
building
your
own
platform,
which
most
people
are
in
the
habit
of
doing,
but
they
don't
know
that
they're
doing
it.
B
So
as
long
as
you're
aware
that
you're
building
your
own
platform
and
if
you're
successful
and
if
you're
lucky
you'll
end
up
with
something
that
looks
like
Opie
ship
at
right.
In
a
few
years,
all
right,
no
it's
serious,
like
you're,
either
you're
buying
one
of
your
building.
One
is
nothing
wrong
with
that.
You
just
need
to
know
what
are
you
doing
here.
B
All
right,
so
the
question
was
one
benefit
of
the
pass.
Was
the
developer,
workflow
and
I
think
what
we're
really
saying,
there's
that
the
paths
had
an
opinion
on
how
that
works,
show
should
be
like
you
go
to.
Heroku
is
like
nope,
get
push
we're
not
going
to
have
meetings,
we're
not
going
to
talk
about
this.
It's
not
going
to
be
an
initiative,
get
push
and
a
lot
of
times.
The
reason
why
you're
successful
is
because
you
take
my
options
anytime,
you
take
away
the
options
and
introduce
constraints.
People
have
to
make
a
decision.
B
Most
people
are
just
paralyzed
because
they
can't
make
a
decision.
Just
too
many
options
do
I
do
chef.
Do
I
do
puppet
right?
Some
bash
try
to
use
this
thing,
so
I
think
that
Pat
I
think
the
passes,
give
people
an
opinion
and
then,
when
you
a
set
the
opinion
you
get
all
these
benefits
in
return,
lower
down
the
level
I.
Think
in
the
case
of
Coober
Nettie's
as
an
application
framework,
we
do
introduce
more
opinions
than
the
raw.
B
Oh
esta
right,
association
to
a
machine,
almost
zero
opinions
about
how
to
do
things
in
Coober
Nettie's.
We
say
it
has
to
be
in
a
container
right,
so
the
developer
workflow
at
that
point,
is
really
influenced
by
that
one
opinion
about
kuber
Nettie's.
You
need
to
figure
out
how
to
get
your
application
into
a
container
into
a
registry
that
can
be
pulled.
So
then
that
starts
to
shape
the
workflow.
Maybe
it's
doctor
for
mac
on
your
local
machine,
but
ideally
we
should
probably
even
move
away
from
that.
B
In
some
cases
right
like
see,
I
CD
is
here
for
a
reason.
You
want
to
push
those
things
into
those
and
let
that
be
abstracted
away
for
them,
so
whether
you're
using
a
pass
or
application
framework,
the
developer
experience
should
be
the
same.
Write
some
code
run
some
tests
and
check
it
in
this
whole
laptop
equals
production
business
that
needs
to
stop
right.
That's
vagrant,
like
cost
us
five
years
as
much
as
I
love
favorite,
but
most
people
lost
their
minds.
I!
Oh
I.
Can
just
put
production
on
my
laptop,
it's
like!
No,
you
cannot.
B
You
have
one
gig
of
date
on
your
laptop
there's,
20
petabytes
reduction,
you
can't
add
an
index
to
every
column,
doesn't
work
that
way.
Okay,
so
I
think
I
think
that
workflow
needs
to
be
unified,
but,
yes,
you're
right
passes,
bring
a
very
well-defined
set
of
opinions
around
how
you
should
get
application
code
running
in
the
platform.
Any
other
questions.
C
So
you've
been
talking
about
these
opinions
that,
basically,
if,
if
you
write
your
own
software,
you
want
to
implement
these
use
some
of
these
opinions.
What
about
for
IT
and
operations,
groups
that
are
primarily
running
vendor
software,
so
I
can't
go
and
tell
it
last
seein
to
make
JIRA
follow
these
opinions.
C
I
just
have
to
sort
of
take
what
I'm,
given
what
I'm
curious
is,
where
you
see
the
breakdown
in
terms
of
how
much
of
that
is
on
the
vendors
to
fit
into
these
new
platforms,
vs,
to
what
extent
that
the
weight
is
on
those
platforms
to
work,
with
the
way
that
this
software
is
already
packaged,
how
backwards
compatible
to
the
old
world?
Should
those
platforms
be
right.
B
So
the
question
is
that
a
lot
of
times
in
IT,
it's
not
about
the
apps
that
we
write.
We
have
more
control
over
those,
it's
about
the
software
like
JIRA,
god
forbid,
Oracle,
right,
you're,
bringing
these
things
in
and
you
have
to
do
what
the
vendor
tells
you
okay
and
we
have
opinions
about
those
vendors
they're,
not
very
favorable
right
now,
especially
given
the
fact
that
new
software
that
comes
out
your
you're
almost
enter
into
a
partnership
with
the
vendor
versus
them
telling.
B
This
is
all
we're
going
to
do
just
deal
with
it
now,
there's
just
so
many
choices
in
these
areas.
That
I
think
from
the
perspective
now
is
that
that's
changing
and
we
talk
about
older
software,
I
think
with
older
software.
If
I
can
keep
making
the
same
money
from
you
with
no
changes,
why
would
I
change
it
right?
B
So
you
do
have
some
stopped
paying
the
money
and
you're
in
a
situation
where
you're
stuck
I'm
gonna
be
honest
with
you,
you're
screwed
right
like
seriously
people
come
in
and
say
no,
we
can
build
stuff
around
the
app
it
will
make
it
work
and
all
these
things
no
I
think
most
people
can
put
some
band-aids
on
it,
but
you
need
to
figure
out.
How
long
is
it
worth?
And
sometimes
you
know
it's.
Okay,
just
run
it
over
here
on
the
legacy.
Hardware.
B
I,
don't
understand
why
everyone
sees
something
new
and
wants
to
push
everything
into
it.
There's
just
no
reason
for
that.
Honestly
in
practicality,
you
should
just
run
the
things
where
it
makes
sense.
So
if
you
have
some
legacy
software
and
you
figured
out
how
to
get
it
running
in
those
environments,
leave
it
there
like
ignore
the
noise
over
here
and
just
do
what's
right
for
that
particular
application.
B
A
couple
of
things-
and
it's
probably
good
news
how
I
can
share
so
I,
have
some
new
co-authors.
When
you
see
their
names
are
going
to
be
really
happy
who
they
are
okay,
so
the
book
is
about
sixty
percent
complete,
but
my
co-authors
will
bring
I
think
some
originating
opinions
about
cover
neighs,
that's
the
only
hence.
I
will
give
you
okay.
So
the
goal
is
the
book
right
now
has
a
lot
of
detail
on
and
exactly
how
to
do
things
in
Coober
Nettie's.
B
But
what
I'm
thinking
is
missing
from
the
book
is
the
why
all
right?
What
at
Google
led
people
to
believe
that
the
complexity
of
using
distributive
systems
to
do
things
like
manage
applications
was
worth
it
in
order
to
tell
that
story,
I
needed
more
voices
that
had
that
experience,
because
I
have
a
lot
of
practical
experience
with
Kuber
Nettie's
in
the
outside
world,
but
we
need
that
voice
to
fill
out
the
book
and
that's
what's
going
to
happen
and
once
I
get
legal
permission
from
all
of
those
entities,
you
will
know
all
right.