►
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.
Panel: Bringing The Cloud To Kubernetes - Matthew Christopher, Microsoft, Dan Mangum, Upbound, Joyce Ma, Google and Jay Pipes, AWS, Moderated by: Nic Cope, Upbound
Organisations are increasingly realising that the Kubernetes approach to infrastructure orchestration can be applied to much more than just containers. Each of the major cloud providers are working on projects that use the Kubernetes Resource Model (KRM) to model their APIs. Similarly, Crossplane aims to model all cloud APIs (and more!) using a superset of the KRM that we think of as the Crossplane Resource Model (or XRM). In this session engineers from the Amazon Controllers for Kubernetes (ACK), Azure Service Operator (ASO), Google Config Connector, and Crossplane projects will discuss the common challenges of building a consistent experience atop a myriad of heterogeneous cloud APIs.
A
So
today,
we've
got
a
panel
assembled
of
folks
who
are
experts
in
taking
cloud
apis
and
modeling
them
as
as
kubernetes
customer
resources.
I'm
not
sure
what
we'll
talk
about
later.
I'm
not
sure
if
there's
a
consistent
name
for
what
that
problem
or
the
software
that
does.
That
is
that's
that's
the
interesting
thing
in
and
of
itself.
So
first,
I
just
want
to
introduce
everyone
that
we
have
on
the
call
here.
A
B
A
C
Yeah,
at
least
you
know
internally
in
my
team,
we
talk
about
this
as
sort
of
yeah
like
a
cloud
operator
or
like
an
azure
operator
for
the
cloud.
You
know
something
like
that.
We
tend
to
prefer
the
the
operator
nomenclature,
as
opposed
to.
I
don't
know
something
else
like
a
plug-in
or
add-on
or
something,
but
I
I
think,
you're
right
that
I
haven't
heard
a
a
industry
accepted
term
for
for
what
this
thing
is.
A
C
A
D
Well,
a
I'm
terrible
at
naming
things
just
generally,
I'm
like
super
flat
and
explicit
about
everything
so
yeah.
These
are
a
bunch
of
controllers
that
do
aws
stuff
on
kubernetes,
so
it
was
aws
controllers
for
kubernetes
yeah.
I
I
actually
like
config
connector
as
like
the
the
the
the
brand
or
like
you
know,
because
that's
what
it
is
right.
These
are
connector
pieces
between
the
kubernetes,
api
and
resource
model
and
the
cloud
providers
apis.
D
So
it's
like
connecting
the
configuration
that's
stored
in
kubernetes
with
the
cloud,
so
I
kind
of
I
kind
of
like
that,
but
yeah
operator
was
these.
Are
these
are
more
than
just
an
operator
right,
like
the
connection
of
a
crd
and
a
custom
controller,
they
are
specific
types
of
controllers
that
provide
that
sort
of
integration,
bridge
right
between
kubernetes
land
and
the
cloud
provider
land.
So
I,
like
the
connector
part
of
things.
A
Yeah
me
too,
which
which
brings
me
to
I,
I
think,
I'm
a
little
hazy
on
the
timeline,
but
I
think
config
connector
was
one
of
the
the
first
projects
out
there
doing
doing
this
kind
of
thing.
Joyce.
Do
you
have
any
background
on
sort
of
what
inspired
the
gcp
team,
the
google
cloud
team
to
start
config
connector?
What
was
the?
What
was
the
background
behind
that
project
being
bootstrapped.
E
So
in
that
sense,
imperative
apis
is
naturally
limited,
providing
this
consistent
user
experience
and
we
started
looking
at
this
declarative
world
and
at
that
time
it
was
back
in
2018.
There
were
like
already
deployment
manager
in
goog
in
gcp
that
supported
declarative
configuration
of
the
apis,
and
also
there
were
like
terraform
google
provider.
E
Those
are
good
toolings,
but
both
of
them
has
its
own
shortcomings.
And
meanwhile
we
see
that
there
are
already
customers
moving
to
the
kubernetes
platform.
So
we
think
it's
better
to
provide
a
more
consistent
user
experience,
so
they
can
manage
their
applications
not
only
for
cloud
but
also
for
other
native
kubernetes
resources.
C
Yeah
I
mean
very
similar
for
us
at
azure.
It's
you
know.
We
wanted
a
kubernetes
first
approach
right,
even
though
there
are
other
ways
to
do
declarative
apis.
If,
if
you're
in
the
kubernetes
world,
it
feels
kind
of
awkward
to
like
have
to
step
out
of
that
in
order
to
interact
with
the
cloud,
especially
because
you're
going
to
be
deploying
your
core
service
in
kubernetes,
and
then
your
core
services
dependencies
like
a
db
or
something
you
all
of
a
sudden.
D
Yeah,
it's
exactly
the
same
for
us
I
mean
we
have
had
cloud
formation
right
for
well
what
seems
like
forever,
right
and
and
then
and
there's
also,
you
know,
terraform
for
another
sort
of
declarative
way
of
driving
infrastructure
changes,
but
yeah.
Just
like
matt
said
we
had
customers
coming
to
us,
saying:
hey,
we
we
prefer
the
kubernetes
api,
we
prefer
the
consistent
kubernetes
resource
model
and
api
machinery,
and
especially
our
devs,
prefer
that
right.
So
I
what
we're?
D
What
we've
struggled
with
really
is
that
most
of
our
customers
or
we've
found
they
have
a.
They
have
a
lot
of
application
development
teams
that
prefer
to
use
the
kubernetes
model.
But
a
lot
of
these
customers
are
huge
enterprises
right
and
they
still
have
these
like
central
I.t
teams
and
a
lot
of
those
central
I.t
teams
also
like
to
work
with
cloud
formation
or
they
may
use
terraform
or
other
solutions.
So
it's
sort
of
a
mixed
bag
and
ack
the
aws
controllers
for
kubernetes
is,
is
primarily
focused
on
that
first
set
right.
D
The
application
developers
that
prefer
to
use
the
the
kubernetes
language
and
we've
had
yeah
some
some
interesting
discussions
like
how
do
you
work
in
this
hybrid
environment,
where
you've
got
a
central
I.t
team?
That's
used
to
either
imperative
configuration
changes
or
using
cloud
formation,
and
things
like
that
versus
the
app
dev
teams
that
are
using
and
preferring
the
kubernetes
model.
A
A
Kind
of
the
best
answer
to
the
question,
though,
to
be
honest,
you
know
it's
much
better
than
like
we
thought,
it'd
be
cool
or
whatever,
which
which
brings
me
to
dan.
Do
you
do
you
know
the
sort
of
have
you
done
any
archaeological
spelunking
to
to
find
out
sort
of
the
history
of
the
cross
playing
project?
Do
you
feel
like
you
can
answer
the
question
of
like?
Where
did
crossland
come
from.
B
Yeah,
I'm,
I
know
at
least
from
I
was
aware
of
the
project
when
it
was
initially
announced
and
but
but
wasn't
yet
with
the
company,
so
part
of
joining
upbound
and
working
full-time
on
crossplane
was
kind
of
like
buying
into
the
mission.
I
guess
so.
I
can
speak
to
that
at
least,
and
I
know
something
that
really
motivated
me
to
work
on
the
project.
D
D
You
know
we
I
I
don't
know
I
I
I
guess
I,
if
I'm
putting
my
archaeologist's
hat
on
right,
crossplan
and
a
number
of
other
things
started
out,
sort
of
in
the
same
time
frame
that
the
open
service
broker
concept
and
community
kind
of
started
to
to
become
a
thing,
and
I
know
that
the
service
broker's
kind
of
fallen
out
of
out
of
favor
and
out
of
out
of
style,
but
I
think
it's
important
to
to
bring
up
that
topic.
As
far
as
like
our
archaeological
dig
here,.
A
That's
that's
very
true.
I've
got
to
admit
I'm
somewhat
personally
ignorant
about
the
history
of
the
sort
of
open
service
broker
project
initiative.
I
will
say
for
those
of
you
who
are
we're
recording
this
weeks
ahead
of
time,
but
for
those
of
you
who
are
watching
this
conference
now,
I
believe
there
will
be
a
talk
that
that
relates
cosplay
to
the
open
service
broker
and
from
from
jana.
A
A
little
bit
like
the
persistent
volume
claim
pattern
to
just
databases
and
buckets
and
things
like
that,
and
then
they
built
that
to
support
the
other
thing
that
they
were
building
and
like
oh
hey.
This
is
useful.
We
should
open
source
this
and
like
get
this
out
there
sort
of
thing,
and
I
believe
that's
where,
where
cross
playing
came
from,
so
I
also
just
going
back
to
dan-
and
I
don't
talk
about
cosplaying
too
much,
but
I
do
want
to
get
ask
dan.
A
Can
you
can
you
give
a
little
context
down
crossplane
kind
of
approaches,
things
a
little
bit
differently
than
the
other
clouds
right
like
more
than
the
clouds?
I
should
say
so.
So
the
other
projects
represented
all
this
cool
focus
on
on
one
cloud,
sort
of
thing
and
delivering.
You
know
all
the
apis
of
that
cloud,
whereas
crossplaying
scope
is
a
little
broader
right.
B
So
I
I
know
jay
actually
mentioned
earlier
today
that
it's
kind
of
like
the
ack
types
have
kind
of
the
top
level
spec
of
a
resource.
You
know
the
fields
that
are
actually
going
directly
to
aws,
whereas
with
crossplane
we
kind
of
have
a
container
for
those
sorts
of
fields
and
then
the
common
fields.
On
top
of
that,
so
just
as
an
example
of
some
things
that
would
be
common
between
resources,
the
way
they
reference
each
other,
the
way
they
produce
connection
secrets
the
way
they
report,
whether
they're,
ready
or
healthy.
A
I
think
another
place
where
sort
of
cross-plains
approach
gets
interesting
goes
back
to
what
we
were
talking
about
before
with
regards
to
potentially
integrating
with
like
legacy
systems
and
things
like
that,
because
we
opened
up
the
you
know,
there's
only
so
much
that's
implemented
so
far,
but
you
know
we
just
released
like
a
vsphere
provider,
for
example,
so
you
can
mix
and
match
your.
You
know
cloud
of
choice
with.
Maybe
I
hadn't
you
know.
Maybe
your
cloud
of
choice,
especially
I
don't
want
to
paint
freesphere,
is
purely
legacy
stuff.
A
But
you
know
if
you
do
have
a
different
environment
sort
of
thing.
Let's
say:
if
you're
moving
from
from
azure
to
aws
or
vice
versa,
you
can
you
can
kind
of
do
both
consistently
or
theoretically.
If
you
were
using,
we
don't
have
a
ton
of
old
school
bare
metal
stuff.
We
have
like
an
equinix
provider,
but
I
don't
really
think
they're
very
old-school.
A
So
but
if
you
were
on
bit
or
you
could
hypothetically
have
a
kubernetes,
sorry,
a
crossplay
provider
that
you
could
sort
of
mix
and
match
there
or
you
could
imagine
like
having
a
you
know,
a
provider
that
just
goes
and
runs
terraform
or
cloud
formation
for
you.
If
you,
if
you
wanted
to
so
this,
this
kind
of
gets
back
a
little
bit.
A
Is
that
a
dynamic
joist
that
you
see
for
config
connector
users,
who
are
the
main
people
who
you
see
using
config
connector?
Is
it
sort
of
mostly
sres
or
mostly
sort
of
sres
sort
of
just
offer
config
connector
as
a
service,
so
that
the
average
application
developer?
The
person
who
writes
deployment
might
also
write
a
cloud
sql
instance,
or
something
like
that.
E
Yeah,
so
we
identify
our
customer.
Our
target
customers
are
like
platform
teams
and
platform
administrators
who
are
like
design,
designing,
building
and
setting
up
their
centralized
infrastructure,
and
I
think
those
are
our
main
customers
and
that
they
might
create
a
general
infrastructure
for
the
entire
organization
or
they
might
create
infrastructure
on
demand
for
the
application
teams.
So
basically
we
consider
those
are
our
target
customers.
E
A
Customers
makes
sense,
and
I
think
I've
seen
I
I
know
that
google
has
some
examples
on
github
of
building
abstractions
on
top
of
cloud,
sorry
on
top
of
config
getting
to
types,
but
google
typically
seems
to
prefer
to
to
do
those
abstractions
client-side
right.
I
think
I've
seen
like
those
tools
like
kbt
the
way,
there's
some
examples
of
how
you
can
have
sort
of
use
kpt
to
render
out
some
some
tools
is
that
sort
of
something
that
that
maybe
would
be
more
focused
to
application
developers
rather
than
platform
teams.
E
The
thing
about
like
config
connector
is
it's
used
to
mainly
manage
the
like,
manage
the
control
plan
of
the
resources
and
for
a
lot
of
the
application
use
cases
they
might
be
focused
on
more
on
data
plan,
and
so
that's
why
we
consider
like
managing
the
infrastructure
as
the
main
use
case.
For
example,
we
have
examples
of
creating
resource
hierarchy,
which
is
basically
create
the
organization,
create
the
folders
and
create
different
photos
for
different
teams,
set
up
impermissions
and
set
up
networking
connections.
So
those
are
actually
something
we
find.
E
The
config
connector
will
be
really
useful
because
it's
providing
the
consistent
template,
consistent
user
experience
and
the
similar
infrastructure
can
be
set
up
for
different
teams
with
several
configurations
by
variables
supported
by
capt.
So
also
so.
The
entire
workflow
can
be
simplified
and
like
yeah,.
A
D
A
A
A
A
as
far
as
I'm
aware,
when
you
create
a
postgres
sql
server,
for
example,
it
will
usually
it
will
not
allow
any
traffic,
and
then
you
have
to
go,
get
some
firewall
rules
to
either
allow
a
virtual
net
or
or
just
an
id
range
to
access
it,
which
is,
you
know,
secured
by
default,
which
is
good.
But
then
it
changes.
The
the
the
problem
from
just
go.
A
C
So
we
have
some
customers
where,
like
they've,
set
up
aso
and
they're
using
you
know,
kubernetes
are
back
and
stuff
such
that
they're
delegating
platform
administration
to
an
individual
team
within
their
company
and
each
team
sort
of
does
their
own
platform
admin.
And
then
the
aso
is
maintained
by
the
the
core
team,
but
they
don't.
They
don't
concern
themselves
with
what
a
particular
team
in
their
company
is
deploying
they
just
give
them.
You
know
sort
of
carte
blanche
to
deploy
whatever
they
like.
C
As
long
as
it's
you
know,
in
their
name
space
and
so
yeah.
The
the
general
case
is
that
customers
sort
of
understand
how
to
configure
these
things
and
one
of
the
things
that
they
like
about
sort
of
the
operator
pattern
and
and
aso
is
hey
like.
I
need
to
create,
like
six
of
these
things
or
whatever,
as
you
say,
like
the
postgres
server,
a
db,
some
firewall
rules
etc,
and
it's
it's
really
nice
in
kubernetes
to
be
able
to
do
that
by
just
like
applying.
C
You
know,
six,
six
resources,
all
at
the
same
time
like
you,
don't
have
to
worry
about
ordering.
You
don't
have
to
worry
about.
Like
does
this
come
before
that
it's
it's
sort
of
just
to
make
it
so,
and
then
you
wait
a
little
bit
and
then
it's
all
there,
and
so
that's
one
of
like
the
big
selling
points
I
think
of
of
not
just
aso
but
sort
of
the
general
pattern
that
kubernetes
is
espousing
is
like
hey.
You
don't
have
to
concern
yourself
with
you
know.
D
Exactly
change
the
spec
and
let
the
controller
deal
with
all
the
ugliness
behind
the
scenes
right
and
which
s3
update,
attribute
api
call.
It's
going
to
make.
You
know
hide
all
of
that:
implementation
that
imperative
implementation
goop
in
the
controller
and
allow
the
developer
experience
to
just
be
one
of
just
tell
me
your
desired
state.
That's
it.
A
D
A
Speak,
I
I'm
not
100
sure
about
this,
but
I
was
reading
a
few
weeks
back
now
on
the
on
the
ack
github
repo
and
was
doing
a
bit
of
research
myself
to
answer
this
like
who
was
the
target
audience
of
ack
and
was
that
correct?
I'm
thinking
that
sk
also
has
a
bit
of
a
bent
toward
letting
people
build
higher
order
things
on
top
of
ack
stuff.
Like
is
there
a?
A
B
Another
thing
that
is
kind
of
a
maybe
the
the
most
controversial
topic
I'll
say
between
crossplan
and
some
other
projects
is
the
cluster
scoping
of
those
managed
resources
right.
So
all
of
these
managed
resources,
the
granular
ones
exist
at
the
cluster
scope,
while,
while
most
other
projects,
whether
they're
you
know
managing
infrastructure
or
doing
other,
are
at
the
name,
space
scope
right
for
isolation
and
our
back
privileges
and
that
sort
of
thing.
B
So
then,
you're
able
to
put
the
permission,
permissioning
you're,
able
to
raise
it
to
the
level
of
abstraction
right,
so
you're
able
to
say
developers
interact
with
this.
You
know
friendly
interface
or
this
friendly
resource
that
has
very
simple
fields:
that
map
to
things
that
we
want
and
enforce
policy
we
want
and
we
can
govern
their
ability
to
do
that
at
the
name,
space
scope.
A
A
C
Right
I
mean
I,
I
would
say
that
these
two
things
sort
of
go
hand
in
hand.
It's
it's
consistency
and
scaling
to
the
number
of
resources
that
they're
that
there
are
in
the
cloud
right
and
it's
the
the
the
more
you
try
to
scale
sort
of
sort
of
manually
or
by
throwing
more
people
at
it
or
whatever
the
harder
it
becomes
to
sort
of
maintain
that
consistency.
As
I'm
sure
you,
you
know,
everybody
on
the
call
is
familiar
with,
and
so
it's
this
constant
tension
between
like
how
fast
can
we
go?
C
C
That's
building
new
things
and
shipping
new
apis
that
you
know,
if
you
look
at
it
from
sort
of
a
person
hours
perspective,
there's
just
no
way
that
you
know
like
five
or
six
of
us
could
ever
keep
up
with.
However,
many
you
know,
like
thousands
of
developers,
there
are
producing
new
apis
in
azure,
and
so
we've
got
to
come
up
with
some
way
to
do
something
about
that
disconnect
and
that's
one
of
the
big
challenges.
A
E
Yeah,
I
completely
agree,
like
consistency
is
always
a
big
problem
or
a
big
challenge
I
would
say,
is
it
comes
together
with
was
scaling
because
the
more
resource,
your
supports,
the
more
ash
cases
you
were
running
to
and
the
more
features
you
need
to
support
to
cover
those
edge
cases.
So
it's
really
hard.
E
The
lucky
part
for
us
is.
We
are
built
on
top
of
declarative
client
libraries,
which
they
communicate
with
service
teams
directly,
and
we
work
closely
with
the
declarative
library
team
to
make
sure
like
they
feature
or
the
resources
they
support,
aligns
with
our
customers
requests
and
then
they
can
probably
delegate
their
own
request
to
the
service
team.
So
it's
like
there
is
a
layer
in
between
us
and
the
api
teams.
A
B
B
We
don't
have
access
to,
of
course-
and
you
know
we
also
well,
no
one
can
right
now,
but
theoretically,
in
a
in
a
future
time
when
we're
not
in
a
pandemic,
be
able
to
walk
down
the
hall
and
knock
on
someone's
door
and
ask
them
how
an
api
works.
That
being
said,
we
definitely
had
awesome
partnership
with
the
folks
on
this
call
right
here
in
being
able
to
share
some
of
the
generation
of
kind
of
the
manual
steps
for
creating
these
resources,
so
specifically
with
aws
ack
and
provider.
B
Aws
for
crossplane
currently
share
a
code
generation
pipeline
which
definitely
helps
accelerate
both
projects.
As
you
know,
they
have
the
context,
for
you
know,
understanding
how
these
apis
work
at
an
intimate
level
and
we're
able
to
contribute
back
based
on
our
experiences
as
well.
So
that's
definitely
a
factor,
and
then
one
thing
we
haven't
touched
on,
which
I
definitely
see
as
a
open
source
maintainer
as
a
big
component
is
community
right.
When
you
get
more
folks
working
on
things,
you
know
whatever
their
background.
B
A
Yeah,
that's
that's
kind
of
one
of
our
big
approaches
to
scaling
is
scaling
the
community
to
scale
with
the
amount
of
work
of
building
building
this
stuff
out.
The
whole
consistency
thing
is
is
really
interesting
to
me.
I
think
you
know
we
talked
about
why
people
like
to
use
kubernetes
to
manage
their
infrastructure
and,
I
think,
part
of
sort
of
what
we
touched
on.
A
You
know
cosplay,
we
call
it
the
xram
or
the
the
crossplane
resource
model
where
we're
just
it's
a
you
know,
a
superset
of
of
that
and
we're
just
saying,
hey
what
if
we
make
this
more
consistent
and
more
opinionated
to
people
like
ooh,
we
like
that,
but
then
there's
also
an
interesting
thing
where
hypothetically
you've
now
got.
You
know
when,
when
where,
when
someone
comes
to
write,
a
new
crossplay
provider,
there's
different
layers
at
which
you
could
ask
them
to
be
consistent.
A
You
could
just
say:
hey,
you
can
go
write
this
provider
in
erlang
for
all.
We
care
just
have
a
consistent
api
and
there
are
trade-offs
there
right
that
you
need
a
big
enough
community
for
that
provider,
where
everyone's
going
to
be
coming
in
learning,
girling,
potentially
or
like
using
a
different
tool
set
building
new
libraries,
all
that
kind
of
thing,
but
but
sure,
and
especially
if
that's
an
open
source
community,
we
might
want
to
have
that
flexibility
or.
A
You
know
take
the
approach
that
we've
come
closer
to
taking
say
we
actually
want
you
to
build
providers
mostly
a
specific
way
using
go
using
these
libraries,
etc,
etc.
I'm
guessing
sort
of
I
know
joyce.
You
said
that
you've
got
sort
of
dcl
which,
which
I
believe
is
like
a
go
library
right
jay
at
amazon
is
everyone?
Do
you
think
you're
gonna
get
everyone
sort
of
pretty
consistently
building
controllers
just
using
the
ack
style
sort
of
thing?
Do
you
ever
have
issues
with
people
saying?
No.
I
really
want
to
go.
D
No,
we
don't
really
have
any
issues
with
that.
I
think
it's
our
our
biggest
challenges
are
primarily
people
based
right,
I
mean
ack
is
a
set
of
service
controllers
right
that
one
for
each
of
the
service
apis,
so
one
for
s3,
rds,
etc,
and
each
of
those
services
is
backed
by
people
at
aws,
right
and
those
service
teams.
D
Some
have
a
very
long
history
of
doing
things,
their
own
way,
some
have
a
very
short
history
and
are
like
very
comfortable
working
in
the
open
source
community.
Some
aren't
so
yeah.
It's
it's
been
a
challenge
bridging
across
those
different
service
teams.
For
me,
personally,
I
mean
it's
a
challenge.
I
welcome,
but
it's
definitely
been
a
challenge
right,
because
I
have
to
sort
of
explain
how
kubernetes
works.
D
In
addition
to
you
know
like
hey:
what
are
our
needs
from
an
ack
perspective,
we
generate
the
controller
right
for
the
for
the
different
resources
in
that
service
api,
and
then
we
work
with
the
service
team
to
build
tests
and,
and
that
kind
of
thing,
so
yeah,
the
the
variety
of
knowledge
about
kubernetes
and
container
ecosystems
within
the
service
teams
at
aws
has
has
been
a
challenge.
I'll
just
put
it
that
way.
A
A
Do
a
quick
round
of
the
room
and
I'm
gonna
ask
everyone
to
give
me
a
you
know
one
or
two
sentence
answer
of
what
what
are
you
most
excited
about
on
your
project
at
the
moment
or
like
what
what's
what's
most
interesting
to
you?
If
it's
not
a
feature,
a
technical
challenge
or
something
so
start
with
joyce?
What's
what's
excites
you
the
most
about
conflict
connector
at
the
moment,
or
what
you're
working
on.
E
It's
like,
like
I
see
I've
seen
a
lot
of
like
customer
quotes
about
that,
and
it's
also
amazing
that
we
can
keep
full
fidelity
of
those
underlying
gcp
resources.
So
those
are
something
I'm
really
excited
about,
because
that's
exactly
the
goal
of
config
connector
and
I'm
so
excited
to
see.
Customer
actually
feel
it
yeah.
A
C
Well,
one
of
the
the
things
that
we're
sort
of
incubating
in
aso
right
now
is
azure,
has
a
arm
and
has
specs
for
all
of
the
management
plane.
Operations
are
in
open
api,
and
so
one
of
the
things
that
we're
working
on
is
you
know.
I
mentioned
the
scaling
challenges
and
the
consistency,
challenges
and
we're
sort
of
pretty
close
to
an
alpha.
Now,
where
we're
planning
on
generating
as
sort
of
jay
mentioned,
aws
is
doing
as
well.
C
The
controllers
for
all
of
these
management
plane
resources
from
these
open
api
specs,
and
so
I'm
really
excited
to
sort
of
hopefully
be
able
to
knock
down
one
block
on
that
challenge
of
hey.
Can
you
know
consistency?
Scalability,
we've
got
this
thing
that
we
can
generate
using
open
api,
and
actually,
you
know
like
90
or
80
of
the
azure
resources,
we'll
just
be
able
to
code
generate
and
then,
of
course,
we
still
have
to
solve
testing
and
all
of
these
other
problems.
C
But
at
least
that's
one
big
step
toward
a
consistent
experience
across
a
large
number
of
resources
that
doesn't
involve
tons
and
tons
of
manual
effort,
and
you
know
people
massaging
each
and
every
one
we're
sort
of
lucky
in
azure,
because
there's
that
uniform
way
to
deploy
through
through
arm
and
all
the
specs
are
there.
So
it's
just
a
you
know,
question
of
writing
the
code
to
turn
it
into
kubernetes
resources.
A
D
Well,
I
think,
there's
two
things
I'm
most
most
excited
about
from
a
user
perspective
of
either
crossplane
users
or
users
of
ack
individual
service
controllers.
I
I'm
really
excited
about
bringing
a
consistent
way
of
interacting
with
some
aws
service
resources
using
the
kubernetes
api
machinery
and
kubernetes
resource
model.
I
think
that
that
consistency
is
has
been
asked
for
for
a
long
time
by
application
developers
who
prefer
kubernetes.
So
I'm
super
excited
about
that
and
just
the
consistency
in
general.
D
A
Yeah,
I
could
totally
empathize
with
that.
I
I
you
know
not
that
not
that
they're
in
any
way
bad
at
open
source,
but
I
spent
my
first
five
years
six
years
of
my
career
at
google,
and
it
was
a
bit
of
a
bit
of
a
culture
shock
to
leave
google
and
you
know
be
using
the
open
source
equivalent
of
all
of
this.
You
know
internal
tooling
sort
of
thing,
so
it
is.
B
Is
the
ability
to
support
essentially
functions
so
right
now
we
have
providers
which
are
basically
controllers
and
crds.
We
have
configurations
which
are
just
yaml
objects
that
get
installed
into
the
cluster
and
then
functions
could
really
lower
the
barrier
to
entry
for
folks
authoring
some
of
this
kind
of
specific
functionality.
B
So
you
could
imagine
day
two
operations
or
disaster
recovery
or
migration.
Those
could
all
be
things
that
could
be
packaged
into
small
functions
and
there's
a
lot
of
innovation
happening
in
the
function,
space
in
the
kubernetes
ecosystem
and
also
more
and
more
folks,
are
using
to
moving
to
things
like
lambda,
and
things
like
that.
So
you
know
providing
that
interface
to
to
interact
with
this
kind
of
ecosystem
that
we've
built
of
cloud
provider.
Resources
as
kubernetes
objects
is
something
that
I
think
could
be
a
really
powerful
model.