►
From YouTube: WG Platforms Project Meeting - 2022-12-07
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
B
Just
give
give
folks
another
couple
minutes
to
join.
Where
are
you
based
out
of
Thomas
I'm
in.
C
B
C
B
Yeah,
it
was
my
first
time
there
I
liked
it
a
lot
of
bikes.
A
B
A
B
But
yeah
I
finally
had
some
time
to
catch
up.
C
D
I'm
just
trying
to
make
some
suggestions
around
one
of
your
replies
just
now,
so
we
have
something
to
like
compare.
D
Thank
you
for
handling
all
of
the
inbounds.
It's
been
a
lot
a
lot
to
juggle
I'm
sure
and.
B
D
B
Yeah
overall,
it
seems,
like
you
know,
we're
noodling
on
a
few
points
in
those
first
few
sections,
but
I
think
it's
I
think
it's
getting
close
to.
You
know
a
point
where
I
could
put
it
in
GitHub
or
something,
and
we
could
you
know,
keep
iterating
there
I
think
we're
pretty
close,
hey
Rafa.
How
are
you.
B
Good
to
have
you
here
all
right:
let's,
let's
go
ahead
and
get
so
I
think
we
have
a
you
know,
Quorum
whatever
that
means
for
a
year.
Thank
you
all
for
joining.
So
if
you
want
to
put
down
here
I
put
down
in
this
document,
that's
the
platforms,
Ouija
notes,
just
some
things
that
I
wanted
to.
B
You
know
kind
of
bring
out
this
time
and
I
put
in
a
few
last
times,
so
that
seemed
I
was
just
jotting
them
down,
though
now
so
it's
just
it's
relatively
quick
thoughts,
so
first
I
I
guess
I
want
us
to
talk
about.
You
know.
One
of
the
things
we
talked
about
last
time
was:
are
there
two
layers
to
a
platform?
B
You
know
the
the
layer
of
collection
of
capabilities
and
then
this
the
more
composites
scenario,
specific
golden
path,
kind
of
environments
that
are
built
on
top
and
we
kind
of
said
no-
that
lower
level
is
not
part
of
the
platform,
but
since
then
I've
had
a
few
conversations
and
I've
kind
of
been
liking.
This
idea
that
maybe
both
are
part
of
the
platform,
meaning
you
can
a
platform.
You
know
May
at
its
most
basic
just
offer
you
well
I
need
a
database
well,
I
need
a
kubernetes
namespace.
B
Well,
I
need
a
space
in
tecton
to
run
my
Pipelines,
and
that
would
be
you
know
that
could
be
a
basic
platform,
but
that
a
more
advanced
platform,
a
more
mature
platform
might
take
those
bring
them
all
together
to
say:
okay,
this
is
a
developer
environment.
It's
got.
You
know,
database
pipeline,
you
know
kubernetes
namespace,
all
you
know
templated
out
right
from
the
start,
so
yeah
I
guess
we
could
have
a
discussion
about
that
I
kind
of
been
changing
the
dock,
to
kind
of
reflect
that
idea.
B
So
I
guess:
let's,
let's
talk
about
that.
What
do
people
think
or
we
could
talk
about
as
we
go
through.
E
E
Perhaps
what
people
have
in
mind
when
they
say
they're
not
is,
is
that
typically,
they
will
belong
to
different
teams,
but
I
don't
map
a
team
to
a
platform.
The
platform
for
for
me
can
span
multiple
teams.
B
I
hear
that
I
hear
that
maybe
associated
with
a
Civic
team.
You
know
how
we
kind
of
were
touching
on
that
last
time
is
that
we
ended
up
saying
the
platform
team.
Never
I
mean
they
could
be
but
they're,
not
by
definition.
They
don't
manage
the
underlying
implementation
of
the
capability,
like
that,
might
there
might
be
10
different
teams
in
your
company?
You
know
one
manages
pipeline
Runners,
one
manages
storage,
one
manages
compute
or
something.
E
C
A
C
Like
to
focus
on
the
composition
part,
there
I'm
not
sure
about
splitting
between
individual
and
composite
in
very
fixed
terms,
because
I
think
it
could
be
difficult
also
to
Define.
What
do
we
mean
by
individual?
Let's
say
a
database.
C
Is
that
individual
or
is
that
the
composite
capability
that
includes
the
network,
the
storage,
the
security
and
the
database
as
well
or
not
yeah,
yeah
I,
don't
know
about
that.
D
Yeah,
my
experience
has
been
that
there
tends
to
be
abstraction
layers
that
grow
up
and
up
right.
So
it's
like
that,
when
there
are
many
teams
providing
capabilities
that
you
end
up
with
teams
that
provide
capabilities
that
in
their
raw
form,
provide
value
but
are
actually
multiple
their
values
that
much
higher.
When
you
have
a
team
that
composes
that
experience
across
like
a
few
of
the
capabilities,
which
is
what
you're
talking
about
like
a
Dev
environment,
kind
of
composed
platform
capability.
But.
B
C
Yeah
and
focus
maybe
on
the
obstructions
that
Abby
mentioned,
like
yeah
I
like
it
in
the
diagram.
Perhaps
we
have
the
pipeline
service
in
a
very
abstract
way
and
or
a
data
service
security,
vulnerability
service
and
that
those
are
the
in
an
abstract
way.
What
we
compose
together
in
different
setups,
depending
on
the
use
case,
it
could
be
a
full
developer
platform
dealing
with
applications,
but
it
could
be
something
else
like
a
deployment
platform,
that
the
input
is
a
container
image
already.
C
So
what
happened
before
it
happens
outside
the
platform
and
both
for
use
cases,
but
also
for
onboarding
I.
Think
some
teams,
when
they
start
onboarding
a
new
platform.
They
don't
necessarily
do
the
whole
thing
right
away,
but
they
go
step
by
step,
so
they
could
start
onboarding
capabilities
from
the
platform
yeah
in
different
different
steps,
different
iterations,
so
having
the
focus
on
capabilities
and
the
com
composition
of
those
capabilities,
I
think
can
help
us
here
address
all
these
different
scenarios.
B
B
Maybe
that's
something
to
think
about
like
even
as
you
guys
are
talking
like
if
we
had
a
diagram
showing
here's
the
developer
platform
with
this,
you
know
six
capabilities.
That
would
then
that
would
be
a
good
way
to
illustrate
hey.
You
could
also
pull
out.
You
know
you
don't
want
the
whole
thing.
You
just
need
one
or
two
capabilities.
That
might
be
a
good
way
to
talk
about
it.
B
I'm
gonna
put
that
here.
Also,
okay,
let's
think
about
this
I,
don't
that's
something
I
think
about
in
general
is
like
how
we
the
doc's,
already
eight
pages
long,
even
just
in
Google
Docs.
So
how
do
we?
You
know?
How
much
do
we
elaborate
on
that
another
one
I
wanted
to
mention
that
somebody
called
out
is
measuring
success.
That
would
that
seems
like
a
great
idea.
B
That's
missing
really
from
here
we
kind
of
say
these:
are
you
know
the
attributes
that
would
make
your
platform
successful,
but
how
do
people
measure
I
actually
could
use
some
insights
there?
So
that's
that's
just
an
open
one
right
now,
but
I
added
a
bullet
for
it
here
and
then
the
last
thing
to
consider
is
yeah
developer
platforms.
E
On
measuring
success
yeah,
if
it's
a
platform
for
Developers,
is
isn't
the
Dora
Matrix.
What
we
use
to
measure
this
success
of
Performing
or
the
ability
to
perform
of
developer
teams,
or
are
you
looking
for
something
else.
B
I
mean
that
could
be.
That
could
be
one
of
them
yeah
for
that
yeah
for
those
scenarios.
B
Yeah
measure
the
reduction
in
time
or
increase
in
you,
know
frequency
of
whatever
task
it's
supposed
to
be
enabling
develop
app
development
right
so
measure
the
dura
metrics.
Okay
I
like
that.
Thank
you.
Let's
put
that
in.
C
So
Spotify
in
the
the
article
where
they
presented
the
golden
path.
They
also
mentioned
these
metrics
they
used
about
when
on
boarding
new
people.
How
long
does
it
take
to
get
to
10
pool,
request,
merch
and
deliver
to
production
so
to
test?
If
how
effective
is
the
the
platform
in
delivering
that
experience
and
the
acceleration
of
the
path
to
production,
I
guess
next
to
the
dura
Matrix?
That
could
help
tweaking
and
refining
the
platform
right
to
get
to
the
yeah,
where
we
want
it
to
be.
D
On
that
Spotify
example,
I
think
it's
the
conversation
of.
Can
you
identify
how
many,
how
often
people
need
to
dive
diverge
from
the
platform
offerings
right
from
like
a
way
that
so
there's
there's
two
levels
of
Divergence
right,
there's
Divergence
from
the
golden
path
to
the
underlying
resources
and
then
there's
Divergence
from
the
underlying
resources
to
other
underlying
resources.
So,
like
you
offer
postgres
and
they
want
my
sequel
or
nosql
or
whatever,
right
and
like
what
are?
D
How
many
times
do
people
have
to
go
off
platform
for
things,
it's
just
like
any
other
product
right.
When
do
your
people
go
to
a
different
provider
instead
of
yourself?
Can
you
measure
that
in
some
way,.
B
Cool
yeah,
I
kind
of
think
that
should
be
another
section.
I.
E
D
C
B
The
fact
that
we
have
a
few
that
that
that
that
argues
for
a
section
for
it
so
that
you
know
people
could
contribute
on
GitHub
or
something
one
day
cool.
Thank
you
so,
where
we
left
off
last
time
really
was
section
six.
So,
let's
just
I'm
just
gonna
scroll
through
relatively
quickly
the
rest.
We
were
just
talking.
What
a
platform
is.
This
is
where
it
now
kind
of
talks
about
basic
platform,
with
just
a
collection
of
individual
capabilities
and
more
advanced
platform
with
compositions.
B
So
that's
the
main
change
there
platform
capability
providers.
That
was
what
we
kind
of
came
up
with
last
time
to
describe
the
people
that
go.
The
teams
that
go
underneath
here
and
I
updated
this
picture
to
to
kind
of
make
those
a
little
bigger
and
emphasize
their
their
role
in
this.
It's.
B
D
They're
not
I,
get
like
are
people
I
guess.
The
question
is:
are
people
providing
the
end
users
of
the
platform,
a
asking
them
to
create
a
cross-plane
crd
or
asking
them
to
create
a
like
a
crd,
to
trigger
an
operator,
or
are
they
wrapping
those
in
an
API?
That
is
then
leveraging
a
tool
like
an
operator
like
cross
plane
to
do
the
platform
work
and
that's
sort
of
like
where
we
talk
about,
like
the
the
experience
of
it
and
and
separating
the
platform
implementation
from
the
user.
D
Experience
like
changing
from
using
terraform
to
using
palumi
shouldn't
impact
a
user's
experience
at
all,
but
when
we
take
those
kinds
of
tools
and
put
them
up
at
the
API
level,
it
would
change
their
experience
if
you
were
to
change
from
using
an
operator
to
using
a
Helm
chart,
or
vice
versa
or
whatever
right
yeah.
So
I'm
just
curious
what
other
people
think
right,
because
I
don't
I.
Look
at
that
as
like
a
gap
where
that
wouldn't
quite
fit.
C
Yeah
I
agree
with
you
also
for
me,
it
would
make
sense
to
have
them
in
provide
environments
and
resources,
or
at
least
that's
how
I
think
of
them,
not
as
an
API
exposed
to
the
end
user,
yeah.
D
D
B
D
Guess
that's
why
I
put
so
my
just
to
like
put
the
to
where
it
was,
was
that
all
four
of
those
logos
were
in
the
purple
box
with
provide
environments
and
resources
yeah
and
when
we
switched
to
apis
I
threw
I,
threw
critics
up
to
the
API
level.
The
reason
I
did
that
or
the
reason
I
felt
like
that
was
the
right
place
is
because
craddix
is
a
framework
that
allows
the
platform
team
to
Define
an
interface
with
their
users,
backed
by
whatever
tools
they
want
to
use.
D
So
credits
is
not
trying
to
configure
public
clouds.
That's
what
cross
plane
does
well
use
cross
plane.
It
is
not
trying
to
vend
databases.
That's
what
the
operators
for
those
databases
do
well
use
them.
What
we're
trying
to
do
is
separate
put
in
a
layer
of
separation
between
the
tools,
you're
choosing
to
use
as
a
as
a
platform
team
and
how
you're
choosing
to
schedule
those
across
quite
a
large
landscape
of
infrastructure
and
the
users
that
are
like
I.
B
E
I
was
gonna,
say:
I
was
just
having
a
similar
discussion
in
my
previous
meeting.
E
Perhaps
the
separation
of
the
you
know,
user
experience
versus
the
actual
orchestrate
of
the
build
infrastructure
is
is
actually
good
right.
So,
as
the
user
experience
you
know,
I
I
need
something
that
is
good
at
making
PR
on
gates
with
the
content
that
I
need.
Perhaps
we
all
have
in
mind
backstage
for
that
role,
but
you
know
it
could
be
something
else.
E
Then.
What's
behind
that
I
don't
care
as
a
user
right,
but
the
platform
Builders.
Of
course
they
care
right
and,
and
then
I,
don't
know
I
democratics.
But
if,
if
you
can
play
a
role
in
that
in
that
space,
But
I
know
that
you
know
things
like
you
know.
If
you're
doing
githubs
with
kubernetes,
then
there
are
githubs
operators
that
can
take
that
content
and
put
it
in
the
in
the
cluster
and
then
it
will
hopefully
be
realized
right.
D
Yep,
so
what
you're
saying
is
that,
if
you
put
into
like
a
form
in
backstage
that
asks
for
a
few
fields
and
what
that
ends
up
doing
is
generating
a
pull
request
for
a
crd
of
type
xrd
for
cross-plane
or
whatever,
like
that,
would
all
the
user
cares
about?
Is
they
filled
in
a
form
and
backstage?
And
all
the
platform
cares
about?
Is
that
it
was
able
to
like
take
the
data
from
that
form
and
like
send
it
on
its
way.
Like
so.
E
What
the
classroom
even
cares,
that
there
is
something
engaged
I,
don't
even
care
how
it
got
there
right.
They
just
have
to
their
commitment,
is
to
take
that
and
make
it
become
true,
and
it
doesn't.
You
know
if
we're
talking
about
get
are,
are
going
this
kubernetes
githubs
operators
Dino?
Yes,
it
needs
to
be
a
crd
or
a
CR
right,
but
it
could
be
a
it
could
be.
Other
things
like
there
are
ways
to
do.
D
I
think
that's
where
you're
100
right
there's
ways
to
do
it
with
terraform
I,
again,
I've
not
done
that
in
Anger,
like
at
scale
either.
So
I
can't
speak
too
intelligently
to
it.
D
But
I
think
that
since
we're
writing
this
for
Enterprises
I
think
the
idea
that
they
have
that
everything
they
do
can
be
done
via
a
CR
on
kubernetes
is
probably
unlikely
right.
Just
being
realistic,
like
they're
gonna
have
things
that
are
going
to
be
not
configurable.
That
way,
and
that's
where,
in
my
opinion,
putting
like
putting
a
tool,
the
tools
that
are
kubernetes
only
kind
of
like
where
they
can't
then
orchestrate
off,
kubernetes,
stuff
or
like
stuff
that
doesn't
that
can't
be
configured
via
the
The
Operators
and
whatnot.
D
It's
like
a
limitation,
but
I,
don't
think
it's
a
big
deal
right,
like
I,
think
they
all
are
apis,
I,
think
yeah,
so
I
think
they're
all
apis.
It's
just
at
what
level
of
abstraction
those
apis
are
at
and
I'm,
not
too
stressed
about
it.
I
just
wanted
to
call
out
that
I
was
interested
to
see
those
move,
because
I
do
feel
like
they're
at
a
slightly
different
level
of
abstraction.
E
I,
don't
want
to
say
that
you
have
to
necessarily
create
CRS
right.
It
could
be
anything
that
can
be
interpreted
by
agit
guitar
tool,
I'm,
even
afraid
of
saying
that
you
have
to
be.
You
have
to
have
a
lot
of
githubs
to
have
a
platform
right.
Maybe
that's
not
true,
but
I
think
you
know
maybe
something
that
we
have
to
discuss.
Do
we
want
to
push
in
that
direction
or
not
I
think
the
world
is
going
in
that
direction,
but
that's
my
opinion.
B
So
I
think
that
the
way
you're
using
get
Ops
rough
is
the
way
that
I'm
using
the
word
apis.
In
other
words,
those
yaml
files
that
you
check
in
to
get
are
the
requests
that
you
send
via
HTTP.
It's
just
that
git
Ops,
you
know
it's
a
pulled
model
or
whatever
event
driven
model.
Instead
of
me,
you
know
submitting
an
HTTP
request,
but
ultimately
you
know
the
stuff
that
you
jot
down
in
the
ammo
files
in
in.
A
B
C
I,
like
the
distinguishing
like
I
guess
everything
works
with
apis
right,
all
those
capabilities
they
work
with
apis,
but
the
apis
in
the
blue
box.
There
that's
the
API,
we
exposed
to
the
end
user,
so
I
think
in
that
way,
I
can
see
that
using
credits
or
cross-plane
to
do
that.
But
an
operator
for
example,
I
I,
wouldn't
use
that
I
wouldn't
expose
that
to
the
end
user.
C
C
C
Would
say
that
there's
an
implementation
detail
so
from
the
interface
in
the
platform,
how
do
I
get
to
the
platform
capability
deployed
and
yeah,
of
course,
most
of
the
times?
It's
that
model
there,
but
perhaps
at
this
level,
I
don't
see
I,
don't
see
it
important
to
surface
in
this
picture,
like
I
I,
look
at
it
more
as
an
implementation
detail.
What.
B
I'm
hearing
from
what
I
heard
from
Abby
and
I
think
you're,
reflecting
it
Thomas
also
is
that
the
use
It's
like
because,
when
I
think
across
I'm
like
well,
you
could
build
a
composition
that
would
look
just
like
a
critics
composition,
but
you're
I
think
what
Abby
is
saying
is
that
cross
plane
is
is
for
cloud
resources
so
like.
If
it's
that,
if
that's
this
target
use
case,
then
it
doesn't
go
up
here.
B
D
To
be
fair
to
cross
play
and
it
does
do
off-cluster
resources
right,
just
like
terraform
has
providers
for
like
pagerduty,
like
SAS
providers
right
like
cross
plain,
has
the
same
potential
to
do
the
same
thing.
It
is
just
the
ability
to
so.
If
you
can,
if
you
can
write
a
controller
for
it,
it
can
be
in
the
cluster
right
like
so
so
that
I
do
I,
don't
want
to
like
pigeonhole
of
cross
plane
into
only
cloud
provider,
things
that
don't
think
it
needs
to
be
I.
D
Think
it's
currently
has
heavily
in
that
space,
but
doesn't
need
to
be
I.
Think
the
the
reason
why
I
see
a
difference.
There
is
because
it's
quite
static
of
like
you,
all
you
can
do
is
throw
some
yaml
at
it.
What
happens
if
there's
like
some
like
imperative
actions
that
you
need
to
take
as
a
part
of
putting
together
your
platform
like
everyone,
wants
a
declarative
world
I
get
it,
but
not
everything's
declarative
like
it
just
isn't.
D
Sometimes
you
need
to
do
an
imperative
action
and
cross-plane
can't
support
that,
and
so
there
will
be
limitations
as
to
like
you
will
need
to
put
some
sort
of
something
wrapping
cross-plane
in
order
to
do
Enterprise
level
in
my
experience,
Enterprise
level
kind
of
stuff
and
so
but
I'd
be
comfortable
with
I.
Think
operators
is,
and
operators
is
a
fair
one,
definitely
to
move
into
the
provide
environments
and
resources,
I
think
yeah,
crosslane
and
the
kubernetes
logo
I
can
see
going
either
way.
B
So
yeah
now
this
makes
a
lot
of
sense
and
another
thing
I'm
taking
from
you
all
right
now,
is
that
the
GUI
is
going
to
write
according
to
those
apis
like
there
there's
I,
guess,
that's
obvious
that
they're
tied
to
each
other,
the
GUI,
is
over
the
API.
A
lot
of
the
users
will
interact
just
with
the
GUI
but
end
up
with
the
API,
the
API
Bridges
from
the
GUI
experience
to
the
implementation.
A
D
That
might
be
where
the
advanced
users
differ
right,
more
more
entry
level
users,
they
use
a
simple
form,
and
if
you
want
access
to
certain
capability
like
certain
fields
or
whatever
you
have
to
go
straight
to
the
API
right,
you
might
not
expose
100
of
the
fields
via
the
Via
backstage
you
know
whatever
right
so
there
might
be.
That
might
be
one
of
the
differentiators
of
like
paved
paths,
golden
paths
versus
like
composed
things
you
can
do
via
the
API.
That's
up
to
the
platform
deliverers
to
to
side.
B
B
Okay,
let's
keep
going
just
being
conscious
of
time.
We
talked
about
why
a
platform
is
valuable.
Last
time,
I
think
the
one
thing
that
we
added
really
here
was.
This
is
a
comment
that
you
Abby
were
oh
I,
see
you
have
someone
here
which
I
haven't
I,
didn't
look,
but
that
the
ReUse
and
sharing
is
another
value,
so
people
could
switch
teams.
New
products
could
be
developed
faster
because
the
person
that's
on
on
team
a
can
switch
to
Team
B
and
get
started
on
day,
one
that
seemed
worth
calling
out
independently.
B
Next,
this
also
kind
of
reflected
that
change
to
like
individual
pla.
This
was
got
a
little
tricky,
an
individual
capabilities
using
individual
capabilities,
and
then
you
know
composing
capabilities
and
here
focusing
on
developer
platform,
actually
I
think
rafta
started
with
your
list
of
items
and
this
there's
probably
room
to
iterate
on
what
you
know.
What
exactly
goes
here.
I
know
you
have
a
comment
on
mine
Abby
like
what's
the
difference
between
number
one
and
number
three,
and
it
was
like
Inner
Loop
and
outer
loop
was
mine.
D
Which
was
totally
fair,
I
took
a
stab
at
changing
the
vocabulary,
a
little
bit
to
call
more
attention
to
that
feel,
free
to
accept
or
decline
those,
but
that
was
yeah
totally
fair
answer.
I
just
didn't
catch
that
my
first
read
so
I
was
hoping
to
make
that
a
bit
clearer
for
the
next
read.
B
B
I
guess
I'm
just
putting
that
out
there.
Somebody
wants
to
take
a
shot
at
that
or
I
might
in
the
next
little,
while
too,
let's
see
attributes
of
platforms.
B
B
Yeah
so
I
did
add
this.
We
wanted
to
use
the
word
product
in
that
first,
one
I
guess
I
hope.
That's!
Okay.
We
move
this
up
to
here.
B
B
Okay,
keeping
going
down
attributes
of
platform
teams.
I
know
Rafa.
You
had
said
at
the
beginning,
so
we
can
pick
up
what
you
had
said
here.
You
don't
think
there
is
a
platform
team
necessarily
which
I,
which
I
hear
I
kind
of,
want
to
bring
that
up
again
for
discussion
here.
I
think
you
were
saying
you
don't
need
a
platform
team
if
all
of
the
capability
teams
can
cooperate
amongst
themselves.
To
prove
is
that
what
you're
kind
of
saying,
you're,
you're,
muted,
by
the
way,
if
you're
talking
Rob.
E
That's
a
desirable
outcome.
What
what
I
you
know!
The
consistency
is
a
desirable
outcome.
What
I
see
in
the
field
is
that
when
you
take
this,
when
you
take
this
this
challenge,
it
is
building
a
platform
tasks
seriously.
E
It
becomes
so
Broad
in
scope
so
quickly
that
it's
hard
to
imagine
a
team
that
can
do
everything
right,
so
I
have
a
customer
that
is
trying
to
do
it,
and
it's
probably
not
going
to
work
very
soon
right
at
some
point,
it's
just
too
large
right
building
pipeline
is
very
different
than
monitoring
application
like
completely
different
set
of
skills
right.
But
those
two
capabilities
for
me
are
capabilities
that
should
come
out
of
the
platform
as
I
look
at
the
platform
as
a
as
a
developer.
E
Yeah,
my
point
was
on
the
my
my
stress.
Maybe
it
wasn't
clear
was
on
the
a
platform
team,
but
more
than
one
right
there
would
be
I
think
there
will
be
multiple
teams
working
at
the
platform
level,
that
that's
that's,
how
I
would
say
it
right
as
opposed
to
building
applications
that
provide
value
to
the
directly
to
the
business
right.
B
B
If
that
platform
team
can
be
really
thin,
then
it
can
spread
over
all
of
these
capabilities.
But
what
I
think
I'm
hearing
from
you
RAF
is
that
that's
that's
wishful
thinking,
because
the
domains
are
too
different,
even
if
you're
just
managing
the
interface
to
the
capabilities.
It's
it.
You
gotta
have
a
different
understanding
if
you're
doing
observability
and
if
you're
doing
Pipelines.
D
You'd
end
up
with
like
a
backstage
team,
but
actually
the
people
who
should
be
making
the
backstage
components
are
the
teams
that
are
delivering
the
components
behind
there
right
rather
than
having
a
team.
That's
in
charge
of
Backstage
components.
You'd
have
a
team.
That's
like
that.
Every
team
should
do
full
stack
delivery
right
from
the
like
user
interface
for
their
product
as
well
or
their
their
service,
as
well
as
down
to
like
the
implementation
and
delivery
and
operations
of
it.
B
That's
actually
and
the
platform
team
is
the
herder
of
cats.
Is
the
is
the
team
that
says
hey
every
capability
team.
You
must,
you
know,
provide
a
backstage
plug-in,
you
must
provide
a
cross-plane,
a
kubernetes,
API
or
a
terraform
manifest
you
know
is
that?
Can
we
reduce
the
platform
team
to
being
an
aggregation
of
everything
underneath.
D
I
sort
of
agree
with
Rafa
that,
like
I,
would
prefer
the
language
being
around
the
multiple
teams
than
the
thinnest
team.
The
reason
I
say
that
is
because
it's
like
what
what
you're
describing
there
has
been
solved
in
different
ways
of
different
orgs.
Sometimes
it's
a
thin
team
right.
D
Sometimes
it's
a
collection
of
like
tech
leads
from
each
of
the
teams
that
like
collaborate
on
like
what
are
standards
right
and
then
it's
like
a
shared
standards
document
and
like
I,
think
I
think
you're
right
that
they're
so
Rafa
you,
you
were
saying
standards
matter
like
consistency,
matters,
I
agree
with
that
statement
and
Josh.
You
were
saying
one
very
reasonable
way
to
solve
that
problem,
but
I
think
there's
other
reasonable
ways
to
solve
it.
That
can
include
multiple
teams,
and
so
maybe
it
is
just
focusing
on
that
point.
D
E
No
I
I
feel
there
is
things
that
we
still
have
to
learn
in
this
space
like
this
is
we're
talking
about
team
topologies
here
about.
When
you
build
platform,
it's
still
I,
don't
have
a
ready
to
go.
Solutions
I
just
see
that
maybe
a
few
customers
start
with
a
single
team
right,
but
it
doesn't
scale.
It's
not
a
good
way
to
scale.
It's.
B
E
You
might
no
my
experience.
You
first
build
a
platform,
then
perhaps
you
put
a
UI
in
front
of
it.
Okay,
so
yeah
yeah
and
you
can.
You
can
absolutely
have
a
backstage
team.
That's
not
that's,
not
a
big
deal
right,
but
the
pla
that,
for
me,
that's
just
a
portal.
That's
just
a
UI
there's
much
more!
The
through
the
mid
is
below
right
and
and
that's
where
I
see
very
hard
to
give
all
over
the
responsibilities
to
a
single
team.
B
F
E
E
B
I'm
I'm
kind
of
asking
like,
should
we
phrase
this
section
to
be
the
top
responsibility
of
the
platform
team?
Is
that
consistent
experience,
even
though
or
and
they
will
be
deeper
into
what
comes
behind
it
in
that
you
know?
Should
we
should
we
reflect
kind
of
those
two
rules
like
they
own
that
top
level
but
they're,
and
then,
where
you
guys
are
kind
of
getting
like
they're
gonna,
also
have
to
get
into
the
deeper
levels
too,
is.
C
That
yeah
I
wouldn't
go
too
much
into
how
they
are
organized,
at
least
in
these
context,
but
more
yeah.
As
you
said,
the
responsibility,
since
we
treat
the
platform
as
a
product,
we
have
product
management.
So
there's
one
single
point
of
contact
for
the
product
teams
that
want
to
have
an
idea
about
the
platforms
and
consistency
and
all
of
that.
But
perhaps
we
can
just
be
generic
about
platform
teams.
B
C
And
I
guess
that's
what
we
do
with
normal
software
products,
even
if
there
are
multiple
teams
working
on
different
microservices
or
whatever
still
as
a
customer
I
have
one
point
of
contact
and
there's
one
product
manager.
Typically
that
ensure
the
consistency,
the
roadmap,
the
vision
for
the
whole
product
and
the
customers
don't
see
how
behind
the
scenes.
Everything
is
organized.
C
Then
here
we're
talking
about
internally.
So
perhaps
you
know-
and
so
it's
different
I
know,
but
that
product
mindset,
I.
D
C
D
Point
where
you're
needing
you
know
five,
ten,
more
platform
teams
all
like
in
their
own
capabilities,
you're,
going
to
be
in
the
space
where
someone
just
needs
a
point
of
contact,
and
then
that
person-
that's
your
customer
service
team
and
then
your
customer
service
seems
to
know
how
to
filter
out
the
conversation
to
the
to
the
people
right
you're.
This
is
just
a
product.
Everything
that
sits
for
product
sits
for
this
and
it
should
be
built
to
the
scale
your
product
is
built
to.
D
A
B
Feel
like
what
I,
what
I
am
coming
out
from
as
I'd
like
to
like
mention
I,
don't
know
if
it's
mentioned
the
product
manager
role
somehow
like
like
try
to
say
that
there
is
a
point
of
contact
for
the
app
teams
like
there.
There
is.
You
know
one
channel
really
for
them
to
get
to
to
send
feedback
in
to
find
out
roadmap.
A
B
Hey
Colin,
yeah,
sorry,
Hi
I
only
see
four
of
them,
I
think
yeah
yeah,
product
owner
product
manager,
okay,
I,
I,
guess,
I
want
to
kind
of
see.
If
we
can.
F
Like
in
in
smaller
teams,
you
have
a
situation
where
it's
probably
an
active
guy,
that's
grown
into
a
role
where
he's
put
a
bunch
of
cicd
systems
together,
and
this
has
evolved
to
a
thing
like
the
platform
and
they
may
graduate
into
a
position
where
they
just
own
that,
where
they
just
become
the
de
facto
point
of
contact,
at
least
in
a
smaller
team
context,
and
in
this
case
it's
and
again
back
at
smaller
companies
and
the
folks
that
are
going
to
be
adopting
this,
not
necessarily
from
like
the
big
company
down
that
are
adopting
this
mindset.
F
It
might
be
done
by
committee
at
first
as
well,
and
so
in
in
my
head.
It's
focusing
on
those
roles
and
responsibilities,
like
you
guys
are
mentioning.
Is
it's
the
key
thing
here
and
I
think
you
may
get
to
a
point
where
you
have
a
team
that
is
dedicated
and
maybe
that's
like
when
you
have
a
platform
team.
This
is
what
a
team
would
look
like,
but
it's
not
necessary
that
you
name
somebody
the
platform
team
or
the
platform
engineer.
B
Yeah
yeah
I
think
it
might
even
be
more.
If
you
do
end
up
with
more
than
one
platform
team
managing
different
capabilities,
then
you
have
to
start
thinking
about
coherence
across
them.
Okay,
I
I
think
that's
I.
Putting
the
role
or
responsibility
down
here
somehow
I
think
that's
what
I'm
gonna
take
away.
So,
let's
noodle
on
that
a
little
bit
more.
B
Yeah,
the
let's:
let's
go
ahead
and
move
on
to
capabilities
of
platforms.
This
was
the
last
topic
and
I
want
to
get
the
thoughts
here.
So
the
idea
here
I
know
Abby
had
brought
up.
Maybe
we
should
split
this
out.
You
know.
The
idea
here
for
me
is
like
I'm,
a
platform
engineer
or
an
Enterprise
architect
and
I
want
to
assess.
Like
is
my
platform
or
you
know,
whatever
somebody's
proposing
to
me
for
a
platform
doesn't
have
you
know
what
my
developers
are
going
to
need
to
be
successful?
B
You
know
kind
of
a
checklist
of
things
that
they
you
know
should
have
must
have.
You
know
should
be
on
the
lookout
for
so
that's
why
I
kind
of
felt
like
it
it
should
go
here.
You
know
to
kind
of
inform
that,
like
this
is
the
this
is
the
meat
of
the
platform.
B
Yeah
so
yeah
with
that
I
put
that
down
the
goal
of
this
is
a
guy
platform
thing.
What
should
be
or
including
their
platform.
You
can
work
on
phrase,
but
I
guess
working
through
them.
I'll
just
read
them
web
portal,
like
so
every
platform
should
have
a
web
portal.
I
hear,
put
provisioning
and
observing
that's
kind
of
what
I
think
you
know
would
end
up
the
portal.
B
This
goes
back
to
what
we're
saying
before
apis
and
clis,
which
are
actually
the
force
behind
the
portal.
Also
I
think
we've
all
agreed
on
that
golden
path,
templates,
I,
guess
this
isn't
required
technically,
and
in
fact
we
just
had
a
presentation
at
Red
Hat
last
week
of
a
place
that
didn't
didn't
really
have
any
golden
path
templates.
They
just
offered
a
lot
of
individual
capabilities,
but
this
is
like
a
probably
I
should
have
like
you
know.
Maybe
that's
like
a
maturity.
C
B
Yeah
I
hear
you,
it
might
be
worth
somehow
it
doesn't
have
to
be
a
huge
deal,
but
somehow
indicating
some
of
these
are
are
more
optional
and
some
of
them
are
like
basic
I,
think
we'd
all
agree.
Apis
are
basic
and
then
these
next
couples,
automation
for
and
I
split
these
into
two.
Let's
talk
about
that
automation
for
building
and
testing
and
automation
for
delivering
and
verifying
I
guess
you
know,
kind
of
thinking
about
building
and
testing
is
more
pipelines.
B
You
know
your
mvn
install
or
npm
build
your
mochas
and
jests
and
J
units
kind
of
testing,
maybe
Jenkins
or
tecton
more
and
then
the
next
one
is
more
delivery,
where
I'm
kind
of
leaning
more
to
the
get
Ops
tools
and
reconcilers
verifying
I,
think
of
Captain
and
other
like
observability
systems.
You
know
chaos,
tests.
E
I
think
the
word
is
used
to
see
in
CD
for
this
concept,
I'm
not
sure
if
I
would
change.
I
I
am
slightly
against
Bill
I'm,
okay,
with
using
building
and
delivering
in
in
place
of
CI
and
CD
right,
it's
more
or
less
the
same
context
on
and
testing
and
verifying
is
a
I
think
there
is
there's
many.
There
are
many
more
ends
if
you,
if
we
want
to
start
to
be
detailed,
I,
wouldn't
I,
wouldn't
do
it
here.
E
B
E
B
C
I
wouldn't
mentioned
cicd
I
I
think
yeah
could
be
confusing.
They're
really
used
a
lot
for
different
things,
those
terms
but.
C
Clear
building
and
testing
and
delivering
and
verifying
I,
also
like
that
they
are
split
because
a
new
team
onboarding
on
the
platform
they
could
start
just
with
the
delivering
a
very
fine
part
and
only
afterwards
also
migrated
pipelines
for
building
and
testing
onto
the
platform.
So
I,
really
like
that
they're
split
there.
B
F
A
quick
question
relating
to
these
as
far
as
management
of
like
multiple
environments,
it's
like
we've
got
Dev
stage
product
QA.
Do
those
do
we
roll
that
up
under
one
idea
of
the
platform
or
like?
Is
that
something
to
con?
Consider,
for
is
the
platform
responsible
for
multiple
environments
or
just
like
a
singular,
does
that
matter.
B
Previously
sorry,
it's
come
up.
There
was
actually
someone
had
a
note
about
it
too,
but
it
has
come
up
along
the
way.
There's
a
few
places
where
we
say
both
research,
development
and
production,
I
guess
yeah,
we
could
say
all
of
these
things
should
apply
to
like
this
stuff
should
be
usable
for
production
environments
too.
F
F
Know
that
I
would
throw
it
in
like
four
or
five,
but
just
thinking
about
it.
It
comes
down
for
me
to
the
definition
of
like
what
is
your
platform
and
how
expansive
is
that
and
what
is
it
encapsulate,
but
because
it
could
just
be
that
the
platform
is
the
production
system
right
and
all
the
developers
are
free
to
just
kind
of
like
run
their
own
Solutions
and
things
like
that.
F
D
A
D
D
I
think
we
talk
about
in
the
capabilities
and
stuff
things
about
building
up
Enviro
like
test
environments
and
things
I.
Think
it's
interesting
when
you
talk
so
I
was
talking
to
someone
who's,
a
customer
for
credits.
It
was
like
when,
when
somebody
requests
a
redis,
we
need
that
to
exist
in
every
environment,
for
them
and
it's
like
and
other
people,
it's
like.
No,
no.
D
We
want
them
to
like
request
a
redis
for
an
environment
and
like
so
it's
just
you
kind
of
get
those
different
experiences
and
again
that's
why
to
me
the
fact
that
we
have
the
word
product
added
earlier
and
the
fact
that
that's
something
that
we
have
is
a
Common
Thread
is
like
the
thing
that
ties
all
this
together
now,
whether
or
not
Executives
that
are
reading
this
clock
onto
that
quite
as
strongly
I,
don't
know.
But
to
me
that's
the
that's.
The
linchpin.
F
Yeah,
it
was
Michael
when
you
asked
the
question
earlier
about:
where
does
it
get
go
in
the
diagram
and
I
added
a
little
comment
about
that?
It's
interesting
because
some
people
expect
that
the
storage
of
their
artifacts
for
code
will
be
encapsulated
within
the
platform
and
then
other
people
say
no.
No
that
doesn't
belong
here
on
get
Ops
right.
It
just
triggers
an
update.
The
platform
is
defined
by
the
resource
by
the
artifacts,
so
that's
actually
somewhere
else,
and
in
that
mindset,
that's
like
that's
again.
F
Does
the
platform
Encompass
everything,
or
does
it
like
in
all
of
my
environments,
including
my
artifacts
for
code,
which
then
kind
of
blossomed
from
within
or
is
it?
You
know,
I
have
different
platforms
and
the
platform
team
is
responsible
for
the
makeup
of
those,
but
git
is
still
the
single
source
of
truth.
It's
like
just
interesting
from
how
different
people
Define
git
Ops
and
where
that
Journey
starts.
C
Yeah,
that's
a
very
interesting
point:
I
I
see
a
lot
of
those
things
as
part
of
the
bullet
number.
Five.
Perhaps
once
I
have
the
capability
to
deliver
and
verify
for
one
organization
that
could
be
just
production
or
it
could
be
going
through
staging
and
then
have
some
kind
of
release,
candidate
promotion
step
or
having
a
QA
environment
like
once.
We
have.
The
capability
then
depends
on
the
requirements.
How
we
use
that
capability
right.
C
Can
you
make
if
it
makes
sense?
I,
don't
know
if
we
want
to
if
we
want
to
add
something
more
on
on
that.
B
Yeah
well,
I
think
what
you're
saying
Thomas
is
that,
as
opposed
to
Colin
is
more
talking
about
the
composites
and
even
suggesting,
maybe
that
the
Composites
are
a
platform
like
Colin
I,
don't
know
if
you
were
at
the
beginning
of
the
call,
but
we
were
we
have
iterated
on
individual
capabilities
versus
like
more
Composites.
That
can
do
you
know
like
artifact
storage,
for
you,
maybe
is
a
is
a
is
a
kind
of
platform
independent
of
the
deployment
platform,
but
we've.
So
this
might
be
a
level
lower
than
what
you've
been
thinking
about.
B
Colin
is
kind
of
where
I'm
going
like
these
are
capabilities
that
you
would
aggregate
into
either
a
production
environment
or,
if
you
wanted
to
consider
you
know
artifact
or
just
separate
domain,
you
know:
do
you
want
to
call
it
your
artifact
platform.
F
Yeah,
it's
to
me
too,
there's
not
a
clear
answer
for
that.
It's
gonna
depend
on.
You
know
a
multitude
of
opinions
for,
depending
on
who
you're
working
with
on
that
one.
It's
funny
to
thinking
of
the
platform
I
think
about
like
gitlab,
they're
kind
of
trying
to
be
the
platform,
and
so
the
you
know.
The
artifacts
storage
is
an
interesting
part
of
that.
But.
B
Okay,
yeah
I
think
that
goes.
We
and
we
said
at
the
very
beginning
that
there's
a
bit
of
a
Continuum
from
Individual
to
composite
and
I,
think
that's,
maybe
what
you're
getting
at.
So
we
can.
Let's
try
to
integrate
that
somewhere,
a
little
more.
Let's.
B
It's
we're
getting
the
time.
This
was
one
that
we
added
or
that
I've
added
in
the
past.
Little
while,
like
because
of
the
feedback
like
it's
things
like
hosted,
Ides,
maybe
even
regular
Ides,
remote
connection
tools
like
telepresence
instrumentation
and
dashboards
for
observability
I
think
observability
is
a
key,
a
key
one,
I'm
thinking.
We
probably
all
agree
on
that.
One
then
I
tried
to
group.
B
These
These
are
still
the
originals
I
put
in
infrastructure
data
messaging,
just
just
so
they
wouldn't
get
overwhelming
infrastructure
is
compute
run
time,
so
that
would
be
kubernetes,
namespaces
I,
don't
know
VMS,
and
things
like
that.
If
that's
what
people
use
functions,
some
sort
of
programmable
Network-
and
this
is
encapsing
a
ton
of
stuff
in
one
you
know
service
meshes
and
proxies
and
gateways
that
block
storage.
So
that's
just
you
know
infrastructure
as
a
service,
though
that's
why
I
put
it
all
at
one.
B
Data
I
also
just
kind
of
encapsulated,
and
this
might
another
thing
I
was
thinking
with
this
whole
section.
Is
that,
like
this,
might
inform
work
in
the
in
our
group
in
the
working
group
future
work
like
let's
talk
about
the
data
services,
you
know
that
are
available,
write
a
paper
on
them
or
write
an
a
blog
post,
maybe
more
relevant
when
we
get
to
like
identity
and
secret,
because
we're
going
to
find
things
that
are
like
overlaps
and
stuff
anyway.
So
that's
another.
So
the
data
services
are
I.
B
Just
put
everything
as
a
data
service
messaging
is
a
broker's,
cues
and
event.
Fabrics
is
things
like
k-native
Eventing
or
you
know,
event
bridge
and
Amazon
yeah,
so
those
are
just
like
resource
provisioning
identity
in
secret
rapide.
You
might
have
some
thoughts
on
this.
That
I
put
these
two
together,
but
what
I
find
I
guess
why
I
put
them
together
is
that
secrets
are
often
about
providing
an
identity
to
the
workload
to
connect
to
backing
services
like
I
have
been
thinking
recently
like
mtls.
B
So
that's
why
I
kind
of
put
these
together,
but
you
know
I'm,
opening
I'm
open
to
changing
that.
This
is
a
pretty
broad
category.
Also
does.
F
That
cover
that
probably
covers
policy
management
as
well.
The
identity.
A
F
And
I
have
elastic
cloud
and
enables
a
user
to
create
infrastructure
and
the
the
roles
like
the
the
role
for
a
user
to
be
able
to
create
a
new
deployment,
also
Maps,
potentially
to
the
back
end
to
that
user
is
able
to
create
a
definition
that
spins
up
a
new
machine
or
to
get
too
into
that,
but
that
policy
definition
I
think
fits
there.
Like.
E
But
yeah
on
the
Secret
side,
Josh
provisioning
credentials
to
workloads,
especially
in
a
github's
world
is,
is
a
is
a
team
where
you
know
it's
a
place
where
you
have
to
put
a
lot
of
thought,
and
especially
when
you're
building
a
platform,
and
my
experience
is
that
you
have
to
probably
have
this
conversation
at
the
beginning
when
you're
laying
the
foundation
of
your
platform.
E
What
you
have
here
is
fine,
but
there
is
really
a
lot
to
say
in
this
space
that
probably
doesn't
belong
in
this
paragraph.
I
would
call
it
cigarette
Management
Service,
as
opposed
to
secret
Services,
because
it's
secret
services.
B
Protecting
the
president,
yeah
cool,
okay,
good,
if
you,
if
you're
okay,
with
that
phrase,
I
find
it
yeah,
there's
a
tone
but
sure-
and
that
is
a
good
jumping
off
point
to
a
paper
about
secrets
and
stuff
next
I
think
the
one
other
one
the
artifact
storage
is
also.
You
might
have
opinions
on
the
fact
that
I've
combined
everything
container
image,
language,
specific
custom,
binaries
and
source
code,
which
is
good,
I,
don't
know
I
I
put
them
all
together
to
make
it
simple
also
are.
B
F
I
I,
like
that,
you
called
it
artifact
here
or
artifact
here.
D
E
I
didn't
read
the
document
recently,
but
do
we
have
a
section
for
processes
as
opposed
to
processes
that
a
platform
needs
to
have
as
opposed
to
you
know
this?
This
capability
are
in
between
technology
and
maybe
a
process
I'm
not
sure
how
to
interpret
them,
but
then,
in
the
table
it's
more
about
technology
right.
E
E
D
E
Is
is
a
big
one,
of
course
right
another
one
like
I
was
mentioning
a
second
ago.
You
need
to
have
a
process
for
provisioning
credential,
no
matter
what
the
credential
is
right.
Can
you
unify
that
process,
and,
and
so
it's
always
there.
A
B
Guess
I
guess
I
kind
of
think
that
falls
in
the
process
falls
in
the
capability.
B
Are
you
commenting
on
the
so
yeah
I
guess
the
table
we're
at
time
and
I
want
to
be
conscious
of
that?
We
do
have
another
meeting.
The
the
Ouija
meeting
is
next
week,
so
just
to
say,
I
think
that
I'll
try
in
the
next
week
to
get
these
each
section,
maybe
as
a
chunk
in
GitHub
or
ready
to
go
with
that,
and
then
we
can
start
we
can
skip
to
here.
B
If
you
know
that's
what
we'd
hope
to
do
today,
but
and
pick
this
up
again,
so
just
want
to
like
wrap
on
that,
but
we
can
keep
talking.
I
still
have
time.
If
people
want
to
keep
talking
for
a
few
minutes,
I.
D
Should
say,
I
think
that's
an
extremely
powerful
future
white
paper
for
the
group
around
to
me,
the
product
management
and
the
driving
of
how
do
you
enable
processes
through
your
platform
by
creating
the
experiences
around
like
this
stuff
right?
So,
as
you
suggested
like,
how
do
you
create
a
secret
right
is
a
huge
part
of
your
secret
process.
You
see
your
management
process,
so
yeah
I
think
that's
another
really
good
example
of
a
offshoot
of
this
document
in
the
future.
B
Awesome
yeah
RAF
has
written
a
document
like
that
on
the
red
hat
blog
at
some
point.
He
dropped
us
I'm
representing
him,
but
that.
B
To
see
that
could
be
our
next
next
thing.
That
fits
with
our
group
too.
Any
thoughts
on
the
table
itself
should
we
have
this
table?
Is
it
helpful?
Is
it
distracting.
D
B
C
Feedback
yeah
I
see
the
value
as
yeah
yeah.
It
helps
understand
better
the
capability.
Perhaps
we
can
change
the
name
and,
on
the
third
column,
just
as
examples
of
projects
so
like
not
comprehensive
place,
but
just
to
give
examples
so
I
know
I
can
understand
better
what
the
capability
is
about
and
perhaps
will
be
covered
in
a
dedicated
paper
later
on.
F
Yeah
exactly
filter
it
to
yeah
a
quick,
quick
question
for
y'all.
Where
do
you
think
like
something
like
open
cost
like
open
cost
would
go
in
this
list
because
I
like
it's
not
quite
yeah
I
mean
maybe
it's
kind
of
observed.
That's
an
opinion
thing.
I
was
just
curious.
If
you
guys
had
a
thought
and
where
that
would
go
to.
D
Me
this
is
the
thing
around
platforms
that
are
so
interesting
is
the
power
of
a
platform
is
not
just
the
codifying
of
what
a
user
needs,
but
it's
also
the
like
codifying
of
what
user
needs,
which
is
I
think
we
had
a
comment
about
this
up
above
Josh
which
meets
business
expectations
and
and
builds
in
the
business
requirements.
So
no
users
can
be
like
hey.
D
Can
you
use
open
costs
for
me
right,
but,
like
the
platform
needs
to
own
that
and
like
how
does
a
platform
build
in
open
cost
to
every
request
that
gets
made?
How
do
they
attribute
it
correctly?
How
do
they
validate
it?
I'm
not
too
familiar
because
I
might
be
speaking
a
bit
off,
but
I
made
assumptions
based
on
the.
F
Name:
yeah
open
cost.
It's
like
intelligent
cost
monitoring
for
infrastructure
for
your
infrastructure,
so
it
like
tells
you
how
much
your
workload
costs
out
of
the
overall
like
how
much
your
note,
costs
and
stuff
like
that
yeah
yeah.
We
use
it
as
an
intelligence
tool
for
developers
to
understand
how
to
write
size
so
like
we
provide
developers
access
to
that.
So
they
you
know,
understand
how
to
meet
business
expectations
with
their
compute
and
the
resources
they
request.
And
so
that's
cool
like
when
that
gets
pulled
into
the
platform.
But
it's
it
to
me.
F
D
C
C
Yeah
I
was
saying:
I
would
vote
to
add
that
capability.
That
is
actually
quite
critical
because
we
have
all
these
self-service
capabilities
and
as
a
product
team
I
can
go
and
provision
anything
that
I
want.
But
someone
has
to
pay
for
that
and
it's
my
tip
so
having
that
kind
of
visibility
called
out
explicitly
not
behind
observability
I
think
would
be
really
good.
D
Arguably,
we
have
13
capabilities,
which
is
starting
to
get
a
bit
like
stressful
right.
If
we're
trying
to
encourage
people
to
do
this,
but
arguably
infrastructure
data
messaging,
even
identity
and
secrets,
like
arguably
there's
one
category
which
is
like
stuff
I,
can
get
you
this
stuff,
like
that,
the
capability
of
the
platform
is
the
ability
to
deliver
you
infrastructure
of
whatever
you
need
examples
being
compute
data,
messaging,
Etc
and
then
actually,
the
other
capability
of
the
platform
is
to
like
codify
business
requirements.
D
Right
like
is,
and
then
and
that's
where,
then,
all
of
a
sudden,
this
table
becomes
a
extremely
powerful
add-on
right
because
you
basically
completely
squash
this
list
to
like
what
it's
like
to
the
the
fact
that
it
can
do.
Infrastructure
and
examples
of
infrastructure
see
table
below
and
then
like
now.
We
have
all
these
infrastructures
that
it
can
deliver
and
so
forth,
but
it
would
completely
change
the
tone
of
the
table.
D
So
it's
something
or
the
tone
of
this
this
list
so
I
think
it's
something
that
definitely
is
worth
a
bit
of
thought
and
I
can't
say
that
at
807
PM,
that's
something
I
have
deep
ability
to
do
right
now,
but
it's
an
interesting
Direction,
possibly
yeah.
F
I,
like
your
point
on
the
messaging
Services
partner,
because,
like
I'd
almost
argue
when
I'm
looking
at
Nats
right
that
to
me
that's
almost
at
the
application
layer
and
I,
don't
even
consider
that
a
part
of
the
platform
in
some
cases,
unless
it's
using
it
unless
it's
used
in
some
functional,
Ways
part
of
the
platform
itself.
F
So
it's
just
curious
to
think
about
it.
That
way
in
my
head,
sometimes
like
it's,
not
the
application
layer
isn't
necessarily
still
the
platform
like
there
can
be
a
separation
of
concerns.
There.
B
D
B
Like
the
codify,
and
maybe
that's
elaborating
on
the
the
composites,
maybe
there's
room
to
do
that
even
in
this
doc,
like
codifying
business
patterns,
you
know
give
an
example
of
that
I'll
think
about
that.
Could.
B
B
Okay,
I
I
kind
of
we're
way
over
so
I
I
think
we're
gonna
wrap
up
now.
Thank
you
all
so
much.
Let's
keep
working
on
this
and
yeah
we'll
meet
again
next
week
and
I'm
going
to
try
to
figure
out
a
way
to
start
getting
this
into
GitHub.