►
Description
We have invited Scott McBrien, RHEL guru, to talk to us about when running a container natively is sufficient and when you should be thinking about OpenShift.
How Red Hat Enterprise Linux (RHEL) users and admins can benefit their organizations and improve their careers by learning how to use containers, Kubernetes, and Red Hat OpenShift.
Learn more at https://red.ht/leveluphour
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
healing
from
welcome
to
openshift
tv
today,
we
are
talking
the
level
up
hour
with
the
one
and
only
langdon
white
and
we
have
a
special
guest
from
another
show
on
the
channel.
The
one
and
only
quote:
rel
guru,
scott
mcbrian,
whoever
put
rail
guru
in
the
description,
needs
like
a
50
like
gift
card
from
me,
or
something
because
that's
what.
C
Even
if
you're
not
a
developer,
you
know
and
when
you
are
a
developer,
why
they're
still
cool
but
then
also
when,
and
what
we're
planning
on
talking
about
today
is
when
is
kind
of
running
a
container
by
itself,
not
good
enough,
and
what
you
know
what
ways
there
are
to
solve
that
I
just
realized
that
I
don't
have
twitch
flying.
So
I'm
not
seeing
the
chat,
but
what
I
wanted
to
say
was
scott
mcbrine.
Would
you
like
to
introduce
yourself
feel
free
to
pitch
your
show.
B
Yep,
oh
thank
you
for
those
of
you
who
don't
know
me.
My
name
is
scott
mcbrian.
I
am
also
a
technical
product
marketer
for
red
hat
enterprise
linux.
One
of
a
couple,
and
the
show
that
langdon
is
talking
about
is
red
hat
enterprise.
Linux
presents
where
we
typically
will
have
on
guests
that
talk
about
linux
or
our
rel
product
managers,
or
maybe
from
engineering
to
just
talk
about
different
topics.
The
next
one,
though,
is
not
until
the
first
week
of
december,
so
we're
taking
a
little
hiatus
as
you
guys
do.
Kubecon.
B
C
A
C
A
C
C
C
C
Yeah
so-
and
I
think
I
I
threw-
or
I
tagged
you
in
some
tweets
already
today,
but
you
can
join
us
on
our
discord.
If
you
wanna
chat
with
us,
you
can
chat
there
with
us
right
now
or
you
can
chat
with
us
on
twitch
or
whatever
you're
watching
the
show
on
looks
like
your.
Your
shirt
provider
has
materialized,
so
today
we'll
be
talking
scott
mcbride.
I
didn't
really
have
a
subject
matter.
Maybe
I'll
put
that
in
the
show
notes.
C
C
A
C
Even
with
comma
and
all
right,
so
so
scott,
so
what
we
wanted
to
talk
about
was
containers,
and
so
one
of
the
things
that
I've
experienced
so
I've
been
using
containers
now
for
a
long
time,
and
one
of
the
things
that
I
discovered
pretty
early
on
was
that
as
soon
as
you
kind
of
have
two
containers,
they
start
to
be
a
headache,
and
so
I
kind
of
wanted
to
hear
your
thoughts.
You
know
what
are
you
what's
your
experience
been,
what
does
rel
feel
like
about
this?
B
So,
for
example,
when
you
have
containers
that
are
or
applications
that
are
architected
around
microservices
right,
so
you're
going
to
have
a
whole
bunch
of
containers
that
all
do
individual
things
that
are
all
working
together
to
accomplish
a
greater
task
like
that,
that's
probably
a
better
workload
for
open
shift
right.
So,
let's
see.
C
I
want
to
ask
a
question
there.
So,
like
okay,
you
know
there
that
you
say
you
know,
there's
kind
of
this
rule
of
thumb
or
whatever
that,
if
you're
doing
you
know
a
host
of
micro
services
together
that
are
making
an
application,
open
shift
or
kind
of
orchestration
starts
to
become
an
important
part
of
it.
But
why
like?
What
is
the
open
shift
or
the
orchestration
bringing
to
the
table
that
you're
not
getting?
By
doing
you
know,
podman
run.
B
B
What
about
its
interplay
with
other
containers
like
if
we
restart
one
in
the
middle
does
that
mess
up
the
others?
And
you
know
that's
a
much
more
complex
operation
and
native
to
rel
tools?
That's
not
something
that
we
would.
We
would
handle
without
a
lot
of
extra
work
on
the
admin
side
like
build
up
that
stuff.
C
Right
right:
it's
not
that
you
can't
do
it
it's
more
the.
Why
would
you
be
right
because
you
can
go
and
get
you
know
something?
That's
already
been
built,
that
does
it
at
least
for
me,
one
of
the
big
things
too
is
is
kind
of
the
shared
storage
component,
not
because
I
can't
do
nfs
mounts
a
bunch
across
a
bunch
of
different
realm
machines.
It's
more
about.
C
C
Yeah
I
was
going
to
add
to
that
kind
of
the
the
in
in
an
environment
that
is
orchestrated.
You
know-
and
I
was
going
to
talk
about
lightweight
orchestration
too
as
well
in
a
bit,
but
you
can
also
what
you're
not
limited
to
the
orchestration
features
in
a
sense
of
open
shift
right,
in
the
sense
that
this
is
where
something
like
service
mesh
kind
of
comes
in,
where
yes,
that's
another
kind
of
external
project
or
it's
another.
C
C
You
want
somebody
and
then,
on
top
of
that,
you
also
don't
want
it
kind
of
unpeer
reviewed
right.
You
want
to.
You,
want
to
have
that
be
getting
an
extra
level
of
code
review,
an
extra
level
of
review
of
whatever
sort,
because
it's
so
critical.
So
if
you
can
apply
it
just
once
from
kind
of
the
outside,
which
is
something
that
service
mesh
does
it
just
brings
that
to
the
table.
C
You
know
kind
of
just
out
of
the
box
and
then,
if
you
also
think
about
the
other,
things
like
a
mesh
can
do
right
is
like
rerouting.
You
know
it's
like
okay.
We
want
to
bring
this
new
service
online
to
replace
this
old
service,
but
we
want
to
test
it
first
and
then
we
want
to
make
sure
it's
actually
rolling
out
slowly
and
all
that
stuff.
A
B
Yeah
and
like
that,
that
brings
up
another
good
point,
which
is:
how
do
you
get
your
containers
deployed
across
your
infrastructure
right?
So
the
the
railway
would
be
something
like
shell
scripts
with
ssh
or
scp
and
or
ansible,
and
so
you
can
just
like
blast
it
down
to
your
population,
and
I
think
that
writing
that
automation
is
fairly
straightforward,
but
then
we
start
to
get
into
more
complex
questions
like
cool.
We
blasted
it
down
there.
B
Yeah
exactly
or
in
the
case
of
a
failure,
it
was
running
when
we
did
it
and
then
it
failed
yeah.
How
do
we
know
that
that
happened
or
the
host
that
it
was
running
on
died?
How
do
we
know
that
that
happened,
and
so
all
of
a
sudden
we
start
going?
Oh
well,
okay,
it's
not
just
blast
down
and
forget
about
it,
because
we
now
have
these
other
concerns,
like
validation
and
monitoring,
and
that's
that's
another
place
where
orchestration
kind
of
brings
money
to
the
table.
C
Well,
and
not
only
not
only
the
orchestration
right,
but
also
like
all
the
stuff
you
just
listed-
maybe
you
know
random
developer
admin
or
whatever
is
going
to
think
of
for
their
particular
application
right,
there's,
probably
another
50,
and
they
you
know
unless
you're
like
magic,
and
I
don't
even
mean
brilliant.
I
just
mean
like
straight
up
magic.
You
don't
discover
all
these
things
until
you
start
to
have
a
problem
right
or
until
you
have
put
a
bunch
of
legwork
into
you,
know
getting
one
piece
of
the
puzzle
solved
and
then
you're
like.
C
C
You
know
it's,
it's
not
just
the
orchestration
of
it
as
much
as
we
now
have
this
community
of
people
who
are
thinking
about
all
the
bugaboos
that
were
are
gonna,
hit
you
and
trying
to
solve
for
them,
or
at
least
document
that
they're
not
solved
right
so
that
you
can
kind
of
say.
Okay,
I
can
do
the
orchestration
with
this
tool
chain
and
not
have
to
worry
about
how
it
lands
right.
B
Yeah
yeah
and
I
mean
that's
how
we
get
into
a
situation.
Actually
this
happens
all
the
time
in
organizations
right
le.
Let's
call
our
prototypical
admin
jason,
so
jason,
like
writes
the
automation
he's
like
cool
I've,
got
a
thousand
containers
running
on
a
thousand
hose
sweet
and
then
it's
like.
Oh
one
of
them,
dies,
oh
okay,
well
I'll,
just
I'll.
Just
like
install
zabex
on
all
thousand
hosts
and
I'll
write,
a
little
monitoring
thing
that
checks
to
see
if
it's
running.
D
B
Yeah
and
then,
and
then
it's
like,
oh
now,
it's
alerting
me,
oh
well.
Let
me
let
me
go
ahead
and
update
the
systemd
unit.
Oh
well,
now
it's
running
and
it
restarted,
but
it
didn't
have
all
the
stuff
attached
to
the
right.
Oh
well,
let
me
just
add
some
more
logic
into
my
systemd
unit
to
do
all
these
checks
and
we'll
actually
we'll
just
make
a
management
script
and
before
long
you
end
up
with
this
thousand
node
thing
that
only
jason
understands
can
make
changes
to
you
know
manages
and
then
jason.
B
C
C
C
Well
to
that
point
right,
why
was
I
there,
because
I
was
a
team
of
seven
people
who
was
coming
in
as
consultants
to
replace
that
financial
service?
You
know
kind
of
infrastructure,
so
yes
exactly
and
you
know
and
what
they
were,
what
they
were
paying
for.
The
consulting
was
a
pittance
compared
to
what
they
would
pay.
C
You
know
both
in
you
know
his
straight-up
salary
whatever,
but
you
know
also
in
because
it
was
insurance
which
is
a
regulated
industry
if
they
drop
the
ball
in
certain
kinds
of
ways
that
results
in
lots
and
lots
of
big
money,
fines
so
yeah
so
completely
agree.
You
know
that
there's.
That
is,
that
is
not
a
position
you
want
to
put
yourself
in,
but
it
happens
all
the
time,
and
so
there
is
something
to
be
said
for
kind
of
choosing
off-the-shelf
software
for
certain
conditions.
C
You
know,
like
only
you,
only
want
to
write
code
for
your
true
special
sauce,
and
I
promise
right.
The
orchestration
of
your
infrastructure
is
almost
never
going
to
be
the
special
sauce
right
and
you
know
so
so
go
pick
it
up
off
the
shelf.
You
know
whether
it's
you
know
whether
it's
a
from
a
product
company,
although
support
is
nice
or
you
know,
even
if
you're,
just
kind
of
picking
up
a
piece
of
open
source
software,
just
it's
so
much
better
to
to
use
something
that
is
tried
and
tested.
B
Well-
and
I
actually
wrote
an
article
for
enabled
sysadmin
probably
about
a
year
ago
now
talking
about
not
being
the
lone
wolf's
admin
right,
which
gets
back
to
our
concept
of
like
it's,
not
job
security,
because
implementing
standards
yeah,
it's
like.
So
let's
say
you
want
to
go
on
vacation,
but
every
180
minutes
you
have
to
type
in
a
code,
because
that's
that's
what
you've
designed
your
stuff
to
do.
How
do
you
take
a
vacation?
B
A
Like
I
have
a
lot
of
experience
in
devops
and
failures
with
transitioning,
or
you
know,
trying
to
make
the
turn
into
a
high-functioning
organization-
and
you
know
when
you
come
in
when
an
org
finally
decides
right
like
we
need
to
move
towards.
You
know
more
standards-based
kind
of
infrastructure
that
works
for
us,
not
against
us
right
like
that
person
that
comes
in
there
and
has
to
do
all
that
discovery
is
gonna,
find
something
wrong
and
it's
usually
gonna
end
up
in
a
reportable
event
of
some
type
right
like
depending
upon
your
industry
right.
A
So
one
prime
example
I
can
give
literally
everybody
is.
I
worked
for
a
research
organization
in
the
research
triangle
and
I
quickly
found
that
one
of
the
nfs
shares
that
was
hosting
you
know,
pii
for
an
iphone
app
was
wide
open
to
the
entire
network,
so
anyone
could
get
access
if
they
had
an
ip
address
on
the
network
which
they
didn't
have
port
security
installed
could
have
figuratively,
been
anybody
so
yeah,
it's
one
of
those
things
where
it's
like
you're,
going
to
discover
something
immediately.
If
you
go
down
this
bespoke
path,
thank
you.
A
Linden,
like
the
bespoke
artisanal
crafted
lone
wolf
built
systems
are
highly
fragile
and
they
do
not
bring
in
the
kind
of
talent
you
wanna
be
bringing
into
your
organization
right,
because
they're
gonna
bring
in
people
that
say
well,
you
know
like
this
is
a
big
mess.
Someone
else
needs
to
fix
it
right
or
they're,
going
to
bring
in
people
that
have
a
lower
level
of
knowledge
and
they
have
to
work
up
to
figure
out
this
mess,
and
you
know
that's
just
setting
them
up
for
failure
in
a
lot
of
cases
right.
A
C
Yeah,
I
mean
my
word
for
it
another
another
example
from
my
own
career
right
was
I.
This
is
the
the
only
time
I
was
truly
a
sys
admin
for
like
a
while
was
some
friends
of
mine
were
running
a
company
and
I
was
freelancing
at
the
time
and
they
were
like.
You
know
linux
right
we
have
a
guy
who's.
Leaving
can
you
can
you
come
and
be
our
sis
admin
for
a
while
and
I'm
like
sure
I
don't
have
another.
C
Yeah
yeah
and
they
were
actually
going
towards
lenode,
actually
who
I'm
a
big
fan
of
so
I
don't
mind
shouting
them
out,
but
what
they
had
already
was
basically
nagios
was
monitoring
all
of
their
environment
and
it
was
great.
It
worked
really
well,
you
know.
However,
there
was
no
config
management
and
I
was
like
I
want
to
do
updates.
You
know,
say
on
some
period
of
time
versus
at
the
time
which
was
zero,
and
so
I
thought
about
introducing
puppet
at
the
time.
C
This
was
actually
before
ansible
existed,
I
think,
or
was
really
nascent,
and
I
started
down
the
path
of
starting
to
leverage
puppet
and
realized.
I
have
to
put
something
on
each
of
those
machines
that
I
am
afraid
of,
and
so
I'm
not
going
to
do
that
so.
Instead
I
wrote
custom
nagios
checks
and
built
a
config
management
engine
on
top
of
nagios,
which
I
felt
okay
about,
because
the
planned
obsolescence
of
that
whole
environment
was
literally
very
soon,
and
I
had
already
kind
of
started
set
up
the
the
new
one
with
more
done
properly.
C
B
A
Yeah,
like
I
remember,
there
was
a
startup
I
worked
at
and
they
were
doing
like
bespoke
dns
management
right
like
every
customer
of
theirs.
They
created
like
their
own
dns
server
just
for
that
customer's
host
records,
and
it's
like
four
records
for
each
customer,
and
I
was
like
so
we
get
a
service
for
this
way
cheaper
and
also
we
could
automate
it
so
that
it's
just
like
hey.
A
You
know
like
customer
id
zero
zero
one,
two
three
four
five
right
like
and
you
know
just
a
simple,
a
little
bit
of
automation
and
to
manage
their
dns
with
cloudflare.
You
know,
and
just
or
some
other
service
right
like
made
a
whole
bunch
of
stuff,
go
away
right
and
it
saved
them
tons
of
money
and
time
and
effort
and
energy.
Because
a
you
took
away
the
need
to
have
the
management
of
all
the
things
and
then
b.
A
You
took
away
all
the
things
right,
like
you,
didn't
have
to
waste
money
or
capacity
on
the
things
so
like
automation,
just
right
there
and
then
like
not
outsourcing
the
service.
But
you
know
going
with
a
more
robust,
is
how
I
phrased
it.
A
more
robust
and
resilient
dns
provider,
as
opposed
to
hosting
it
ourselves,
which
was
just
rife
with
you,
know,
potential
for
security
concerns,
and
you
know
all
kinds
of
weirdness
so,
and
this
was
at
the
same
time
as
all
the
dns
reflection
attacks.
A
C
You
know
the
internet
and
the
computer
world
to
kind
of
know.
What's
out
there
or
you
know,
look
at
you
know
consulting
for
that
or
look
at
you
know.
You
know
talking
to
the
analysts
or
basically
is
that
being
aware
of
how
the
market
and
how
the
software
development
world
is
changing
is
really
really
important
to
be
able
to
drive
efficiencies
into
your
into
your
own
data
center.
Well,.
A
You
know
so,
if
you
don't
have
a
thirst
for
knowledge
or
thirst
for
continuous
learning
in
your
organization,
you're
going
to
end
up
getting
outmoded
by
someone
or
something
at
some
point
right
like
it
could
be
something
within
your
own
organization,
or
it
could
be
some
other
company
completely
taking
your
business
or
you're
the
federal
government
in
jp
dave's
case.
So
the
the
the
the
idea
of
jp
youth
completely
threw
me
off
anyways.
A
So,
like
the
the
point
I
think
I'm
trying
to
make
is
that,
like
you,
have
to
have
the
capability
to
learn
constantly
right
like
yes,
I
know
it
can
feel
exhausting.
But,
like
I
write
a
newsletter
and
I
read
tons
of
news
every
day,
it's
not
exhausting,
you
can
do
it
in
a
way
to
where
it's
right,
like
I
mean
I'm
reading
hundreds
of
articles
a
day.
A
If
I
can
do
it,
anybody
can
right.
I
mean
that's
just
kind
of
my
opinion
of
the
whole
situation,
and
why
do
I
do
that
is
to
a
write,
a
newsletter
and
then
b
like
to
keep
myself
aware
of?
What's
going
on
around
in
the
industry
right
like
no
matter
what
that
has
helped
my
career
right
like
making
decisions
about
technologies,
you
know
until
I
joined
red
hat,
that's
what
I
did
now,
I'm
talking
to
y'all
about
the
technology
choices
we
made.
A
C
So
I
was
going
to
change
direction
a
little
bit
of
you
know,
kind
of
the
lighter
weight
or
well.
I
was
going
to
ask
one
more
question
first,
which
is
that-
and
I
think
this
is
a
really
hard
question
for
a
lot
of
people,
and
I
know
I
err
on
one
side
and
I
think
other
people
err
on
the
other,
which
is
you
said
that
there's
you
know
kind
of
you
know
if
you
have
a
large
set
of
microservices
for
your
application
or
whatever
applications.
Don't
start
that
way.
C
Right
applications
start
with
two
and
then
they
grow
to
twenty
thousand
right
where,
when
in
the
process
of
the
growth
of
that
application,
do
you
start
to
make
a
tipping
point
or
hit
a
tipping
point
where
that
orchestration
becomes
really
necessary?
Because
the
flip
side
of
that
is,
you
know
going
back
to
the
you
know.
You
start
with
two
and
you
do
you
know
you're
running
all
the
containers
individually
and
then
you're
up
to
whatever
200
services.
C
Introducing
orchestration
at
that
point
is
hard,
so
there's
kind
of
this
magic
moment
somewhere
in
there,
where
it's
still
low
enough
barrier
to
entry
to
get
your
orchestration
in,
but
providing
enough
feature
that
you,
you
know
that
it's
worth
it
versus
getting
the
the
just
the
overhead
of
the
orchestration.
I
don't
know
what
are
your
thoughts
on
that.
B
Could
you
work
straight
yeah?
Do
you
need
to
maybe
probably
not
possibly
it
depends,
but
then
there's
the
flip
side.
It's
like!
Oh.
I
have
these
three
containers
that
have
to
spin
up
together,
but
they
have
to
spin
up
in
the
right
order
and
there's
going
to
have
to
be
checks
between
them,
because
it's
not
just
like
turning
them
on
in
the
right
order.
But
it's
like
turning
this
one
on
and
waiting
until
these
services
become
available
and
then
turning
this
one
on
and
then
waiting
for
these
services
to
become
available.
B
And
in
that
case
it's
like
oh
and
we
have
to
make
sure
that
if
one
of
them
dies
that
gets
spun
back
up.
But
it
gets
spun
back
up
in
a
really
specific
way
to
maintain
that
across
the
other
two
that
are
mated
with
it
and
so
there's
a
place
where,
even
though
it's
a
small
number
of
containers,
orchestration
might
be
interesting
or
if
each
of
those
containers
is
just
really
consumes
a
lot
of
system
resources,
because
it's
maybe
a
super
huge
database
is
one
of
the
containers
right.
B
So
it
needs
like
a
lot
of
memory
and
you
need
to
now
not
just
run
all
three
of
those
on
the
same
host
but
on
different
hosts,
and
they
still
have
to
interconnect
with
each
other.
That's
a
place
where
you
know.
Maybe
orchestration
is
the
better
the
better
choice
for
that,
even
though
it's
only
three
containers
so.
C
It
depends
so
it
seems,
like
the
that
kind
of
you
know,
the
y-axis
really
is
like
the
the
complexity
rather
than
a
count
right
right.
You
know,
at
least
for
me
the
example
is
also
kind
of
you
know.
Do
you
have
a
whole
bunch
of
like
flat
containers
in
a
sense
right,
so
the
static
websites
you
know
are
are
all
kind
of
in
parallel,
whereas
you
know
a
more
complex
application,
it's
it's
a
series
right
it.
Basically,
it
goes
forward
to
back
and
you
have
to
go
through
various
hops
to
get.
C
You
know
some
process
of
the
application
done
and
that
that's
where
the
complexity
starts
to
get
introduced.
You
know
the
flatter
or
the
the
you
know,
kind
of
the
yeah
flatter
the
application.
The
you
know
with
less
branches,
that
kind
of
stuff
the
the
less
likely
it
is
that
you
would
need
something
to
orchestrate.
C
So
so
joe
fuzz
brings
up
my
point,
which
is
I've,
always
looked
at
orchestration
like
security,
the
earlier
it's
introduced,
the
less
it
costs,
which
true
story
is
true,
but
it's
it
costs
more
on
the
maintenance
side
on
the
early
side
and
me
I.
I
know
myself
as
a
developer,
that
I
have
a
tendency
to
over
engineer
things.
So
I
tend
to
start
with
things
like
orchestration,
even
for
something,
that's
simple.
So,
like
your
static
website
example
right,
I
would
probably
orchestrate
that
because
it's
so
much
cheaper
at
the
early
stage.
C
But
if
you,
if
you're
in
an
organization
that
you
are
doing
a
lot
of,
I
hesitated
to
use
the
word
testing
but
like
you're
you're,
trying
to
see
what
spaghetti
sticks
the
wall
right
so
like
you
have,
you
know
three
different
versions
of
your.
You
know
application
and
you
kind
of
want
to
fire
them
out
there
and
see
what
gets
take
up
in
the
in
the
market
right
and
what
doesn't
you
know
if
you're,
if
you're
trying
fast
and
furious
another
good
example?
C
C
C
C
You
know,
because
you
know
just
a
straight
up
container
with
nginx
and
some
web
pages
and
some
video-
that's
probably
three
nines
of
uptime,
like
just
out
of
the
box,
because
the
software's
so
good
that
you
know
getting
to
six
nines
just
doesn't
matter
right
like
and
you're,
not
doing,
changeover
and
stuff.
So
I
think
that's
a
that's.
Definitely
the
trade-off
right
is.
C
B
B
That
would
cause
someone
to
choose
rail
over
something
else
and
we
can
get
into
like
value
subscription
and
support
it
and
a
whole
bunch
of
stuff
like
that.
But
you
know
on
each
of
the
pieces
of
your
container
journey,
whether
it
be
building
running
sharing
orchestrating
there
are,
there
are
options
for
each
of
those
places
right,
not
just
red
hat.
C
But
one
of
the
things
I
really
like
about
podman
is
that
you
can
actually
run
pods
in
podman
and
while
it's
similar
to
docker
compose,
although
definitely
younger,
you
know
like
as
not
as
featureful
and
that
kind
of
stuff.
The
really
awesome
thing
about
it
is
that
that
that
walk,
that
you
were
talking
about
right
is
is
consistent
with
kubernetes
and
openshift,
where
what
you're
describing
or
how
you're
describing
your
running
application
is.
C
You
know
your
initial,
and
this
is
kind
of
where,
like
you
know,
you
fall
into
the
trap
of
you
know.
You
write
a
bunch
of
systemd
services
to
run
those
containers
and
you
know,
and
so
then
you
write
some
scripts
to
make
sure
they're
running
or
to
do
the
ordering
that
you
were
kind
of
talking
about
before,
or
something
like
that.
C
If
you,
if
you
do,
that
stuff
kind
of
the
right
way
to
begin
with,
not
only
is
it
probably
going
to
be
more
robust,
but
also
it's
then
starting
you
on
the
journey
of
that
application.
Being
you
know,
orchestratable
without
rewriting
chunks
of
your
code,
and
so
I
I
would
strongly
encourage
people
to
look
at
podman
pods
as
an
alternative
to
docker
compose
and
and
where
it
is
less
feature
full
go
file
bugs
you
know,
let's
get
the
let's
get
that
stuff
fixed.
C
B
B
Let
me
figure
out
the
tactics
I
need
to
take
to
implement
that
strategy,
like
everybody
in
our
industry
seems
to
be
strategists
and
nobody
seems
to
be
tacticians,
and
so
it's
like.
Oh,
this
is
where
I
want
to
go
cool.
How
are
you
going
to
get
there,
and
I
think
that
we
tell
a
really
compelling
story
of
how
you
get
there?
It's
like
you.
You
can
start
with
what
you
have
today
and
it's
like.
B
Okay,
so
we'll
you
know,
maybe
we
have
people
writing
stuff
as
containers
on
their
development,
workstations
and
we're
gonna
implement
that
through
podman,
and
then
we
need
something
lights,
we'll
do
pods,
but
we
know
that
ultimately
we're
we
want
to
be
more
complex.
We
want
to
be
able
to
have
the
ability
to
use
operators,
for
example,
so
that
we
don't
have
to
reinvent
every
container
or
containerize
everything
we
just
pull
in
some
pre-made
ones.
B
Yeah,
so
we
know
that's
where
we
want
to
go,
but
you
know
it,
you
could
start
to
move
that
direction
and
then
maybe
it's
like
oh
well,
maybe
we
should
start
thinking
about
things
like
source
to
image
right
where
we're
not
generating
containers
on
someone's
desktop
and
then
sending
them
over
the
wall
to
be
put
somewhere
like,
let's
actually
write
into
our
process.
How
we
do
that
direct
deployment-
and
I
mean
you
could
do
all
that
stuff
yourself,
but
that's
a
lot
of
work.
C
C
You
know
is
like
so
that
I
can.
I
can
start
that
walk
as
early
as
possible
and
you
already
do
to
some
extent,
except
you
have
to
make
some
changes
where
you
can
kind
of
go.
You
can
go
and
get
a
containerized
version
of
like
mysql
and
use
that
in
your
application,
that's
being
delivered
to
you
by
you
know,
red
hat,
so
you
don't
have
to
build
a
mysql
container
from
scratch.
C
You
know,
but
it'd
be
nice.
If
the
the
walk
from
that
you
know
container
was
a
little
clearer
to
the
my
sequel
operator
that
you
might
want
to
use
in
openshift
and
a
lot
of
this
stuff.
I
mean,
I
think
you
know
I've.
You
know
a
number
of
criticisms,
but
I
mean
a
lot
of
the
stuff.
It's
it's
evolving
right
now,
right
and
a
lot
of
this.
A
lot
of
my
you
know,
kind
of
complaints
or
commentary
or
whatever,
like.
C
You
know
it's
not
there
yet,
but
it's
evolving
and
it's
important,
and
I
really
think
we
have
a
lot
of
you
know,
there's
a
lot
of
red
hatters
who
are
really
interested
in
that
being
true,
you
know,
and
so
I
think
you
know,
because
we're
an
open
source
company
that
likes
to
do
stuff,
we'll
probably
make
it
happen.
So
let's
see
we're
at
47
minutes
should
we
do
points.
I
think
we.
A
B
C
I
I
think
it'd
be
hilarious.
All
right,
let
me
find
the
correct
window,
and
now
we
have
slides
again-
and
here
we
are
with
the
sweet,
sweet
internet
points,
and
I
realized
that
I
also
forgot
to
cut
and
paste
this
stuff.
So
let
me
do
that.
Real,
quick,
no
friction
wow,
so
no
friction
still
on
top
and
I'm
not
sure
if
they're
here
today.
C
But
so,
if
you
want
to
collect
the
points
for
this
episode,
it
is
on
the
screen
as
you
can
see,
but
I
also
just
threw
it
in
the
chat.
So
we
have
noaa
friction
with
1500
sweet,
sweet
internet
points.
We
probably
need
some
more
commas
and
then
narendev
still
with
1300
points
still
holding
it
close,
but.
C
C
C
Yes,
so
a
new,
a
new
contender,
yes,
but
we
do
still
have
third
place
tie
with
joe
fuzz
and,
however
you
pronounce
nlhacm
and
and
then
j
walter
at
400
points,
so
there's
still
room,
there's
still
movement.
You
know
you
can
always
go
back
to
the
old
episodes
and
and
collect
those
sorry,
there's
also
other
activities
you
can
use
to
collect
internet
points.
You
can
go
and
join
the
discord.
You
can
also
submit
an
issue
with
ideas
for
the
show
on
the
on
the
episodes
repo.
A
This
slide,
although
again
discourse
is
or
not
discourse.
This
discord
is
disconnected
from
restream,
but
whatever
oh
really
like
I
mean
after
yesterday,
like
yesterday,
was
my
monday
as
far
as
the
channel
went
right,
like
technical
problems
like
little
glitches
here
and
there
across
the
entire
day
right,
but
like
that's
the
glitch
today,
there's
always
one
right
like
too
many
apis
out
there
for
me
to
have
a
smooth
streaming
day
right
actually.
A
Well,
no,
that
brings
up
a
good
point
right,
like
someone
told
us
to
launch
a
streaming
channel,
and
the
first
thing
we
thought
of
was
orchestration
right.
Restream
right,
like
we
thought,
let's
go
where
everybody
is
not
where
one
group
of
people
are
right,
so
we
thought
well.
How
do
we
orchestrate
this?
How
do
we
manage
this
at
scale?
C
B
A
So
it
used
to
be
a
joke
yeah,
I
think
actually,
one
of
my
military
buddies
might
have
started
that
like
when
we
were
gearing
up
for
oif
right,
like
we
were
literally
just
like
waiting
for
months
for
a
war
to
happen
and
if,
if
you've
ever,
you
know,
served
you're
like
okay,
are
we
starting
the
war
today?
No
or.
C
C
But
the
thing
I
particularly
remember
is
yahoo,
launched
during
the
time
I
was
there
and
so
before
that
we
would
literally
guess
website
names
and
because
apparently
we
were
dumb,
it
didn't
occur
to
any
of
us
that
you
could
have
maybe
a
list
of
them
somewhere
and
then
yahoo
launched
and
we
were
like
this
is
brilliant.
You
know,
because
yahoo
was
originally
right.
Just
it
was
a
literal
curated
list
of
website
names.
It
was
a
directory,
it.
D
C
Directory,
it
was
a
yellow
pages
and
you
know-
and
it
was
just
it
changed
the
game
so
much
and
and
in
retrospect
right
at
the
time
we
were
like
this
seems
so
obvious
to
build
something
like
this
right
and
yet
it
didn't
occur.
To
you
know
I
mean
some
fairly
technical
people
working
at
a
you
know
an
isp
we
had
at
internet
access.
We
understood
it
yeah,
but
it
was
pretty
hilarious
and.
B
A
C
B
A
C
C
How
do
you
know
when
you're
getting
to
the
tipping
point
of
you
know
kind
of
manually,
managed
containers
and
then
kind
of
some,
automated
orchestration
or
automated
management
of
the
containers
and
then
what
you
can
do
kind
of
in
the
meantime,
to
get
some
level
of
orchestration,
which
you
know
we
we've
done
podman
pods
on
the
show.
So,
if
you've,
if
you
haven't
watched
it
before,
you
know,
definitely
check
it
out
and
yeah,
that's
I
think,
I'm
pretty
good.
I
wanted
to
wrap
it
up.
A
Is
today
yeah
if
you
have
decided
to
go
down
the
orchestration
journey,
the
open
shift
administrator's
office
hour
is
coming
up
at
11
a.m:
eastern
1600
utc
and
then
after
that,
we'll
be
fueling
digital
transformation
with
cloud
native
applications
with
the
one
and
only
folks
from
light
bend
will
be
joining
michael
waite.
I
think
on
his
operator
hour,
so
yeah,
that's
the
next
two
shows
11
and
noon
eastern
time
today,
so
16
and
1700
utc,
and
then
after
that
meetings.