►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A Flight Over the Cloud Native Landscape - Carson Anderson, Weave
The Cloud Native Computing Landscape is big! And it's just getting bigger all the time. There are already 12 graduated and 21 incubating projects in the foundation! Most of us have heard of a few of these projects. But who really knows what they all do? And more importantly: how they all fit together? This presentation is a speed-run through all 33 graduated and incubating projects, what they are on a surface level, and how they relate to each other. The presentation will be given with zero bullet points and a lot of visual aid. *Projects promoted to incubating status during the conference may not be covered.
https://sched.co/ek9f
A
Hello
and
welcome
to
a
flight
over
the
cloud
native
landscape.
My
name
is
carson
anderson.
I
work
for
weave
not
that
weave,
not
the
one
you're
thinking
but
we'll
get
there
in
a
second.
You
can
find
me
on
twitter,
at
carson,
underscore
ops
and
on
github
at
carsonoid.
I
actually
have
the
distinct
honor
of
having
more
followers
on
github
than
on
twitter,
so
feel
free
to
follow
me
on
one
or
both
of
those
platforms.
A
If
you
want
to
see
what
I'm
doing,
in
fact,
every
presentation
I've
ever
made
all
the
artwork
for
this
presentation
and
my
others
is
always
open
source
on
github,
so
follow
me
there
now
before
I
go
any
further.
I
want
to
say
what
I
mean
when
I
said
not
that
weave
the
weave
that
I
work
for
is
not
the
cloud
native
vendor
you
might
be
thinking
about.
My
wave
is
an
end
user
company
and
if
you're
curious
about
what
we
do,
you
can
find
us
on
gitweave.com.
A
I'm
saying
this
because
I
want
you
to
know
that
I'm
going
to
teach
you
about
a
lot
of
different
projects,
and
I
want
you
know
we
have
no
stake.
I
have
no
personal
professional
stake
in
any
of
these
projects,
so
you're
not
getting
any
sort
of
specific
vendor
pitch
here
now.
What
I
want
to
do
in
this
presentation
is
cover
the
12,
graduated
and
21
incubating
projects
in
the
cncf.
That's
33
projects
total
and
I
have
less
than
35
minutes
to
teach
them
all
to
you.
A
Now,
I'm
not
going
to
obviously,
in
that
amount
of
time,
be
able
to
teach
you
everything
about
a
project
or
cover
all
the
features
and
nuances
of
any
given
project.
But
I
want
you
to
leave
this
presentation
having
a
base
understanding
of
what
these
projects
do
and
how
they
relate
to
each
other
and
know
which
ones
you're
curious
about,
might
want
to
learn
more
about
or
might
want
to
use
yourself.
A
So
you're
going
to
see
these
characters
show
up
quite
a
bit
specifically
going
to
see
fippy
and
when
you
see
fippy,
it's
I'm
going
to
refer
to
a
legacy
application
written
in
an
unspecified
language,
so
it
could
be
any
language
and
when
you
see
goldie,
it's
specifically
a
newer
application
written
in
go
before
we
go
into
the
projects
themselves.
Let's
talk
about
what
it
means
to
be
graduated
in
the
cncf.
A
So
if
I've
got
a
project
and
that
project
wants
to
be
a
graduated
project,
you
have
to
pass
a
few
things.
First,
you
have
to
be
receiving
constant
contribution
from
at
least
two
different
organizations
into
the
project
that
that
means
that
you
know
that
if
you're
going
to
use
a
project,
that's
graduated
you're
not
dependent
on
one
organization
to
maintain
the
project.
A
A
Once
you
do
that,
you
pass
a
super
majority
vote
from
the
cncf
and
you've
become
a
graduated
project,
now
notice
that
never
in
that
did
I
talk
about
something
being
quote:
unquote:
production
ready
graduated
status
in
the
cncf.
You
don't
have
to
be
graduated
to
be
production
ready.
There
are
plenty
of
incubating
and
even
sandbox
projects
that
might
be
production
ready
for
you,
depending
on
what
you're
trying
to
get
so
don't
be
afraid
to
use
projects
that
are
incubating
or
sandbox.
A
Now,
let's
go
ahead
and
dig
into
all
these
projects,
because
I
have
a
lot
to
cover
the
first
one
I
want
to
talk
about
is
container
d.
It's
a
daemon
like
you
might
expect
from
the
d,
meaning
it's
a
process
that
runs
on
your
systems
to
help
you
manage
containers.
So
you
can
use
container
d
directly
in
your
code
to
build
container
images
and
to
manage
containers,
but
most
of
us
won't
use
container
d
directly.
A
Most
of
us
will
use
continuity
as
part
of
something
like
docker
or
another
project,
so
when
most
of
us
build
a
container
image
today,
and
we
do
that
with
docker
we're
doing
it
with
container
d.
So
in
fact,
this
project
is
so
useful
that
it's
actually
built
into
a
lot
of
the
public
cloud
kubernetes
offerings
and
the
k3s
project,
which
is
in
sandbox
state
that
allows
you
to
run
a
full
or
mostly
full-featured,
kubernetes
cluster,
all
in
one
binary,
and
that
does
that
using
container
d.
A
So,
if
you're
curious
about
low
level
container
operations
check
out
container
d
next
is
tough.
Tough
stands
for
the
update
framework
and
it's
all
about
dealing
with
managing
updates.
So
it's
tough
as
a
series
of
standards
and
tools
that
we
can
build
into
our
code
and
use
to
deal
with
updates,
I'm
being
intentionally
vague
here,
because
the
tough
standards
don't
prescribe
to
any
one
specific
kind
of
update
you
might
be,
they
might
be
package
updates
or
image
updates,
but
anything
that
you
might
want
to
get
regular
updates
from
and
verify
the
source
of.
A
A
Notary
takes
all
the
tough
ideas,
but
it
builds
us
some
actual
tools
that
most
of
us
can
use,
rather
than
writing
our
own
code
to
deal
with
update
management,
verification
and
most
of
us
will
probably
use
notary
as
part
of
image,
signing
and
verification
to
ensure
that
when
we
get
an
image,
we
get
it
from
somebody
that
we
trust
and
it
hasn't
been
modified
along
the
way,
so
that
when
we
pull
images,
when
we
pull
code
into
our
infrastructure,
we
know
that
we
can
trust
where
it
came
from.
So
that's
notary
again,
tough
and
notary.
A
Have
this
tight
relationship
where
tough
is
the
standards
and
notary
is
an
implementation
of
it,
but
you
should
look
into
both
those
if
you're
curious
about
that.
Next
is
harbor.
Harbor
is
a
private
image
registry
and
it
has
all
the
features
you
might
expect
from
a
private
image
registry.
You
can
upload
oci,
compliant
images
and
get
things
like
validation
through
something
like
notary
or
even
image.
Inspection
or
vulnerability
scanning
and
along
with
a
bunch
of
other
features
like
you,
might
expect
from
a
private
registry.
A
It
also
has
a
really
cool
feature
in
that
it
can
be
a
pull
through
cache,
so
you
can
run
hardware
in
your
infrastructure,
hook
it
up
to
public
image
registries
and
then
have
your
clients
point
to
harvard
and
when
they
need
an
image.
If
that
image
exists
in
a
public
registry,
harper
will
pull
it
through
cache
it
locally,
allowing
your
clients
to
pull
from
harbor
instead
of
always
going
over
the
internet.
A
So
if
you
need
to
reduce
your
overall
image
pole
bandwidth,
you
might
check
out
harbor
for
that
either
way
if
you're
curious
about
having
a
private
image
registry
check
out,
harbor
next
is
kubernetes.
Of
course,
we
can't
talk
cloud
native
without
talking.
Kubernetes
kubernetes
was
the
first
cncf
member
project
to
reach
the
graduated
status
and
it
is
at
its
core
container
orchestration
engine.
So
when
I
say
that
I
mean
we've
got
a
suite
of
backend
machines
in
kubernetes.
A
We
call
these
nodes
and
we
want
to
run
workloads
on
those
nodes
and
we
can
tell
communities
hey.
I
want
you
to
run
a
workload.
Here's
what
it
should
look
like
and
kubernetes
will
put
that
workload
somewhere.
We
can
then,
of
course,
scale
up,
run
multiple
copies
of
our
workload.
In
fact,
kubernetes
can
handle
tons
and
tons
of
different
workloads
with
different
configuration
and
because
it's
an
orchestrator,
it
has
things
like
automatic
dealing
with
things
like
nodes
going
down.
A
A
Kubernetes
is
really
kind
of
the
heart
of
a
lot
of
other
things
that
I'm
going
to
talk
about,
and
it
is
that
way
because
it
provides
a
lot
of
touch
points.
A
lot
of
integration
points
for
other
systems
to
build
upon
kubernetes,
to
provide
more
value
using
kubernetes
as
a
core.
So
communities
has
the
ability
to
add
storage
or
networking
layers.
It
can
add
custom
resources
which
we'll
talk
about
in
a
second
or
even
extend
brand
new
apis
into
the
kubernetes
api
ecosystem.
A
So
really
kubernetes
is
the
heart
of
cloud
native
in
a
lot
of
ways.
Now
you
don't
have
to
run
kubernetes
to
be
cloud
native,
but
a
lot
of
us
do
speaking
of
kubernetes
helm
is
a
package
manager
for
kubernetes,
so
home
is
something
we
do
actually
have
to
run
in
kubernetes,
because
it's
specifically
around
creating
and
maintaining
applications
in
kubernetes.
So
we
know
that
we
can
run
our
workloads
in
kubernetes
and
we
call
those
pods,
but
it
turns
out
there's
actually
a
lot
of
things
in
kubernetes
that
we
could
create.
A
We
can
create
configuration
or
services
or
different
routing
information
to
all
help.
Tell
kubernetes
what
our
application
looks
like
to
describe.
Our
application
to
kubernetes
helm
allows
us
to
take
all
that
configuration
put
it
into
one
thing
called
a
helm
chart
and
that
chart
is
sort
of
like
a
package
that
says
here's
what
my
application
looks
like:
here's
all
the
things
you
need
to
make
and
how
they
relate
to
each
other.
A
We
send
that
to
telm
and
help
creates
it
in
our
quran's
cluster,
like
we
expect
the
great
thing
about
helm
and
helm
chart
is
it's
this
kind
of
recipe.
This
redistributable
thing
we
can
take
our
chart
and
not
only
use
it
internally,
but
give
that
chart
to
other
users
or
distribute
that
chart
out
into
the
world
to
help
other
users
install
our
applications
into
their
kubernetes
clusters.
A
So
you'll
very
often
see
a
lot
of
the
things
I'm
going
to
talk
about
be
installable
into
your
clusters,
using
something
like
helm.
Another
way
that
you
might
manage
your
applications
in
kubernetes
is
using
something
like
argo.
Argo
is
also
an
application
manager,
but
it
takes
a
different
tact
than
helm.
Argo
is
a
get
ops-based
system
for
kubernetes
application
management,
meaning
that
we
set
up
one
or
more
git
repositories
and
in
those
repositories
we
describe
what
we
want
our
application
to
look
like
in
kubernetes.
A
We
then
hook
argo
up
between
the
repositories
and
our
kubernetes
cluster
or
clusters,
and
it
takes
the
described
application
and
makes
it
true
in
kubernetes
and
it's
doing
git
ops.
So
it's
always
watching
the
repository
and
as
the
repository
changes,
it
syncs
those
changes
into
kubernetes
as
they
happen,
and
it
allows
us
to
take
all
the
get
ops
tools
we
know
and
love
and
use
them
to
manage
our
kubernetes
applications.
A
So
if
you're
interested
in
git,
ops
and
kubernetes
check
out
argo,
I
will
also
say
that
argo,
you
don't
have
to
just
use
argo
adjust
you
use,
helm.
Argo
actually
knows
how
to
leverage
helm
and
customize
and
some
other
kubernetes
deployment
mechanisms.
That
means
they're,
not
mutually
exclusive.
You
can
use
argo
and
helm
together.
It's
absolutely
fine.
A
One
other
way
we
might
manage
applications
or
the
other
applications
may
create
for
us
to
manage
them
is
something
called
an
operator,
and
the
operator
framework
is
a
set
of
tools
and
libraries
to
help
us
build
operators.
Now
my
30
second,
what
is
an
operator
talk?
So
an
operator
can
be
thought
of
as
an
engine.
It's
a
process.
We
run
inside
our
kubernetes
cluster.
A
That
knows
how
to
create
applications
for
us
and
we
create
something
kubernetes
called
a
custom
resource
and
that
custom
resource
describes
just
the
minimum
amount
of
configuration
that
would
need
to
exist
to
describe
application
and
the
engine
we've
written
called
an
operator
knows
how
to
take
that
resource
and
make
the
application
in
kubernetes
force
based
on
that
resource,
and
then,
if
we
make
a
different
resource
with
different
configuration,
the
operator
can
operate
on
that
and
make
that
copy
of
the
application.
Really.
A
The
focus
here
is
these
crds,
rather
than
build
a
helm
chart
or
a
git
repository,
we
actually
put
a
resource
into
the
kubernetes
api
describing
our
application
and
we
use
the
operator
framework
or
other
tools
to
create
an
operator.
That
knows
how
to
take
those
custom
resources
and
turn
them
into
applications
in
our
cluster.
A
So
if
you're
curious
about
a
more
advanced
way
to
manage
your
applications
throughout
their
entire
life
cycle,
inside
kubernetes
check
out
the
operator
framework
and
just
like
before
the
operators
and
helm
and
argo,
those
are
not
all
mutually
exclusive
and
a
lot
of
them
can
work
together.
Very
well.
A
Next
is
contour
contour
sort
of
fills
another
gap
in
the
kubernetes
ecosystem,
so
we
talked
about
kubernetes
can
run
our
workloads.
It
can
also
run
these
things
called
ingress
and
ingress
really
is
just
a
set
of
configuration.
It's
a
set
of
configurations
like
host
and
path-based
information
that
says
hey
if
you're
coming
in
for
this
host
and
this
path
go
to
this
workload.
But
there's
something
missing:
ingress
is
just
configuration.
Something
has
to
exist
in
the
kubernetes
cluster
to
make
that
configuration
real.
Something
has
to
run
in
the
cluster.
A
A
Many
of
them
are
legacy
web
servers
kind
of
jammed
into
this
ingress
controller
role,
but
contour
is
built
from
the
ground
up
to
be
an
ingress
controller
for
kubernetes.
So
if
you're,
looking
for
a
cloud
native
ingress
controller
or
an
angus
controller,
that's
built
specifically
for
this
job
and
to
try
to
do
the
right
things
for
you
right
from
the
start.
Check
out.
Contour
next
is
cube.
A
Edge,
cube
edge
is
interesting
because
it's
orchestration
built
on
kubernetes,
so
we
already
know
kubernetes
can
do
container
orchestration,
but
cube
edge
is
a
platform
that
leverages
the
kubernetes
apis
and
extension
points
to
allow
us
to
do
edge
compute
management
using
the
kubernetes
apis.
So
if
you're
curious
about
doing
edge
management
and
managing
your
computer
at
the
edge-
and
you
want
to
use
the
kubernetes
tools
and
api
check
out
cube
edge
next
is
rook.
A
Rook
is
also
orchestration
that
runs
in
kubernetes,
but
instead
of
managing
other
devices
or
containers,
work
is
about
managing
storage
inside
kubernetes,
so
rook
runs
in
kubernetes
and
allows
you
to
deal
with
block
storage
or
object
storage,
and
it
can
do
things
like
provide
persistent
volumes
for
your
workloads,
so
they
can
have
a
volume
that
follows
them
around
in
your
cluster
or
do
other
things
like.
I
said,
object,
storage
and
other
kinds
of
storage,
extensions
that
you
would
build
on
top
of
kubernetes
using
rook.
A
So
if
you're
curious
about
storage
and
kubernetes
check
out
rook
next
is
cryo
or
crio.
Cri
stands
for
container
runtime
interface.
It
is
kind
of
a
layer
that
we
described
that
we
defined
to
help
kubernetes,
run,
containers
and
o
stands
for
oci
compliant.
So
every
single
node
in
our
kubernetes
cluster
runs.
This
thing
called
a
cubelet
and
it's
the
cubelet's
job
to
create
and
manage
containers
over
their
lifecycle
on
the
node.
A
But
there's
this
kind
of
squishy
blue
layer,
I've
drawn
between
the
cubelet
and
actually
doing
things
with
containers,
and
that
is
where
cri
or
the
container
runtime
interface
lives,
and
it
is
definitely
where
crio
lives,
because
cryo
is
a
run.
A
container
runtime
interface
built
specifically
for
kubernetes
to
be
simple
and
fast
and
efficient.
So
if
you're
curious
about
container
runtime
for
kubernetes
built
for
kubernetes
check
out,
cryo
next
is
cni.
Cni
stands
for
container
network
interface,
so
we've
got
our
workloads
running
on
multiple
nodes
and
often
they'll
talk
to
each
other
over
the
network.
A
Sometimes
that's
on
the
same
node,
but
very
often
it's
across
nodes
and
something
needs
to
exist,
to
kind
of
define
and
implement
standards
for
how
we
set
up
networking
between
our
workloads
in
a
cluster
or
in
the
cloud,
and
that's
what
cni
seeks
to
do.
It's
a
set
of
standards
and
tools
and
some
kind
of
low-level
helpers
to
help
you
build
tools
to
deal
with
container,
to
container
networking
in
the
cloud
or
in
kubernetes.
A
So
if
you're
interested
in
the
low-level
operations
of
networks
check
out
cni
next
is
grpc,
so
we've
got
our
applications
and
they
need
to
talk
to
each
other
one
way
they
might
do.
That
is
over
something
like
http.
It's
been
around
for
a
long
time.
It's
kind
of
a
low-level
interrupt
but
http,
although
it's
great,
has
its
problems.
A
Primarily,
it's
got
a
lot
of
overhead
because
it's
connectionless
and
stateless
there's,
a
lot
of
overhead
in
every
single
http
request
to
describe
what's
going
on,
grpc
exists
as
an
alternative
or
can
run
alongside
http
as
another
way
for
our
applications
to
communicate
with
each
other
over
a
network,
and
this
is
stateful
and
has
less
overhead.
So
it
can
be
a
lot
lot
faster
than
http.
A
So
if
you're
looking
to
do
application
to
application
communication
over
the
network
and
want
to
go
above
and
beyond
what
you
get
from
http
check
out,
grpc
next
is
core
dns.
Core
dns
is
like
you
might
expect
a
dns
server
built
for
the
cloud.
So
we've,
if
we're
all
honest
with
each
other
dns,
is
the
oldest
form
of
what
we
call
service
discovery
right.
We
ask
for
something
by
name.
A
Dns
gives
us
back
where
that
lives,
and
even
though
we've
got
all
of
these
cool
new
ways
to
do
service
discovery
in
the
cloud
we
still
tend
to
tend
to
use.
Dns
a
lot
and
core
dns
exists
to
be
a
brand
new
dns
server
that
is
built
for
the
cloud,
and
this
picture
that
I'm
showing
you
seems
empty
seems
like
there's
a
lot
missing
and
that's
because
core
dns
really
exists
at
the
core
of
this
big
ecosystem
of
plug-ins.
A
It
also
has
the
ability
to
bring
in
configuration
and
receive
both
initial
configuration
and
constant,
active
reconfiguration
from
multiple
sources,
including
things
like
kubernetes
etd,
which
we'll
talk
about
or
even
public
clouds,
where
core
dns
can
privately
serve
the
records
that
you
define
in
your
public
cloud,
dns
systems.
It
also
has
plugins
to
help
you
do
things
like
rewrites
and
tracing
and
metrics
on
your
dns.
It
really
brings
dns
into
the
modern
age.
A
In
fact,
all
these
features
make
coordinates
the
recommended
and
go-to
dns
solution
for
doing
dns
inside
of
kubernetes,
and
it
has
been
that
way
for
quite
a
while
now.
So
if
you're
curious
about
a
modern,
dns
implementation
check
out
coordinates
now
before
I
talk
about
the
next
two
projects,
I
want
to
briefly
describe
what
a
service
mesh
is,
so
we've
got
our
applications
they're
talking
to
each
other,
and
if
we
want
to
add
features
to
this
network.
A
A
service
mesh
says
well
what,
if
we
write
a
proxy
process
and
this
proxy
process
can
be
thought
of
as
living
around
our
application,
although
it
technically
lives
just
between
the
application
and
the
and
the
network,
and
that
proxy
is
responsible
for
implementing
the
code
to
do
all
the
things.
I
just
talked
about
transparency
encryption,
that
kind
of
thing
well,
once
we've
got
all
these
proxies
distributed
and
running
in
our
ecosystem,
we'll
want
a
control
plane
that
can
manage
these
distributed
proxies
and
give
us
a
way
to
view
what's
happening
with
them
and
control
them.
A
You
combine
a
proxy
and
a
control
plane
and
you
get
a
service
mesh
and
you
get
powerful
features
like
metrics
load,
balancing
encryption
and
transparency
and
tracing
all
from
the
proxy
without
ever
having
to
change
your
service
code,
and
this
is
very,
very
powerful
and
there
are
two
projects
I
want
to
talk
about.
That
are
part
of
a
service
mesh.
The
first
one
is
linker
d.
Linker
d
is
a
cns
cncf
project
that
is
a
complete
service
mesh
offering
so
we've
got
our
applications
talking
to
each
other.
A
Linker
d
comes
with
the
linker
d2
proxy,
which
is
a
proxy
process
written
from
the
ground
up
for
linker
d,
to
do
this
service
mesh
to
implement
these
service
mesh
ideas,
it
also
comes
with
the
linker
d2
control
plane
that
allows
you
to
manage
all
the
proxies.
So
it
really
is
a
full
complete
end-to-end
service
mesh
solution.
A
It's
also
very
easy
to
get
up
and
going
and
to
use
linker
d.
So,
if
you're
looking
to
implement
a
service
mesh-
and
you
want
to
get
up
and
going
and
want
a
complete
solution,
you
can
check
out
link
or
d.
Another
alternative
for
a
service
mesh
is
envoy
now
envoy
is
a
bit
different
in
that
envoy.
Just
focuses
on
being
the
proxy
process
for
the
service
mesh.
A
So,
if
you're
curious
about
just
running
a
service
proxy
check
out
envoy
next
is
open
tracing
like
you
might
guess
it's
all
about
dealing
with
traces.
So
we
know
that
we
can
use
something
like
a
service
mesh
to
get
automatic
tracing
between
app,
our
user
requests
and
the
applications
it
bounces
around.
But
if
we
want
to
know
what
that
user
request
does
in
each
application,
it
visits
as
it
kind
of
goes,
from
method
to
method
and
spends
a
different
amount
of
time
in
each
application
doing
different
things.
We
need
to
instrument
our
application.
A
We
need
to
write
code
to
create
these
tracing
these
traces
and
that's
what
open
tracing
exists
to
do
it
like?
You
might
have
guessed
from
the
name.
Open
tracing
is
provider
agnostic,
so
the
great
thing
about
it
is:
you
can
instrument
your
applications.
You
can
write
code
in
your
applications
to
generate
trace
data
and
open
tracing
works
with
a
multitude
of
providers,
meaning
that
it
doesn't
care
who
you
use
you
instrument
once
and
never
have
to
do
it
again.
One
place
you
might
export
this
trace.
A
Data
from
open
tracing
or
elsewhere
is
to
jager
jaeger
is
a
trace,
aggregation
and
trace
management
platform.
So
we've
got
our
trace
data
that
we've
got
from
our
service
mesh
or
some
from
something
like
open
tracing.
We
need
to
take
that
data
and
send
it
somewhere
so
that
we
can
aggregate
it
all
and
view
it
and
manage
it
and
that's
what
jaeger
does.
Jaeger
provides
a
ui
where
you
can
dig
into
your
traces
and
see
exactly
how
they
break
down
it.
You
can
search
through
your
traces,
and
it
has
other
api
extensions
that
lets.
A
You
really
be
the
core
of
tracing
in
your
cloud
native
system.
So
that's
jaeger,
if
you're
curious
about
somewhere
to
send
your
traces
and
view
your
traces
in
the
cloud
check
out.
Yeager
next
is
prometheus.
Prometheus
is
all
about
dealing
with
metrics
in
the
cloud
now
we
know
that
we
run
applications
all
over
the
place,
especially
in
the
cloud
and
those
applications
are
generating
data
right.
They
want
to
generate
data
around
how
many
requests
they're
making,
how
many
requests
are
succeeding
and
failing
that
kind
of
stuff
what
we
used
to
do
when
we
wanted
application.
A
A
Prometheus
turns
out
on
its
head,
primitive
says:
well,
part
of
the
prometheus
spec
is
saying:
here's
a
standard
way
that
you're
all
going
to
serve
up
metrics
you're,
going
to
expose
a
web
page
and
give
me
your
metrics
and
prometheus
is
going
to
go
to
each
application
individually
and
pull
that
metric
data
down
and
aggregate
it.
And
it
knows
where
your
applications
live
because
remember
we're
in
the
cloud
things
are
coming
and
going
all
the
time
it
knows
where
your
applications
are
and
how
to
find
them.
A
By
having
cloud
integrations
or
kubernetes
integrations
so
that
azure
applications
come
up
and
down
and
move
prometheus
always
knows
where
to
go
to
get
that
metric
data
and
it
kind
of
flips
the
whole
idea
of
metrics
on
its
head
once
prometheus
has
gone
and
scraped
that
metric
data
and
pulled
it
in
it,
pulls
it
into
its
own
internal
time
series
database
and
can
give
you
features
like
charting
and
alerts
and
metric
searching
and
other
api
integrations
that
really
sort
of
like
jager
was
with
traces.
It
lets
prometheus,
be
the
core
of
metrics
in
the
cloud.
A
But
the
thanos
project
is,
you
can
think
of
thanos
as
a
rapper
around
one
or
more
prometheus
instances
that
allows
you
to
aggregate
data
and
go
to
thanos
and
run
a
metrics
query
and
have
it
go
to
all
your
prometheus
instances
and
run
that
query
for
you.
Thanos
also
has
the
ability
to
take
that
data
and
export
it
into
multiple
cloud
storage
mechanisms
so
that
you
can
have
long-term
prometheus
storage,
because
prometheus
doesn't
tend
to
want
to
keep
data
for
very
long.
A
So,
if
you're
curious
about
distributed
prometheus,
long-term
metrics
from
prometheus
check
out
thanos
in
that
same
vein,
there's
the
cortex
project.
Now
the
cortex
project
also
exists
to
solve
the
multiple
prometheus
problem,
but
it
works
a
bit
differently.
It's
designed
to
always
pull
all
of
the
data
rather
than
wrapping
it
just
ingests
all
the
data
from
all
your
prometheus
instances
and
stores
it
in
its
own
internal
architecture.
That
way,
when
you
query
your
metrics,
you
don't
even
have
to
go
to
your
prometheus
instances.
A
They
just
act
as
a
data
source
and
really
cortex
is
at
the
heart
of
your
metrics
at
that
point.
So
if
you're
interested
in
long-term
aggregated
prometheus
metrics,
you
can
check
out
cortex
now.
I
know
those
two
projects,
thanos
and
cortex-
seem
very
similar
and
that's
because
they
are
you'll
have
to
do
your
own
research
to
find
out
which
of
these
two
projects
might
be
the
right
one
for
you.
A
Next
is
fluent
d
now.
Fluentd
is
all
about
dealing
with
streaming
text,
processing
and
very
often
log
processing
in
the
cloud
and
elsewhere.
So
atascore
fluentd
can
be
set
up
to
take
in
multiple
streams
of
text.
Read
those
streams
as
they
come
in
process
them
internally
and
spit
them
out
into
other
places
to
clouds
to
files
to
other
integrations.
It
really
kind
of
exists
as
this
integration
and
glue
layer
between
your
data
sources
and
where
you
might
want
to
put
that
data.
A
Vitesse
is
all
about
dealing
with
relational
databases
in
the
cloud.
So
it's
easy
easy
easy
to
run
a
relational
database
in
the
cloud
or
in
kubernetes.
But
the
problem
with
these
databases
is
they
tend
to
have
to
scale
vertically,
and
that
is
really
vulnerable
and
brittle
in
the
cloud,
because
we
don't
want
things
to
scale
vertically.
We
want
to
scale
horizontally.
We
want
to
be
fault,
tolerant
and
distributed.
A
So
we
want
to
split
that
big,
horizontal
or
vertically
scale
database
into
multiple,
smaller
databases
and
vitesse
exists.
To
help
us
do
that
by
test
is
a
layer
that
runs
on
top
of
the
mysql
or
mariadb
engine
that
you
already
know
and
trust,
but
allows
for
powerful
features
like
replication
and
sharding,
and
you
can
actually
increase
replicas
and
reshard
and
do
all
sorts
of
database
manipulation
using
vitesse.
A
So
that's
why
I
test
next
is
titanium
or
thai
kv.
Tai
kv
is
a
key
value
store,
so
it's
all
about
dealing
with
key
values.
So
it
does
the
things
you
might
expect
from
a
key
value
store.
It
does
adds
it
does
updates
it
does
deletes,
but
the
cool
thing
about
thai
kv
is
that
it
scales
horizontally.
Likewise,
it
skates
horizontally.
Very
very
well,
in
fact,
according
to
my
test
page,
they
say
that
it
scales
up
to
petabytes
worth
of
key
value
data,
that's
a
huge
scale.
A
Another
really
great
thing
about
tai
kv
is
that
it
supports
distributed
acid
compliant
transactions,
so
you
into
a
thai
kb
installation.
You
can
say
I
want
you
to
update
this
key
delete.
These
three
keys
change,
those
two
keys-
and
I
want
you
to
do
all
of
those
operations
at
once
or
not
at
all.
That
ensures
that,
if
you're
doing
multiple
key
operations
in
your
key
value
store,
you
don't
have
to
get
stuck
in
a
halfway
state
where
one
transact
one
operation
worked
and
the
other
failed,
and
you
don't
know
how
to
recover.
A
So,
if
you're
interested
in
a
really
high
scale,
key
value,
store
or
transactional
key
value
store
check
out.
Taikv
ncd
is
also
a
key
value
store,
that's
cloud
native,
so
it
does
all
the
same
things
that
I've
just
described,
add
updates
deletes,
but
ncd,
rather
than
focusing
on
sheer
scale,
has
focused
on
simplicity.
A
A
So
it
has
all
the
things
you
might
expect
leader
election
fault,
tolerance
distributed
load,
but
it's
much
much
simpler
to
run
than
some
of
the
other
offerings.
In
fact,
the
kind
of
combination
of
features
and
simplicity
have
made
etcd
the
go-to
back-end
for
the
kubernetes
api
for
a
long
time
for
a
while
it
was
the
only
back
end.
A
Next
is
dragonfly.
Dragonfly
is
all
about
peer-to-peer
file
transmission,
so
we've
got
multiple
peers.
They
can
send
files
to
each
other.
Dragonfly
is
agnostic
about
the
file
content,
but
it
does
have
some
first
class
integrations
for
images,
so
dragonfly
has
native
integrations
to
deal
with
image,
transmission,
peer-to-peer
and
that's
not
very
interesting,
but
what's
cool
about
dragonfly?
A
Is
it's
distributed
peer-to-peer
transmission,
so
you
set
up
dragonfly
nodes
throughout
your
system
and
when
anybody
wants
to
download
a
specific
image
rather
than
having
to
go
out
to
a
single
place,
to
download
the
whole
image,
they
can
download
parts
of
that
image
or
parts
of
any
file
from
the
peers
that
have
chunks
of
that
file,
rather
than
always
having
to
go
out.
So,
if
you're
curious
about
a
better
way
to
do
peer-to-peer
file
transmission
or
a
better
way
to
do
image
transmission
check
out
dragonfly
next
is
cloud
events.
A
Cloud
events
like
you
might
guess,
is
all
about
dealing
with
event
infrastructure
in
the
cloud,
so
we've
got
our
applications
and
they
have
the
ability,
of
course,
to
we've
say
we
decide
that
we
want
to
do
event-based
infrastructure.
One
thing
we
might
not
agree
on
is
the
exact
format
of
our
events.
We
may
want
to
use
different
structure
different
terms
and
it
makes
it
really
hard
to
say
well.
A
We
all
want
to
do
events,
but
we
can
agree
on
what
the
event
should
look
like
cloud
events
exist
to
be
a
series
of
standards
and
sdks
for
us
to
work
with
event-based
infrastructure
and
all
agree
that
we're
going
to
use
cloud
events
so
that
we
can
very
easily
and
efficiently
interop
with
each
other,
because
we
all
use
the
same
back
end
event
structure.
So,
if
you're
curious
about
event
based
infrastructure
check
out
cloud
events,
in
that
same
vein,
let's
talk
about
gnats
nats
is
at
its
heart,
really
a
message
bus.
A
So
you
have
producers
and
consumers
where
you
can
put
messages
into
nets
and
get
them
from
other
processes,
and
nets,
of
course,
can
run
distributed
and
deal
with
lots
and
lots
of
producers
and
consumers.
It
supports
a
lot
of
different
event
bus
systems,
so
you
can
do
things
like
pub
sub,
where
you
publish
a
message
and
multiple
subscribers
get
that
message.
You
can
do
request
reply
where
you
send
specifically
to
someone
and
get
a
specific
answer
back
or
you
can
do
topic
based
or
streaming
event
processing
all
using
gnats.
A
That's
also
scales
dynamically
and
very
efficiently.
So
not
only
is
it
fast
and
flexible
and
really
efficient,
but
it
scales
really
well,
which
makes
it
a
great
solution
for
doing
event-based
infrastructure
in
kubernetes.
So
that's
nats.
If
you're
curious
about
building
an
event-based
system
check
it
out,
next
is
spiffy
or
the
secure
production
identity
framework
for
everyone,
and
it's
all
about,
like
you
might
guess,
identity
spiffy
is
a
set
of
standards
and
tools
for
dealing
with
identity
in
the
cloud.
A
Now,
when
I
say
identity,
I
don't
just
mean
users,
I
mean
identity
at
the
node
level,
identity
at
the
workload
level
or
identity
at
processes
inside
the
workload
spiffy's
really
about
saying.
Well,
let's
take
identity
and
go
as
deep
as
we
need
to
and
be
more
dynamic
and
more
fluid
and
more
granular.
If
we
need
to
to
help
us
deal
with
identity
in
the
cloud,
spiffy
is
another
case
where
you
probably
won't
use
it
directly.
A
You
probably
use
the
spire
project,
which
takes
all
the
implementations
and
standards
of
spiffy
and
builds
some
tools,
the
spire
server
and
the
spire
agent,
where
you
can
implement
some
of
the
spiffy
concepts
and
get
this
kind
of
identity
stuff
that
I've
been
talking
about
without
having
to
write
your
own
code.
So
if
you're
interested
in
identity-
and
you
want
to
write
your
own
code
check
out
spiffy
or
if
you
want
to
just
leverage
the
specific
concepts
check
out.
Spire
next
is
open
policy
agent,
it's
all
about
dealing
with
policy
enforcement.
A
So
we
feed
open
policy
agent
policy
documents,
saying
here's
what
we
do
and
do
not
want
to
allow
into
a
given
system
and
then,
as
we
feed
objects
into
that
system,
opa
either
accepts
them
or
rejects
them.
Based
on
the
policy,
it's
been
given,
I'm
being
intentionally
vague,
because
open
opa
doesn't
prescribe
a
specific
thing
that
it's
an
enforcer
of
opa
has
been
used
to
enforce
policy
for
a
ton
of
things.
One
thing
opa
fits
really
well
onto,
though,
is
kubernetes.
A
Opa
can
run
on
top
of
and
in
front
of
your
kubernetes
api
so
that
you
can
kind
of
control
what
you
allow
into
your
kubernetes
cluster
and
what
you
don't
based
on
the
policy
that
you
give
opa.
So
if
you're
interested
in
policy
definition
or
policy
enforcement
check
out
opa
last
but
not
least,
is
falco.
Falco
is
all
about
container
runtime
security,
so
we've
got
our
images
and
we
can
use
things
like
notary
to
validate
that
we're
running
images.
A
We
trust,
but
we
might
still
want
to
watch
these
images
or
these
containers
or
these
processes
the
entire
time
they're
running
so
falco.
Does
that
falco?
Is
this
to
run
in
our
infrastructure
and
watch
our
processes
all
the
time,
and
it
has
a
set
of
internal
rules
that
says
what
it
expects
them
to
do
and
what
expects
them
not
to
do,
and
if
any
of
our
processes
does
something
we
don't
expect
like
accessing
a
database.
We
didn't
expect
it
to
reach.
Falco
can
see
that
and
send
an
alert
when
it
happens.
A
So
you
get
always
on
active
security
for
your
workloads.
So
if
you're
curious
about
that
check
out
falco.
So
that's
it!
I
have
covered
all
of
the
projects
in
this
amount
of
time.
Hopefully
you
kind
of
kind
of
wet
your
appetite
for
a
lot
of
these,
giving
you
a
basic
idea
of
what
each
of
these
projects
does
and
how
they
fit
together.
So
you
can
kind
of
go
forth
and
learn
more
about
them,
as
you
see
fit
one
last
thanks
to
50.io
for
these
great
characters.
I
absolutely
love
them.