►
From YouTube: Webinar: GitOps, DSL & App Model - Getting Started Building Developer Centric Kubernetes
Description
As platform builders, we are puzzled by how to use Kubernetes to serve our end users (application developers and operators) properly. In this webinar, we will talk about the lessons learned from serving end users in the broader cloud native community, specifically:
1. Why are end users not satisfied in Kubernetes?
2. Is PaaS the right answer?
3. What is “developer centric” Kubernetes?
4. How can we build it? Anything is missing in the picture?
5. Is GitOps and DSL part of the story? What about OAM?
Speaker:
Lei Zhang, Staff Engineer @Alibaba
A
Go
ahead
yeah,
so
I
will
take
over
from
here.
Okay!
Thank
you
very
much
so
yeah.
So
my
name
is
lee
john.
You
can
call
me
hari
from
alibaba,
I'm
of
course
a
cncf
investor,
and
today
I
will
talk
a
little
bit
about
the
several
things
in
kubernetes
community
like
github's,
dsl
or
configure
configuration
data,
language
and,
of
course,
application
model.
A
So
what
do
I
build?
I'm
responsible
for
building
virus
of
platforms
on
top
of
kubernetes
to
serve
my
users,
who
are
mostly
application
developers
and
operators
in
my
company
they
come.
They
come
from
different
business
units.
They
actually
serve
their
own
customers.
I
mean
the
customer
for
alibaba
director
and
we
serve
them.
A
A
So
will
we
hope
so
actually,
but
the
reality
is
not
and
the
reason
we
need.
Such
platforms
is
because
we
need
them
to
feel
the
gap
between
users,
expectations
and
what
kubernetes
provides,
for
example,
first
of
all
the
api
and
primitives
what
other
users
focus
on
our
code
applications
and
ci
cd
pipelines?
A
The
second
issue
is
the
levels
of
abstraction,
for
example,
for
application
operators
in
over
organization.
They
are
working
on
policies
like
how
to
do
auto
scaling.
They
will
define
strategy
like
this
and
for
another
example:
how
to
do
automatic
rollouts.
A
They
also
device
challenges
to
describe
what
what
kind
of
a
rogue
strategy
I
want
to
use.
That
is
a
job
for
our
application
operators,
but
whatever
kubernetes
provided
to
them,
however,
are,
for
example,
kubernetes
service,
ingress,
permissive,
api
and
easter
virtual
service,
like
that,
so
as
kubernetes
expert
like
us,
I
mean
for
me,
it's
straightforward
to
assemble
the
concept
into
something
like
a
raw
strategy
or
other
scanning
policy,
but
these
primitives,
however,
really
don't
make
any
sense
from
our
application
operator's
perspective.
They
don't
even
know
what
it
permissives
or
is
still
so.
A
The
last
issue,
which
is
actually
the
worst
one,
is
the
user
interface
from
builders.
We
think
kubernetes,
declarative
api
is
very
powerful
and
extensible.
It's
perfect,
but
our
end
users,
I
mean
developers
and
operators,
definitely
don't
agree
with
that.
They
want
to
work
with
human
readable
interfaces
like
dashboard,
like
command
line
tool
or
infrastructure.
As
code
writing,
kubernetes
yaml
files,
which
is
over
normal
life,
however,
for
them
is
more
like
writing.
Assembly
language
from
developers
perspective,
and
no
one
wants
to
do
that.
Actually,.
A
And
at
the
same
time,
we
gradually
notice
that
building
such
kind
of
platform
is
not
a
silver
bullet,
because
the
biggest
problem
is
that
in
order
to
solve
over
users
better
in
order
to
bring
them
this
easier
user
experience,
you
tend
to
define
overall
platform
level
api.
A
But
on
the
other
hand,
this
kind
of
api
will
actually
hide
the
extensibility
of
kubernetes
because
we
basically
lose
the
kubernetes
accessibility
here,
because
other
users,
in
that
case,
can't
access
directly
to
kubernetes.
So
they
can't
enjoy
the
unlimited
capabilities
provided
by
kubernetes
ecosystem.
For
example,
microsoft
just
released
the
open
service
mesh
correct,
but
it
will
need
a
very
long
time
for
over
platform
to
support
it,
because
our
platform
doesn't
have
such
hdmi
api.
A
A
So
can
we
try
to
make
kubernetes
itself
more
easier
to
use?
I
mean
build
something
like
a
developer.
Focused
kubernetes,
I
need
to
say
what
we
want
to
build
is
a
kubernetes
that
speaks
higher
level,
epi
provide
abstractions,
which
is
user,
friendly
and,
of
course,
still
keep
highly
extensible.
So
it's
essentially
another
form,
or
you
can
say
the
distribution
of
kubernetes.
A
So
let's
look
at
the
higher
level
api.
At
start,
it's
essentially
about
building
user,
facing
objections
for
your
workloads
and
your
operational
capabilities
like
rollout,
auto
scaling
and
monitoring
right.
There
are
various
efforts
in
the
community
that
could
provide
such
kind
of
higher
level
abstractions
on
top
of
kubernetes,
for
example,
key
native
and
the
ranger
rail.
A
A
We
can
easily
find
out
that
the
higher
level
the
attraction
is,
for
example,
like
heroku
the
lower
learning
curve.
It
is
that's
why,
even
today,
everybody
is
still
talking
about
the
experience
of
hair
is
the
best
right
and
we
need
to
bring
this
kind
of
experience
to
kubernetes
to
everywhere
or
everybody's
talking
about
talking,
like
that.
A
But
on
the
other
hand,
you
will
notice
that
it
actually
leaks
a
lot
of
kubernetes
details
or
infrastructural
details
to
end
users,
for
example,
sacred
conflict
map.
You
need
to
care
about
the
workload
you
need
to
think
about
how
to
do
manually.
Traffic
split
you
need
to
manually.
A
Look
that
we're
not
talking
about
chlorine
here,
chlorine
actually
have
much
higher
level
abstraction
than
kinetic
native
is
more
like
foundation
below
that.
So,
of
course,
when
it
comes
to
kubernetes
itself,
there
are
already
many
complaints
about
a
super
high
learning
curve.
Right,
I
will
say
it's
actually
natural
it's
by
design,
because
kubernetes
is
a
platform
for
platform.
A
Let's
still
take
these
four
projects
here
for
heroku.
The
only
way
you
for
you
to
extend
this
this
this
product
is
building
heracles
atoms
by
floating
tons
of
restrictions
and
conventions
defined
by
heroic
itself.
It's
essentially
a
closed
system
right,
so
it
can
barely
leverage
in
open
source
community.
I
mean
the
kubernetes
community
or
even
wider
community,
because
it's
essentially
vendor-locking,
and
that
is
a
big
concern
for
the
open
source
world
and
for
rental
rail.
In
same
case,
there
are
no
even
straightforward
approach
to
support
more
workloads
or
capabilities
in
rail.
It's
really
hard.
A
Unless
you
modify
the
code
refactoring
project,
I
think
it's
also
body
that,
because
real
is
a
lightweight
weapon
on
top
of
kubernetes,
so
if
you
give
it
more
flexibility
to
the
users,
it
will
essentially
break
its
model
and
leave
the
attraction
for
kinetic.
However,
you
basically
have
more
room
to
do
customization.
For
example,
it
provides
you
with
several
extension
points
by
design,
and
you
can
also
write
your
own
crdd
controller
to
extend
the
kinetic
as
long
as
you
don't
break
its
fundamental
model.
That
is
how
it
works,
of
course,
for
kubernetes
itself.
A
A
And
another
drawback
of
building
attraction
is,
if
you
want
to
do
that
on
server
side,
I
mean
you
want
to
build
objections
inside
kubernetes
by
exposing
crds
to
a
user.
You
really
need
to
put
a
lot
of
engineering
efforts
in
this
space.
The
reason
is
that
abstraction
actually
has
many
forms.
For
example,
you
may
want
to
combine
a
deployment
at
a
service
into
one
abstraction,
which
name,
for
example,
web
service
right,
so
it
will
expose
a
external
port
by
that
that
is
one
kind
of
attraction.
A
We
can
call
that
composition
or
you
may
want
to
split,
for
example,
argo
route
into
two
simple
object,
which
name
is
workload
and
a
route,
so
you
can
do
separate
concerns
here
and
let
different
persona.
For
example,
developer
will
take
care
of
the
workload
and
the
operator
will
take
care
of
the
route
strategy,
so
they
will
have
different
objects
and
different
apis.
It's
separate
concerns.
A
Sometimes
you
want
to
do
that
and
we
can
call
that
decomposition
and
there
are
also
some
cases
that
you
want
to
transform,
for
example,
deployment
into
a
read-only
and
a
simplified
version
which
limited,
for
example,
kinetic
relation.
That
is
how
they
decide
today.
You
want
to
do
transformation,
it's
also
another
kind
of
abstraction.
A
So
all
of
these
efforts-
even
the
simplest
abstraction,
for
example,
transformation-
will
require
you
to
define
crd
and
implement
controller,
problematic
server
side.
You
also,
you
also
need
to
think
about
the
interoperability
with
other
systems
without
other
objects.
It's
complicated,
but
you
raise
the
bar
very
high
for
you
to
build
abstraction,
not
to
mention
the
extra
burden
to
maintain
these
controllers
and
crds.
You
are
basically
creating
another
kinetic
think
about
that.
A
So,
basically,
the
difficulty
of
building
attractions
is
there
and,
besides
that,
we
also
notice
some
other
issues
like
building
attractions
will
actually
create
more
silos
in
your
system
or
in
your
organization.
This
is
because,
as
a
big
company
like
alibaba,
like
microsoft,
like
google,
they're,
cramming
from
over
users
from
our
developers
are
highly
diverse.
For
example,
some
applications
in
our
organization
are
stable
workouts,
so
we
need
to
build
them
in
stable
application
platform
with
manual
scaling
policy
with
canary
road
strategies.
A
However,
there
are
also
many
applications
are
stateless.
They
use
deployment,
for
example,
at
workload
and
b
works
flagger
to
do
route,
for
example,
and
hpa
for
auto
scaling
right,
and
there
are
also
even
some
other
applications.
They
just
prefer
to
go
to
service
style,
so
we
have
to
use
keynetive
to
serve
them,
see
also
all
of
these
platforms.
They
have
unique
requirements.
A
They
also
share
a
lot
in
common,
for
example,
all
of
these
platform
platforms
may
require
the
service
like
let's
encrypt
right,
but
at
platform
builders.
We
have
to
implement
this
functionality
in
different
forms
again
and
again,
because
every
platform
here
speaks
different
api,
so
essentially
we're
creating
more
fragmentations
by
because
we
need
to
provide
different
attractions
to
our
developers,
we're
creating
more
silos
and
a
more
closed
ecosystem
and
waste
a
lot
of
the
engineers
time
here
that
don't
feel
good.
A
So
I
think
we
all
agree
that
we
want
to
build
developer-centric
kubernetes
now
right.
We
want
to
provide
them
abstractions,
but
obviously
the
re.
The
the
point
is
how,
in
the
rest
of
the
talk,
I
will
try
to
introduce
some
useful
tools
that
can
help
you
to
build
such
kind
of
attractions
and
to
build
such
kind
of
kubernetes,
which
is
any
user
face,
maybe
can
be
some
maybe
can
create
more
possibilities
for
us
to
do
this
thing
better.
A
So
actually,
if
you
revisit
these
three
patterns
of
x
actions,
I
mentioned
before,
you
could
find
out
that
abstraction
is
basically
about
data
manipulation,
no
matter
it's
decomposition,
composition
or
transformation.
That's
why
building
objection
should
be
easily.
I
mean
you
should
be
handled
by
some
dsl
or
dcl.
This
kind
of
data
configuration
language
way
easier
than
writing
crd
and
the
controllers,
because
dsl
happens
on
clyster.
A
There
is
minimal
maintenance
effort
for
them
right.
For
example,
I
will
highlight
this
q
here
the
q
language
here
q
is
just
perfect
for
you
to
define
traction
for
configuration,
data
and
queue.
Don't
want
to
want.
You
to
learn
any
programming
language,
they
don't
q.
Don't
want
you
to
write
a
program
to
define
abstraction.
You
don't
need
to
do
that.
You
don't
need
to
write
python
code
or
typescript
code.
You
don't
need
to
do
that.
A
A
You
can
define
types
or
schema
for
a
data,
that's
how
you
define
traction
section.
This
is
the
main
difference
between
q
and
other
ds
cells
like,
for
example,
cd
kubernetes
from
ocd
from
aws,
because
cdk
will
require
you
to
write
program
and
they
encourage
you
to
write
your
program
to
define
attraction.
But
q
cannot
work
like
that.
Q
itself
is
a
configuration
language.
A
The
only
difference
is
q
allows
you
to
define
schema
alongside
real
data
and
besides
q
device
and
estimation
q
defines
schema
value,
inconsistent
grammar,
so
you
will
find
its
schema
and
your
and
your
data,
you
define
the
follow.
The
same
pattern
here,
so
it's
basically
like
every
time
you
play
with
q,
you
will
provide
two
things.
The
first
is
schema.
Second,
is
your
data
and
they
all
looks
like
a
json.
That's
all.
A
So
it's
very
easy
to
learn,
although
its
documentation
are
very
good,
I
admit,
but
if
you
look
at
it
in
detail,
it's
very
actually
familiar
with
json
language,
available,
schema
and
four
for
its
data.
So
you
just
defile
schema
and
then
define
data,
and
then
you
can
use
that
to
define
any
kind
of
objection
you
want.
That's
all
so
for
users
they
can
just
interact
with
the
abstraction
data.
That's
why
you
can
actually
build
your
platform.
A
User
interface
based
on
this
abstraction
and
the
client-side
attraction
will
handle
the
transformation
from
q
to
the
real
raw
kubernetes
data
like
deployment,
but
for
user
they'll
need
to
define
three
fields
in
this
case
in
this
example
yeah.
So
this
is,
I
think,
a
either
way
or
a
better
way
to
define
a
track
instead
of
define
a
bunch
of
crd
controller,
your
kubernetes
cluster.
A
A
second
tool,
is
how
we
actually
introduce
a
standard,
hylo
api
to
users,
and
in
this
section
I
will
introduce
open
application
model,
which
is
the
project
I
personally
also
involved
together
with
microsoft.
A
The
core
idea
of
ohm
is
it
enable
you
to
find
application-centric
primitives,
which
are
enforced
by
own
specification
and
that's
how
you
break
the
silos
animation,
because
oil
platform
now
will
speak
same
and
standard
api,
for
example.
My
first
platform
in
this
example
is
designed
to
run
stable
workloads,
so
it
will
expose
a
own
object
to
user,
which
named
application
configuration
and
in
that
application
configuration
it
claims
to
deploy,
for
example,
postgresql
operator,
it's
a
stay
for
workload,
and
it
also
defines
that
manual
scaling
policy
will
be
applied
to
this
postgresql
operator.
A
So
we
call
that
shade.
So
your
workload
and
shade
are
all
contents
in
your
application
configuration
on
the
other
hand.
The
second
platform
here,
which
you
desire
to
run
steadily,
is
stateless
workload.
It
will
also
expose
a
similar
application
configuration.
The
only
difference
here
is
that
its
workload
will
be
changed
to
kubernetes
deployment
and
its
shades
will
be
changed
to
kubernetes
hpi
hpa,
horizontal
port,
auto
scanner.
So
you
can
see
difference
here.
Those
two
platforms
expose
similar
epi
structure.
A
The
only
difference
is
what
kind
of
workload
or
what
kind
of
shade
it
provides
to
users,
and
similar
pattern
also
applies
to
the
third
platform
which
deploy
connective
service,
so
it
will
claim
creative
service
and
workload
and
use
kinetic
autoscaler
as
a
trade
to
scale
the
container
see,
although
the
different
characteristics
in
detail.
These
three
platforms
expose
a
unified
api
to
end
users.
A
Such
experience
or
consistency
is
the
key
to
break
silos
in
over
organization,
and
due
to
now,
they
share
the
same
application
model.
All
these
platforms
can
now
share
a
common
pool
of
capabilities
and
the
platform
builders
can
just
pick
what
they
want
to
assemble
them
into
their
own
platforms.
Api.
It's
just
the
easy
and
neat
and
all
of
these
capabilities.
They
are
kubernetes,
crdm
operators
or
building
kubernetes
apis,
nothing
special.
We
don't
need
to
reinvent
any
rail
here,
and
the
last
tool
I
want
to
highlight
is
githubs.
A
It's
basically,
in
my
opinion,
the
modern
way
to
build
a
modulized
cd
system,
continuous
delivery
system
in
kubernetes.
Today,
the
model
application
delivery
actually
starts
from
developer,
writing
code
and
trigger
continuous
integration
process.
By
pushing
code
to
github,
for
example,
then
the
ci
system
will
generate
dark
images
and
the
artifacts
of
your
application
and
for
development
I
mean
for
deployment
for
the
these
artifacts.
A
For
this
image
we
will
write
kubernetes
example,
files
to
define
workload
and
operational
configuration
field
application,
for
example,
the
workload
could
be
deployment
and
the
operational
capability
could
be
route
strategy
or
scaling
policy
right
and
those
yama
files
normally
stored
in
git
alongside
a
video
application,
so
it
will
trigger
github's
workflow
for
every
change
it
fails.
For
example,
I
changed
the
route
throughout
the
strategy
and
when
this
changes
reach
to
kubernetes,
the
controller
like
rod
controller,
will
respond
and
perform
the
corresponding
application
delivery
functionality.
A
So
everything
will
work
smoothly
inside
kubernetes
and
this
github
application
delivery,
workflow
with
kubernetes
and
the
controller
pattern
of
this
car
and
it's
hard,
it's
very
different
from
the
traditional
csd
pipeline,
and
the
key
point
here
is
this
system
you
can
see
here
is
highly
modular
modular
modularized,
because
every
everything
talking
with
it
at
the
standard
interface
and
the
logics
are
just
a
stable
controllers
and
crt
inside
equipment.
You
can
replace
them
as
at
your
wheel
right
and
this
kind
of
system
is
very
easy
to
be
integrated
with
any
other
system
or
any
other.
A
A
Okay,
so
let's
try
to
put
them
all
together.
So
now
we
talk
about,
we
use
q
for
build
abstraction,
and
then
we
use
om
to
organize
your
abstraction,
which
we
named
it
as
application
model,
and
we
will
also
use
the
give.
We
will
git
ops
for
continuous
delivery,
so
it
seems
like
the
delay
percentage
is
coming
up.
A
Okay,
let's
see
what's
the
whole
picture
looks
like
so.
First
of
all,
in
this
posing
is
proof
of
concept.
I
mean
my
version
of
developer.
Centric
kubernetes
is
based
on
github's
workflow,
but
this
time
what
we
stored
in
git
is
not
a
kubernetes
yaml
file.
It's
too
complicated
for
over
end
users.
Instead,
we
can
define
something
which
is
super
user
friendly.
We
call
that
application
file
or
application
yaml,
and
this
yama
file
is
based
on
q,
language
schema
and
this
structure
is
actually
complete
or
enforced
by
own
specification.
A
So
in
this
example,
for
I
just
give
a
very
simple
instance
here,
it's
a
my
application
and
it's
one
component,
a
component
in
the
concept
of
ohm
and
the
workload
for
this
component
is
deployment
right
and
the
fields
you
you
put
here
is
actually
abstraction
defined
by
q,
language
or
by
q
schema.
So
you
can
define
image,
you
can
define
environment,
that's
that
that
is
only
concerns
me
exposed
to
our
users.
Of
course,
we
can
change
the
queue
schema
at
any
time.
A
Then
our
users
can
fill
more
fields,
and
in
this
section
that
is
the
power
of
client
side
abstraction,
you
don't
need
to
write
controllers.
You
don't
need
to
refactor
your
code
or
redeploy
your
platform.
You
don't
need
to
do
that,
because
everything
here
is
client-side
and
also
it
has
a
bunch
of
chase,
including
auto-scaling
and
draw-outs
exposed.
They
are
all
crds
over
kubernetes
installed
and
again.
The
fields
user
needs
to
build
is
are
still
defined
by
q.
Schema.
That's
why
this
yama
file
can
be
super.
A
Simple
can
be
super
developer,
focused
or
developers
intrigued,
that's
the
key
and
any
change.
Only
yama
file
will
trigger
the
gdos
tools,
such
as
flux
or
argo
cd,
to
apply
the
changes
to
kubernetes,
and
in
that
case
the
kubernetes.
The
the
own
plugin
for
kubernetes
will
then
abstract
the
information
from
the
structure
and
use
the
cube
to
generate
the
real
kubernetes
api
resource
and
those
each
kubernetes
epi
resource
will
drive
the
controllers,
for
example,
router
controller
or
scaling
controllers
work.
A
That
in
client
side,
for
example,
if
I
want
to
enable
open
service
mesh
based,
for
example,
I
want
to
enable
traffic
speed
based
on
open
service
mesh
right
in
this
platform,
I
just
need
to
install
open
source
image
in
kubernetes,
and
then
I
will
use
q
to
define
a
abstraction
for
smi
traffic's
vcrd,
and
then
I
will
define
it
as
a
shade
in
my
demo
file
because
it's
followed
on
specifications,
so
I
can
define
shape
and
real.
I
can
add
more
chat
here,
so
everything
will
work
you
can
see
here.
A
The
only
thing
I
need
to
do
is
install
the
capability
installed
operator
and
define
abstraction
by
using
q,
which
is
minimal
effort,
and
then
I
can
use
own
structure
to
define
the
application
of
file
here.
So
no
single
line
of
code
is
needed
essentially
right.
That
is
what
I
mentioned
about
how
to
build
a
easier
abstraction
which
is
extensible,
so
we
can
build
a
developer,
centric
kubernetes
in
that
case,
okay.
A
So
this
is
just
a
proof
of
concept
and
if
enabled
anybody
interested
in
that
part,
I'm
very
happy
to
collaborate
with
you
to
work
on
work
on
that
in
open
source
community,
of
course-
and
it
was
still
missing
here
if
you
want
to
move
that
kind
of
thing
to
a
real
world
solution.
So
I
think
the
most
important
part
is
that
today
we
are,
we
basically
don't
have
the
add-on
system
to
build
platform,
for
example,
for
example,
how
we
register
and
discover
kubernetes
api
or
crd
as
a
workload
or
trade.
A
So
we
basically
have
a
lot
of
crds
in
our
kubernetes
cluster,
so
which
crd
is
a
one.
I
want
to
define
in
my
application
and
part
of
my
application,
for
example,
rollout,
auto
scaling
or
install
virtual
service.
We
need
to
have
a
way
to
register
them
and
discover
them,
and
what's
more
important
is,
can
we
just
automatically
install
missing
controllers
by
giving
crds
it
will
actually
make
our
platform
more
powerful
and
extend
and
extensible
in
that
case.
So
this
is
first
first
first
issue:
I
don't
have
a
solution
for
now.
A
We
can,
I
think
we
can
leverage
a
helm
to
do
to
do
that
if,
if
helm
can
handle
the
dependency
and
technical
management
as
expected,
a
stakeholder
thing
is
a
modular
command
line,
tool
or
dashboard,
because
you
can
see
here,
we
emphasize
extensibility
very
well,
you
can
add
more
workload.
You
can
add
more
chat
to
this
platform
right.
A
This
kind
of
thing
will,
if,
if
that
can
be
implemented,
this
actually
can
improve
the
experience
or
developers
at
a
new
stage,
because
it's
commodity
dashboard
become
extensible,
and
the
last
thing
is
what
will
be
a
developer.
Centric
pipeline
looks
like
I
I'm
looking
at
the
tecton,
but
tecton
itself
is
still
very
low
level.
If
you
look
at
its
primitives,
but
that
remind
us
actually,
okay,
you
can.
A
You
should
have
a
way
to
build
something
with
tekton
right
to
leverage
detection
capability
to
build
something
like
a
developer
facing
pipeline,
and
you
can
deploy
the
pipeline
into
this
kind
of
platform
at
ease.
You
can
also
leverage
githubs
to
do
that,
so
I
think
this
is
also
another
field
that
we
want
to
put
some
effort
to
looking
at
well.
So
this
is
the
rest
of
things
I'm
also
thinking
of
again.
All
of
these
efforts
are
early
stage,
community
effort,
and
I
I
already
noticed
there's
something
already
happened.
A
Something
is
still
missing,
so
I
will
be
very
happy
to
talk
with
anyone
and
share
the
ideas
regarding
to
building
such
kind
of
developer.
Centric
coordinates
so
basically
hope
you
enjoy
the
journey
of
building
dual
purposing
audio
developer,
centric
kubernetes,
okay.
So
this
is
end
of
my
station
and
thank
you
very
much
for
attending
okay.
B
Thank
you
lee
for
a
great
presentation.
Do
we
have
any
questions
at.
B
B
A
Yes,
yes,
so
service
container
is
actually
a
concept
bring
up
by,
for
example,
kinetic
even
the
chlorine,
so
we
can
think
of
that.
A
We
all
know
about
it,
so
that
is
the
service
container,
and
so
I'm
basically
talking
about
chlorine,
fargate,
microsoft,
either
eci
and
it's
open
source
version
and,
of
course,
creative
and
but
kinetic
only
provide
actually
part
of
that.
For
example,
you
can't,
I
don't
think
you
can
do
you
can
do
pen,
you
go
pricing
with
kinetic,
but
you
can
build
on
top
of
that.
So
this
is
the
service
container.
I'm
talking
about
it's.
The
epi,
which
can
native
and
color
run
the
target
provide
to
its
end
users
right.
B
B
That
problem,
thank
you
again
lee
for
a
wonderful
presentation.
Thank
you
all
for
joining
us
today.
The
webinar,
recording
and
slides
will
be
on
the
website.
Later
today,
at
cncf
dot,
io,
slash
webinars.
We
look
forward
to
seeing
you
again
in
a
future
cncf
webinar.
Thank
you
again
for
participating
have
a
wonderful
day.
Everyone.