►
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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
A
I
have
been
the
executive
director
of
the
cloud
native
foundation
for
about
two
months
now,
so
this
is
actually
our
first
run
event
and
my
first
time
getting
to
talk
up
a
little
bit
about
what
cncf
is
doing
publicly
and
I'm
curious
to
see
what
you
think
before
we
start.
I
wanted
to
go
ahead
and
thank
our
sponsors.
A
We
couldn't
be
here
without
them,
which
is
ibm
and
red
hat
at
the
diamond
level
and
cisco
is
our
platinum,
sponsor
and
navops
is
our
gold
sponsor
if
I
can
just
get
a
quick
round
of
applause
for
all
of
them?
Thank
you
very
much
for
helping
us
run
this
event,
and
I
also
wanted
to
mention
if
you
are
going
to
be
tweeting
about
the
event
that
the
hashtag
is
hashtag
cloudnativeday.
A
A
So
I
want
to
give
you
my
perspective
on
what
I
call
a
brief
history
of
the
cloud.
Just
a
reminder.
First
of
what
cloud
native
computing
foundation
is,
we
were
founded
just
about
nine
months
ago
december
2015
we're
a
non-profit,
we're
part
of
the
linux
foundation,
the
linux
foundation.
I
was
the
chief
operating
officer
there
back
in
2006
when
we
merged
together,
two
predecessor,
organizations,
and
it
was
much
tinier
now.
A
It
seems
like
this
kind
of
foundation
of
foundations,
there's
something
like
40
different
projects,
of
which
cncf
is
actually
one
of
the
the
fastest
growing
and,
I
think,
most
exciting.
We
are
among
the
things
a
host
of
different
software
projects,
there's
two
to
start
with.
By
far
the
best
known
is
kubernetes.
A
The
orchestration
container
scheduling
platform
that
was
donated
by
google
and
the
second
one
was
prometheus,
which
is
originally
from
soundcloud,
but
now
supported
by
a
bunch
of
our
different
members
and
has
committers
from
a
number
of
different
companies
and
I'll
just
give
a
quick
shout
out
here
to
our
platinum
members,
who
are
the
main
folks.
Who've
helped
us
get
started,
but
we
have
another
40.
A
It's
actually
more
like
50,
now
members,
including
seven
new
ones,
that
we
announced
this
week
and
we
have
a
lot
of
startups
and
others
in
this
area
who
are
excited
about
cloud
native
computing.
So
I
find
it
easiest
when
you
think
of
cloud
native
to
say:
where
are
we?
What
was
the
history?
A
Where
does
this
fit
in?
And
so
this
is
my
hopefully
relatively
brief
history
of
the
cloud.
I
don't
think
we
want
to
spend
days
and
days
on
this,
but
for
me
it
really
starts
pre-cloud,
which
is
2000
when
you
had
non-virtualized
servers.
I
think
folks,
remember
sun
marketing
themselves
as
the
dot
in
dot
com
and
they
the
stock
price
going
wild
and
every
time
you
wanted
you,
a
new
application,
a
new
website,
a
new
internal
service.
You
were
going
to
release.
A
A
So
then,
in
2001
vmware
released
and
they
popularized
the
concept
of
virtual
machines
that
you
could
run
individual
applications
more
than
one
on
a
server.
They
could
remain
isolated
and
you
know
one
of
the
dirty
secrets
of
the
vast
majority
of
computing
out
there
is
that
it
very
rarely
taxes
most
servers.
I've
heard
statistics
of
most
servers
running
at
15
utilization.
A
I've
also
heard
statistics
from
a
lot
of
companies
that
the
average
server
or
the
medium
server
runs
it
more
like
three
percent
utilization,
and
so
the
concept
of
of
multiplexing
of
vms
is
that
you
could
then
stack
together
a
ton
of
different
applications.
All
on
the
same
machine
saves
you,
huge
amounts
of
money,
turned
vmware
into
a
massive
success,
and
so
at
that
point
for
developers
for
architects,
the
building
block
stopped
being
a
physical
server
and
started
being
a
vm.
A
When
you
had
a
new
application,
deploy,
you'd,
say:
okay,
I'm
going
to
spin
up
avm
or
a
set
of
vms,
then
jump
forward
to
2006,
and
this
is
really
where
the
cloud
got
going
for
aws
to
come
out
and
say
that
they're
going
to
provide
infrastructure
as
a
service.
This
kind
of
difficult
to
pronounce
acronym
is
they
launched
elastic,
compute
cloud
ec2,
and
they
said
you
can
rent
servers
by
the
hour
and
I
actually
used
to
be
a
venture
capitalist
in
silicon
valley
from
2000
2005,
and
I
remember
companies
coming
in
and
saying.
A
Well,
of
course,
we
need
two
million
dollars
to
buy
all
these
servers
from
sun
or
some
of
the
very
forward-looking
ones
saying
we
need.
You
know
750
000,
to
buy
all
of
these
x86
servers
and
run
linux
on
them,
but
it
was
this
massive
capex
that
was
incredibly
dilutive,
that
they
had
to
raise
money
to
do
and
now
suddenly
all
of
that
went
away
and
they
could
rent
the
servers
instead
that
it
converted
the
capex
to
an
operating
expense.
A
The
building
block
the
name
changed
from
a
virtual
machine
to
amazon's
case
to
an
amazon
machine
image
in
ami,
but
it
was
really
the
same
thing.
It's
still
a
virtual
machine
amazon
allows
you
to
put
multiple
different
or
amazon
does
put
multiple
different
amis
onto
the
same
physical
server.
A
So
now
fast
forward
to
2009-
and
we
have
another
unlovely
acronym,
paz
and
heroku-
was
really,
I
think,
one
of
the
most
incredible
startups.
They
one
of
the
neat
things
about
it
is
this
wasn't
even
their
original
business.
They
they
had
a
developer,
front-end
and
a
sort
of
shared
coding
environment,
and
it
was
actually
very
popular
and
people
loved
it
and
as
a
little
add-on
to
it,
they
said
oh
and
we
can
also
let
you
deploy
what
you're
playing
with
and
then
they
had.
A
They
looked
at
where
their
business
was
and
the
tens
of
thousands
of
users
they
had
who
loved
this
development
front
end
and
the
relatively
small
number
of
hosting
they
were
doing,
and
they
actually
made
the
incredibly
hard
decision.
There's
a
great
blog
post,
describing
it
as
an
epic
pivot,
where
they
threw
away
the
dev
tools
and
shut
that
down
and
said.
We
are
going
to
focus
solely
on
being
a
platform
as
a
service
and
they
really
defined
and
popularized.
A
A
Things
like
dev,
prod
parity,
that
you
should
have
an
identical
environment
for
what
you
develop
in
and
what
you
put
up
on
the
product
that
you
shouldn't
have
any
secrets
in
your
repository
that
those
should
be
stored
as
environment
variables
and
there's
a
number
of
others
and
what
they
said
is.
If
you
follow
these
rules,
then
you
can
switch
to
a
development
methodology
where
you
can
constantly
be
pushing
your
code
up
into
production
that
the
typical
enterprise-
maybe
they
do,
a
new
release.
A
Every
six
months,
every
three
months
and
heroku
popularized
recommended
a
set
of
practices
that
allow
you
to
deploy
every
hour
several
times
a
day
and
so
the
process
of
how
they
did.
That
was
a
little
bit
opaque.
They
have
something
called
a
build
pack,
it
actually
is
a
container,
but
it's
not
something
that
the
the
end
user
or
the
developer
has
control
over.
A
So
the
thing
that
I'll
point
out
so
far
on
this,
this
history,
sun,
vmware,
aws
and
heroku-
were
all
very
successful
private
companies
and
all
of
these
were
very
successful,
important
closed-source
solutions.
And
now
we
jump
to
the
fifth
step
here,
which
is
openstack
and
in
my
history.
A
But
without
locking
people
into
a
certain
certain
proprietary
environment,
and
so
that
was
started
in
2010.
I
think
there
have
been
some.
Maybe
it
took
a
little
bit
longer
for
that
to
be
developed
than
they
want.
A
There
have
been
some
hassles
or
issues
along
the
way,
but
at
the
end
of
the
day
they
have
succeeded
in
creating
is
aws
ec2
competitors
that
do
work
that
are
deployed
both
in
enterprises
and
in
public
clouds,
and
that
is
based
on
a
real
open
source
community
and
but
the
part
that
I'll
emphasize
is
that
the
building
block
of
openstack
what
they
were
offering
to
their
end
users
is
still
a
vm.
A
So
then,
the
next
step
is
cloud
foundry,
and
this
is
a
a
group
that's
dear
to
to
us,
because
it
also
is
home
to
the
linux
foundation.
So
we
have
a
close
relationship
with
them.
We
share
several
board
members,
we're
we're
happy
to
collaborate
when
we
have
the
opportunity
and
what
they
were
doing
in
the
simplest
way
is
basically
taking
heroku
the
idea
of
a
pass
and
saying
we're
going
to
create
an
open
source
version
of
it.
So
this
company
pivotal
started
building
it
in
2011..
A
They
open
sourced
it.
In
late
2014,
they
created
the
cloud
foundry
foundation.
They
brought
in
a
number
of
other
big
companies
that
have
have
adopted
it
and
it's
particularly
popular
in
finance
and
again
this.
The
the
building
block
is
what
they
call
garden
containers
now,
there's
a
little
bit
more
flexibility,
it
can
hold
a
heroku
build
pack,
it
can
work
with
docker
that'll
talk
about
a
second.
It
can
actually
work
non-linux
os's,
but
it's
still
basically
designed
as
a
path
for
that
12-factor
application.
A
It's
it's
a
very
similar
concept
in
how
it's
mainly
used
to
what
heroku
was,
but
again
open
source
with
competition,
so
then
fast
forward
to
2013,
and
you
have
docker
and
so
containers
came
along
and
have
really
upended
the
entire
industry.
Now
one
of
the
interesting
themes
for
each
of
these
companies
is
that
in
many
cases
the
company
that
I'm
listing
here
is
not
the
very
first
one
that
did
it
there.
I
believe
apogee
had
a
pass
before
heroku
did
and
aws
was
not.
A
The
very
first
is
provider,
but
in
each
case
these
are
the
companies
that
really
defined
that
marketplace
and
had
a
massive
impact,
and
so
for
docker.
What's
interesting
is
that
they
didn't
necessarily
invent
that
much
new
technology,
at
least
at
first.
They
took
three
big
projects
that
actually
already
existed
out
there
that
had
been
contributed
by
a
number
of
different
companies.
A
Lxc
was
a
container
implementation
that
had
been
put
into
the
linux
kernel.
Union
file
systems
was
a
way
of
merging
together
different
file
systems.
C
groups
is
a
protection
mechanism
that
actually
goes
back
25
years
as
an
evolution
of
of
ch
root
and
but
there's
sometimes
just
a
magic
of
when
you
combine
the
right
technologies
together
at
the
right
time.
A
It
kind
of
reminds
me
of
an
analysis
of
tim
berners-lee,
creating
the
web
and
people
say
well,
you
know,
http
wasn't
really
all
that
different
from
ftp
or
gopher
and
html
wasn't
all
that
different
from
xml
and
urls
were
not
really
all
that
big
in
innovation,
but
somehow
the
magic
of
those
three
things
together,
just
created
the
web
and
also,
obviously
at
the
right
time
when
the
network
was
there
and
took
off
the
world
was
changed,
and
similarly
docker
created
these
three
created
a
just
incredibly
powerful
developer
experience.
A
Sarah
novotny
who's
speaking
today
has
the
phrase
time
to
first
endorphins
that
that
experience
the
first
time
a
developer
downloads
it
and
starts
playing
with
it
and
clicks
and
says
wow.
I
just
created
an
entire
environment.
I
was
able
to
just
recreate
the
exact
environment
that
my
colleague
has
all
the
dependencies.
Everything
else
has
been
created
between
linux,
macs
and
windows.
A
All
of
that
is
abstracted
away
and
even
though
java
had
sort
of
been
promising
something
similar
for
20
years
of
that
right
once
work
everywhere
in
a
lot
of
ways,
docker
really
did
make
that
work
in
the
developer
environment,
and
so
my
claim
is
that
that
it
actually
resulted
in
the
fastest
uptake
of
a
developer
technology.
A
A
This
just
classic
problem
of
the
new
team
member
comes
on
and
they're
trying
to
get
up
and
running,
and
they
say.
Oh,
I
hit
this
error
and
the
sort
of
bearded
older
developers
says.
Oh,
it's
not
my
problem.
It
works
for
me
as
opposed
to
the
new
developer
comes
in
and
types
one
command
and
the
exact
environment
comes
in,
and
everything's
working
in
a
way
that
is
just
totally
replicatable,
so
those
concepts,
isolation,
reuse,
immutability,
were
incredibly
powerful.
A
The
part
I'll
focus
on,
though,
is
that
docker,
particularly
when
it
launched
particularly
the
first
couple
years,
was
all
around
the
developer
environment.
The
story
about
how
it
gets
into
production
was
kind
of
left
to
be
written,
and
that
really
brings
us
to
today,
which
is
cloud
native
and
so
cloud
native
is
saying
that
containerization
and
by
which
we
really
mean
docker
containers
or
the
standardized
version
of
docker
containers,
that's
occurring
in
our
partner,
our
sister
organization.
A
The
open
container
initiative
is
one
of
the
critical
components
of
that.
That's
number
two
here.
The
other
part
is
this
concept
of
microservices
that
you
no
longer
need
to
have
one
big
monolithic
application
that
you
can
cut
your
application
up
into
different
pieces,
and-
and
I
I
let
me
just
say
a
second
about
this-
which
is
that
kind.
Almost
all
applications
start
out
as
a
monolith.
There's
also
this
sort
of
in-between
term
from
lexis
richardson
microlift.
A
But
the
idea
is,
you
start
writing
an
application,
and
eventually
you
run
in
not
to
a
technology
constraint,
but
a
human
constraint
that
it
becomes
difficult
to
coordinate
your
whole
team
around
adding
features
around
adding
pieces
and
a
certain
part
of
your
team
says
hey
if
we
could
just
cut
off
this
one
piece
of
the
application,
the
credit
card
processing
or
the
auth
piece
or
the
user
login
or
the
batch
files
that
are
producing
the
csvs
at
night,
whatever
it
is,
and
maybe
write
that
piece
in
this
other
language
or
have
it
hooked
into
this
existing
system
or
reuse
this
code
from
somewhere
else,
we
could
actually
move
much
faster
and
so
the
concept
of
microservices
is
that
you
don't
need
to
have
everything
in
the
same
environment.
A
So
this
is
this
is
so
what
are
the
lessons
and
what
are
the
directions
that
we
can
take
from
that
history?
What
have
we
learned?
So?
The
first
piece
is
to
look
at
the
core
building
block.
A
We
started
with
physical
servers
and
then
we
moved
to
vms
to
virtual
machines
and
the
big
difference
there
is
that
each
of
these
vms
had
its
own
version
of
the
operating
system
was
running
its
full
os
and
then
we
went
to
build
packs
which
are
containers
but
are
kind
of
opaque
and
the
developer
has
a
limited
amount
of
control
over
it.
Two
true
containers
these
docker
oci
containers
where
the
developer
can
specify
every
aspect
of
it
control
it
replicate
it
etc.
A
So
the
isolation
union
units
went
from
heavier
to
lighter
weight.
The
spin
up
time
went
from
a
month
of
calling
the
sun
sales
person
and
waiting
for
your
new
rack
of
service
to
arrive
down
to
minutes
for
vms
and
tens
of
seconds
for
build
packs
and
in
containers.
In
many
cases
for
milliseconds,
we
have
this
concept
of
immutability,
where
traditionally
for
most
companies,
their
server
configuration
is
still
a
priesthood.
A
This
concept
that
instead
of
treating
each
server
as
a
pet
that
needs
to
be
carefully
tended
to
that
you
should
treat
it
as
cattle
that
can
be
replicated
in
in
and
dealt
with
in
mass
and
then
also
this
trend
of
providers
where,
through
the
history
of
cloud
in
each
case,
we
started
out
closed
source
from
a
single
vendor
and
we've
moved
to
open
source
cross
vendor
in
a
way
that
has
eliminated
lock-in
given
end
users,
a
ton
of
additional
options.
A
Now
one
of
the
the
natural
follow-ons
from
this
is
what
about
pass
because,
as
I
said,
heroku
that
has
experience
has
been
incredibly
powerful
for
developers
and
one
of
the
interesting
parts
of
the
cloud
native
computing
foundation
is
that
our
platform
itself,
the
software
stack
that
we're
talking
about,
doesn't
actually
have
a
pas
component
to
it.
But
many
of
our
members
are
offering
a
paz
platform
on
top
of
it,
and
so
four
of
them
are
red.
Hat
with
openshift
huawei.
A
On
monday,
with
at
containercon
talked
about
their
container
engine
deus
has
one
called
workflow
and
another
company
aprenda
has
one
that's
been
more
kind
of
windows
focused.
Those
are
all
passes
that
are
built
on
top
of
cloud
native
platforms,
so
they're
using
the
orchestration,
the
containers,
the
microservices
underneath,
but
to
the
developer.
They
provide
a
much
friendlier
front
end
and
the
the
way
that
I
think
about
that
is
that
a
lot
of
applications
start
out
as
12-factor
apps
that
you
can
deploy
in
a
path.
A
I
don't
have
a
a
way
of
proving
this,
but
I
would
estimate
that,
for
most
companies,
more
than
80
of
their
internal
applications
should
be
12-factor
applications
and
should
always
be
that
that
it's
the
best
thing
for
the
developer.
It's
the
best
for
the
company
that
those
guide
rails
are
extremely
helpful
to
basically
enforce
best
practices.
But
in
reality
what
happens
is
that
some
of
those
applications
tend
to
grow
and
mutate
and
morph
in
a
way
that
eventually,
you
do
want
to
cut
off
pieces
of
them
or
to
utilize
services.
That
paz
can't
offer.
A
And
so
one
of
the
powers
of
one
of
the
advantages
of
a
cloud
native
approach
is
that
you
have
a
lot
more
power
underneath
that
you
can
do
a
true
containerized
application
with
microservices
that
you
can
reach
in
and
I'm
still
working
on.
What
my
right
metaphor
here
is
something
like
moving
from
a
tablet
to
a
laptop
or
the
ability
to
soup
up
your
your
sports
car
and
swap
out
the
engine.
A
A
What
are
the
takeaways
from
that
from
that
transition?
Why
are
people
excited
about
cloud
native
today?
Some
of
the
value
propositions,
a
huge
one,
is
isolation,
and
this
really
comes
directly
from
containerization.
I
think
most
folks
are
familiar
with
docker.
Their
logo
is
a
whale,
and
so
I
love
this
whales
of
the
world
slide.
But
the
idea
is
that
when
you
containerize
your
application,
you're
able
to
achieve
dev
prod
parity
to
have
the
identical
environment,
both
on
your
laptop
that
you're
developing
on
and
on
the
server
you
can
have
fat.
A
You
can
code
and
component
reuse
and
it
just
dramatically
simplifies
the
operations.
In
fact,
it's
this
whole
trend
of
devops
to
try
and
eliminate
the
operations
team
and
allow
the
developers
to
be
the
one
who
are
ones
who
are
responsible
for
operations.
As
well,
we
are
trying
to
reduce
or
even
eliminate
lock-in.
A
So
when
you
look
at
containers,
these
are
designed
to
start
and
stop
incredibly
quickly.
This
is
actually
a
two-year-old
estimate
that
google
starts
about
two
billion
containers
per
week
or
3
300
per
second
on
average,
and
the
idea
is
that
a
modern
distributed
system
should
be
able
to
scale
up
to
tens
of
thousands
or
hundreds
of
thousands
of
these
self-healing
multi-tenant
nodes
and
the
kind
of
orchestration
the
kind
of
cloud
native
environment
we're
talking
about
is
very
much
designed
to
deal
with
that
agility
and
maintainability.
This
is
really
what's
the
value
of
microservices.
A
I
love
this
slide.
It's
maybe
not
the
best
illustration
of
microservices,
but
I
have
so
much
respect
for
these
pirates
for
the
amount
of
effort
that
it
must
have
taken
to
get
those
containers
into
those
boats.
But
the
idea
is
that
you
can
split
up
your
app
into
multiple
containers
and
have
each
of
them
communicate
with
each
other
and
one
of
the
one
of
the
neat
parts
of
that
is
that
you're
not
locked
in
if
your
development
environment's
been
in
ruby,
but
you
have
a
certain
aspect
of
it
that
is
now
much
more
performance
sensitive.
A
A
This
is
really
the
concept
of
orchestration,
and
so
here's
our
orchestra
and
the
idea
is
that
when
you
have
these
different
containers,
they're
all
specifying
what
kind
of
services
they
need,
what
their
availability
is,
which
ones
always
need
to
be
up
which
ones
are
working
as
a
batch
job,
which
ones
can
just
make
use
of
available
background.
And
essentially
this
is
going
to
lower
your
cost.
A
So
it's
going
to
allow
you
to
have
extremely
high
uptime,
but
to
pack
many
more
containers
onto
a
smaller
number
of
services,
a
smaller
number
of
servers
and
then
continuing
with
our
container
theme,
resiliency
and
so
a
modern
cloud
native
environment
is
really
needs
to
be
designed
to
deal
with
the
failure
of
individual
containers,
the
failure
of
machines
and
even
the
failure
of
data
centers
so
that
as
demand
is
spiking
or
going
down
that
in
every
environment,
you're
able
to
to
react
to
that,
and
and
do
it
in
a
way
that
maintains
your
uptime.
A
And
this
is
a
horrifying
but
pretty
compelling
shot
of
problems
with
containerization,
but
nobody
was
killed
on
this,
so
you
can
still
admire
the
image.
A
So
now,
let
me
just
give
you
a
quick
perspective
on
cncf.
We
have
two
projects
in
the
foundation
today.
Our
goal
over
the
next
year
is
to
bring
in
another
half
dozen
or
dozen
more
and
when
we
go
to
those
projects,
what
we're
looking
for
are
open
source
software
that
has
an
existing
thriving
community.
That's
solving
a
key
part
of
the
puzzle
of
deploying
cloud
native
applications
and
what's
interesting,
is
that
the
pitch
for
that
is.
Nobody
is
impressed
when
we
can
say.
A
A
So
this
is
a
an
abbreviated
list
of
that,
but
our
argument
for
why
projects
should
come
to
cncf
and
should
want
to
work
with
us.
The
first
is
that
a
neutral
home
increases
contributions,
and
this
is
really
the
biggest
one
by
far
that
when
one
company
controls
a
project
even
when
they
have
committers
from
other
from
other
companies,
it
does
make
new
folks
hesitant
on
contributing
will
there
will
they
be
treated
the
same.
We're
saying
that
a
neutral
home
with
clear
intellectual
property
rules
makes
that
much
easier.
A
We
have
an
incredibly
august
technical
oversight
committee,
folks,
like
solomon
hawks
hikes
of
docker
and
brian
cantrell,
joyant
and
ben
heinrin
of
mesosphere
who's
speaking
later
today,
and
we
require
a
vote
of
that
committee
to
adopt
in
a
new
project.
So
I
don't
actually
control
that
I
can
propose
projects
to
that
group,
but
it's
only
that
group
that
can
actually
adopt
it.
A
We
have
an
end
user
board
that
we're
now
spinning
up
that
we
give
connections
and
engagement
to.
We
have
a
full-time
press
and
an
analyst
relation
team
and,
for
instance,
projects
like
prometheus.
We've
been
very
helpful
on
on
raising
the
awareness
about
them
and
getting
a
lot
more
excitement.
We
give
them
a
little
bit
of
cash
that
they
can
spend,
ideally
with
their
existing
committers
and
existing
contributors
to
improve
their
documentation,
which
is
basically
always
a
hole
in
every
project.
A
We
don't
take
over
the
project.
We
don't
try
and
run
it
for
them.
All
we
require
is
that
they
have
a
neutral
process
of
how
they
bring
on
new
committers,
how
they
take
their
existing
committers
to
emeritus
status,
and
that
needs
to
be
an
unbiased
process.
We
have
a
full-time
staff,
starting
with
me.
That's
there
to
answer
their
emails
and
their
phone
calls
and
help
them
out.
A
We
have
a
world-class
events
team
and
we're
as
I'll
do
a
call
out
in
just
a
second
going
to
be
running
a
big
kubercon
event
in
north
america
in
europe,
in
asia,
in
china,
in
fact
that
we
will
give
them
tracks
at
and
the
opportunity
to
promote
their
work,
we're
doing
a
worldwide
meetup
groups
and
road
shows,
and
then
we
have
a
marketing
demo
that
shows
the
different
technologies
working
together
on
different
public
and
private
clouds.
A
So
I'm
just
going
to
flash
this
slide
up
here.
This
is
very
much
a
prognostication
on
my
part.
It
is
projects
that
have
been
talked
about
by
our
technical
oversight
committee.
Only
they
can
decide
what
goes
in
I'll.
Tell
you
that
a
vote
started
this
morning
on
the
last
one
on
the
list:
core
dns,
which
is
a
evolution
of
sky
dns
and
a
very
popular
back
end.
A
Some
of
them
will
not.
Some
of
them
will
be
swapped
around.
In
some
cases
we
may
bring
in
a
couple
competitive
projects
if
it's
not
clear.
Yet
what
who
the
winner
is?
There's
so
there's
different,
there's
different
parts
of
this,
but
the
idea
is
that
we
are
trying
to
support
individual
projects.
We're
also,
then
trying
to
stitch
them
together
into
a
narrative
about
cloud-native
computing.
A
A
How
can
I
decide
between
them
and
conveniently
they're
the
same
event?
And
so
it's
actually
a
little
bit
like
this
week,
where
we
had
linuxcon
and
containercon,
and
so
it's
gonna
be
something
like
seven
tracks
and
something
like
four
or
five
of
them
will
be
kubernetes
and
one
or
so
of
them
will
be
prometheus
and
then
another
two
will
be
other
kind
of
cloud
native
stuff
of
our
other
projects
and
how
things
plug
together
and
end
user
case
studies
and
that
kind
of
thing.
A
But
this
is
really
the
preeminent
event
for
learning
about
the
space
that
we
very
much
encourage
you
to
participate
and
I'll
also
give
a
quick
call
out.
We
don't
have
a
date
or
a
city
yet,
but
we're
definitely
going
to
be
doing
the
same
combination
of
events
in
europe
in
april
and
then
in
beijing
in
the
third
week
of
june.
A
And
lastly,
please
don't
hesitate
to
reach
out
to
me
via
twitter,
via
email.
We
have
a
decent
amount
of
information
on
our
website.
We
have
a
blog
that
we're
going
to
be
adding
a
lot
of
user
stories
and
other
information,
and
I
really
am
available
to
all
of
you
and
to
your
colleagues
to
to
help
move
this
forward.