►
From YouTube: Welcome to CloudLand! An Illustrated Intro to the Cloud Native Landscape - Kaslin Fields, Google
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Welcome to CloudLand! An Illustrated Intro to the Cloud Native Landscape - Kaslin Fields, Google
Like a kid in a theme park, the number of shiny exciting new technologies teams encounter as they move into and re-architect for the cloud can be overwhelming. Thus we welcome you, to CloudLand! Adopting the cloud comes with a lot of questions to explore and tools to learn. Why should I care about "Cloud Native?" What technologies count as “Cloud Native?" What Cloud Native technologies does my team/business need and why? Through colorful illustrations and a memorable theme park analogy, you will learn: How to identify "Cloud Native" technology and why it matters, The key characteristics of categories of technologies from the CNCF Landscape, And get an introduction to many of the individual CNCF projects that fill in the Cloud Native Landscape.
https://sched.co/Zety
A
Hello
and
welcome
to
kubecon
cloud
nativecon
eu
virtual.
This
is
welcome
to
cloudland
an
illustrated
intro
to
the
cloud
native
landscape,
I'm
kasilyn
fields
and
I'm
a
developer
advocate
at
google,
I'm
also
a
cloud
native
computing
foundation
ambassador
and
a
member
of
the
kubernetes
contributor
special
interest
group
related
to
contributor
experience.
A
A
A
common
question
that
I
get
is
tell
me
about
cloud
native,
and
this
can
be
a
really
challenging
thing
to
answer,
because
the
answer
really
depends
on
where
you're
at
in
your
cloud-native
journey
for
a
lot
of
people
they're
just
at
the
very
beginning,
and
they
want
to
understand
what
is
cloud-native.
Where
did
it
come
from?
Why
do
I
need
to
care
about
it?
And
what
do
I
need
to
do
if
I
want
to
get
involved
with
it?
A
A
lot
of
people
are
just
getting
started
with
kubernetes,
and
you
know
a
little
bit
about
cloud
native.
You
know
a
little
bit
about
a
few
technologies
related
to
cloud
native,
but
maybe
you
want
to
know
what
the
next
step
is,
and
then
there
are
those
who
are
really
deep
into
cloud
native
and
have
been
using
a
variety
of
cloud
native
technologies
for
a
long
time
and
might
want
to
go
deeper
on
some
specific
technologies
or
really
advanced
topics.
A
So
the
answer
can
vary
a
lot
and
I
came
up
with
this
presentation
as
a
way
to
kind
of
bring
everyone
together
and
it's
very
introductory
level.
So
if
you're
really
just
at
the
beginning-
and
you
want
to
understand
what
is
cloud
native-
where
did
it
come
from
and
what
technologies
count
as
cloud
native
we're
going
to
cover
all
of
that
here-
and
this
is
a
great
place
for
you.
A
And
now,
let's
start
at
the
beginning
and
when
we're
talking
about
cloud
native
starting
at
the
beginning
means
talking
about
data
centers
and
for
anyone
who
might
not
be
familiar
with
them.
A
data
center
is
basically
a
big
box
in
the
middle
of
nowhere,
that's
full
of
computers,
which
generally
generate
a
lot
of
heat,
thus
the
ac
units,
so
no
matter
what
your
business
may
be.
Today,
businesses
of
all
types
need
computers
in
this
day
and
age,
whether
it's
managing
logistics
or
payroll.
A
The
thing
about
these
boxes,
in
the
middle
of
nowhere
full
of
computers
is
that
they
take
up
a
lot
of
money.
They
are
a
very
big
budget
item
in
terms
of
real
estate
expertise.
You've
got
to
have
experts
who
know
how
to
manage
these
computers,
the
computers
themselves,
the
electricity
costs
and
then
the
management
of
the
software
and
software
licensing
costs,
and
all
that
there
are
a
lot
of
different
types
of
costs
associated
with
this.
It's
all
very
important
to
the
business,
but
looking
at
all
of
that
on,
your
budget
sometimes
makes
toilet
paper.
A
A
A
A
And
an
important
thing
to
remember
with
this
is
that
the
majority
of
workloads
today
are
still
being
run
in
data.
Centers
majority
of
workloads
have
not
been
run
into
cloud
style
paradigms,
so
this
is
still
a
very
relevant
situation.
That's
happening
every
day,
as
companies
are
looking
at
their
data
centers
and
deciding.
A
Maybe
I
want
to
switch
to
a
cloud
model
so
that
that's
something
that
a
lot
of
people
who
are
really
involved
in
cloud
native,
don't
think
about
as
much
aws
came
around
like
10
years
ago.
They're
like
oh,
that's
something
that
happened
so
long
ago,
but
no.
This
is
very
much
something
that
people
are
still
considering
and
struggling
with
today.
A
So
if
a
company
decides
that
they
want
to
start
getting
involved
with
the
cloud,
what
does
that
look
like
one
model
of
doing
this
is
lift
and
shift,
and
lift
and
shift
is
basically
take
all
that
stuff.
That's
running
in
your
data
center,
lift
it
up
and
shift
it
into
the
cloud
as
as
is
or
as
close
to
as
is
as
possible.
A
This
is
a
great
option
for
a
lot
of
businesses,
because
you
can
take
all
that
stuff,
that's
running
in
your
data
center
and
just
run
it
in
the
cloud.
It's
all
very
important.
You
still
need
it
and
that
changes
the
way
that
your
budget
looks
immediately,
but
the
main
reason
that
a
lot
of
businesses
adopt
the
cloud
isn't
actually
this
budget
model
at
all.
It's
that
they
want
to
go
through
a
process
of
app
modernization.
A
And
why
do
they
think
that
that's
where
the
whole
concept
of
cloud
native
comes
in
the
cloud
is
a
unique
place
when
you
compare
to
a
data
center,
let's
think
about
a
data
center
for
a
minute
say
that
you
want
to
spin
up
a
new
machine
learning
team
they're
going
to
need
special
hardware
to
do
what
they
need
to
do.
They
probably
have
pretty
considerable
requirements
for
the
computing
power
that
they
need.
So
you
might
have
to
order
new
machines
for
your
data
center
that
you
didn't
have
before.
A
That
means
figuring
out
what
to
order,
placing
the
physical
order
waiting
for
that
to
come
in
and
then
having
experts
put
all
that
stuff
in
your
data
center
rack
it
up,
get
all
the
cabling
right
and
then
maybe
your
team
can
start
using
it.
So
that's
a
lot
of
lead
time
from
idea
to
development,
whereas
in
the
cloud
you
have
someone
else
running
these
big
data
centers
and
you
can
just
say
hey,
I
want
this
specialized
type
of
equipment
right
now
and
they'll
just
give
it
to
you.
A
A
An
important
thing
I
want
to
mention
here
is
that
all
of
these
cloud
native
technologies
that
I'm
going
to
talk
about
today,
you
can
run
at
home
in
your
own
data
center
or
on
your
own
laptop
or
whatever.
The
case
may
be
it's
just
a
little
bit
like
microwave
popcorn,
in
that
a
lot
of
these
technologies
were
designed
specifically
with
the
capabilities
of
the
cloud
in
mind.
A
So
you
might
find
some
weird
things
about
how
they
work
when
it
comes
to
on-prem
some
things
that
might
not
be
quite
as
streamlined
as
it
would
be
in
the
cloud,
but
you
absolutely
can
still
do
them
in
your
data
center
so
doing
cloud
native
type
stuff.
In-House
on-prem
is
a
little
bit
like
doing
microwave
popcorn.
Sometimes
in
that
you
don't
have
the
specialized
equipment
that
maybe
that
type
of
technology
was
expecting,
but
it's
still
good.
Sometimes
that's
still
exactly
what
you
need.
A
A
You
want
to
be
able
to
run
these
types
of
technologies
on
whichever
cloud
provider
you
may
choose
so
having
a
an
independent
nonprofit
organization
that
helps
to
support
these
projects
is
really
important,
so
they
helped
us
support
and
promote
many
cloud
native
open
source
projects,
and
they
also
maintain
a
cloud-native
landscape
that
helps
companies
understand
what
types
of
cloud-native
software
are
out
there,
and
here
it
is.
This
is
the
cloud
native
landscape,
so
you
know
all
about
all
of
the
different
types
of
cloud
native
technology.
A
Now
right,
dan
cohen,
the
former
head
of
the
cncf,
once
showed
this
at
a
cube
con
and
referred
to
it
as
an
eye
chart
and
apologize
for
the
eye
strain
there's
a
lot
on
here.
So
it
can
be
kind
of
hard
to
figure
out
where
to
begin,
when
you
start
trying
to
understand
what
cloud
native
technologies
are
out
there
and
how
to
use
them.
A
You'll
know
where
to
look
on
this
cloud
native
landscape
for
the
tools
that
you
need
and
a
really
great
quote
here
from
kelsey
hightower
that
I
wanted
to
throw
in.
So
you
want
to
roll
your
own
application
platform.
All
you
need
is
this
big
list
of
things.
There
are
a
lot
of
different
types
of
cloud
native
technologies,
so
creating
these
cloud
native
application
platforms
is
going
to
end
up
taking
a
lot
of
pieces.
We're
not
going
to
pretend
this
is
not
complex
and
it's
not
going
to
involve
a
lot
of
learning.
A
For
me,
I
loved
the
food
and
I
originally
created
this
for
a
talk
in
tokyo,
so
I
used
some
tokyo,
specific
festival,
part
festival,
foods
and
amusement
park
foods.
So
don't
worry
if
you're
not
familiar,
I
will
explain
them,
but
we're
going
to
start
off
with
amusement
park.
Food
analogies
and
we're
going
to
start
with
popcorn
like
we
were
talking
about
earlier.
A
Really,
the
core
of
a
lot
of
cloud
native
technology
is
containers
which
you've
probably
heard
a
lot
about.
Hopefully,
you've
experimented
with
them
a
little
bit.
If
not
a
general
overview
of
the
benefits
of
containers
actually
sounds
a
lot
like
popcorn
kernels
they're,
a
very
efficient
way
to
package
up
the
applications
that
you
need
and
their
dependencies.
A
A
Another
really
exciting
thing
about
containers
is
that
they
are
very
portable
generally
we're
talking
about
linux
containers
here.
If
you
want
to
talk
about
windows,
containers
love
to
talk
about
it,
I
just
wrote
a
blog
post
on
it
recently.
So
let
me
know
if
you
want
that
in
the
questions-
and
I
will
totally
give
you
a
link,
but
talking
about
linux
containers.
A
A
A
You
can
also
store
your
container
image
once
and
then
spin
up
as
many
containers
you
want
from
that
image
on
mass
they're,
repeatable
you're,
going
to
get
the
same
thing
every
time
and
they're
super
quick
to
start
up.
So
one
thing
that
people
like
to
talk
about
when
they're,
comparing
containers
and
virtual
machines
is
that
virtual
machines
usually
take
a
few
minutes
to
spin
up
they're.
A
A
So
I
actually
want
to
do
a
quick
little
demo
of
containers.
In
case
you
aren't
familiar
and
I'm
going
to
refer
back
to
this
example
microservice
a
few
times
during
this-
and
so
this,
like
I
said,
is
an
example
microservice
and,
let's
see
which
parts
of
this
are
containers
all
of
it.
All
of
it
is
containers,
so
you'll
see
that
with
a
lot
of
cloud
native
workloads,
you
end
up
splitting
all
of
the
pieces
of
your
application
into
their
own
micro
services
that
are
run
in
containers,
and
I
want
to
show
you.
A
This
is
what
this
example.
Microservice
actually
looks
like
it's
an
example.
That's
on
github
from
google
cloud.
It's
this
online
boutique!
You
can
click
on
an
item.
Add
it
to
your
cart,
see
it
in
your
cart.
You
can
place
an
order
empty.
Your
cart.
Keep
browsing
all
the
stuff
that
you'd
expect
from
an
online
boutique
and.
A
I
want
to
give
you
a
quick
demo
of
what
this
looks
like
so
this.
If
I
do
git
remote
dash
v,
you'll
see
that
this
is
google
cloud
platform
microservicesdemo.get.
So
that's
the
architecture.
I
was
just
showing
you
on
the
slide
and
we're
inside
of
that.
If
we
go
into
the
source
repo,
let's
go
into
front
end,
so
I
was
just
talking
about
containers
and
that
they're
a
really
easy
way
to
package
up
your
applications
right.
So
let's
look
at
this
docker
file,
so
this
is
an
example
of
a
container
definition.
A
It's
got
this
from
statement
right
here
that
basically
defines
the
base
layer
of
your
container,
so
this
is
golang.
1.12
alpine
alpine
is
known
for
being
very
lightweight
as
a
container
base
and
it's
got
golang
in
it.
So
you
can
run
some
kind
of
building
application
in
this,
and
then
it's
got
all
these
instructions
for
how
you're
going
to
run
your
actual
application
inside
of
this
container.
A
A
A
Yeah
it
just
re
re-tagged
the
existing
image,
but
you
get
the
idea,
so
we've
created
a
container
image
here
and
then,
if
we
wanted
to
actually
run
a
container,
we
would
do
docker
run
grab.
Let's
say
a
unique
part
of
the
image
id.
We
run
that
so
you
can
see
it
outputted
all
this
stuff.
That
means
that
it
tried
to
run
it.
It
actually
had
a
panic.
A
So
if
we
look
at
docker
ps,
that
shows
you
all
running
containers
we
won't
see
any.
But
if
you
do
docker
ps,
a
you'll
see
that
there's
this
container
here
that
exited
16
seconds
ago,
which
is
the
container
that
we
actually
run
great
point
about
microservices-
is
that
a
lot
of
them
just
spin
up,
do
their
thing
and
spin
back
down.
So
having
a
container
like
this,
that
would
you
would
hit
the
run
command
and
then
it
would
just
kind
of
die
is
actually
a
an
existing
use
case.
A
But
in
this
case
it
did
that
because
it's
supposed
to
be
part
of
this
whole
microservice
architecture
and
I
tried
to
just
spin
up
one
single
container.
But
hopefully
this
gives
you
an
idea
of
container
image
versus
running
a
container
itself,
so
let's
go
back
to
our
slides
here.
So
if
you
want
to
try
that
out,
it's
on
github,
so
I
just
mentioned
container
images.
If
you
have
all
these
container
images
like
your
popcorn
kernels,
you
need
some
way
to
store
those.
That's
where
container
registries
come
in.
A
There
are
a
whole
lot
of
different
ways
to
do
that,
you
can
use
something
online
like
docker
hub.
You
can
pay
someone
to
run
a
registry
for
you.
Most
cloud
providers
will
offer
some
kind
of
managed
registry
for
you.
But
if
you
want
to
do
this
on-prem
or
you
just
want
to
own
it,
you
can
also
run
it
yourself
using
something
open
source
like
harbor,
which
is
under
the
cncf.
A
So
this
is
for
it's
basically
a
repository
for
all
of
your
container
images,
sort
of
like
a
bag
of
popcorn,
a
bag
of
popcorn
kernels,
specifically
one
of
the
most
important
things
that
I
talk
about,
I
think,
is
container
run
times.
This
is
the
thing
that
when
I
hear
about
it,
I'm
like
yes,
people
need
to
talk
about
this.
A
So
a
couple
really
interesting
ones
here
that
I
like
to
to
hear
more
about
our
g-visor
and
kata.
So
kata
actually
uses
a
lightweight
vm
to
wrap
their
containers.
So
it's
still
really
fast,
it's
very
minimal
for
a
vm,
but
it's
still
a
vm.
So
that
changes
the
security
model
of
your
container
rather
than
sharing
the
kernel
g
visor,
actually
uses
an
application
kernel
that
it
spins
up
for
each
individual
container.
So
it's
not
quite
a
vm,
but
there's
kind
of
the
spectrum
between
vm
and
container
when
it
comes
to
speed
security
and
weight.
A
So
if
you're
interested
in
all
of
those
trade-offs,
definitely
look
into
your
container
runtimes
you'll
also
notice
that
docker,
which
is
the
type
of
container
I
just
ran,
isn't
actually
in
here,
but
docker
uses
container
d,
which
is
a
linux,
sorry
cloud
native
computing
foundation,
project
and
also
run
c.
Another
interesting
one
here
before
I
move
on
is
lxd,
which
is
kind
of
the
classic
container
project.
A
So
if
you're
interested
in
learning
about
the
history
of
containers
definitely
check
that
one
out,
so
we
were
just
talking
about
all
of
these
containers,
but
we're
at
cubecon
cloud
native
cotton
right,
we're
all
about
kubernetes,
which
is
where
the
cube
comes
from.
So
what
is
kubernetes
kubernetes
is
container
orchestration,
and
this
analogy
is
kind
of
like
it's
really
more
like
the
logistics
of
running
your
own
popcorn
business,
your
own
popcorn
stall
at
an
amusement
park.
So
let's
look
at
that
microservice
application
that
we
were
just
talking
about
again.
A
A
You
can
even
get
up
into
the
millions
of
containers
every
day
that
you
have
to
run.
How
do
you
manage
all
of
that?
You
need
something
to
orchestrate
all
of
those
containers.
So
kubernetes
is
all
about
operating
containers
at
scale.
It
has
things
that
allow
you
to
set
up
how
your
containers
can
communicate
with
each
other.
It
has
a
few
capabilities
around
storage,
which
we
will
talk
more
about
later.
It's
a
pretty
complicated
topic,
but
it
has
all
of
these
concepts
and
kind
of
the
main
key
component
of
container
orchestration.
A
Is
that
there's
still
servers,
there's
still
actual
nodes,
compute
nodes
that
you're
using
to
run
all
these
containers
on,
and
you
can
basically
say
kubernetes.
I
need
this.
Many
containers
go
make
it
happen
on
the
computers
that
we've,
given
you
and
kubernetes
will
schedule
them
on
the
nodes.
So
you
don't
actually
have
to
worry
about
where
your
computers
are
located,
they
can
be
in
the
cloud
they
can
be
in
various
regions
in
the
cloud
and
kubernetes
will
just
make
sure
that
things
are
scheduled
onto
nodes
appropriately.
A
You
can
use
labels
to
make
sure
that
things
are
are
scheduled
in
the
right
areas,
and
things
like
that,
so
kubernetes
provides
a
lot
of
great
container
orchestration
tooling,
but
if
you're
a
developer,
you
probably
don't
want
to
care
about
all
of
that,
in
fact,
it
may
as
well
be
serverless
from
your
perspective
and
so
there's
this
concept
of
serverless,
and
this
is
a
very
cloud
native
type
of
concept
where
you're
really
just
focusing
on
the
code.
Technically,
it's
kubernetes
and
containers
running
underneath,
but
we
just
say:
hey
give
us
the
code.
A
You
need
to
run
we'll
slap
it
into
a
container
and
throw
it
on
some
hardware
for
you
and
run
it.
So
you
just
focus
on
code
and
that's
kind
of
what
serverless
and
functions
as
a
service
is
all
about.
Here's
a
use
case
to
help
you
understand
it
better,
so
say
that
you
have
a
photo
booth,
app
on
your
phone.
You
take
a
picture
of
you
and
your
friends.
A
It
sends
that
picture
to
storage
in
the
cloud
and
then
that
triggers
an
event
which
triggers
a
function
to
spin
up
some
code
has
to
do
the
processing
on
that
image
so
put
that
in
a
function,
it'll
spin
up
and
do
the
processing
and
then
it'll
spit
out
an
image
and
then
that
image
processing
function
that
did
that
just
goes
away.
So
this
is
a
part
where
running
in
the
cloud
has
benefits.
A
If
you
run
this
on,
like
a
cloud
providers
functions
as
a
service
offering,
you
can
say,
hey
run
this
processing
code
every
time
an
image
comes
in
it'll,
just
spin
that
up
and
run
it
and
then
spin
it
back
down.
So
you
don't
have
to
be
paying
for
it.
However,
if
you're
running
this
on-prem,
that
can
be
a
great
user
experience
for
your
developers,
but
you're
still
technically
paying
for
the
actual
hardware
right,
because
it's
in
your
data
center
and
you're
paying
for
it
all
the
time.
A
A
It's
all
about
managing
your
ops,
like
you
manage
your
dev,
so
this
food
is
okonomiyaki,
which
literally
means
your
preferences.
Grilled,
oh,
and
by
the
way
the
serverless
analogy
was
caramel
corn.
So
it's
popcorn
because
it's
kubernetes
and
containers
under
the
hood,
but
somebody
already
did
all
that
for
you.
It's
pre-packaged
ready
to
go
so
serverless,
so
for
infrastructure
as
code
we've
got
okonomiyaki,
which
literally
is
your
preferences
grilled,
so
things
that
you,
like
grilled
in
the
case
of
infrastructure,
is
code.
A
That
means
the
vms
that
you
want,
how
you
want
your
network
setup
to
look
like
the
storage
that
you
might
need
define
all
of
that
in
code
hand
it
off
to
a
infrastructure
as
code
management
tool
like
chef
puppet
terraform,
and
they
will
make
that
infrastructure
happen
for
you.
This
is
also
related
to
git
ups.
A
A
Next
is
service
mesh,
so
service
mesh
is
beyond
the
basics.
It's
kind
of
what
I
think
of
as
day
two
of
kubernetes,
and
my
food
here
is
a
hanami
dango,
which
is
a
specific
type
of
dango
for
flower.
Viewing
and
dango
is
a
pounded,
rice
ball.
It's
a
sweet
thing
and
it's
grilled
and
specifically
hanami
dango
is
three
different
flavors
all
in
one
stick.
A
As
you
start
to
run
things
in
kubernetes,
you'll,
start
to
see,
gaps
and
so
service
mesh
provides
you
a
bunch
of
tools
that
help
to
fill
those
gaps.
So
once
you
get
started
with
kubernetes
at
some
point,
you're
probably
going
to
have
to
start
looking
at
service
meshes.
So
keep
that
in
mind.
These
are
a
bunch
of
different
options.
Linker
d
is
the
cncf1
and
then
there
are
other
open
source
and
pay
options
as
well.
A
A
So
we're
going
to
talk
about
these
three
different
components
of
observability.
The
first
one
is
monitoring
and
monitoring
is
all
about
knowing
what's
happening
when
it
happens.
The
analogy
for
this
is
a
person
running
an
attraction
of
some
sort
and
they're
at
this
control
panel
and
a
problem
light
lights
up,
so
something
has
gone
wrong,
so
you're
knowing
what's
happening
while
it's
happening
and
what
was
the
attraction
this
person
was
in
charge
of
well,
let's
just
say
it
was
important.
A
So
now
we
need
logging,
and
in
this
analogy,
logging
is
the
caretaker
sign
in
so
if
you
look
at
the
caretaker
sign
in
you'll,
see
who
was
the
last
person
in
the
velociraptor
paddock
so
that
maybe
you
can
know
who
left
the
door
open,
so
logging
is
all
about
knowing
what
happened
before.
Fluentd
is
what
cncf
has
there
and
there
are
all
sorts
of
other
tools
for
logging
tracing
is
all
about
following
where
the
trail
leads
so
say
following
the
dinosaur
tracks.
A
So
there
are
all
sorts
of
various
tools
for
looking
into
that,
and
why
is
why
is
tracing
in
observability
so
important
in
these
environments?
So
you
see
that
we've
got
all
these
different
pieces
and
it's
kind
of
a
mess
in
our
microservice.
It's
not
actually
a
mess
of
course,
but
if
you
have
something
that
goes
wrong
say
in
payment
service,
you
need
to
trace
back
and
find
out
where
the
actual
error
happened.
Maybe
the
error
actually
happened
in
front
end.
A
So
tracing
is
all
about
tracing
through
this
mess
of
of
connections,
to
figure
out
where
the
problem
actually
occurred.
It's
very
important
in
these
distributed
systems,
security
and
compliance
I
mentioned
earlier,
like
enforcing
policies,
is
one
challenge
in
these
distributed
systems.
Open
policy
agent
gets
a
lot
of
attention.
Falco
gets
a
lot
of
attention
here
and
it's
kind
of
like
having
fences
and
park
rules
and
the
security
guard.
If
you
want
people
to
do
things
right,
you
need
to
make
it
hard
for
them
to
do
wrong.
A
So
it's
all
about
consuming
data
at
scale-
and
here
are
some
of
the
tooling
tooling's
available
around
that
in
cloud
native
remote
procedure.
Call
again,
we've
got
all
these
connections.
Kubernetes
opened
up
the
pathways
so
that
these
could
connect
with
each
other.
But
how
do
they
actually
connect?
How
do
they
send
commands
to
each
other?
That's
in
this
specific
case,
in
fact,
grpc,
which
is
a
yeah,
the
connections,
the
actual
connections
that
are
happening
between
here.
So
that's
a
remote
procedure
call.
A
So
if
you've
got
distributed
systems,
you've
got
to
worry
about
distributed
communication,
so
remote
procedure
call
is
where
you
go
for
that,
and
this
is
the
last
thing
we're
going
to
talk
about
here,
which
is
cloud
native
storage.
So
if
the
system
is
distributed,
where
is
your
data
located?
What
are
your
tolerances
for
latency?
A
You'll
you'll
have
to
decide
for
yourself
what
trade-offs
you
want
to
make
within
your
system.
It's
a
pretty
difficult
challenge.
I
was
just
listening
to
kelsey
hightower
talk
about
storage,
still
being
one
of
the
the
challenges
that
has
a
ways
to
go
within
cloud
native
and
distributed
systems,
but
if
you're
looking
for
what
solutions
exist
today,
you
can
check
out
this
area
of
the
cloud
native
landscape.
A
So
that's
all
I'm
going
to
cover
for
you
today.
Look
how
much
you've
learned
this
is
the
cloud
native
landscape
and
you've
covered
all
these
different
aspects
of
it.
I
hope
that
you
have
a
great
time
at
kubecon,
cloudnativecon
eu
and
feel
free
to
drop
any
questions
into
the
questions
box.
For
me,
thanks
have
a
great
time.