►
From YouTube: Cloud Native Apps (The Podlets, Ep 16)
Description
Do you know what cloud native apps are? Well, we don’t really either, but today we’re on a mission to find out! This episode is an exciting one, where we bring all of our different understandings of what cloud native apps are to the table. The topic is so interesting and diverse and can be interpreted in a myriad of ways. The term ‘cloud native app’ is not very concrete, which allows for this open interpretation. We begin by discussing what we understand cloud native apps to be. We see that while we all have similar definitions, there are still many differences in how we interpret this term. These different interpretations unlock some other important questions that we also delve into.
For the show notes and transcript: https://thepodlets.io/episodes/016-cloud-native-apps
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/joshrosso
https://twitter.com/bryanl
https://twitter.com/apinick
C
A
C
B
Awesome
laughs,
yeah
I've
been
having
a
good
week
as
well,
been
doing
a
bit
of
some
fun
stuff
after
work
like
my
soon-to-be
in-laws
are
in
towns,
I've
been
visiting
with
them
and
that's
been
really
fun,
so
cloud
native
applications.
What
what
does
that
mean
to
y'all,
because
I
think
that's
an
interesting
topic
really
see
I
want
you,
sir.
Definitely.
A
Not
a
monolith,
I
think
if
you
have
one
of
its
Ronnie
on
the
clouds,
even
if
you
started
out
that
way,
I
wouldn't
say
it's
a
cloud
near
the
path.
I,
always
think
of
containers
contests
containerize
applications
and,
if
you're
using
the
container
system,
then
usually
because
you
want
to
have
smaller
systems
and
more
of
them,
that's
sort
of
me
and
also
when
I
think
of
cloud
native
applications.
I
think
that
they
were
developed.
C
So
I
think
of
it
as
applications
that
were
designed
to
run
in
container
and
and
I
also
think
about
things
like
services
like
micro
services
or
macro
service.
I.
Don't
really
know
what
you
want
to
call
them
that
we
have
multiple
applications
that
are
made
to
talk
not
just
with
themselves
but
with
other
apps,
and
they
deliver
a
bigger
functionality
through
their
coordination
and
then
when
I
also
want
to
think
of
cloud
native
apps
I.
C
Think
of
apps
that
we
are
moving
to
the
cloud
and
that's
a
it's
a
big
topic
in
itself,
but
applications
that
we
run
in
the
in
the
cloud.
So
all
of
our
new
fanzi
services
and
our
SAS
offerings.
A
lot
of
these
are
cloud
native
apps.
But
then
on
the
other
side,
I
think
about
applications
and
maiden
that
are
cloud
native,
are
tolerant
to
failure
and
on
the
other
side
can
give
themselves.
You
can
actually
talk
about
themselves
about
their
health
and
who
they're
talking
to
you.
D
I
think
I
think
the
key
things
have
been
mentioned.
I
guess
the
the
big
attributes
for
me
that
always
come
to
mind
are
obviously
portability
right.
So
wherever
you're
running
this
application
and
it
can
run
somewhat
consistently
beyond
different
clouds
or
even
a
lot
of
people,
you
know
are
running
their
own
cloud,
which
is
basically
their
on-prem
cloud
right
and
that
application
being
able
to
move
across
any
of
those
places
and
oftentimes
containerization
is
one
of
the
mechanisms
we
use
to
do
that
right,
which
is
what
we
all
had
stated,
then
I
guess.
D
B
It's
interesting
for
me
like
this
question,
because
it's
like
we
all
gave
or
so
far
everyone
is
getting
like
similar,
but
also
different
answers,
and
for
me,
I'm
gonna
give
a
slightly
different
answer
to
me.
A
cloud
native
is
a
lot
of
things.
We
said
like
portable
I,
think
of
microservices
when
I
think
of
a
cloud
a
native
application,
but
it's
also
an
application
that
can
modify
the
infrastructure
it
needs
the
API
calls
right.
B
So
if
your
application
needs
a
service
or
needs
and
networking
connection
it
can
the
application
of
can
manifest
that,
via,
like
the
cloud
offering
right,
that's
what
I
always
thought
of
as
a
cloud
native
application
like.
So,
if
you
need
like
a
database,
the
application
can
reach
out
to
like
AWS,
RDS
and
spin
up
a
database,
and
that
was
an
aspect
that
I
always
found
very
fascinated
with
cloud
native
applications.
It
isn't
necessarily
the
definition,
but
for
me
that's
a
part
that
I
was
really
focused
on
I.
Think
it's
quite
interesting.
Oh.
C
I
have
an
addition.
Also
CI
and
CD
cloud
native
apps
are
made
to
work
well
with
our
CI,
our
continuous
integration
and
our
continuous
delivery
/
deployment
systems
as
well.
So
that's
like
another
very
important
aspect
of
native
applications.
We
should
be
able
to
deploy
them
to
production
without
typing.
Anything
in
it
should
be
some
kind
of
automated
process.
C
B
B
C
A
B
A
To
have
and
for
example,
when
we
think
our
natives
crowd,
native
and
them
think
maybe
I'm
going
off
on
the
tangent
here,
but
we
have
kubernetes,
isn't
that
what
coverlet
is
supposed
to
do
to
glue
it
out
together.
So
the
application
only
needs
to
know
what
it
needs
to
do,
but
like
spinning
up
an
outside
system
is
not
one
of
the
things.
I
would
need
to
do
so,
but
you're
an
infrastructure
infrastructure
professional.
So
teach
me.
B
Sure,
actually
I
was
gonna
use
kubernetes
as
my
example
for
a
cloud
native
application,
because
Cooper
knows
it's
an
app
right
and
it
can
modify
the
cloud
that
it's
running
in
right.
So
if
you
have
communities
running
an
AWS,
you
can
create
a
elby's
elastic
load.
Balancers,
you
can
create
new
nodes.
B
You
can
create
new,
like
databases
if
you
need,
as
I
mentioned
so
Crimmins
itself
is
the
doesn't
like
my
example
of
like
a
cloud
native
application
and
I
should
say
that
that
it's
a
good
call
out
my
example
of
what
a
cloud
native
application
is
isn't
necessarily
like.
That's
a
rule
like
all
cognitive
applications
have
to
map
modify
the
cloud
in
which
they
exist
in
it's
more
that
they
can
modify
be
like.
That
is
a
component
of
a
cognitive
application.
So
Goodman
is
being
an
example.
B
A
A
See
where
you're
saying,
because,
for
example,
if
I
choose
to
use
data
stored
there
storage
inside
something
like
kubernetes,
then
it
will
be
required
of
my
app
to
have
to
call
an
SDK
and
connect
that
data
storage
some
somehow
so
in
essence,
I
guess
you
are
using
your
app
it.
Someone
correct
me
if
I'm
wrong,
but
so
you
would
that's
how
the
connect
is
created
right
like
so.
A
You
just
request
but
you're,
not
necessarily
saying
I
want
this
thing
and
specifically
just
say:
I
want
this
sort
of
thing
like
which
is
severe
storage,
and
then
you
define
that
elsewhere.
So
your
application,
this
doesn't
need
to
know
details,
but
it
definitely
needs
to
say
I
need
this
and
I'm
talking
about
again.
Like
me,.
B
C
So
that
brings
up
an
interesting
part
of
this
whole
term
cloud
native
app
because
I
think
we
it's
a
it's
like
everything
else
in
the
space,
our
terms
are
not
super
concrete
and
an
interesting
piece
about
this
is
that
an
application
there's
an
application
have
to
map
one
to
one
with
the
running
process.
What
is
an
application
that.
B
C
So
let's
say
you
were
building
this
large
SAS
service
and
because
you
were,
you
were
selling
dog
food
online.
Your
application
could
be
your
your
dog
food
application,
but
you
have
inventory
management,
you
have
a
front-end,
maybe
you
have
an
ad
service,
you
have
a
shipping
management,
manifest
manager
and
things
like
that
sales,
tax
calculator
are
those
all
applications
or
is
it
one
application?
C
And
so
a
neat
piece
about
cloud
applications
are
cloud
native
applications,
because
we
found
in
kubernetes
is
that
the
way
we're
thinking
about
applications
is
an
application
is
is
multiple
processes
that
could
be
linked
together
and
we
can
tell
the
whole
story
of
all.
Those
interactions
are
working
so
just
something
else.
Another
way
to
think
about
this.
B
B
C
So
that
is
actually
something
that
is
happening.
It's
a
little
transparent
of
people,
but
I
can
see
it
to
the
point
of
we're
just
requesting
a
new
resource
and
if
we
are
using
for
using
our
services
to
watch
our
other
things
or
our
our
cloud
native
services
to
watch
our
applications,
I
can
see
us
asking
for
discs
on
demand
or
even
a
service
like
a
like
a
database
or
some
other
type
of
queuing
thing
on
debating.
It's
did
you
make
that
point.
Yeah.
A
A
I
mean
I
mean
we
can
talk
about
like
how
is
it
so
hope,
so
this
is
sort
of
how
it's
done
now.
I
mean
it's
really
hard
to
go
into
details
on
one-hour
episode,
so
we
can't
cover
the
how
it's
done.
I
mean
conceptually.
We
are
sort
of
throwing
a
lot
of
words
out
there
to
try
to
conceptualize
it,
but
we
can
also
try
to
talk
about
it
in
a
conceptual
way
how
he
was
done
in
an
oncoming.
It
is
done
in
a
no
cloud
negative
world.
B
Yeah
I
couldn't
want
to
get
back
to
the
question
I
posed
before,
like
what
is
a
monolithic
app
like
what
is
he
not
in
cloud
native
app
and
not
all
a
non-coding
area.
Babs
are
monoliths,
but
this
is
actually
some
that
I've
heard
a
lot
and
I'll
be
honest.
I,
don't
I
have
an
idea.
What
a
monolithic
app
is,
but
I
think
I
don't
have
very
good
comp,
a
very
good
grasp
of
it.
So
we
kind
of
talked
a
bit
about
like
what
a
cloud
native
app
is.
B
A
A
lot
of
thoughts
I'm
particularly
I'm
personally,
not
a
big
fan
of
monoliths.
Of
course,
I
worked
with
them,
but
once
micro
services
started
becoming
common
and
I
tried
and
I
started
using
developing
in
that
mode,
I
am
much
more
of
a
fan
of
breaking
things
down,
for
so
many
different
reasons
is
a
controversial
topic
for
sure.
But
to
go
back
to
your
question,
the
monolith
is,
basically,
you
have
an
app
and
sort
of
goes
to
what
Brian
was
saying.
It's
like
what
isn't
there.
A
So
if
you
think
of
a
now
like
one
thing
like
like
Amazon,
is
an
app
right,
it's
an
app
that
we
use
to
to
buy
things
as
consumers,
and
you
know
they
are.
The
part.
Is
the
clouds?
Let's
not,
but
let's
look
at
it
like
it's
an
app
that
we
use
to
buy
things
as
consumers,
if
that,
if
all
like,
we
know,
is
broken
down
into
so
many
different
services,
there
is
the
checkout,
sir.
That
is
the
the
cart
service.
A
I
mean
I
imagining
things
that
I
can
imagine
our
small
services
that
compose
that
one
amazon.
Now,
if
he
was
a
monolith,
those
services
that
you
know
like
those
things
are
different
systems
that
are
talking
together.
The
whole
thing
would
be
over
on
one
code
base,
you'll
be
right.
It's
like
we
reside
in
the
same
code
base
will
be
deployed
to
get
there
will
be
shipped
together.
If
you've
made
a
change
in
one
place,
you
know
the
hole
and
you
needed
to
deploy
die.
A
You
have
to
deploy
the
whole
thing
together
and
the
teams
they
are
working.
You
might
have
teams
that
are
working
on
several
aspects,
but
they're
working
against
the
same
codebase,
and
maybe
because
of
that
that
will
lend
itself
to
teams
not
really
specializing
on
Citroen
that
won't
separate
aspects,
because
everything
is
together,
so
you
might
make
one
change
the
impacts
another
place,
and
then
you
have
to
know
that
far
as
Wow,
and
so
there
is
a
lot
less.
D
Yeah,
maybe
maybe
to
give
an
example
of
my
experience
and
I
think
it
aligns
with
a
lot
of
deep
I
was
Carly,
so
you
just
went
over
like
even
taking
five
years
back.
My
experience
at
least
was
we'd
read
up
a
ticket
and
we'd
ask
somebody
to
like
make
a
server
space
for
us,
maybe
room
right,
and
then
we
write
all
this
Java
code
and
we
package
it
into
these.
These
things
that
run
on
us
on
a
JVM
somewhere
right
and
we
would
deploy
this
whole
big
application.
D
You
know
it's
called
that
dog
food
app
right
and
it
would
have
maybe
even
like
the
state
layer,
it
would
have
the
web
server
layer
that
would
maybe
have
all
these
different
pieces
all
running
together.
This
is
this
big
code
bases
carlie,
you
put
it
and
we
deploy
it
and
that
process.
You
know
that
process
took
a
lot
of
time
and
it
was
very
consuming,
especially
when
we
needed
to
change
stuff.
D
We
didn't
have
all
these
like
modern
api's
and
these
kind
of
decoupled
applications
right,
but
then,
over
time
you
know
we
started
to
learn
more
and
more
about
the
notion
of
like
isolating
each
of
these
pieces
or
layers
that
we
could
have.
You
know
the
web
server
isolated
in
its
own,
let's
say
container
or
unit,
and
then
the
state
layer
and
the
other
layer
is
even
isolated.
You
know
the
the
micro-service
approach
more
or
less
and.
C
D
And
that
was
really
awesome,
so
we
saw
a
lot
of
games
in
that
respect,
but
it's
not
all
like
you
know,
rainbows
and
right
like
we
just.
We
basically
moved
our
complexity
to
other
airports.
We
took
our
complexity
that
used
to
all
happen
in
the
same
memory
space,
and
we
moved
a
lot
of
it
into
the
network
with
these
new
protocols
that
let
different
services.
A
Me
just
say
one
more
thing:
sorry
because
it's
actually
the
biggest
the
biggest
act,
the
the
aspect
of
micro
services
that
I
like
the
most
in
by
comparison.
You
know
the
aspect
of
monolith
that
I
hate
the
most,
not
I,
don't
hate
it.
Just
like
I
appreciate
the
least.
That
way
is
that
when
you
have
a
monolith,
it
is
so
easy
because
design
is
hard.
So
it's
so
easy
to
couple
different
parts
of
your
system
of
your
app
with
other
parts
of
your
app
and
have
couples
cold
and
in
couples
functionality.
A
And
when
you
break
things
into
micro-services,
it's
that
is
impossible,
because
if
it's
working
with
separate
code
bases
and
though,
if
you're
forced
to
think
what's
your
interface,
you
always
think
it
about.
What's
your
interface
and
in
what
people
need
to
consume
from
you,
because
that
your
interface
is
the
only
way
in
and
out
only
way
into
your
app
into
your
system.
So
I
really
like
the
aspect
that
it
forces
you
to
think
about
your
API
and
people
were
argue.
Well,
you
can't
put
the
same
amount
of
effort
into
that.
A
If
you
have
a
monolith
absolutely,
but
in
reality
I,
don't
see
it
and
like
Josh
was
saying,
is
not
a
walk
in
the
park,
but
I
much
rather
deal
with
those
issues.
Those
complexities
that
microservice
creates.
Then
the
challenges
of
running
em
on
big
and
I'm
talking
about
big
monolith
right
I'm,
not
nothing,
not
not
something
to
review.
Sorry:
okay,
go
ahead,
burn.
C
Alright,
so
I
will
come
to
distill
this
about
how
monoliths
and
and
how
it
fits
into
this
conversation.
So
a
model
is
simply
an
application
that
is
or
a
single
process
in
this
case
that
is
running
both
the
the
UI,
the
fronting
code
and
the
code
that
fetches
the
state
from
a
data
store,
whether
that
be
disk
or
or
database.
That
is
that
is
what
about
all
this.
The
reasons
people
use
models
are
many,
but
I
can
actually
think
of
some
very
good
reasons.
C
If
you
have
code
reuse
and
let's
say
you
have
a
website
and
you
were
trying
to-
and
you
know
forms
and
you
want
to
be
able
to
those
form,
libraries
or
you
have
data
access,
and
you
want
to
be
able
to
reuse
that
data
access
code,
a
monolith
is,
is
great.
The
problem
with
monoliths
is,
as
functionality
becomes
larger,
the
complexity
becomes
larger
and
not
at
the
same
rate
and
I'm
not
gonna
say
that
it
is
it's
not
linear,
but
it's
not
quite
exponential.
C
So
maybe
it's
log
into
or
something
like
that,
but
the
problem
is
that
at
a
certain
point,
you're
going
to
have
so
much
functionality,
you're
not
going
to
be
able
to
put
it
inside
of
one
process
see
rails
rails
is
actually
a
great
example
of
this.
Where
we've
added
to
the
issues
where
we
put
so
much
application
into
our
ArrayList
source
directory
and
we
try
to
run
it
and
we
basically
run
up
with
these
huge
processes
and
we
split
them
up.
C
But
what
we
found
is
that
we
could
actually
split
out
the
front-end
code
to
one
one
process.
We
could
spit
out
the
middleware
to
multiple
processes
in
the
middle,
the
data
access
layer
to
another
process,
and
we
can
use
those
and
we
could
actually
take
care.
We
could
actually
take
advantage
of
multiple
CPU
cars
or
multiple
computers.
The
problem
with
this
is
is
that
with
splitting
this
out
is
complexity,
so
one
via
the
libraries.
So
what
I'm
trying
to
say
here
in
a
very
long
way
is
that
model
is
half
their
place.
C
A
C
Native
world,
because
we're
trying
the
advantage
of
containers
we're
trying
to
take
advantage
of,
of
course,
on
CPUs
we're
trying
to
take
advantage
of
multiple
computers
to
do
that
in
the
most
efficient
way.
You
want
to
split
your
application
up
into
smaller
pieces
so
that
your
front
end
versus
your
middleware,
which
is
your
data
access
layer.
This
is
your
data
layer
itself
can
run
on
as
many
computers
and
as
many
cores
as
possible,
therefore
spreading
the
risk
and
spread
and
the
usage,
so
everything
should
be
faster.
B
It
was
interesting
to
hear
the
concept
of
it
being
that
each
way
you
deploy
your
application
is
complex,
but
there
are
different
trade-offs
right
and
so
is
the
idea
that
I'm,
like
I,
always
thought.
Oh
whoa.
What
you
want
to
turn
your
monolithic
into
micro
services
like
well,
there's
so
much
overhead,
so
much
more
yak
shaving.
You
have
to
do
to
get
there
to
take
advantage
of
micro
services,
so
that
was
awesome.
Thank
you.
A
A
You
feel
like
you
need
to
do
that
you're
going
to
get
some
advantage
from
it,
but
when
you
at
that
point,
when
you
do
that,
you
split
into
services
like
Josh
was
saying
in
Barry
I'm
saying
you
have
the
ability
to
increase
like
increase
your
capabilities,
your
process
capabilities,
based
on
the
more
you
like
what
aspects
of
your
system
that
needs
it.
So
you
have
something
that
it's
very
low
that
requires
very
low
low
processing.
A
So
you
run
that
service
with
certain
level
of
capabilities
and
something
that,
like
your
orders
process
or
your
orders
micro
service,
then
you
did.
You
increase
the
processing
power
for
that,
much
more
so
than
some
awesome
other
part
and
the
when
it
comes
to
running
these
in
the
cognitive
worlds.
I
think-
and
this
is
more
an
infrastructure
aspect,
but
my
understanding
is
that
you
can
automate.
All
of
that.
You
can
determine
okay,
I
have
analyzed
my
requirements
based
on
history
and
what
I
need
is
acts
so
I'm
going
to
say,
tell
the
cognitive
infrastructure.
A
This
is
what
I
need
in
the
in
the
animation
will
take
care
of
bringing
the
system
up
to
that.
If
anything
happens,
so
we're
always
always
going
to
be
healing
and
your
system.
You
are
up
in
an
automated
way,
and
this
is
something
that
I
think
gets
talked
about
enough
like
we
say
we
talk
about
how
things
are
split
up
this
way
and
then
run
this
way,
but
in
an
automated
mode
that
this
makes
all
the
difference.
Yeah.
B
C
Think
about
this,
whenever
you
have
five
micro
services
delivering
your
applications,
functionality
and
you
need
to
upgrade
the
let's
say
the
upgrade
the
front
end
code
for
the
HTML.
Whatever
generates
the
HTML,
you
can
actually
replace
that
piece
or
replace
that
piece
and
not
bring
your
whole
application
down
and
even
better.
Yet
you
can
replace
that
piece,
one
at
a
time
or
two
at
a
time
still
have
a
majority
of
your
applications
still
running,
and
maybe
your
users
won't
even
know
at
all.
We
model
it.
C
C
App
is
actually
smarter
in
the
long
run,
because
what
it
gives
you
is
the
flexibility
to
mix
and
match,
and
you
could
actually
scale
the
front-end
at
a
different
level
than
you
did
the
backend
and
that's
actually
super
important
in
rarest
land
and
actually
in
Python
land
and
indictment
land.
If
you're,
if
you're
writing
violence,
when
there
you
have
to
scale
at
the
at
the
level
of
your
monolith,
and
if
you
can
scale,
then
then
you're
having
wasted
resources,
so
smaller
microservices,
smaller
cloud
native
apps,
makes
the
Brennan
containers
actually
we'll
use
less
resources.
D
B
A
So
there
are
gonna
little
because
I
glad
you
brought
that
up.
I
always
were
going
to
bring
that
up
because
I
hear
Brian
using
micro
services
in
cloud
native
apps
interchangeably,
and
it
makes
it
really
hard
for
me
to
follow
okay.
So
what
is
not
a
call
native
application
or
what
is
not
a
cloud
native
service?
What
is
not
a
call
native
monolith,
for
example,
so
to
start
this
thread
with
the
question
that
Josh
just
asked
with,
which
became
also
my
question:
if
I
have
a
monolith
app
running
on
the
cloud
provider.
A
C
Wow,
okay:
well,
let's
see,
let's
unpack
this
I've
been
using
my
Christmas
and
cloud
native
interchangeably,
probably
not
to
the
best
effect,
but
let
me
clear
up
something
here
about
native
versus
micro
services.
Cloud
native
is
a
big
term
and
it
goes
further
than
an
application
itself.
It's
not
only
the
application,
it's
also
the
the
environment
the
application
can
run
in.
It
is
the
process
that
we
use
to
get
the
application
to
to
production.
So
monoliths
can
be
cloud
native
at
us.
We
can
run
them
through
CIS
CD.
They
can
run
in
containers.
C
They
can
take
advantage
of
their
environments.
We
can
scale
them
independently,
but
when
we
use
micro
services
instead
it
becomes
this
becomes
easier
because
our
surface
area
is
smaller.
So
what
I
want
to
do
is
not
use
that,
like
this
I
will
not
cloud
native
applications
is
an
umbrella
term,
but
I
will
actually
I
won't
ever
say
cloud
native
application,
I
always
say
of
micro
service
and
the
reason
why
I
will
say
the
micro
Service
is
because
it's
much
more
I
heard
description
of
that
process
that
it's
running
cloud
native
applications.
D
People
are
a
little
bit
confused
about
it
because
sometimes
they're
actually
asking
us
how
do
I
break
this
legacy
app
in
smaller
micro
services
right,
but
sometimes
they
are
actually
asking
like.
You
know
how
do
I
make
it
more
cloud
native
and
usually
are
our
guidance
or
the
things
that
we're
working
with
them
on
is
exactly
that
right.
D
D
C
That's
a
that's
actually
a
good
way
of
putting
it
a
cloud
native
application
isn't
a
thing:
it's
a
set
of
principles
that
you
can
use
to
guide
yourself
to
running
apps
in
cloud
environments
and
and
it's
interesting
when
I
say
cloud
environments,
I'm
not
even
really
talking
about
kubernetes
or
any
type
of
scheduler
I'm,
just
talking
about
we're
running
apps
on
other
people's
computers
and
the
cloud.
This
is
what
we
should
think
about.
C
What
what
should
we
think
about,
and-
and
it
goes
to
those
principles
where
we
you
see-
ICD
storage,
maybe
most
likely
will
be
ephemeral.
Actually,
you
know
what
that
whole
process
that
whole
virtual
machine
that
we're
running
on
that's
ephemeral
to
everything
will
go
away.
So
what
I
mean
of
applications
is
basically
a
theory
that
allows
us
to
be
strategic
about
running
applications
on
other
people's
computers
and
storage
and
networking
and
compute
may
go
away.
So
we
do
this
in
this
way.
B
C
B
D
Guess
for
for
greenfield
projects
where
we're
starting
from
scratch
and
we're
kind
of
building
this
thing
it's
a
really
pleasant
experience,
because
a
lot
of
things
are
sort
of
done
for
us.
We
just
need
to
know
how
to
interact
with
the
API
or
the
contract
to
get
the
things
we
need.
So
that's
that's
kind
of
my
blanket
statement.
I'm
not
trying
to
say
it's
easy
I'm,
just
saying
like
it's
become
quite
convenient
in
a
lot
of
respects.
D
Is
it's
been
a
bit
hard
to
convert
older
applications
into
the
cloud
native
space
right,
because
I
think
a
point
car
Lisa
had
started
with
around
the
idea
of
all
the
code
being
in
one
place.
You
know
it's
a
massive
undertaking
to
understand
how
some
of
these
older
applications
work
again,
not
saying
that
all
older
applications
are
only
honest,
but
my
experience
has
been
there.
They
generally
are
there
bigger
codebase,
it's
hard
to
understand
how
they
work
and
where
to
modify
things
without
breaking
other
things
right.
D
D
C
A
C
C
Other
applications
that
I
won't
be
cloud
native
are
applications
that
require
a
certain
level
of
machine
or
server
access.
We've
been
able
to
abstract
GPUs,
but
if
you're
working
on
the
I/o
level,
but
you're
actually
looking
at
I/o
or
if
you're,
looking
at
hardware
interrupts
or
you're.
Looking
anything
like
that,
that
application
will
never
be
cloud
native
because
there's
no
way
that
we
can
in
a
shared
environment
which,
most
likely
your
application
will
be
running
in
in
the
cloud.
C
There's
no
way
that,
first
of
all
that
that
this,
the
hypervisor
that
is
actually
running
your
virtual
machine,
wants
to
give
you
that
process
or
give
you
that
access
or
that
it's
not
being
shared
with.
You
know,
from
1
to
200
other
processes
on
that
server,
so
applications
that
what
low-level
access
or
have
real-time,
you
don't
want
to
run
those
in
the
cloud.
They
cannot
be
clouded.
That
still
means
a
lot
of
applications
can
be
so.
A
I
keep
thinking
of
if
I
owned
a
tack
stack
and
I
every
once
in
a
while,
stop
and
evaluate
if
I
am
squeezing
as
most
tack
as
I
cannot
system,
meaning
am
I
using
the
best
technology
out
there
to
the
extent
that
fits
my
needs.
If
I
am
that
kind
of
person,
yeah
and
I,
don't
really
know
I
like
I,
don't
know
it's
like.
A
Why
would
I
say
I'm
a
decision
maker
and
and
even
if
I
was
a
tact
person
like
a
hands-on
tech
person,
I
still
would
not
have
unless
I'm
one
of
the
architects,
but
sometimes
even
architects,
don't
have
a
entire
vision.
I
mean
they
have
to
talk
to
other
architects.
I
have
a
greater
vision
of
a
whole
system
because
systems
that
can
be
so
vague
but
at
any
rate,
if
I'm,
an
architect
or
oh
I
own,
that
tech
stack
one
way
or
another
and
I
want.
A
My
question
is:
is
my
system,
a
cloud
native
system
is
my
app
a
cognate
of
earth
I'm,
not
even
sure
that
we
clarified
enough
for
people
to
answer
that
I
mean
it's
so
complicated,
maybe
with
it.
Hopefully
we
helped
a
little
bit,
but
so
basically
this
will
be
my
questions
like
how
do
I
know
and
if,
if
I'm
there
or
not,
because
my
next
step
would
be
well,
if
I'm
not
there,
then
what
am
I
missing.
A
A
We
talked
about
this
a
little
bit
on
the
on
episode,
1,
which
we
talked
about
coordinated,
like
what
is
called
native
in
general
and
now
we're
talking
about
apps,
and
so
you
know
there
should
be
like
a
checklist
of
things
that
called
native
like
should
at
least
have
this.
This
set
of
things
like
the
12
factor
app.
What
do
you
need
to
have
to
do
have
to
be
considered
12
factor
app?
A
We
should
have
a
checklist
to
affect
our
app
I,
think
having
that
checklist
is
part
of
being
a
micro
service
in
the
cloud
native
app,
but
I
think
that
it
needs
to
be
more
and
I
just
wish.
We
would
have
that
not
that
we
need
to
come
up.
We
would
come
up
with
a
list
now,
but
something
to
think
about
someone
should
do
it.
A
D
C
There
is
a
checklist
does
exist,
I
know
that
redhead
has
one
I
know
that
IBM
has
one
I
would
guess.
Vmware
has
one
on
one
of
our
web
pages.
The
problem
is
they're
all
different,
so
what
I
do-
and
this
is
me
trying
to
be
fair
here-
the
new
stack
basically
they're
they're
a
cloud.
They
talk
about
things
that
are
happening
in
the
cloud
and
in
tech.
If
you
search
for
the
new
stack
and
cloud
native
application,
there
is
a
10.
C
There
is
a
10
bullets
list,
that's
what
I
send
to
people
now
and
the
reason
I
send
that
one
rather
than
any
and
any
vendor
is
because
a
vendor
is
trying
to
sell
you
something
they're
trying
to
sell
you
their
vision
of
cloud
native
where
they
excel,
and
they
will
give
you
products
that
help
you
with
that
part
like
CI
CD.
Oh,
we
have
a
product
for
that.
So
I
like
the
new
stack
list
and
and
actually
I
googled
it.
C
While
you
were
talking
Carly
SIA,
because
I
wanted
to
bring
it
up,
so
I'll
just
go
through
the
titles
of
this
list
and
we'll
make
sure
that
we
make
this
link
available.
So
it
says
10
key
attributes
of
cloud
native
applications
packages,
lightweight
containers
developed
with
Best
of
Breed
languages
and
frameworks.
C
So
a
cloud
native
app
from
my
point
of
view,
tries
to
target
most
of
these
items
and
has
an
opinion
on
both
of
these
items.
So
a
cloud
native
app
isn't
just
one
thing:
it's
a
mindset
that
I
am
running
like
I
said
before
I
am
running
my
software
on
other
people's
computers.
How
can
I
best
do
this
I
added.
A
The
link
to
that
to
our
show
notes
now,
when
I
look
at
this
at
this
list,
I
don't
see
observability
I
literally.
That
word
is
not
there.
Does
it
fall
under
one
of
those
points,
because
observability
is
another
newest
term.
That
seems
to
be
a
part
and
parcel
of
cognitive
correct
me
here:
people
I
am.
C
Actually,
the
eighth
item
managed
through
agile
devops.
Pratices
processes
is
actually
they
don't
say,
talk
about
monitoring
observability,
but
for
an
application
for
a
person
who
is
not
developing
in
applications,
whether
you
have
a
DevOps
team
or
you
have
an
SRE
practice,
you're
going
to
have
to
be
able
to
communicate
the
status
of
the
application,
whether
it
be
through
metrics,
logs
or
metrics
logs
or
whatever
the
other
one
is
I'm
thinking
I'm
at
races,
so
that
is
actually
I.
Think
it's
baked
in
it's
just
not
called
out
so
to
get
the
proper
DevOps.
C
A
This
is
how
obscure
these
things
can
be.
I
just
want
to
point
this
out.
It's
so
frustrating.
So
literally
we
have
item
AIDS,
which
Brian
is
has
been
a
sysadmin
developer,
so
he's
super
knowledgeable.
He
can
look
at
that
in
understanding.
You
know
what
he
means,
but
I
look
at
that,
and
there
is
no
the
worst
log
metrics
observability
know
these
words
out
there
and
yet
Brian
knew
that.
That's
what
he
means.
That's
what
he
meant
in
the
end.
I
don't
disagree
with
him.
D
A
D
C
And
actually,
this
is
what
we
should
be
doing
as
experts
as
thought
leaders
as
as
industry,
movers
and
shakers.
Our
job
is
to
make
this
easier
for
people
coming
behind
us
that
at
one
time
it
was
hard.
So
you
can
start
an
application
or
in
stop
your
operating
system.
Remember
when
we
had
to
load
again
one
you
know
we
had
to
do
that
back
in
the
day
on
our
basics,
on
our
Commodore
64's
or
our
Apple
or
Apple
twos.
C
Now,
if
you
turn
your
computer
on
and
it
comes
on
instantly,
you
click
on
application
and
it
works.
We
need
to
actually
bring
this
whole
cloud
movement
to
that
point
where
things
like,
if
you,
if
you,
if
you
include
these
libraries
and
you
could,
with
these
api's,
you
get
automatic,
observability
and
I'm
saying
that
with
air
quotes,
but
you
get
the
ability
to
have
to
think
monitored
in
some
fashion.
C
If
you
use
this
practice-
and
you
have
this
stack,
CI
CD
should
be
super
simple
for
you
and
we're
just
not
quite
there
yet
and
that's
why
the
industry
is
is
definitely
rotating
around
this
and
that's.
Why
there's
been
a
lot
of
buzz
around
cloud
native
and
and
kubernetes
is
because
people
are
looking
at
this
to
actually
solve
a
lot
of
these
problems
that
we've
had
because
they
just
haven't
been
solvable
because
everybody
stacks
are
too
different
and
and
I'll
get
I
don't
end
with
this
one,
though
the
reason
Linux
was
I.
C
Think
ultimately
successful
is
because
it
allowed
us
to
do
things
and
all
these
UNIX
things
that
we
grip.
We
liked
and
it
worked
on
all
sorts
of
computers,
and
it
got
that
mindset
behind
it
behind
companies.
Kubernetes
could
also
do
this.
It
allows
us
to
think
about
our
data
centers
as
potentially
one
big
computer
or
fewer
computers.
It
allows
us
to
make
sure
things
are
running,
and
once
we
have
this
now
we
can
develop
new
tools
that
will
help
us
with
our
observability,
with
our
getting
software
into
production
and
upgraded
and
where
we
need
it.
C
A
B
B
C
I,
have
one
thought
is
that
this
is
all
this
things
that
we
are
talking
about.
It
sounds
kind
of
daunting,
but
it's
better
that
we
can
have
these
conversations
to
talk
about
things
that
don't
work
further
than
not
knowing
what
to
talk
about
in
general.
So
this
is
a
journey
for
us
and
I
hope
you
come
for
more
of
our
journey.
A
By
being
here
and
asking
questions
and
then
questions,
and
hopefully
people
will
also
be
very
interactive
with
us,
and
that
and
asked
us
to
talk
about
things.
They
want
to
know
that
we
will,
you
know,
try
to
connect
the
two
little
by
little
I
mean
I'm,
not
saying
it's
her
rocket
scientist
and
nobody
can
understand
it.
I'm
just
saying
for
some
people
who
don't
have
like
multi
background
experience,
they
will,
they
might
have
big
gaps
so
yeah.
B
And
that
is
for
sure
this
was
a
very
useful
episode
for
me.
I'm
glad
to
know
that
everybody
else
is
just
as
confused
to
what
cloud
native
applications
actually
mean.
So
that
was
awesome.
It
was
a
very
informative
episode
for
me
and
I
had
a
lot
of
fun
doing
it.
So,
thank
you
all
for
having
me
thank
you
for
joining
us
on
this
week
of
the
cube
woods,
podcast
and
I
just
want
to
wish
our
friend
Brian
a
very
happy
birthday,
bye,
y'all,
happy.