►
From YouTube: Cloud Native Infrastructure (The Podlets, Ep 5)
Description
Where does code live and run and what does it mean to create a cloud native infrastructure? Tune in to find out! We also have a conversation about the future of administrative roles in the cloud native space.
For the show notes and transcript: https://thepodlets.io/episodes/005-cloud-native-infrastructure/
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepodlets/issues
info@thepodlets.io
Hosts
https://twitter.com/carlisia
https://twitter.com/mauilion
https://twitter.com/apinick
B
A
Me
this
week
it's
been
really
interesting.
There's
a
internal
VMware
conference
called
radio
where
we
have
a
bunch
of
engineering
teams
across
the
entire
company
kind
of
get
together
and
talk
about
the
future
of
pretty
much
everything,
and
so
I've
been
kind
of
sponging
that
up
this
week
and
that's
been
really
interesting
kind
of
talking
about
all
the
interesting
ideas
and
fascinating
new
technologies
that
we're
working
on
awesome.
C
B
B
Basically,
I
I
was
interested
in
talking
about
this,
because
we've
spent
some
time
talking
about
some
of
the
different
ways
that
people
can
use
cloud
native
tooling,
but
I
wanted
to
kind
of
get
to
the
root
of
it
like.
Where
do
all
the?
Where
does
your
code
live?
Where
does
it
run?
What
does
it
mean
to
create
cloud
native
infrastructure
and
so
to
start
us
off?
You
know
I'm
going
to
talk
about
the
concept.
B
So
to
me,
cloud
native
infrastructure
is
basically
any
infrastructure
tool
or
service
that
allows
you
to
programmatically,
create
infrastructure
and
by
that
I
mean
like
your
compute
nodes.
Like
anything
running
your
application,
your
networking
so
software-defined,
networking,
storage,
so
Ceph
objects
or
that
sort
of
thing
you
can
just
spin
them
up
in
a
programmatic
allanne
like
contract
way,
and
then
you
know,
databases
as
well,
which
is
very
nice
and
then
I
also
kind
of
lump
in
anything.
That's
like
a
managed
service
as
part
of
that.
B
A
I
think
it's
I
mean
it's
definitely
one
of
my
favorite
topics.
I
spent
a
lot
of
my
career
working
with
infrastructure,
one
way
or
the
other,
whether
that
meant
racking
servers
and
racks,
and
do
it
the
old-school
way
and
figuring
out
power
budgets,
and
you
know,
dealing
with
networking
and
all
that
stuff
or
whether
that
meant.
You
know
finally
getting
to
a
point
where
I
have
an
API
and
my
customers
when
they
come
to
me
and
they
say:
I
need
10.
New
servers.
A
I
can
be
like
one
second
and
then
run
a
little
script
and
they
have
ten
new
servers
versus
you
know
having
to
order.
The
hardware
get
the
hardware
delivered,
gets
the
hardware
back
to
replace
the
stuff
that
was
dead
on
arrival
kind
of
go
through
that
whole
process,
and
so
yeah
infrastructure,
cloud
native
infrastructure
or
infrastructure
as
a
service.
It's
definitely
near
and
dear
to
my
heart.
B
C
Do
you
feel
about
if
you
are
an
admin,
so
you
work
for
VMware
and
you
were
a
field
engineer
now,
so
you
basically
a
consultant,
but
if
you
were
back
in
that
role
of
an
admin
at
a
company
and
you
had,
the
company
was
doing,
it
was
practicing
calculating
infrastructure
things,
and
so
basically,
what
we're
talking
about
is
we
go
back
to
the
theme
of
self-sufficiency,
I.
Think
we're
going
to
be
going
back
to
this
a
lot
too,
as
we
go
through
different
topics.
C
B
So
in
the
field
engineering
org,
we
kind
of
have
this
mantra
that
we're
trying
to
automate
ourselves
out
of
a
job
and
I
feel
like
anyone
who
is
like
really
getting
into
cloud
native
infrastructure.
That
is
the
path
that
they're
taking
as
well.
So
as
an
if
I
were
an
admin
in
a
world
that
was
like,
hybrid
or
anything
like
that.
They've
had
like
on
on
primer
main
or
bare
metal
infrastructure,
and
they
had
cloud
native
infrastructure.
B
I
would
be
more
than
ecstatic
to
take
any
amount
of
the
administrative
work
of
like
spinning
up
new
servers
in
the
cloud
native
infrastructure
I'll
wave
like
if
the
people
just
need
something
we
can
go,
click
click
click,
I've
got
whatever
services,
I
need
and
they
all
work
together,
because
the
cloud
makes
it
work
together.
Awesome
that
gives
me
more
time
to
do
other
tasks
that
may
be
a
bit
more
on
reserve
like
less
automated,
so
I'm
I
would
be
all
for
it.
So.
C
B
A
A
That's
you
know
so
many
thousand
people
who
are
like
gonna
be
storing
their
photos,
they're
getting
email,
doing
all
the
things
that
we
do
in
our
daily
lives
with
the
internet
and
that
globally,
like
across
the
whole
world,
there
are
only
about
which,
like
250,
K
or
300,000,
people
that
do
what
we
do,
that
understand
infrastructure
at
a
level
that
they
might
even
be
able
to
automate.
You
know
to
work
in
the
IT
industry
and
are
able
to
actually
facilitate
the
creation
of
those
resources
on
which
all
of
those
applications
will
be
hosted
right.
A
This
isn't
even
taking
into
account
the
number
of
applications
per
day
that
are
brought
into
the
internet
or
made
available
to
users.
Right
I
mean
like
this.
That
in
itself
is
a
whole
different
thing
like
how
many
people
are
putting
up
new
web
pages
or
putting
up
new
content
or
or
what-have-you
every
single
day.
So
fundamentally,
I
think
that,
like
we
have
to
think
about
the
problem
in
a
slightly
different
way,
this
isn't
about
whether
we
will
have
jobs.
A
It's
about
how
when
we
are
so
outnumbered,
you
know
how
do
we
as
this
as
this
regular,
relatively
small
force
in
the
world,
handles
the
demand
that
is
coming
that
head?
That
is
already
here
today
right
and
so
those
people
that
are
listening,
they
were
working
in
infrastructure.
Today,
your
value
is
actually
your
even
more
valuable
when
you
think
about
it
in
those
terms,
because
there
just
aren't
enough
people
on
the
planet
today
to
solve
those
problems
using
the
tools
that
we
are
using
today.
A
Right
and
so
automation
is
king
and
it
has
been
for
a
long
time
and
it's
not
going
anywhere
right.
We
need,
we
need
one
person
to.
We
need
the
people
that
we
have
to
be
able
to
actually
support
much
larger
numbers
or
bigger
scale
of
infrastructure
than
they
can.
Then
they
know
how
to
do
today.
Mess
and
that's
the
problem
that
we
have
to
solve.
Yeah.
C
Looking
from
the
perspective
of
whoever's,
paying
the
bills,
I
think
that
in
the
past
he
as
a
developer,
you
had
to
request
the
server
to
run
your
app
in
the
test
environment
and
eventually
you
get
it,
and
that
would
be
the
server
that
everybody
would
use
to
run
against.
Because
they're
you
develop
your
developer
in
the
group
and
everybody's
developing
different
features
and
that
one
server
is
what
we
would
use
to
push
up
changes
to
and
do
some
level
manual
tests.
C
So
maybe
we
have
a
QA
person
who
would
do
it
so
now,
so
that's
one
server
or
one
resource
or
one
virtual
machine,
so
now
I,
maybe
I'm
wrong,
but
as
a
developer,
I
think
what
I'm
seeing
is
I
will
have
access
to
to
compute
and
storage
and
I'll
run
a
script
and
I
boot
up
that
resources.
Just
for
myself,
is
there
more
or
less
expensive?
C
You
know
I
would
like
if
every
single
developer
is,
has
this
facility
to
spin
things
up
so
well,
much
quicker
because
we're
not
depending
on
I.t
and
if
we
have
a
script
I
mean
the
reality.
Is
it's
not
as
easy
like
just
one
command
and
you
get
it,
but
we
almost
there.
So
if
it's
so
easy
and
that's
why
everybody
is
doing,
doesn't
it
become
expensive
for
the
company
so.
B
It
can
like
that
I
think
when
cloud
native
infrastructure
really
became
more
popular
in
the
works
play,
a
replacement
became
more
like
mainstream.
There
was
a
lot
of
talk
about
the
concept
of
sticker
shock
right,
and
so
it's
the
idea
of
you
had
this
predictable
amount
of
money
that
was
allocated
to
your
infrastructure
before
you
know,
you're
right,
these
things
cost
this
much
and
their
value
will
degrade
over
time.
B
B
Suddenly
you
have
this
script
that
we're
talking
about
that
can
spin
up
an
equivalent
like
resource
as
one
of
those
servers
and
it'll,
and
if
someone
just
leaves
it
running,
that'll
run
for
a
long
long
time
and
so
you're
responsible
users
of
the
cloud
or
even
just
regular
users,
of
the
cloud
that
they,
it
does
cost
a
lot
of
money
to
use
any
of
these
cloud
services
or
it
can
cost
a
lot
of
money.
So
yes,
there
is
some
concern
about
the
amount
of
money
that
these
things
cost.
B
Because,
honestly,
as
we're
exploring
cloud
native
topics,
one
thing
keeps
coming
up
is
that
cloud
really
just
means
somebody
else's
computer
right
and
so
you're,
not
maintaining
you're,
not
using
the
cost
of
maintenance
or
the
time
it
takes
to
maintain
things.
Somebody
else
is,
and
you're
you're
paying
that
price
upfront,
instead
of
doing
it
on
like
a
yearly
basis
right.
So
it's
less
predictable
and
usually
a
bit
more
than
people
are
expected
right.
C
C
B
Yeah,
so
for
like
a
test
like
say
you're
running,
do
you
want
to
spin
up
your
code
really
quickly?
You
just
need
a
a
quick
like
setup
like
networking
and
compute
resources
to
test
out
your
code
and
you
spin
up
a
small
like
a
tiny
instance
somewhere
in
one
of
the
clouds
test
out
your
code
and
then
kill
the
instance
that
won't
cost
hardly
anything
and
it
didn't
really
cost
you
much
on
time
either
right.
B
So
you
had
this
automated
process,
hopefully
or
you
had
a
manual
process
that
isn't
too
onerous
and
you
get
the
resource
and
the
things
you
need
and
you're
good.
If
you
aren't
a
good
player
and
you
keep
it
going,
that
can
get
very
expensive
very
quickly
right,
because
it's
a
number
of
resources
used
per
hour,
I
think,
is
how
most
billing
happens
in
the
cloud
and
that
can
exponentially
run
by
me.
B
A
When
it
comes
to
infrastructure
and
means
that
you
can,
you
can
think
of
the
fact
that,
like
for
a
particular
cluster,
I
might
have
ten
of
those
VMs
that
we
talked
about
having
high
value
and
I
might
ended
of
those
running.
And
then
my
goal
is
to
make
sure
that
I
have
enough
consumers
of
those
ten
nodes
to
be
able
to
get
my
value
out
of
it.
And
so,
when
I
split
up
the
environment
such
that
every
level
developer
has
a
name
space
right.
A
B
C
B
C
B
B
Iii
think
that
they're
the
same
thing
so
cloud
like
infrastructure
is
code
for
the
cloud
is
inherently
cloud
native
right.
So
cloud
native
just
means
that
whatever
you're
trying
to
do
leverages
the
tools
and
the
contracts
that
a
cloud
provides,
so
the
basic
like
infrastructure
as
code
is
basically
just
how
do
I
use
the
cloud
and
like
that's
in.
B
An
automated
way-
or
it
is
in
a
way
right,
so
a
properly
constructed
cloud-
should
have
a
user
interface
of
some
kind
that
uses
an
API
write
a
contract
to
create
these
machines
or
create
these
resources
so
that
the
way
that
it
creates
its
own
resources
is
the
same
that
you
create
the
resource.
If
you
programmatically,
do
it
right.
C
B
A
A
B
Api's
are
critical
and
you
bring
up
a
good
point
or
mine,
or
something
not
every
cloud
that
you're
going
to
run
into
is
made
the
same.
There
are
some
clouds
that
exist
and
I'm
not
going
to
specifically
call
them
out,
but
there
are
some
clouds
that
exists,
that
the
API
is
people
use
in
their
requests
and
a
human
being
interprets
a
request
and
makes
the
changes.
That
is
a
big
no-no.
Mm-Hmm
me
no,
like
no
good
breaks
table,
I,
don't
yeah,
so
that
is
a
poorly
constructed
cloud
native
environment.
B
C
A
I'm
gonna
take
it
from
I'm
gonna.
Take
this
question
in
the
form
of
like
what
was
the
first
programmatic
infrastructure
of
the
service
that
I
played
with
and
and
for
me
that
was
actually
like
back
in
the
Neisseria
days
when
we
were
when
we
were
virtualizing
the
network
and
effectively
providing
and
in
building
an
API
that
would
allow
you
to
create
and
network
resources
and
the
and
the
difference.
The
different
targets
that
we
were
developing
for
were
things
like
XenServer,
which
at
the
time,
had
a
reasonable
API.
A
There
were
also
technologies,
like
KVM
the
ability
to
actually
use
KVM
to
create
virtual
machines
again
with
an
api
and
then,
although
in
KBM
it
wasn't
quite
the
same.
It
wasn't
quite
the
same
as
an
api,
that's
kind
of
where
things
like
OpenStack
and
those
technologies
came
along
and
kind
of
wrapped
a
lot
of
the
a
lot
of
the
capability
of
KVM
behind
a
restful
api
which
was
awesome
but
yeah
so
I
would
say.
A
His
answer
was
the
first
one,
and
that
gave
me
the
ability,
like
a
command-line
option,
with
which
I
could
stand
up
and
create
virtual
machines
and
give
them
somebody
resources
and
all
that
stuff.
And
then
you
know,
from
my
perspective,
it
was
the
witch
Neisseria
was
the
first
network
API
that
I
actually
ever
saw,
and
it
was
also
one
of
the
first
ones
I
worked
on,
which
was
pretty
neat
and.
B
All
right
for
me,
I
first
heard
of
cloud
native
infrastructure,
Nick
reminded
me:
it
was
a
the
OpenStack
day
as
I
think
it
was
really
when
I
first
heard
the
phrase
like
I
infrastructure-as-a-service
and
at
the
time
I
didn't
even
get
close
to
grokking.
It
I
still
don't
know
if
I
grok
it
fully,
but
I.
B
Was
working
a
redhead
at
the
time,
so
this
was
probably
back
in
like
2012-2013,
and
we
were
starting
to
leverage
OpenStack
more
and
having
like
this
API
driven
cool
set
that
could
like
spin
up
these
VMs
or
instances
was
really
cool
to
me.
But
it's
something
I
didn't
really
get
into
using
until
I
got
into
kubernetes
and
it's
specifically
using
kubernetes
on
different
clouds
such
as
like
80
AWS
for
Ezra
and
we'll
touch
on
those
a
little
bit
later.
B
But
it
was
using
those
and
then
having
like
a
CLI
that
had
an
API
that
I
could
reference
really
easily
to
spin
things.
I
was
like
holy
crap.
This
is
a
grotto
ball,
and
so
that
must've
been
around
like
the
2015/16
timeframe,
I
think
and
then
I
actually
heard
the
phrase
cloud
native
infrastructure,
first
from
our
friend
Chris
Nova's
book
cloud
native
infrastructure
and
I.
Think
that
really
helped
me
wrap
my
brain
around
really
what
it
is
to
have
something
be
like
cloud
native
infrastructure
and
like
how
the
different
clouds
interacted
in
this
way.
B
C
B
I
need
to
go
back
to
it,
cool
and
so
I
think
we
touched
on
something
that
we
normally
do,
which
is
like
what?
What
does
this
topic
mean
to
us?
I
think
we've
kind
of
touched
on
that
a
bit,
but
if
there's
anything
else
that
you
all
want
to
expand
upon
any
aspect
of
infrastructure
that
we've
not
touched
on
well,.
C
I
was
thinking
to
say
something
which
is
reflects
my
first
encounter
with
kubernetes
when
I
joined
happier
when
was
I
started
using
kubernetes
for
the
best
for
the
very
first
time
and
I
had
such
a
misconception
of
what
kubernetes
for
is
and
I'm
saying
what
I'm
going
to
say
to
touch
base
on
what
I
think
what
I
want
to
say.
I
want
to
relay
what
infrastructure,
as
code
is
not
that's.
B
C
C
I
need
to
have
a
cluster
running,
not
one
instance,
because
I
was
used
to
like
yeah
I
could
bring
up
an
instance
or
like
or
like
an
Isis
or
two
I've
done
this
before,
but
bringing
up
a
cluster
make
sure
everything
is
connected.
I
was
a
so
when
I
started
having
to
do
that.
I
was
thinking.
I
thought,
that's
what
kubernetes
did
I
don't
have
to
bother
with
this.
Isn't
that
what
he's
supposed
to
do?
Isn't
it
like
justify
kubernetes
and
all
that
gets
done?
And
then
I
had
that
realization?
C
You
know
their
encounter
with
reality.
No
I
still
have
to
put
up
money
for
structure
that
doesn't
go
away
because
it's
doing
kubernetes
kubernetes
is
like
this
abstraction
code
that
sits
on
top
of
that
infrastructure.
So
now
what
okay
I
can
do
manually
Wow
TGI
K
has
a
great
episode
where
Joe
goes
installs
everything
by
hand.
He
does
like
theme
by
every
single
thing
right,
every
single
step
that
you
need
to
do
hook
up
the
networking
piece.
It's
brilliant!
It
really
helps
you
visualize
what
happens
when
you
put
all
of
that
stuff?
C
How
all
that
stuff
is
brought
up,
because,
ideally
you're
not
doing
that
by
hand,
which
is
what
we're
talking
about
here
so
I
used,
for
example,
cloud
formation
on
on
AWS
with
a
template
that
helps.
You
also
has
a
partnership
with
AWS.
There
is
a
template
that
you
can
use
to
bring
up
a
cluster
for
kubernetes
in
everything's
hooked
up.
C
The
proper
networking
piece
is
there,
and
so
you
have
to
do
that
first
and
then
you
have
kubernetes
automatically
installed
as
part
of
the
template,
but
the
take
home
lesson
for
me
was
that
I
definitely
wanted
to
do
it
using
some
sort
of
automation,
because
otherwise
I
don't
have
time
for
that.
Nobody.
C
My
job
is
something
different:
I'm
just
voting
this
stuff
up
to
test
my
my
software
so
yeah,
absolutely
it's
very
handy,
and
but
if
you
for
people
who
is
not
working
with
kubernetes,
yet
I
just
wanted
to
clarify
that
there
is
a
separation
and
one
thing
is
having
your
infrastructure
in
place.
And
then
you
have
install
communities
on
top
of
that.
B
Kind
of
what
that's
a
good
point,
it's
something
I
want
I,
should
dive
into
and
I'm
glad
that
you
brought
this
up.
Actually
that's
a
good
example
as
a
cloud
native
application
using
the
cloud
native
infrastructure
and
criminalities
does
a
pretty
good
job
of
that
all
around,
and
so
the
idea
of,
like
kubernetes
itself,
is
platform.
B
So
you
have
like
a
platform
as
a
service,
that's
kind
of
what
you're
talking
about,
which
is
like
if
I
spin,
up
I
just
need
to
spin
up
a
kubernetes
and
then
boom
I
have
a
platform,
and
that
comes
with
the
infrastructure.
Part
of
that,
and
so
there
are
more
and
more
to
like
of
these
managed
kubernetes
offerings
that
are
coming
out
that
facilitate
that
function
and
those
are
an
aspect
of
cloud
native
infrastructure.
B
Those
are
the
managed
services
that
I
was
referring
to
where
the
administrators
of
the
cloud
are
taking
it
upon
themselves
to
do
all
that,
for
you
and
then
manage
it,
for
you
and
I
think
that's
a
very
great
offering
for
people
who
just
don't
want
to
get
into
the
weeds
or
don't
want
to
worry
about
the
management
of
their
applications.
Some
of
these
like,
for
instance,
databases.
These
managed
services,
are
an
awesome
tool.
Yeah.
C
B
Going
back
to
Kirby's
a
little
bit
as
well,
it
is
a
great
show
of
how
a
cloud
native
application
can
work
with
the
infrastructure
that
it's
on
so,
for
instance,
with
kubernetes.
If
you
spin
up
a
service
of
type
load
balancer
and
it's
connected
to
a
cloud
properly,
the
cloud
will
create
that
object
inside
of
itself.
For
you
right,
so
an
a
load
balancer
in
AWS
is
an
EOB.
It's
just
a
load,
balancer,
Nasir
and
I'm,
not
familiar
with
the
other
terms
that
the
other
cloud
z
is
but
it'll
create
these
things.
B
A
Yeah
I
agree
well,
yeah,
then
actually
I
kinda
wanted
to
make
a
point
on
that
as
well,
which
is
that
I
think
the
way
I
interpreted
your
original
questions.
Kaliesha
was
like
what
is
the
difference,
perhaps,
between
these
different
models
like
the
infrastructure
as
code
versus
a
pot,
you
know
or
infrastructure,
as
a
service
versus
platform
as
a
service
versus
you
know,
containers
are
those
service
like
what
what
I
work?
What
are
the
differentiation?
A
Whereas
when
we
look
at
infrastructure
as
a
service,
the
entry
point
is
fundamentally
different
right.
We
need
to
be
thinking
about
what
the
infrastructure
needs
to
look
up
like
I.
Would
my
I
might
ask
an
infrastructure
as
a
service
API,
how
many
machines
I
have
running
and
what
networks
they
are
associated
with
and
how
much
memory
and
disk
is
associated
with
each
of
those
machines,
whereas
if
I'm
interacting
with
a
platform
as
a
service
I,
might
ask
whatever
the
you
know,
questions
about
those
those
primitives
that
are
exposed
by
the
platform?
A
B
These
api's
all
the
way
down,
give
you
this
true
flexibility
and
like
the
real
functionality
that
you're
looking
for
in
cloud
because,
like
as
a
developer,
I,
don't
need
to
care
how
the
networking
works
or
where
my
storage
is
coming
from
or
where
these
things
are
actually
located.
What
the
IP
address
any
of
these
things,
I
want
someone
to
do
it
for
me
and
an
API
does
that
success,
and
that's
what
cloud
native
infrastructure
gets
you
speaking
of
that,
the
things
that
you
don't
care
about?
What
was
it
like
before
cloud?
B
C
A
Quite
the
same
thing,
I
don't
think
because
it
because
it
fundamentally,
the
underlying
technologies
are
very
different.
Another
way
of
explaining
the
difference
that
get
kind
of
that.
That
history
is,
you
know
back
in
the
day,
like
you
know,
2000
90s,
even
even
currently
like
what
we
have
is
we
have
a.
We
have
a
layer
of
people
who
are
like
involved
in
dealing
with
with
physical
hardware.
A
They
rack,
you
know,
10
or
20
servers
and
and
before
we
had
orchestration
and
virtualization
and
any
of
those
things
we
would
actually
be
installing
an
operating
system
and
applications
on
those
servers.
Those
servers
would
be
web
servers
and
those
servers
would
be
database
servers
and
they
would
be
a
physical
machine
dedicated
to
a
single
task
like
a
web
server
or
database
where
vSphere
comes
in
and
XenServer
and
KVM,
and
those
technologies
is
that
we
think
about
that.
We
think
about
this
model
fundamentally
differently.
A
Instead
of
thinking
about
it
like
one
application
per
physical
box,
we
think
about
each
physical
box
being
able
to
hold
a
bunch
of
these
virtual
boxes
that
look
like
the
virtual
machines
right
and
so
now
those
virtual
machines
are
where
we
put
our
application
code.
I
have
a
virtual
machine
that
is
a
web
server.
I
have
a
virtual
machine.
That
is
a
database
server.
A
A
A
I
just
need
enough
of
an
abstraction
to
give
me
enough
just
enough
isolation
back
and
forth
between
those
applications
such
that
they
have
their
own
file
system,
but
they
can
share
the
kernel
that
they
have
their
own
network,
but
they
can
share
the
physical
network
that
they
have
their
own,
that
you
know
that
we
have
enough
isolation
between
them
that
they
can't,
but
they
can't
interact
with
each
other,
except
for
when
intent
is
present.
Right.
Look
that
we
have
that
sort
of
level
of
abstraction
you
can
see.
A
This
is
a
much
more
granular
level
of
obstruction,
and
the
benefit
of
that
is
that
we're
not
actually
trying
to
create
a
virtual
machine
anymore,
we're
just
trying
to
effectively
isolate
processes
in
a
Linux
kernel,
and
so
instead
of
20
or
maybe
30
VMs
per
physical
box,
I
can
get
a
hundred
and
ten
processes
all
day
long.
You
know
on
a
physical
box
and
again
this
takes
us
back
to
that
concept
that
I
mentioned
earlier
around
bin
packing.
A
When
we're
talking
about
infrastructure,
we
have
been
on
this
eternal
quest
to
the
most
of
what
we
have
to
make
them
most
of
that
infrastructure.
You
know,
how
do
we
actually
well,
you
know
what
tools
and
tooling
do
we
need
to
be
able
to
see
the
most
efficiency
for
the
the
dollar
that
we
spend
on
that
hardware,
that.
A
Please
fear
is
the
one
that
creates
the
many
virtual
machines
on
top
of
a
physical
machine.
It
gives
you
it
gives
you
the
capability
of
having
really
good
isolation
between
these
virtual
machines
and
inside
of
those
virtual
machines.
You
feel,
like
you
have
like
a
metal
box,
but
it's
not
a
metal
box.
It's
just
a
process
running
on
a
metal
box.
All.
A
B
So
think
of
it
in
the
cloud
native
in
the
cloud
native
like
infrastructure,
world
vSphere
is
essentially
the
API
or
you
could
think
of
it
as
the
cloud
itself,
which
is
you
know,
it
is
in
a
sense
in
AWS,
but
for
your
data
center,
the
difference
being
that
there
isn't
a
particularly
useful
API
that
vSphere
exposes.
So
it
makes
it
harder
for
people
to
programmatically
leverage
which
makes
it
difficult
for
me
to
say,
like
these
fear,
is
a
cloud
native
app
like
okay,.
C
B
B
What
you
would
do
is
you
would
create
a
VM
that
had
your
application
already
installed
into
it,
there's
kind
of
burnt
into
the
image
so
that
when
that
VM
stood
up,
it
would
spin
up
that
process.
So
that
would
be
the
way
that
you
would
start
processes.
The
other
way
would
be
through
orchestration
tools
similar
to
Ansel,
but
they
existed
prior
ansible
that
essentially
just
ran
SSH
on
a
number
of
servers,
just
start
up
to
like
these
processes
and
that's
how
you'd
get
distributed
systems
prior
to
things
like
cloud
native
and
containers.
B
B
A
server
was
never
installed
properly
unless
my
blood
was
on
it
essentially
cuz
they're
heavy
and
the
it's
all
metal
and
it's
sharp
in
some
capacity,
and
so
you
would
inevitably
squash
a
hand
or
something
and
so
you'd
rack
up
the
server
and
then
you
plug
in
all
the
things,
plugging
all
the
plugs
and
then
set
it
up
manually
and
then
it's
good
to
go
and
then
someone
can
use
it
as
at
will
or
in
a
logical
manner.
Hopefully
so,
and
that's
what
we
had
to
do
before.
It's
like.
B
B
C
B
C
C
One
example
is
we
see
companies
like
uber
lyft?
Are
these
super
high-volume
companies
using
private
cloud
ProPublica
on
public
clouds,
which
is
to
say
paying
another
company
for
all
that
there
are
traffic
of
data
storage
of
data
in
compute
in
security
and
everything,
and
you
know
one
could
say
you
would
save
a
ton
of
money
to
innate
in-house,
but
using
bare
bare
metal
and
other
people
would
say
there
is
no
way
is
it
cost
so
much
for
us
to
host?
All
of
that
I
would.
B
Say
it
really
depends
on
the
environment,
so
usually
I
would
I
think
that
if
a
company
is
using
only
cloud
native
resources
to
begin
with,
it's
hard
to
make
the
transition
into
bare
metal,
because
you're
used
to
these
tools
being
in
place,
a
company
that
is
more
familiar
like
they
came
from
a
bare
metal
background
and
move
to
cloud.
They
may
leverage
both
in
a
hybrid
fashion,
well
because
they
should
have
tooling
or
they
can
now
create
tooling.
B
It
really.
It
really
depends
on
the
company
and
also
the
need
of
security
and
data
retention,
and
all
these
things
that
have
like,
if
you
need
this
granularity
of
control
bare
metal,
might
be
a
better
approach,
because
if
you
need
to
make
sure
that
your
data
doesn't
leave
your
company
in
a
specific
way,
putting
it
on
somebody
else's
computer,
probably
isn't
the
best
way
to
handle
that
or
I
can't
remember
was
gonna.
Go
with
that,
so
it
there
is
like
a
balancing
act
of
like
how
much
resources
are
using
in
the
cloud
and
how?
B
How
are
you
using
the
cloud
and
what
does
that
cost
look
like
versus?
What
does
it
cost
to
run
a
data
center
and
like
have
the
physical
real
estate
and
then
have
like
run
the
electricity
of
the
HVAC
people's
jobs,
like
their
salaries,
specifically
to
manage
that
location
and
your
your
compute
and
network
resources
and
all
these
things?
B
B
B
It
can
it
really.
It
really
depends
on
the
people
that
you
have
working
for
you
like.
If
the
people
you
have
working
for
you
are
good
at
trading
automation
and
are
good
at
managing
infrastructure
of
any
kind.
It
shouldn't
be
too
bad,
but
as
we're
moving
more
and
more
into
a
cloud
focused
world
I
wonder
if
those
people
are
going
to
start
going
away.
A
I
do
I
completely
agree
with
the
statement
of
it
depends
on
the
people
that
you
have
right
and
fundamentally
I
think
my
point
I
would
add
to
this:
is
that
uber
right
or
a
company
like
uber
or
a
company
like
lyft?
How
many
people
do
they
employ
that
are
focused
on
infrastructure,
right
and
I?
Don't
know
the
answer
to
this
question,
but
I'm
positioning
it
right.
A
So
if,
if
we
assume
that
they
have,
you
know
that
this
is
a
pretty
hot
market
for
people
who
understand
infrastructure,
so
they're
not
gonna
have
a
ton
of
them.
So
what
specific
problems
do
they
want?
Those
people
that
they
employ
that
are
focused
on
the
infrastructure
just
solve
alright,
and
now
we're
now
we're
now
we're
thinking
about
this
as
a
scale
problem
I
have
10
people
that
are
gonna,
manage
the
infrastructure
for
all
of
the
applications
that
uber
has.
A
Maybe
I
have
20
people,
but
it's
gonna
be
percentage
of
the
people
compared
to
the
number
of
people
that
I
have
maybe
developing
for
those
applications
or
for
marketing
or
for
you
know,
within
the
company
I'm
going
to
have
I'm
going
to
be
I'm.
Gonna
quickly
find
myself
off
balance
and
the
number
of
applications
that
I
need
to
actually
support
that
I
need
to
operationalize
to
be
able
to
get
to
deployed
right.
A
First
is
the
number
of
people
that
I
have
doing
the
infrastructure
work
to
provide
that
base
layer
for
which,
for
which
all
of
those
applications
will
be
deployed.
All
right,
I,
look
around
on
the
market
and
I
see
things
like
orchestration.
I,
see
things
like
uber,
you
need
is
mezzos
and
technologies
like
that
that
can
provide
kind
of
a
multiplier,
or
even
you
know,
AWS
or
as
your
GCP
I
have
these
things
act
as
a
multiplier
for
those
10
infrastructure
people
that
I
have
right.
A
Cuz
knows
they're,
not
looking
at
trying
to
figure
out
how
to
store.
You
know,
get
this
data
and
that
worried
about
data
centers
and
not
worry
about
servers
are
not
worried
about
networking
right.
They
can.
Actually,
you
know.
Ten
people
that
are
decent
at
infrastructure
can
span,
can
spin
up
very
large
amounts
of
infrastructure
to
satisfy
the
developer
or
the
operational
need
of
a
company
the
size
of
a
goobers
reasonably.
A
B
But
it's
like
that
one
percent,
their
job
is
usually
focused
around
automating
the
allocation
of
resources
and
figuring
out
like
how
the
tools
that
they
can
use
to
better
leverage
those
clouds
in
the
bare
environment.
Those
people's
jobs
are
more
like.
Oh
crap,
suddenly
were
at
90
degrees
in
the
data
center
in
San
Jose.
B
What's
going
on
and
then
having
someone
go
out
there
and
figuring
out
what
physical
problem
is
going
on
and
it's
like
a
lot
of
their
their
day-to-day
lives
and
something
I
wanted
to
touch
on
really
quickly
as
well
with
bare
metal
prior
to
bare
metal.
We
had
something
kind
of
interesting
that
we
were
able
to
leverage
from
an
infrastructure
standpoint
and
that's
mainframes
and
we're
actually
kind
of
going
back
a
little
bit
to
the
mainframe
idea,
but
the
idea
the
mainframe
is
kind.
B
It
is
essentially
it's
almost
like
a
cloud
native
technology,
but
not
really
so,
instead
of
you,
using
whatever,
like
you're
able
to
spend
a
X
number
of
resources
and
networking
and
make
that
work,
the
way
the
mainframe
would
work
was
that
everyone
used
the
same
compete
resource.
It
was
just
one
giant
compute
resource.
There
was
no
networking
needed
because
everyone's
connected
to
the
same
resource
and
they
would
just
do
whatever
they
needed,
write
their
code,
run
it
and
then
be
done
with
it
and
then
come
off,
and
it
was
it's
a
really
interesting
idea.
C
A
C
A
What's
the
idea
of
a
cluster
and
those
sorts
of
those
sorts
of
things
are?
Is
it
it's
kind
of
a
domain
of
what
you're
looking
at
mainframe
considers
everything
to
be
within
the
same
physical
domain,
whereas
like
when
you
start
getting
into
kind
of
the
larger
architectures
are
some
of
the
more
scalable
architectures?
You
find
that
just
like
any
distributed
system,
we're
kind
of
spreading
that
we're
spreading
that
work
across
a
number
of
physical
notes,
and
so
we
think
about
it
fundamentally
differently.
But
it
is
interesting.
A
B
B
So
something
we've
mentioned
before,
but
Amazon's
AWS
is
pretty
much
like
the
number
one
cloud,
I'm
pretty
sure
right,
like
that's
the
most
number
of
users
and
they
have
a
really
well
structured,
API,
really
good
CLI,
decent
GUI
sometimes
have
some
problems
with
it,
and
it's
it's
like
the
thing
that
people
think
of
when
they
think
cloud
native
infrastructure.
So.
B
A
Going
back
to
that
point
again,
I
think
that
AWS
was
you
know,
agreed.
One
of
the
AWS
is
one
of
the
largest
cloud
providers
and
has
kind
of
the
most
certainly
the
most
adoption
as
a
cloud
native
as
an
infrastructure
for
cloud
native
infrastructure,
and
it
is
really
interesting
to
see
a
number
of
other
solutions
out
there.
Ibm
has
one
GCP
as
your.
A
B
Yeah
and
also
something
that
we
kind
of
touched
on
a
little
bit
as
well,
but
from
a
cloud
native
infrastructure
standpoint.
It
isn't
long
to
say
that
a
bare-metal
data
center
can
be
a
cloud
native
infrastructure.
As
long
as
you
have
the
tooling
in
place,
you
can
have
you
can
have
your
own
cloud
native
infrastructure,
your
own
private
cloud,
essentially
I,
know
that
private
cloud
doesn't
actually
make
any
sense.
B
That's
not
how
clouds
work,
but
you
can
have
a
cloud
native
infrastructure
in
your
own
data
center,
but
it
takes
a
lot
of
work
and
it
takes
a
lot
of
management,
but
it
isn't
something
that
exists
solely
in
the
realm
of
Amazon,
IBM,
Google
or
Microsoft,
and
I
can't
remember
the
other
names,
the
other
ones
that
are
running
as
well.
Yeah.
A
Agreed
and
actually
one
of
the
questions
you
asked
Carly
said
earlier,
that
I
didn't
get
a
chance
to
answer
was
like.
Is
it?
Do
you
think
it's
worth
running
bare-metal
today
and
in
my
opinion
the
answer
will
always
be
yes
right,
there's
always
going
as
we
think
about
like.
If
the
line
that
we
draw
in
the
sand
is
container
isolation
or
container
orchestration,
then
there
will
always
be
a
good
reason
to
run
on
bare
metal
to
basically
expose
resources
that
resources
that
are
available
to
us
against
a
single
bare
metal
instance.
A
I,
think
there'll,
I,
think
they'll
always
be
around,
but
to
Nick's
point
in
a
sequence:
we've
covered
pretty
pretty
thoroughly
in
this
episode
having
an
API
between
me
and
the
infrastructure.
It's
not
something
I'm
willing
to
give
up
I
need
that
to
be
able
to
actually
to
solve
my
problems
at
scale,
even
a
reasonable
scale.
Yeah
you.
B
Mean
you
don't
wanna
go
back
to
the
battle
days
of
our
tell
netting
into
a
Juniper
switch
and
telling
you
know,
setting
up
your
IP,
not
IP
tables
of
your.
You
know,
IP
conf
commands
usually
telling
it
Nick
I,
said
Tellman
yeah
or
serial
serial
connect
into
a
yeah
anyway
excellent
baby,
I
I
think
that
pretty
much
covers
it
from
cloud
native
infrastructure.
Do
you
do
you
all
have
any
thoughts,
finishing
thoughts
on
the
topic?
No.
B
I
had
a
great
time,
this
is
a
topic
that
I
very
much
enjoy.
It's
I'm
things
like
kubernetes
and
the
cloud
native
infrastructure
that
we
exist
in
is
always
what
I
wanted
us
to
get
to
like
when
I
was
in
university
like
this
was
I'm
like
oh
man,
someday
we're,
gonna
live
in
a
world
with
virtual
machines
and
I
didn't
even
have
the
idea
of
containers,
but
like
people
can
like
really
easily
deploy.
B
C
A
developer,
I
have
to
say:
I
am
too
and
I
was
I
had
just
started
my
mind
as
we
having
this
conversation
that
I
am
so
happy
to
WR,
where
we
are
and
I
think.
Well,
obviously,
not
everybody
is
there
yet
and
but,
as
people
start
practicing
cognitive
developments,
you
know
what
they
will
come
to
realize
what
we
did,
but
it
isn't.
We
talking
about
I,
mean
I,
said
before
I.
Remember
the
days
when,
for
me
to
get
access
to
a
server
I
had
to
fire
a
ticket
way
for
somebody
to
approve.
C
Oh,
maybe
I,
wouldn't
gather
approval
and,
and
when
I
say
me
I
said
I
mean
my
team,
or
one
of
us
would
do
the
request,
and
you
know
you
had
that
server
and
everybody
was
pushing
to
to
the
server
like
one.
The
main
version
of
our
app,
maybe
would
run
like
every
day.
We
will
get
a
fresh
copy
now,
the
way
it
is
now
I
don't
have
to
depend
on
anyone.
And
yes,
it
is
a
little
bit
of
work.
C
It's
like
I,
don't
have
to
wait
for
code
to
merge
and
it
pushed
its
my
codes.
That's
right.
They're
sitting
on
my
computer
I
am
pushing
it
to
the
clouds
boom.
I
can
test
a
some
things.
I
can
test
on
my
on
my
machine,
but
some
things
I
can't
it's
like
when
I'm
doing
follow,
I
have
to
push
it
to
the
cloud
provider.
It's
amazing.
It
is
so
now
I
feel
very
old
telling
them
with
some.
That
makes
me
very
happy
totally.
B
Agree
for
that
exact
reason,
like
you
know,
testing
things
out,
maybe
something
isn't
ready
for
somebody
else
to
see.
It's
not
ready
for
primetime,
so
I
just
needed
I
need
something
really
quick
to
test
it
out,
but
also
for
me,
I
am
the
avatar
of
unwitting
chaos,
meaning
basically,
everything
I
touch
will
eventually
blow
up.
So
it's
also
nice
that
whatever
I
do
that's
weird,
isn't
going
to
affect
anybody
else
either
and
that's
great
blast.
Radius
is
amazing.
B
Alright,
so
I
think
that
pretty
much
wraps
it
up
for
the
cloud
native
infrastructure
episode,
I
had
an
awesome
time.
This
is
always
fun,
so
please
send
your
concepts
and
ideas
in
the
github
issue
tracker.
You
can
see
our
existing
episode
in
suggestions
and
you
can
add
your
own,
add
github.com,
slash
hefty
FTO
/dq
bullets
and
go
to
the
issues,
tab
and
file
a
new
issue
or
see
what's
already
there.
Alright,
we'll
see
you
next
time.