►
Description
Steward, the Kubernetes-Native Service Broker [A] - Gabe Monroy, Deis
No application is an island. Most applications interact with a diverse set of services, not all of which run on a Kubernetes cluster. How do you manage access to both on and off cluster resources? Join Gabe Monroy, CTO of Deis, for a discussion about service catalogs, explicit service bindings, and how they can help you rationalize heterogeneous computing environments. We will end with a demo of Steward, an open source service broker for Kubernetes.
About Gabe Monroy
Gabriel Monroy (@gabrtv) is the CTO and creator of Deis. As an early contributor to Docker and Kubernetes, Gabriel has deep experience with containers in production and frequently advises organizations on PaaS, distributed systems, and cloud-native architectures. Gabriel speaks regularly at industry events including KubeCon, Dockercon, CoreOS Fest, Tectonic Summit, and QCon.
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
My
name
is
gaben
roy.
I
am
the
CTO
at
dais.
I
am.
It
was
an
early
dr
contributor,
very
early,
kubernetes
user
mediocre
go
programmer
lots
of
lots
of
things
I
spend
actually
most
of
my
time
in
the
field
working
with
customers
who
are
working
at
the
bleeding
edge
of
containers
and
distributed
systems,
micro
service
architectures,
and
I
really
like
to
try
and
find
folks
who
are
willing
to
cut
themselves
real
bad
so
that
I
can
get
then
supply
the
band-aids
right.
That's
kind
of
our
tour
bandages
as
it
work.
A
We've
actually
sort
of
merged
efforts
that
I'll
talk
a
little
bit
about
how
that
came
about,
but
I
do
think
it's
sort
of
fascinating
to
know
that
in
the
time
between
you
know,
submitting
this
talk-
and
you
know
coming
here
and
giving
in
the
open
source
community
is
sort
of
converged
on
the
direction
and
this
work
is
really
started
to
rock
it
towards
a
very
interesting
place
and
in
my
view,
so
where
do
we
start
here?
You
know
I,
think
this
is
kind
of
an
abstract
concept.
Right
service,
catalog
service
broker
technology.
A
It
feels
a
little
abstract
and
I
think
to
route
the
discussion.
It's
important
to
talk
about
what
problem
this
is
solving
and
it
turns
out
service
cattle.
It's
actually
solving
multiple
problems,
but
let's
just
focus
on
one
for
a
minute.
So
no
application
is
an
island
right.
We
can
all
agree
with
this.
You
know
applications
have
to
talk,
databases,
queues.
You
know
lots
of
different
things
that
applications
need.
You
know
outside
of
their
their
ecosystem
and
I.
Think
in
the
container
micro
service
space,
we've
sort
of
been
sold.
A
This
false
premise
that
everything
we
do
from
an
application
standpoint-
the
other
apps
and
services-
we're
going
to
talk
to
it's
going
to
be
provided
to
us
in
an
ocean
of
containers
right.
So
there's
going
to
be
all
these
containers,
databases
and
running
containers,
remnant,
containers,
all
your
sort
of
durable
stuffs,
going
to
run
in
containers
and
I.
Think
that's
not
really
how
this
is
work
playing
out
to
date
and
I
also,
don't
think
it's
how
it's
going
to
play
out
as
we
move
forward
and
the
reason
for
that
is
pretty
straightforward.
A
The
reality
of
most
IT
environments
is
that
they're
heterogeneous
they're
siloed
right,
so
you
had
container
clusters
right
kubernetes
running
over
here.
You
have,
you
know
cloud
provider,
stuff
right,
RDS
or
you
know
equivalents.
You
know
running
it
running
in
the
cloud.
You
have
the
database
in
the
back
of
the
closet.
You
have
the
Machine
under
some
guys
desk
right.
A
All
of
that
forms
the
company's
IT
infrastructure
right
and-
and
you
know,
solutions
that
only
deal
in
the
container
portion
of
that
are
only
solving
part
of
the
problem
and
we're
not
interested
in
solving
or
you
know,
part
of
the
problem
we
need
to
solve
all
of
it
and
I
think
the
service
broker
and
sort
of
the
Service
Catalog
technology
allows
us
to
do
that.
So
today's
solution
and
is
funny
I,
talked
about
note,
passing
in
the
session
earlier
today
that
actually
physically
we're
passing
notes
to
each
other
to
sort
of
demonstrate
this.
A
But
you
think
about
today
how
this
works
when
you're
reading
an
application
that
depends
on
another
service
or
another
application.
What
happens
today
is
that
someone
typically
in
operations
will
you
know,
grant
you
access
to
a
database
service,
they
will
provide
you
current
coordinates
like
host
and
port
username
password,
maybe
something
like
a
logical
database
name,
and
they
will
write
that
on
a
note
or
send
that
to
you
over
slack
or
some
other
medium,
and
that
will
be
your
mechanism
for
retrieving
your
credentials.
Now,
that's
not
great
right,
but
it's
what
we
have.
A
That's
what
we're
doing
today,
everyone
is
doing
that
right
and
you
know
forget
about
what
happens
when
you
need
to
rotate
credentials
or
when
a
service
gets
deprecated
and
you
get
a
lot
of
problems
with
this
sort
of
model,
but
in
general
it
works
today
and
people
are
happy.
But
the
issue
with
this
is
that
if
you
have
n
applications
with
n
other
services
that
they
need
to
get
connected
to,
you
end
up
with
an
N
squared
problem.
A
The
proliferation
of
these
notes
effectively
that
are
getting
passed
and,
if
you
think
about
this,
the
only
record
right
now
of
the
fact
that
my
app
is
connected
to
that
database
is
in
the
config
that
I
injected
into
that
app,
which
is
typically
tracked,
maybe
in
a
manifest
somewhere.
But
if
I
wanted
to
go
figure
out
like
who
are
all
the
consumers
of
that
database,
there's
nowhere
for
me
to
go
right.
Maybe
I
could
look
at
network
traffic
to
implicitly
figure
out
who's
connected
to
something.
But
that's
that's
not
a
great
solution.
A
So
the
problem
today,
the
one
I'm
most
interested
in
is
how
do
we
manage
interconnects
between
all
of
these
different
applications,
applications
application,
application
to
service
application
to
cloud
provider
service
I
mean
lots
of
different
interconnects
that
we
need
to
be
worried
about.
This
is
a
big
big
problem
today
and
so
I
think.
There's
actually
two
answers
for
this.
The
first
is
the
introduction
of
a
Service,
Catalog
and
Service.
Catalog
is
the
place
where
you
take
everything
in
your
environment,
heterogeneous
IT
environment,
and
you
put
it
into
the
catalog
I'm
talking
you're.
A
Once
you
have
a
catalog
in
place
of
what
you
have
from
an
IT
perspective,
then
you
can
move
on
to
the
second
phase
of
this,
which
is
explicit
bindings,
and
this
is
really
important.
What
going
forward
I
think
today
what's
happening
is
implicit
binding
right,
so
if
your
application
can
find
the
other
application
via
service
discovery,
you
know
via
coordinates
that
were
injected
via
the
username
and
password
that
happens
to
work
against
that
service
boom.
You
made
a
connection
right.
You
you're
bound
to
that
service
sort
of
implicitly,
that's
not
great
right.
A
What
we
need
in
the
future
is
we're
going
to
need
explicit,
binding
to
allow
hooks
for
things
like
policy,
so,
for
example,
if
my
application
needs
to
talk
to
a
database,
server,
I
should
be
able
to,
for
example,
open
up
the
Sdn
to
allow
for
Network
communication
flows
to
happen
over
a
default.
Deny
network
policy
right,
explicit,
binding
allows
for
that.
Another
example
is
dependency
graph
right
you,
if
you
have
all
of
the
service
connected
explicitly,
and
these
bindings
are
tracked
in
a
database
somewhere.
A
You
can
actually
query
that
database
and
draw
a
pretty
nice
picture
of
what
your
current
sort
of
service
topology
looks
like
in
terms
of
dependents,
or
so
when
you
go
to
deprecate
a
service
or
do
credential
rotation
on
a
service.
You
know
what
the
downstream
impacts
of
changes
like
that
are.
So
if
you
can
do
these
two
things
introduce
the
service.
Catalog
promote
this
concept
of
explicit
bindings.
You
can
hopefully
bring
some
sense
of
order
to
the
chaos
that
we're
currently
dealing
with.
A
With
regard
to
sort
of
this
note
passing
model,
that's
so
prevalent
in
IP
operation
state,
so
this
brought
today's
team
to
Stuart
my
view
here
is
looking
after
passengers
on
the
good
ship
kubernetes
and
we
started
you
know
as
we
do
a
dais
with
early
prototypes.
You
know
trying
to
get
it
the
problem,
trying
to
feel
what
sort
of
solutions
look
to
right.
We
started
off
with
some
third-party
resource
stuff.
It
was
pretty
interesting,
but
the
goals
of
this
were
to
you
know
threefold.
A
Well,
first
was
to
make
it
easy
to
expose
and
consume
services
right.
This
stuff
isn't
easy
to
use.
It
won't
matter
right.
We
can
build
the
coolest
thing
ever,
but
if
developers
can't
actually
wrap
their
head
around
it,
then
it's
not
going
to
make
a
difference
to
folks,
so
that
was
goal
number
one.
The
second
goal,
I
think
this
is
more
interesting
and
I'm
just
going
to
show
this
in
the
demo
later
on.
Is
we
want
to
decouple
provider
from
consumer?
You
know
the
ideal
for
me
is
as
a
developer.
A
A
So
you
know
if,
for
example,
you're
only
allowed
to
you
know
access
databases
with
this,
many
AI,
ops
or
you're
not
allowed
to
provision
this
super
expensive
cloud
provider
service
without
getting
permission.
First,
we
want
to
enforce
some
operational
constraints
on
what
people
are
able
to
do
with
something
like
a
catalog
so
turns
out
that
there
was
a
group
of
us
Cowboys
who
were
working
on
this
problem.
It
was
mainly
ourselves
Red,
Hat,
Google
and
IBM.
A
Hat
was
thinking
deeply
about
the
problem
and
we
actually
all
got
together
for
a
face-to-face
at
the
dais
offices
in
Boulder,
and
we
sort
of
started
designing
this
thing
as
as
a
team
as
a
group
of
your
despaired,
vendors
who
share
common
goals
and
that's
really
interesting
and
I-
think
a
fascinating
kind
of
part
of
the
story
here
and
what
ended
up
happening
is
that
the
steward
project?
You
still
find
it
on
github
if
you're
interested,
but
we
we
thought
it
was
made
more
sense
for
us
actually
merge
efforts
with
the
cig
who's.
A
You
know
we
decided
that
the
cig
sort
of
implementation
was
something
that
we
could
contribute
to
effectively.
It
met
our
goals
and
we
really
wanted
this
to
be
a
community
effort
from
the
outset
and-
and
we
were
frankly
quite
pleased
with
the
way
the
cig
was
being
run
and
with
the
the
progress
that
we
were
making,
despite
it
being
pretty
difficult
to
do
things
like
design
by
committee.
You
know
in
the
context
of
something
like
a
cig,
we
were
actually
able
to
make
that
work
of
against
all
odds.
A
I
would
call
it
so
at
a
super
super
high
level.
How
does
this
work?
It's
really,
to
my
mind
three
steps.
So
the
first
thing
is
you're
going
to
install
the
magical
service,
catalog
and
well.
I'll
show
you
what
this
looks
like
in
a
bit,
but
you
know
the
service
catalog
right
now
is
sort
of
separate
API
surface
that
is
implementing
a
kubernetes
like
API.
With
its
own
controller,
you
install
that
into
the
crew
brew
Nettie's
cluster.
A
The
part
of
the
broker
specifc
is
a
way
to
fetch
and
enumerate
what
services
are
you
know,
being
provided
and
brokered
via
that
broker
those
get
populated
into
what
are
called
service
classes
inside
of
kubernetes
and
those
service
classes
are
then
available
to
you
know,
developers
to
consume
via
manifests,
and
the
third
step
is
to
do
that.
Consume
the
stuff.
There's
two
objects
here
that
you
are
concerned
with
sort
of
on
the
consumer
side.
A
The
first
is
an
instance,
so
I,
for
example,
want
an
instance
of
Postgres
or
I
want
an
instance
of
RabbitMQ
and
specifying
that,
in
a
manifest
that
reference
is
a
service
class
that
is,
you
know,
was
populated
by
one
of
those
brokers.
That's
how
you
can
basically
provision
dynamically
an
instance
of
any
one
of
the
services
that
are
in
the
catalog,
those
whether
I
could
be
Bureau
a
micro
service.
It
doesn't
have
to
be
something
like
a
data
store
and
then
the
most
important
part
on
the
consumer
side
is
actually
the
binding
the
binding
does.
A
It
says
I
want
to
connect
to
this
instance
and
I
want
you
to
give
me
the
credentials
and
the
coordinates
and
everything
that
I
need
in
v---aids
are
secrets:
config
map
volumes,
whatever
the
sort
of
output
of
that
binding,
looks
like
and
I
want
that
injected
into
my
application.
Dynamically
right
I
want
to
think
about
it,
and
you
know
you
saw
that
in
the
demo.
A
Don't
really
earlier
today,
I'm
going
to
show
you
another
version
of
that
demo-
and
you
know
this
is
the
model
right-
install,
serves
catalog,
launch
some
brokers
and
start
consuming
stuff
via
manifests,
so
with
that,
let's
jump
right
into
the
demo
here.
So
the
first
thing
I'm
going
to
do
is
I'm
going
to
drop
into
a
helm
list.
So
I
just
set
the
stage
here,
I'm
going
to
deal
in
terms
of
helm
packages
here,
which
is
just
easier
to
you,
know,
work
through
the
flows
that
way
all
this
stuff
can
be
done
with
coops
ETL.
A
A
A
This
is
Danis
s3
uploader,
and
so
what
this
is
is
a
very,
very
simple,
go
application
that
is
going
to
upload
a
file
to
s3
and
what
it
does.
If
we
take
a
look
at
the
charts
for
this
thing,
take
a
look
at
the
templates
and
the
job
inside
of
the
container
spec.
Here
we
have
three
fields
in
the
environment.
We
have
the
access
key
ID,
we
have
the
secret
and
we
have
an
s3
bucket
name.
This
is
the
interface
for
the
application.
This
is
what
it
expects
in
terms
of
credentials
right.
A
A
They
give
the
access
key
and
the
secret
key,
and
you
sort
of
inject
that
in
the
application
using
in
this
case
a
set
or
some
other
environment
injection
secret
injection,
I'll,
typically
out-of-band
and
we
hit
enter.
We
can
see
that
this
will
get
installed
and
what
it's
going
to
do
is
it's
going
to
populate
a
secret
which
includes
those
credentials.
It's
going
to
create
a
batch
job
here
and
if
we
go
only
query
in
the
steward
name,
space
get
pods.
A
We
can
see
here
that
we
have
a
manual
s3
consumer
job
that
completed.
So
if
we
take
a
look
at
the
logs
of
this
thing,
we
can
see
this
thing
worked.
It
uploaded
to
de
cabra
TV
bucket
uploaded
a
file.
If
we
go
into
the
s3
console
here
and
hit
refresh
I
can
see.
Gabber
TV
bucket
I
can
see
tests
on
a
tag
open
it
up
and
that's
not
a
nice
business.
A
A
nice
Lachlan
Everson
on
the
team
built
this
thing
so
he's
from
Australia
didn't
guess
that
so
so
that's
sort
of
the
manual
phase
of
this,
but
that
really
stinks
right.
We
had
to
go
through
this
process.
We
had
to
manually
inject
these
credentials.
What,
if
there's
another
way.
So
if
we
took
a
look
inside
of
the
the
next
thing,
I'm
going
to
show
you
here,
which
is
the
template
for
the
instance,
you
can
see
that
we're.
Actually,
you
know
what
let
me
just
install
and
I'll
show
you
the
post
rendered
version
of
that.
A
So
we're
going
to
do
this
again,
but
in
this
case
I
am
just
going
I'm
not
going
to
specify
any
credentials
instead.
I'm
going
to
bundle
into
my
package
a
binding
in
an
instance
and
if
I
do
a
helm,
get
on
s3
consumer,
we
can
take
a
look
at
what
that
got
template
it
out
to
you
can
see
the
instance
here,
references
this
service
class
s,
AWS
s3
plan
name
default.
So
if
I
get
sort
of
this
class
name
steward,
you
can
see
this
AWS
s3
item
in
our
catalog.
That's
effectively.
What
this
is.
A
We
output
it
to
llamo.
You
can
see
a
little
more
here.
What
this
looks
like
so
we
see
the
really
long
is
actually
actually
an
icon,
that's
provided
by
this
broker,
and
we
can
see
the
default
plan,
which
is
basically
a
single
s3
storage.
Unlimited
bucket
unlimited,
a
number
of
objects,
that's
basically
what
this
broker
is
providing.
So
if
we
take
a
look
at
the
output
of
this
thing,.
A
We
can
see
the
s3
consumer
nice
thing
about
jobs,
the
first
one
error
it
out
because
the
secret
wasn't
actually
mounted
yet
the
controller
had
to
run
for
a
minute
to
actually
mount
the
secret,
so
the
job
restarted
until
it
got
one
successful
completion.
That's
why
we
use
jobs
folks
and
take
a
look
at
the
output
of
this
thing,
and
we
can
see
the
same
thing
happened
here.
However,
this
time
you'll
notice
that
there
is
a
CF
grid
bucket
name.
A
So
if
we
jump
into
s3,
we
can
see
that
there
is
a
CF
grid
bucket
with
the
same
file
inside
of
it
here
right
so
same
exact
application.
We
didn't
modify
the
app
at
all,
but
what
we
were
able
to
do
is
using
the
service
catalog,
the
s3
service,
AWS
s3
service
class,
and
by
specifying
an
instance
in
the
binding.
Actually,
let's
take
a
look
at
the
binary,
real,
quick,
binding
and
Stewart.
A
Take
a
look
at
the
binding
here.
You
can
see
that
we
reference
the
s3
consumer
instance,
which
is
the
bucket
is
effectively
and
we
provided
it
with
a
secret
name.
This
is
a
where
do
you
put
the
results
of
the
binding?
This
is
going
to
involve.
As
you
know,
there
are
plans
currently
in
the
Service
Catalog
test
sort
of
leverage,
new
features
and
kubernetes
like
yob
were
used
to
be
called
pod.
Injection
policy
now
is
called
pod
preset
correct.
Thank
you.
So
there's
going
to
be
more
flexibility,
it's
won't
just
be
secrets.
A
You'll
be
able
to
secrets
config
Maps
volumes,
lots
of
different
things
that
can
be
preset
into
the
pod
specs.
You
can
also
see
the
status
condition
here.
Inject
bind
result
is
true
right,
so
you
can
see
that
this
thing
actually
completed
end
to
end
and
finish
that
and
if
we
actually
go
grab
the
secret
and.
A
I'll
put
this
TMO:
you
can
see
that
the
name
password
username
this
is
actually
what
got
consumed
by
the
application.
So
this
is
demonstrating
basically
the
automated
provisioning
and
binding,
and
you
know
the
eliminating
sort
of
this
note
passing,
and
this
is
I,
think
incredible.
Cool,
and
this
is,
you
know
why
I
talked
about
that
first
goal,
making
it
easier
to
consume
and
produce
services.
This
is
the
future.
This
is
what
we're
going
to
be
doing
in
a
year
right.
A
There's
another
thing
I
want
to
show
you
here,
which
is
decoupling
provider
from
consumer
right
I,
want
flexibility
as
an
operator
to
do
different
things
to
fulfill
the
service
request
in
different
ways
in
different
environments.
So
what
we're
going
to
do
here
is
I'm
actually
going
to
go
and
install
a
different
broker,
I'm
going
to
install
the
a
Mineo
broker.
How
many
here
are
familiar
with
me:
neo
dominio
project,
okay,
I
love,
this
group
mini
OS,
3,
compatible
storage
system.
I
happen
to
have
one
proceeded
on
my
cluster.
A
The
cluster
I'm
demoing
right
now
is
actually
an
ACS
cluster
because
just
have
to
be
the
last
one.
I
spun
up
running
on
Azure
and
I'm,
connecting
to
s3
right
now
to
do
this
demo,
not
ideal
right
as
an
operator.
That's
not
what
I
want,
but
the
developer
did
it
that
way.
So,
let's
fix
that
right.
So
instead,
what
I'm
going
to
do
is
I'm
going
to
take
the
many
of
that
I
already
have
installed
on
this
local
cluster.
A
That's
actually
co-located
with
the
workload
and
I'm
going
to
load
this
broker,
and
what
this
actually
did
here
is
it
installed
a
basically
off-the-shelf
open
service
broker,
API
for
dominio,
very,
very
simple,
to
crank
one
of
these
out.
It
basically
says
it.
Has
three
endpoints
give
me
the
catalog.
You
know
what
sort
of
services
you
offer.
What
does
it
mean
when
you
provision
one
of
these
things?
How
do
I
get
a
new
instance
effectively,
and
what
does
it
mean
to
bind
to
one
of
these
things?
What
are
the
coordinates?
You
need
to
inject?
A
That's
all
you've
got
to
do
for
these
brokers,
they're,
incredibly
easy
to
crank
out
and
there's
some
future
plans
we
have
in
that
direction.
But
now,
if
I
clear
this
thing,
if
I
get
service
class
in
the
name,
space
steward
I
can
see
all
the
way
that
we
got
Mineo
now
added
as
a
new
service
class.
So
as
a
developer,
what
I
can
do
is
I
want
to
run
that
job
again,
but
I'm
actually
going
to
run
the
Mineo
consumer
job,
which
actually
is
the
same
exact
application
same
exact
workload.
A
A
A
So
we'd
see
here
that
the
we're
looking
at
the
binding
here's
the
instance
we
can
say
the
service
class
name
is
many.
Oh
the
plan
name
is
the
default
plan
for
many
outages.
You
know
the
same
thing
and
the
binding
here
references
that
Mineo
consumer
instance
and
we're
injecting
the
Mineo
consumer
secret
right.
So
now,
if
I
take
a
look
at
this,
this
job
I
can
see.
A
And
see
the
logs
here,
if
you
just
upload
it
again,
using
a
very
similar
CF
grid
name
and
if
I
jump
over
here
into
my
Mineo
browser
and
hit
refresh,
you
can
see.
I've
got
my
bucket
here
with
my
file
and,
if
I
grab
a
link
to
this
thing,
that's
a
nice,
so
we've
managed
to
decouple
provider
from
consumer
without
modifying
the
application
at
all,
we
were
able
to
swap
the
implementation
of
the
backing
service
we've
also
for
the
previous
example,
been
able
to
radically
simplify
what
it
the
experience
looks
like
for
developers.
A
You
know
who
want
to
consume
these
services
and
do
it
in
a
way.
That's
actually
secure
right.
No
more
note,
passing
and
I
I
think
that
you
know
there's
a
big
future
here
in
being
able
to
query
the
these
binding
objects,
get
Steward
binding
output
CMO
by
iterating
over
all
the
bindings
in
the
system.
You
have
all
of
the
data
that
you
need
to
draw
dependency
graph,
so
you
can
envision
a
future
where
every
single
application
you
wrote
even
the
ones
you're
writing
in-house.
A
You
basically
made
the
contract
of
the
developers
that
yeah
you're
going
to
ships
off
over
you're,
also
going
to
publish
that
software
to
the
catalog
and
when
you
publish
it
to
the
catalog,
we're
going
to
be
able
to
open
up
the
SDN
on
the
fly,
we're
going
to
be
able
to
track
bindings
and
we'd,
be
able
to
draw
dependency
graphs
for
people,
but
folks
are
getting
at
this
problem
in
similar
ways
with
things
like
service
meshes.
But
the
problem
with
that
is
those
aren't
generally
very
policy
driven.
A
A
Want
to
be
clear,
this
is
all
under
construction
heavily
under
construction.
There's
a
few
things
I
want
to
point
out
that
are
specifically
related
to
that
construction.
The
first
is
aggregated
API.
So,
interestingly,
this
is
one
of
the
first
projects.
I've
been
involved
in
or
really
known
about.
Generally,
that
is
extending
the
kubernetes
api
significantly
enough
that
you
can't
do
it
with
third-party
resources.
A
This
really
breaks
TP
RS,
and
actually
we
we
knew
that
firsthand,
because
the
first
versions
of
steward
use
TP
RS,
and
you
realize
it
was
just
you're
not
going
to
be
sufficient
for,
for
you
know
something
that
had
this
many
different
types
of
resources-
and
you
know
what
happens
when
you
delete
a
broker
and
that
cascading
deletes
instances,
and
it's
just
really
really
tricky
to
model
that
at
you
know,
inside
of
TP
are
unfortunately
aggregated.
Api
is
not
what
I
would
call
fully
baked.
Yet
it's
getting
there.
A
You
know
I
think
the
future,
for
this
thing
is
bright,
but
until
the
kubernetes
clients
can
actually
discover
all
these
aggregated,
API,
endpoints
and
sort
of
you
know
amalgamate
all
that,
and
so
the
one
presentable
control
plane
surface.
This
is
it's
weird
to
use
this.
You
know
you
can
install
it.
You
can
there's
a
walkthrough
in
the
Service
Catalog
repo,
where
you
can
go
run
through
a
very
similar
demo
to
this.
A
A
Where
you
know,
people
are
brokering
up
all
their
services
and
I
really
think
that
having
an
SDK
to
make
it
easy
to
fill
in
a
few
methods
and
get
effectively
the
ability
to
write
a
broker
with
just
a
few,
you
know
function
implement
all
implemented,
that's
the
future
that
we
need
to
be
in
and
that's
something
that
the
sig
is
going
to
be
taking
on.
I
have
no
doubt,
and
the
last
thing
I
want
to
point
out
is
I,
actually
think
that
there's
an
opportunity
here
to
create
a
higher
level
consumer
API.
A
The
thing
I'm
interested
in
is
I,
don't
as
a
developer
necessarily
want
to
worry
about
a
instance
in
binding
as
first-class
I
think
we
can
wrap
an
abstraction
on
top
of
that.
That,
basically
is
working
at
the
service
protocol
and
service
version
level.
So
you
know
I
want
Postgres
greater
than
or
equal
to
9.4
right,
and
that
should
be
the
intent
that
I
specify
and
then
that
can
compile
down
into
instances
and
bindings.
But
we
need
to
really
think
that
through
because
it
requires
consistent
naming
right.
What
does
Postgres
mean
right?
A
What
is
greater
than
or
dope
9.4
word
mean
across
different
environments.
If
we
can
get
all
the
folks
that
are
currently
involved
in
the
sig
to
collaborate
on
that,
as
well
as
the
communities
like
cloud
foundry
and
something
folks
that
are
working
with
us,
I
think
we
have
a
real
opportunity
to
sort
of
homogenize
a
namespace
and
make
it
just
an
order
of
magnitude
easier
for
developers
to
consume
this
stuff
across
different
platforms,
kubernetes
and
and
and
and
well
beyond.
But
there's
still
some
work
to
do
here
and
I.
A
Think
the
point
of
this
is,
you
know,
we're
at
the
point
now
with
the
the
Service
Catalog,
where
we
have
working
code.
We
have
demos,
there's
a
lot
of
excitement
around
the
work
that's
happening
here.
We
really
need
voices
of
the
user
community
now
and
specifically,
if
operators,
you
know
this.
A
lot
of
this
comes
down
to
what
are
the
interaction
models
that
operators
are
going
to
want
for
this
stuff
going
forward
and
we'd
love
to
have
your
voices
in
the
sig.
So
we
definitely
appreciate
it.
A
A
The
brokers
will
run
in
the
cluster
I.
Sorry,
the
question
was:
how
do
you
create
and
manage
her
two
brokers
going
forward
because
it's
a
critical
part
of
this
process,
so
there
are
off-the-shelf
ones
for
common
services,
but
if
you
want
to
broker
to
your
own
applications,
you're
going
to
have
to
write
one-
and
today
you
unfortunately,
the
API,
for
this
is
not
very
complicated
I'm.
A
In
fact,
one
of
the
folks
in
the
day
team
whipped
up
the
Mineo
broker
and
about
a
day
for
me,
so
you
know
tell
about
this
demo,
so
thank
you
Matt.
By
the
way
you
know
it's
not
that
hard
to
write
these,
however
I
do
think
in
SDK
is
warranted
and
I
think
that's
something
that
will
probably
end
up
tackling
in
the
sig.
It's
my
guess.
A
The
birth
the
broker
is
going
to
be,
you
know,
enumerate
the
plans
for
this
thing.
You
know
Redis
small,
medium
large
right,
what
those
mean
in
terms
of
parameters
to
things
like
the
provision
calls
and
then
what
the
provision
call
looks
like
right.
So
how
do
you
provision
a
new,
a
Redis,
small,
medium
or
large,
and
then
the
third
is
binding?
What
when
someone
binds
to
Redis?
What
does
that
mean
right?
And
how
do
you
return?
You
know
those
those
credentials
and
those
coordinates
back
to
the
consumer
right.
A
A
Yes
well
so
you
know,
the
question
is
a
config,
Maps
and
and
and
more
granularity
around
what
you
can
inject.
That's
absolutely
the
goal.
You
know
secrets
was
the
easy
thing
for
us
to
kind
of
knock
out
in
demo,
but
having
that,
as
the
only
thing
that
you
can
inject-
that's
not
that's-
not
great
I
mean
they're
they're.
Our
future
x'
we're
your
future
brokers
that
were
thinking
through
that
involved
mounting.
You
know
volumes
right
where
you
could
actually
broker
to
a
volume
service
and
actually
get
a
volume
injected.
A
So
pod
presets,
if
you
haven't,
looked
up
those
they
just
landed
in
1.6
check
out
the
dock
actually
on.
My
Twitter
account
actually
have
a
link
to
the
docs
gabart
CV
on
Twitter.
You
can
check
that
out,
but
pod
presets
are
going
to
allow
you
to
make
sort
of
policy
driven
changes
to
pod
specs.
That
will
be
a
better
way
of
fulfilling
what
that
secret
field
is
doing
in
the
binding
right
now,
so
it'd
be
functionally
equivalent
but
more
flexible.
Yes,.
A
That's
a
good
question,
so
the
question
is
around
day
to
operations
for
some
of
these
brokers
and
what
does
that
look
like,
so
the
open
service
broker
API
has
the
concept
of
a
plan
change
and
you
can
make
a
you
know.
So
if
you
provision
this
red
is
small
and
you
need
to
go
to
red
is
large.
There
is
an
API
call
for
that.
I,
don't
quite
know
how
that
works
today.
A
I
would
envision
that
you
would
change
the
plan
name
in
the
spec
for
the
instance
from
small
to
large,
and
we
would
make
that
intent.
You
know
we
would
sort
of
reconcile
that
intent
and
upgrade
the
the
thing
for
you.
Obviously,
the
services
themselves
have
to
be.
You
know
supportive
of
that,
and
that's
not
always
clear.
So
you
know
I
think
it's
a
fine
line.
A
Hi,
how
do
we
see
declaring
relationships
between
services
and
applications?
Yes,
so
you
know
the
concept
of
a
binding,
you
know,
assuming
you
have
done
the
work
to
make
it
easier
to
cross
brokers
and
assuming
that
you
make
brokers
part
of
the
contract
for
shipping,
an
application
which
you
know
is
the
future.
We
can
get
to
I
think
if
we
make
it
easy
and
make
the
SDK
sort
of
plug-and-play
right,
which
is
which
is
something
we
can
do.
Then
you
basically
have
bindings.
A
You
can
query
and
draw
relationships
between
you
know
instances
and-
and
that
can
sort
of
allow
you
to
draw
that
idea
of
a
dependency
graph.
I
think
this
combined
with
service
mesh,
creates
a
really
powerful
solution.
I
think
the
the
interesting
thing
about
this
approach
is
that
by
having
a
provision
call
explicitly
performed,
you
can
do
things
like
open
up.
Sdn
or
you
know,
can
do
your
policy
checks
at
the
last
minute
that
are
just
not
something
we
see
with
service
measures
in
the
world.
A
A
The
lead
from
the
dais
team
here
who's
up
in
the
front,
can
talk
about
kind
of
what
the
schedule
looks
like
for
this
thing
it
is
early,
but
we
are
moving
aggressive
and
you'll
due
to
all
the
demand
that
we're
seeing
from
from
folks
like
yourselves,
we're
going
to
be
under
even
more
pressure
to
get
this
thing
out
soon,
because
people
really
want
it.
So
fast
is
my
answer
that
said,
I
think
non-a
won't
be
until
kubernetes
1-7
that
the
aggregated
api
story
hardens
enough,
where
I
recommend
putting
this
into
anything
resembling
production.