►
From YouTube: Open Standards: Anchoring Extensibility for Cloud-Native Tooling - Katie Gamanji, CNCF
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Open Standards: Anchoring Extensibility for Cloud-Native Tooling - Katie Gamanji, CNCF
Within its 7 years of existence, Kubernetes has been the centerpiece of the Cloud Native landscape, elevating a pluggable system that contributed to the diversification of the entire ecosystem. As a result, multiple areas have developed in the industry, galvanizing solutions for components such as runtime, tracing, metrics, service mesh, and many more. However, to accommodate the expanding space of cloud-native tooling, it was necessary to introduce standardization and guidelines to simplify the interoperability and consumption of these tools. This talk will focus on the evolution of open standards and manifestos within the cloud-native landscape, including OCI, OpenTelemetry, Open Service Mesh, Open Application Model, and many more. Attendees will acquire an understanding of why open standards are pivotal in the path towards the extensibility of cloud-native tooling.
A
Hello:
everyone,
my
name,
is
katie
gamanchi
and
currently
I
am
the
ecosystem
advocate
at
cncf.
I
have
joined
this
role
quite
recently,
my
responsibilities
to
lead
the
end
user
community,
while
making
sure
to
close
the
gap
between
the
practitioners
of
cloud
native
and
the
projects
within
the
ecosystem
as
well.
Currently,
I
am
one
of
the
member
of
the
advisory
board
for
captain,
which
is
a
cncf
sandbox
project,
I'm
working
with
openidk
audacity
to
ensure
that
open
standards
are
used
fairly
and
they're
actually
created
across
data
hardware
and
software.
A
I
have
mentioned
the
end
user
community
and
I'd
like
to
give
a
brief
introduction
of
what
it
actually
represents.
The
end
user
community
is
composed
of
more
than
140
vendor
mutual
organizations
across
different
industries
and
sectors.
These
organizations
are
using
cloud
native
technologies
to
build
and
distribute
their
services.
They
are
not
selling
cloud
native
technology.
This
is
quite
an
important
distinction.
A
A
Today,
however,
I
would
like
to
talk
about
open
standards
and,
more
specifically,
how
these
are
anchoring
extensibility
within
the
cloud
native
ecosystem,
and
to
do
so.
I
would
like
to
start
by
talking
about
container
globalization
in
this
section,
I'm
going
to
focus
on
open
container
initiative
and
docker
and
how
these
pretty
much
help
to
have
a
wide
adoption
for
containers
across
the
industry.
A
In
this
particular
section,
I'm
going
to
talk
about
the
container
runtime
interface
network,
interface,
storage,
service,
mesh
interfaces
and
cloud
provider
interfaces
as
well.
I'm
going
to
briefly
talk
about
the
observability
stack
and
the
open
standards
across
metrics
and
traceability,
and
I'm
going
to
talk
about
the
open
standards
within
the
application
delivery
talking
about
cubella
and
crossplane.
A
A
When
we
look
into
the
end
user
community
or
the
practitioner
community,
more
than
41
attendees
were
registered
at
the
coupons
around
the
world
last
year.
Now
this
encapsulates
kubecon
europe
and
north
america,
and
this
flourishing
community
around
kubernetes,
pretty
much
focused
on
extending
its
functionalities
and
this
created.
What
today,
we
know
as
the
cloud
native
landscape,
which
resides
under
the
cncf
umbrella
or
cloud
native
computing
foundation,.
A
However,
the
community
around
kubernetes
was
not
always
as
flourishing,
but,
more
importantly,
it
was
not
always
as
engaging
the
picture
at
the
beginning
was
quite
different.
Nowadays,
kubernetes
is
known
for
its
adaptability
and
flexibility
to
run
containerized
workloads
with
predefined
technical
requirements.
It
will
provision
the
ecosystem
for
application
execution
while
shrinking
its
footprint
in
the
cluster.
A
A
Application
complexity
refers
to
the
fact
that
we
have
a
service
oriented
architecture
where
is
composed
of
multiple
microservices
that
construct
one
bigger
application.
While
this
introduces
simplicity
and
uniformity,
standardization,
it
is
still
a
challenge
on
how
can
we
deploy
and
keep
all
of
these
components
up
to
date
within
the
production
system
as
well?
Fast
deployment
is
an
imperative
nowadays,
the
faster
you
deploy
new
features,
the
more
more
the
more
of
a
competitive
offering
you
have
for
your
customers
and
the
other
challenge
was
environment
uniformity.
A
How
can
the
differences
or
the
delta
between
the
development,
environment
and
the
production
environment
can
be
reduced
or
completely
eliminated,
and
to
solve
all
of
these
challenges?
Docker
actually
had
was
introduced
and
had
a
wide
adoption
within
the
community
docker
pretty
much
packages
and
executes
an
application
in
a
environment
which
is
loosely
isolated,
called
container
with
docker
there.
Of
course,
by
default
are
a
couple
of
advantages.
A
The
first
one
there
is
an
application
environment
defined
as
code
within
the
dockerfile,
we'll
be
able
to
specify
how
the
application
can
be
executed,
but,
more
importantly,
we'll
be
able
to
predefine
all
of
the
dependencies,
and
these
are
going
to
be
consistent
across
all
of
the
environments
as
well.
Docker
simplified
the
testing
process.
A
That
means
that
you
have
a
reproducible
environment
between
your
development
staging
and
production,
and
you
can
have
more
confidence
into
what
exactly
is
going
to
be
deployed
to
every
single
cluster
or
every
single
environment
at
the
time
and,
of
course,
you're
going
to
have
frictionless
deployment.
As
long
as
you
have
the
docker
engine
running
within
the
environment,
you'll
be
able
to
deploy
your
application
with
minimal
effort.
A
However,
the
introduction
of
docker
pretty
much
made
sure
that
containers
are
widely
adopted
within
across
the
industry,
but
there
is
not
only
docker.
We
can
see
that
multiple
initiatives
at
the
time
were
to
diversify
the
ecosystem
of
runtimes
images
and
registries,
and
it
was
clear
that
it's
necessary
to
have
a
set
of
standards
to
make
sure
that
all
of
these
container
solutions
are
compatible
with
each
other,
and
this
prompted
pretty
much
for
the
open
container
initiative
or
oci
to
be
introduced.
A
The
open
container
initiative
is
a
governance
models
which
focuses
on
the
industry
standards
across
container
formats
and
runtimes.
It
was
established
by
docker
in
june
2015
and
out
for
industry
leaders,
and
it
mainly
focuses
on
three
main
core
principles:
composability
decentralization
and
minimalism
composibility.
Pretty
much
focuses
on
the
fact
that
every
single
container
should
be
run
independently,
but
at
the
same
time
should
be
portable
and
executed
securely.
A
And
when
you're
talking
about
the
oci
specifications,
there
are
four
of
them
from
which
two
of
them
are
mostly
mostly
wide
known
and
used.
We
have
the
image
and
the
runtime
specification,
distribution
and
artifacts.
The
image
specification
will
pretty
much
define
how
an
image
for
a
container
should
be
constructed.
It
will
contain
the
image
index
layers,
configuration
files,
any
file
systems
and
so
forth.
A
Runtime
on
the
other
side,
is
a
specification
which
looks
into
how
to
initialize
and
execute
a
container
distribution
focuses
on
how
these
images
can
actually
be
distributed,
and
it's
going
to
be
focused
on
the
construction
of
registries,
pretty
much.
It
will
look
into
operations
how
to
pull
and
push
an
image.
How
to
list
tags
delete
an
image,
and
so
forth
and
artifacts
is
another
specification
which
focuses
on
how
to
distribute
artifacts,
which
are
not
container
file
system,
bundles.
A
Now
this
stage
we
can
see
the
the
open
container
initiative,
pretty
much
introduces
standardization
and
when
it
comes
to
the
adoption
of
containers
on
an
industry
level.
However,
at
the
same
time
had
kubernetes
emerge
within
the
ecosystem
and
it
slowly
but
surely
gained
adoption
from
the
community,
and
it
was
clear
that
it
is
necessary
to
introduce
a
set
of
standards
within
the
cuban
kubernetes
ecosystem
as
well.
A
The
first
notable
one
was
the
runtime
component.
The
runtime
particle
is
pretty
much
the
one
which
intercepts
any
request
from
the
keyplate
and
makes
sure
that
the
containers
are
created
on
the
node,
with
the
right
specification,
and
these
functionalities
at
the
beginning
were
provisioned
by
docker
and
rocket.
A
One
of
the
challenges
to
these
two
runtimes
is
the
fact
that
they
were
their
logic.
Were
they
very
deeply
ingrained
within
the
kubernetes
source
code,
and
this
imposed
quite
a
few
challenges.
The
first
one
was
a
low
rate
for
future
development.
If
you'd
like
to
introduce
new
features
for
these
runtimes,
the
release
process
is
tightly
coupled
with
the
kubernetes
release
process,
which
in
itself
is
quite
lengthy.
A
Another
challenge
is
imposed
for
new
runtimes
if
you'd
like
to
create
a
new
runtime
and
pretty
much
introduce
it
for
kubernetes,
because
the
developers
will
require
a
very
in-depth
knowledge
of
the
kubernetes
source
code.
It
was
clear
that
a
runtime
interface
is
necessary
to
pretty
much
abstract
the
integration
of
runtime
capabilities,
but,
more
importantly,
most
of
these
were
already
using
the
oci
or
open
container
initiative
standards.
A
As
such,
the
cryo
container
runtime
interface
provides
an
abstraction
layer
over
the
integration
of
container
run
times
from
which
docker
and
rocket
would
be
just
some
of
them,
and
when
you
look
currently
into
the
ecosystem,
there
are
plethora
of
tools
provisioning.
These
capabilities
from
which
we
have
tools
such
as
scatter
containers,
cryogeovisor,
container,
dawbs,
firecracker
and
many
more
container
d
here
currently
is
a
graduated
cncf
project
and
is
known
for
its
ability
to
provision
these
ranting
capabilities
as
an
industry.
A
Standard
cryo
as
well,
is
a
lightweight
version
of
a
runtime
and,
of
course,
it's
not
for
its
compliancy,
with
open
container
initiative
standards
as
well.
It's
only
natural
to
make
sure
that
the
containers
can
be
created
on
any
infrastructure,
and
this
means
to
enable
the
cloud
providers
to
use
their
own
apis
and
libraries
to
create
containers
on
their
infrastructure.
A
As
such,
google
comes
with
their
own
runtime
provider,
which
is
going
to
be
called
gvisor,
and
there
is
another
one
which
comes
from
aws,
for
example,
which
is
going
to
be
aws
firecracker
as
well.
During
the
same
time
when
the
runtime
interface
was
introduced,
there
are
a
lot
of
initiatives
to
democratize
the
networking
tooling
around
kubernetes
as
well,
and
this
prompted
for
the
container
network
interface
to
be
prompted,
which
focuses
mainly
on
the
connectivity
of
containers
within
a
cluster
or
within
a
distributed
amount
of
machines
as
well.
A
The
runtime
and
network
interfaces
were
extremely
important
because
they
made
the
adoption
of
containers
with
kubernetes,
more
feasible
and
from
now
on,
the
community
concerns
so
more
and
more
with
how
to
extend
kubernetes
rather
than
choose
and
use
very
specific
tooling,
and
this
can
be
confirmed
by
the
appearance
of
other
interfaces.
Around
storage
service,
mesh
and
cloud
provider.
A
The
csi
or
container
storage
interface
was
introduced
in
kubernetes
1.9
and
it
moved
to
general
availability
in
1.13
pretty
much.
This
interface
focuses
on
how
the
services
within
the
cluster
can
consume
storage
outside
of
the
cluster,
and
here
we
have
again
many
tools,
provisioning,
these
capabilities
and
it's
actually
one
of
the
most
developed
areas
within
the
cloud
native
landscape,
because
more
than
60
providers
are
actively
collaborating
and
integrating
with
csi
from
which
you
have
work.
A
Cef
open
eps,
and
many
more
you
deserve
to
mention
here
that
work
is
a
graduated
cncf
project
and
it's
known
for
its
simplicity
to
dynamically
allocate
storage
for
an
application
as
well.
There
were
a
lot
of
initiatives
to
democratize
the
introduction
of
the
service
mesh
within
the
cluster,
and
this
prompted
this
service
mesh
interface
to
be
about.
A
Currently,
the
smi
integrates
with
tools
such
as
istio
link,
rd
console,
open
service
mesh
and
many
more.
It
is
worth
to
mention
here
that
link
rd
is
an
incubating
cncf
project
and
is
known
for
its
simplicity
to
provision
the
service
capabilities
for
a
cluster
and
the
last
interface
I'd
like
to
talk
about
is
the
cloud
provider
which
is
heavily
used
by
cluster
api.
A
Now
the
perspective
of
interfaces
completely
changed
in
this
case,
because
when
I
talked
about
the
runtime
network
storage
service
mesh
interfaces,
all
of
this
resides
within
the
cluster.
However,
with
a
cloud
provider
interface,
this
takes
the
idea
of
standards
of
verb
for
step.
It
defines
how
the
kubernetes
cluster
can
be
created
across
different
cloud
providers
using
the
same
the
same
standards
or
the
same
manner,
and
currently
this
container
provider
interface
integrates
with
tools
such
as
gcp,
aws,
vsphere
from
vmware
azure
and
many
more.
A
Now
there
are
a
lot
of
initiatives
as
well
to
introduce
open
standards
when
it
comes
to
the
observability
stack
when
you're
talking
about
observability.
Usually
it
encapsulates
how
we
can
simplify
the
instrumentation
while
at
the
same
time
lowering
the
cost
for
data
aggregation,
but
introducing
standards
to
the
formats
and
the
frameworks
to
ensure
the
visibility
across
the
stack
pretty
much.
A
This
is
for
this
is
going
to
be
focused
on
how
we
collect
data
points
from
our
application
to
ensure
that
we
have
the
transparency
of
what
happens
within
the
systems,
and
this
is
translated
by
collecting
metrics
events.
Logs
and
traces
metrics
are
locals
to
collect,
but
they
are
the
most
efficient
to
diagnose
and
verify
or
to
define
actually
the
state
of
an
application
events.
They
are
collected
from
the
application
to
provide
these
data
data
points
or
historical
data
points
of
when
exactly
an
action
happened
within
the
system.
A
However,
events
are
supposed
to
be
high
abstraction
level
just
to
indicate
that
something
either
has
happened
or
something
went
wrong
for
an
actual
debugging
process.
Logs
are
necessary,
which
is
present
high
fidelity
data,
and
the
engineering
team
will
be
able
to
recreate
step
by
step.
What
exactly
are
the
functions
called
within
the
system
and
traces
are
necessary,
especially
nowadays
in
a
service
oriented
architecture
where
to
solve
one
request
or
to
serve
one
request
at
the
there's
necessary
to
trace
or
to
invoke
multiple
microservices.
A
A
However,
this
merged
in
2019,
with
open,
telemetry
and
upload
telemetry,
now
is
focused
on
how
we
can
identify
gather,
collect
traces
logs
metrics
around
an
application
to
make
sure
that
we
can
have
an
indicator
of
the
performance
and
the
behaviors
of
the
system
and,
in
addition
to
observability
stack,
there
were
initiatives
to
introduce
standards
within
the
application
delivery.
Now
this
pretty
much
focuses
on
how
an
application
can
be
deployed,
but
at
the
same
time,
how
can
we
enrich
the
overall
developer
experience
and
these
initiatives
have
been
crowned
by
tools
such
as
cubella
and
crossplane?
A
That
means
that
if,
as
a
developer
would
like
to
deploy
using
kimvela,
you
don't
need
to
be
aware
of
the
resources
behind
kubernetes
such
as
deployment
services,
ingress
and
so
forth.
You
will
just
be
able
to
provision
a
configuration
file
just
specifying
what
functionalities
or
what
variables
you'd
like
for
your
application,
and
this
is
going
to
pretty
much
deploy
your
application
in
the
background
as
well.
A
Now
we
have
seen
a
lot
of
initiatives
to
introduce
these
open
standards
and
interfaces
amongst
the
cloud
native
ecosystem
and
as
a
result,
that
means
that
the
cloud
native
ecosystem
transmursified
its
identity
multiple
times
and
this
overall
has
been
possible
because
kubernetes
overall
is
not
opinionated.
Of
course,
it's
going
to
be
opinionated
when
it
comes
to
the
networking
model,
for
example,
has
indicated
that
every
single
container
should
have
an
ip.
However,
it's
not
going
to
be
assertive
when
it
comes
to
the
underlying
amount
of
tooling
that
you're
going
to
run
carrying
this.
A
On
top
of
what
kind
of
plugins
you
can
introduce
to
ensure
a
functional
cluster,
and
this
had
a
huge
impact
when
looking
into
the
perspective,
it
had
a
huge
impact
on
the
vendors
and
users
and
the
community
when
you're
looking
into
the
vendor
community.
The
introduction
of
open
standards
and
interfaces
means
innovation
as
a
vendor.
You
don't
have
to
concern
yourself
how
to
integrate
your
services
within
kubernetes.
Usually
these
standards
and
the
interface
is
already
going
to
be
there
as
such
as
a
vendor.
A
You
can
focus
on
how
to
deliver
customer
value
with
minimal
latency
when
you're.
Looking
into
the
end
user
community,
the
emergence
of
open
standards
and
interfaces
means
extensibility.
It
was
never
as
easy
as
it
is
today
to
benchmark
different
tools
with
the
same
capability
as
an
end
user.
You
have
the
leverage
to
further
empower
or
create
or
focus
on
your
product
and
choose
the
right
tool
for
your
problem
when
looking
into
the
community.
A
The
emergence
of
interfaces
and
open
standards
means
interoperability,
because
we've
created
this
canvas
of
different
tooling,
where
multiple
solutions
for
the
same
problem
is
actually
embraced,
and
this
has
been
extremely
beneficial
for
kubernetes,
because
over
time
multiple
tools
were
built
around
it
to
extend
its
functionalities,
and
this
created.
What?
Today,
we
know
as
the
cloud
native
landscape,
and
this
has
been
possible,
because
the
open
standards
and
interfaces
are
the
central
engine
for
innovation
that
anchors
extensibility
but,
more
importantly,
it's
an
ecosystem
that
embraces
contrasting
solutions
for
the
same
problem.
A
If
you'd
like
to
find
out
more
about
today's
talk,
please
visit
my
medium
account.
I'm
going
to
have
an
article
written
about
this
book
in
a
bit
more
detail,
so
I'm
going
to
find
more
resources
and
if
you
have
any
more
questions,
I'm
going
to
be,
of
course
available
on
social
media
such
as
twitter
and
linkedin
enjoy
the
rest
of
the
conference.
Thank
you.