►
From YouTube: Plays Well with Others: Composability for Cloud Native Applications - Steve Judkins, Upbound
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Plays Well with Others: Composability for Cloud Native Applications - Steve Judkins, Upbound
Writing cloud native applications today involves custom code to stitch everything together across microservices, open-source frameworks, and managed services. In this talk, we look beyond Kubernetes’ usage for container orchestration and extend the Kubernetes API to the management of external resources (not running on pods or nodes). Imagine if an application developer writing a monitoring framework could ask for a SQL database and message queue for their application in the same way that the Kubernetes API enables them to ask for an abstract PersistentVolumeClaim backed by a concrete PersistentVolume implementation. We can imagine that this developer might also expose the monitoring framework as a resource for consumption by other applications. In this talk we explore the use of this new approach to facilitate composability and reuse of resources within heterogeneous applications.
https://sched.co/Nrlf
A
When
I
was
growing
up
in
school,
children
were
graded,
young
children
were
graded
on
how
well
they
played
with
other
kids
in
the
school
yard,
and
we
want
to
make
sure
that
when
they
grow
up
they're
capable
of
working
well
with
others
and
in
different
environments.
So
we
think
we've
seen
a
lot
of
learn.
Lessons
learned
from
the
open
source,
kubernetes
project
on
how
to
build
cloud
native
applications
that
work
well
with
others
and
have
greater
composability
and
reuse.
So
as
it
matures.
A
You
all
probably
are
aware
of,
and
love
kubernetes
as
well
or
you
wouldn't
be
here
so
I'll
be
talking
a
bit
about
the
benefits
of
container
orchestration
for
scaling
your
own
software
deployments.
But
that's
not
all
that
kubernetes
brings
to
the
table.
It
also
makes
it
easy
to
use
declarative
management
API,
and
these
active
state
controllers
can
reconcile
the
actual
state
of
your
application
with
the
desired
state.
A
So
this
has
shown
how
great
it
can
be
for
complex,
apps
and
but
there's
even
more
there's
it's
extensible
kubernetes
lets
us
define
custom
resource
definitions
and
implementing
controllers
is
for
the
right
way
to
extend
kubernetes,
so
we
can
manage
more
things
within
our
infrastructure
than
we
have
been.
So
if
we
took
a
look
at
like
the
modern
cloud
application,
you're,
probably
leveraging
kubernetes
in
your
apps,
it
just
makes
sense
to
deploy
our
apps
to
containers
like
many
companies,
you've
probably
built
these
apps
you've
deployed
them
to
a
cluster.
A
It's
just
like
the
big
container
ship
here
when
we
talk
about
deploying
with
kubernetes
those
are
running
in
your
own
cluster
and
you
have
responsibility
for
managing
that
cluster.
So
most
of
us
want
to
take
advantage
of
cloud
platforms,
and
the
cloud
providers
have
built
these
big
beautiful
cities
with
lots
of
infrastructure.
They
have
an
SLA,
they
can
give
you,
and
so,
in
order
to
take
advantage
of
that,
you
know
to
manage
databases.
A
We
can
then
have
scaleable
databases
that
manage
backups
replication
disaster
recovery,
there's
just
a
lot
of
features
there
that
we
don't
have
to
manage
when
we're
deploying
to
our
own
cluster.
So
you
know,
and
of
course,
public
cloud
providers
have
been
rolling
out.
New
features,
advanced
features
at
an
amazing
rate,
so
if
you
want
to
take
advantage
of
those
differentiated
services
like
search
AI
and
it's
kind
of
a
pain
to
manage
those
in
your
own
cluster,
so
kind
of
what's
wrong
with
the
picture,
modern
applications
are
basically
composed.
A
More
than
just
the
services
that
we're
writing
and
maintaining
you're
gonna
have
dependencies
on
databases,
object,
storage,
buckets,
pub/sub,
search,
monitoring,
sort
of
the
typical
application
components.
But
do
you
really
want
these
all
running
in
your
cluster?
Do
you
want
to
be
paged
at
midnight?
I
don't
so.
A
A
So
can
we
solve
this
in
an
elegant
way
if
we
take
a
moment
to
look
at
the
different
approaches
to
infrastructure
orchestration
that
are
out
in
the
wild,
we'll
see
some
patterns
so
I
kind
of
find
it
useful
to
categorize
these
components
in
in
this
way?
So
along
the
vertical
axis,
you
have
your
services
and
those
running
in
your
kubernetes
cluster,
which
you
might
have
deployed
with
helm.
A
You
might
have
basic
cloud
provider
services
that
you're
taking
advantage
of,
and
if
you
need
something
like
cloud
formation
that
can
cover
the
gamut
of
AWS
but
doesn't
extend
to
other
cloud
providers
at
the
top
of
that
axis
is
utilizing
different
differentiated
clouds
provider
services
across
multiple
cloud
providers
and
something
like
terraform.
You
know
HCl
allows
you
to
basically
do
that
kind
of
thing
for
installation
and
some
upgrade
cycles
on
this
axis.
A
You
have
write
the
whole
resource,
lifecycle
management
and
many
of
these
tools
like
ansible
and
chef
and
puppet,
have
gotten
you
closer
to
the
install
and
upgrade
path.
But
when
we
look
at
core
LS,
you
know
who
introduced
the
operator
framework,
we
see
what
it
means
to
have
the
entire
lifecycle
manage
within
an
active
state
controller,
and
there
been
some.
A
So
how
could
we
solve
this
in
an
elegant
way
if
it
were
based
on
the
communities
engine
and
it
brings
those
cloud
provider,
services
and
infrastructure
into
kubernetes?
Gives
you
one
API
to
manage
everything
and
provides
portability
for
those
workloads
that
you
have
beyond
containers
it'd
be
nice,
wouldn't
it!
So
if
we
look
back
from
a
moment,
the
time
feels
right
for
this
we're
kind
of
an
interesting
moment
in
the
evolution
of
cloud
native.
A
B
A
So
when
we
look
at
the
resource
lifecycle
management,
piece
of
this
kubernetes
has
custom
resources
and
that
we
can
use
to
model
cloud
provider
services
as
well,
and
we
can
use
custom
controllers
to
provision
configure
scale,
monitor,
upgrade,
provide
failover
and
back
up
all
of
those
lifecycle
management.
Things
can
be
that
logic
can
be
put
into
a
controller
and
that
control
can
handle
active
reconciliation
so
that
we
essentially
hands-up
have
hands-off
management
of
those
cloud
provider.
Services.
A
We
also
have
this
portable
resource
abstraction
notion.
So
you
know
kubernetes
has
a
powerful
volume
abstraction,
it's
a
give
its
portability
for
stateful
applications,
but
what
about
other
resources?
Cloud
provider?
Resources
might
include
databases,
buckets
clusters,
caches
message,
queues
data
pipelines,
everything
there.
So
let's
abstract
those
two.
We
really
want
to
get
to
writing
once
and
running
anywhere.
And
how
do
we
do
that?
So.
A
So
about
seven
months
ago
a
pound
introduced
crossplane,
it's
an
open-source
multi-cloud
control
plane
and
it
was
released
where
it's
still
young,
it's
a
version
0.2.
But
what
this
does
is
it
leverages
the
kubernetes
api
machinery
at
CD,
the
workload
scheduler
and
introduces
resource
controllers
for
both
we
support
the
three
cloud
providers,
AWS
Azure
and
Google
cloud.
There
are
other
cloud
providers
we'd
like
to
extend
that
support
to,
and
it
can
also
provide
controllers
for
actively
managing
other
third-party
software.
A
We'd
like
to
see
that
extended
to
you
things
like
elastic
confluent
data
bricks,
other
typical
apps,
the
typical
frameworks
that
your
apps
going
to
manage
and,
of
course,
by
building
on
the
kubernetes
api
machinery.
You
have
all
the
same
user
interfaces
and
client
libraries
that
you've
grown
to
love
and
use
and.
A
But
when
we
think
about
how
we
build
upon
the
machinery
of
software,
we
have
to
get
to
the
point
where
we
have
a
factory
model
of
components
that
we
want
to
reuse
and
design
to
be
modular
and
reused
in
other
applications,
regardless
of
where
those
applications
are
intended
to
run.
So
the
separation
of
concerns
also
lets
an
administrator,
define
the
environment,
specifics
and
policies
so
at
development
time
I
might
be
running
this
in
mini
cube
and
installing
crossplane
using
cloud
resources.
A
A
So
how
do
we
model
that
we
we?
We
looked
at
persistent
volume,
claims
and
storage
class
and
kubernetes
and
that's
a
model
for
creating
resource
claims
and
resource
classes.
So,
if
I
have
a
resource
class,
that
is
a
database.
I
can
make
a
claim
on
that
as
an
app
developer,
and
this
allows
us
to
do
some
dynamic,
on-demand
provisioning
of
resources.
When
we
deploy
to
a
specific
environment.
A
A
So
just
to
give
you
an
example
of
what
a
resource
claim
would
look
like
as
an
app
owner.
Here's
Postgres,
where
the
request
for
Postgres
it
doesn't
have
a
whole
lot
of
the
environment.
Specifics
I
don't
yet
say
where
this
is
going
to
run
and
I
basically
can
specify
the
engine
version
that
I
need
and
that
it's
going
to
come
from
a
cloud
Postgres
provider.
A
The
resource
class
as
defined
I,
there
are
defaults
that
are
installed
when
crossplane
is
installed,
but
the
system
administrator
can
go
in
and
update
those
defaults,
but
this
is
going
to
contain
properties
that
are
defined
that
are
specific
to
that
cloud
provider.
It
might
on
a
dia
AWS,
be
using
a
certain
instance
size
or
database
size
they're,
going
to
be
able
to
define
policy
and
allow
apps
to
default.
To
that.
A
We
wanted
to
choose
a
partner
that
has
a
fairly
complex
real-world
application
to
prove
out
cross
plains
model
and
we're
learning
a
lot
about
how
to
design
the
controllers
and
the
workloads.
So
just
to
give
you
an
example:
get
lab
is
currently
deployed.
It's
a
helmet
art.
It
has
about
48
hundred
lines
of
yamo.
It
consists
of
14
deployment,
three
jobs,
nine
services,
16
config
maps,
so
there's
a
lot
going
on
in
there.
A
Their
main
dependencies
are
on
Postgres
Redis
and
object
storage,
so
they
wanted
to
have
this
run
across,
be
able
to
deploy
across
different
cloud
providers,
and
we
were
starting
to
look
at
their
current
install
and
how
could
we
make
this
better
so
with
a
custom
resource
definition?
There's
a
simple
configured:
speery
ins
with
the
custom
get
lab
controller.
We
can
generate
these
artifacts
and
essentially
manage
the
state
of
the
deployment
and
get
to
the
point
where
the
deployment
of
get
lab
is
a
fully
automated
and
portable
multi
cloud
deployment.
A
So
this
is
how
it
kind
of
looks
when
you
look
at
what
we've
design
design
forget
lab
and
by
the
way
this
is
all
out
on
our
open
source
site.
So
you
can
review
how
this
is
the
examples
for
this
you'll
see
that
basically,
the
Postgres
controller,
Redis,
controller
and
bucket
controller
are
pulled
in
as
resource
claims
within
gitlab,
the
on
AWS
or
GC,
P
or
Azure.
A
A
A
A
So
we
grab
crossplane
from
the
master
channel
and
by
the
way,
I
could
never
type
this
fast
and
I
don't
want
to
screw
up
the
demo.
So
it's
a
video
for
you,
so
we'll
install
the
helmet
chart
from
our
master
channel
to
get
crossplane
installed
and
the
key
third
part
of
this
is
once
we've
installed
crossplane.
We
will
have
on
our
system
custom
resources
for
a
set
of
classes.
A
A
A
So
the
process
of
provisioning
resource
classes
is
really
the
domain
of
the
administrator.
If
you're
playing
administrator
and
app
developer,
you
can
put
these
two
together,
but
an
administrator
in
this
case
might
decide
they're
going
to
make
available
the
resource
classes
for
AWS
only
if
you're
an
AWS
shop,
and
so
you
can
go
in
and
set
various
properties
within
this.
A
Also
look
at
the
bucket
configuration
here
and
just
make
sure
that
it's
good
to
go
before
I
start
having
apps
unleashed
into
our
buckets.
So
once
that's
set
up.
I
now,
basically
can
keep
CTL
create
on
those
resource
classes.
Those
are
now
created
and
they're,
essentially
provisioned
in
that
crossplane
instance,
and
available
to
any
apps
that
want
to
consume
them.
So
now
we
go
back
to
what
does
the
app
developer
do
in
this
case
we're
going
to
provisions
to
manage
services
in
Google,
Cloud
and
then
I'll
show
you
an
AWS.
A
So
this
is
this:
is
the
dependencies
for
forget
lap?
We
basically
make
use
of
kubernetes,
so
we're
gonna
spin
up
a
cluster
that
we're
going
to
deploy,
get
lab.
Two
we're
gonna
make
an
instant
reference
to
Postgres
and
Redis,
and
so
what
we
did
was
basically
deploy
the
buckets
they
have
about
nine
different
buckets
they
use
since
we
basically
keep
CTL
applied
the
bucket
resource.
A
So
if
we
switch
over
and
look,
we
can
just
keep
pulling
this
where
you
can
go,
get
a
coffee
and
just
wait.
The
buckets
are
fast,
other
things
might
take
a
few
minutes,
and
but
now
you've
got
a
reconciler.
That's
just
doing
that
work
for
you.
It's
a
hands
off
so
here
I
kind
of
just
switched
through
the
console
and
kind
of
look
and
see
what
the
state
of
things
is,
making
sure
that
things
are
spinning
up,
but
really
I
don't
have
to
do
this.
It's
just
to
show
you
and.
A
So
once
those
resources
are
created
and
bound
within
kubernetes,
we
can
basically
then
come
and
take
those
resource
claims
that
we
have
and
export
them
to.
Our
git
lab
help
chart
this.
These
two
steps
would
generally
be
bundled
together
in
your
application,
but
we're
showing
them
here
so
that
you
can
kind
of
see
what's
going
on
under
the
covers.
A
So
here
we
basically
have
the
git
lab
resource
claims
that
we
made
in
our
default
namespace
we're
going
to
copy
those
to
our
target
cluster
and
make
sure
they're
available
in
the
get
lab
namespace
and
then
we're
going
to
update
the
helm
chart
make
sure
we
have
a
values
file
that
has
all
of
our
secrets
and
is
or
references
to
our
secrets
and
is
ready
to
go
so
there
we
go.
We've
copied
over
everything
into
the
target
cluster.
A
So
we
can
either
go
get
coffee
again
or
we
could
basically
watch
as
it
spins
these
services
up.
So
now
we're
waiting
for
we're
using
kubernetes,
of
course,
to
check
the
status
of
whether
these
services
are
bound,
and
you
can
see
here
the
services
that
are
being
initialized,
including
the
buckets
and
Postgres.
A
A
Once
those
are
spun
up,
we
will
have
an
address.
An
IP
address
that
we
can
grab
crossplane,
doesn't
yet
provision
the
things
like
V,
pcs
and
other
open
ports
and
other
things
like
that,
we'd
like
to
extend
it
to
manage
those
things
so
you'll
see
here
that
I
just
grabbed
the
IP
address
and
manually
open
that
up.
A
A
So
we'd
love
to
welcome
the
community
to
continue
to
grow
cross
flane
we're
just
about
to
hit
a
dot
three
release
and
but
the
would
love
to
see
folks
get
involved.
I
put
some
resources
up
here.
If
you
want
to
take
a
look
at
the
get
lab
deployment
and
other
sample
applications
like
woodward
press
on
the
site,
we
have
regular
community
meetings
and
would
love
to
extend
crossplane
into
infrastructure,
provisioning
and
other
cloud
providers.
C
A
Right
so
one
advantage
being,
you
know
all
different
sides
of
your
house.
Your
administration
and
developers
are
converging
on
kubernetes,
but
also
the
application
things
that
you're
deploying
may
not
live
in
a
cluster.
They
may
be
managing
things
across
clouds,
so
your
application
spans
that,
with
a
single
development
framework.
C
A
I
think
you
know,
if
I
understand
your
question.
The
there
are
going
to
continue
be
differences
across
cloud
providers,
the
they're
creating
walled
gardens
and
their
incentive
is
to
have
differentiated
services,
but
for
many
of
the
services,
like
particularly
services
that
have
been
taken
from
open
source-
and
you
know
put
into
the
walled
garden
like
databases,
you
have
compatibility
at
a
wire
protocol
level
like
if
I
want
Postgres.
A
You
know
it
doesn't
really
matter
that
it's
RDS
so
taking
those
and
creating
a
portable
abstraction
for
requesting
a
sequel
database
and
allowing
apps
to
essentially
for
the
80%
scenario,
use
portable
extractions
before
you
get
into
cloud
provider.
Specifics
is
a
great
way
to
essentially
reduce
the
development
time
right
and
give
people
a
common
set
of
controllers
that
are
well
tested
and
and
very
rich
in
their
active
state
management.