►
From YouTube: Cloud Native Live: One spec to rule them all
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. 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
A
They
will
build
things,
they
will
break
things
and
they
will
answer
all
of
your
questions,
so
you
can
join
us
every
Wednesday
to
watch
live
so
this
week
we
have
Thomas
here
to
talk
with
about
one
spec
to
rule
them
all
a
very
fun
title,
I'm
really
looking
forward
to
this,
and
as
always,
this
is
an
official
live
stream
of
the
cncf
and
as
such
it
is
subject
to
the
cncf
code
of
conduct.
So
please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
A
So
basically,
please
be
respectful
of
all
of
your
fellow
participants
as
well
as
presenters,
but
perfect
with
that
done
I'll
hand
it
over
to
Thomas
to
kick
off
today's
presentation.
B
Thank
you
very
much
and
thank
you.
Everyone
for
joining,
so
yes
I'm
here
today,
to
talk
about
an
open
source
project
named
score
score
aims
to
sort
of
improve
the
developer.
Experience,
reduce
cognitive
load
on
Developers
and
score
was
born
out
of
the
the
platform
engineering
movement.
Okay.
So
before
we
address
score,
I'd
like
to
talk
a
bit
about
platform
engineering
and
where
score
fits
into
that,
so
I
shall
share
my
screen.
A
Yes,
now
we
see
the
content
perfect.
B
Cool
so
I'm
just
going
to
go
sort
of
a
a
short
whiteboard
experience,
platform
engineering
and
we're
talking
about
platform
engine
engineering
from
quite
a
high
level
here
so
platform
engineering
really
is
sort
of
the
discipline
of
a
a
platform
team
providing
a
product
to
internal
developers
in
an
organization
so
that,
ultimately,
software
can
be
delivered
faster,
more
sustainably
of
higher
quality,
all
while
developers
focusing
on
the
work
that
they
actually
need
to
do
and
the
work
that
they
want
to
do,
which
is
writing
application
code
to
develop
applications
that
provide
you
know,
business
outcomes
right,
okay,
so
in
platform
engineering
we'd,
have
you
know
these
two
distinct
teams,
the
actual
platform
engineering
team
that
are
creating
the
platform
for
the
developers
to
consume
and
the
development
team
who
are
consuming
that
platform
and
writing
their
application
code?
B
Okay,
so,
on
the
platform
engineering
team
side,
what
what?
What
do
they
care
about
right?
Ultimately,
they
care
about
enabling
developers
to
to
do
their
job
sufficiently
and
within
that
reducing
ticket
operations.
So,
rather
than
a
you
know,
an
operations
team
being
reactive
to
every
single
request
on
an
ad
talk
basis,
really
sort
of
defining
best
practice.
Infrastructure
sort
of
some
golden
standards,
designing
the
tool
chain,
CI
pipelines,
embedding
login
observability,
all
those
things
that
we
need
to
run
an
application
at
scale
in
production.
B
So
some
of
the
things
that
a
platform
engineering
engineering
team
may
have
a
CI
pipeline
that
you
know
they
have
designed
some
infrastructure
code
to
actually
go
and
deploy
the
relevant
infrastructure.
B
A
Well,
it
is,
it
is
I,
think
it's
better.
Now
we
can.
If
the
audience
I
can
see
now
well
with
the
audience,
you
still
have
trouble,
let
us
know,
and
we
can
zoom
in
maybe
a
bit
more,
but
so
far
I
think
it
could
work.
C
B
So
yeah
platform
engineering
same
they
have
infrastructure
codes,
they're
going
to
reply
infrastructure
and
really
they're
in
the
business
of
making
these
higher
level
architecture
decisions.
B
People
within
that
team
actually
right
in
the
infrastructure
code
to
best
practice
to
a
golden
standard.
Okay,
and
then
we
have
the
development
team
over
here,
and
you
know
what
what
do
they
do
pretty
pretty
obvious
I
suppose
you
know
we
write
an
application
code
and
really
do
they
care
about
the
infrastructure.
Do
they
care
about
the
implementation
of
that
infrastructure
that
you
really
just
care
about?
B
Writing
the
application
code
and
the
point
getting
their
app
to
production
right
so
to
actually
do
these
things
or
to
to
to
to
live
in
this
world
where,
where
you
know,
platform,
engineering
teams
are
creating
this.
This
architecture
and
development
teams
are
just
writing
the
code.
We
actually
need
a
platform
all
right
so
bring
in
the
platform.
Okay-
and
this
is
an
example
of
what
a
good
practice
platform
could
look
like,
did
warn
that
this
might
not
go
100
smoothly.
B
C
B
Middle
the
platform.
Okay,
so
we've
got
this
platform
that
the
development
team
actually
interact
with
and
that
the
platform
engineering
team
I
would
certainly
make
resources
available
to
developers
Okay.
So
it's
a
very
high
level
look
at
a
platform,
but
how?
How
could
this
work?
Okay?
So
the
first
thing
is
that
a
the
platform
team
they're
actually
going
to
deploying
infrastructure,
okay
to
a
cloud
provider,
so
that
could
be
using
something
like
terraform,
for
example
I'm
trying
to
oh.
B
Here
we
go
so
they
would
got
deployed
to
a
cloud
provider
so
that
might
be
Google
Cloud.
Then
they
actually
make
and
that's
all
fine
on
its
own.
You
know:
we've
got
these
resources
running
there,
but
we
don't
want
developers
to
access
those
resources
directly
as
such,
or
be
too
aware
of
those
resources.
You
know
if
it's
kubernetes
do
we
want
them
accessing
Cube,
ctol
and
write
in
you
know,
deployment
manifests,
probably
not.
B
It
doesn't
really
fit
into
the
the
ideology
of
what
we're
trying
to
do
here
so
platform
Engineers
will
make
those
resources
available
to
the
platform
via
something
like
a
resource
definition.
You
know
it's
a
pointer
to
the
actual
resource
and
gives
access
to
that
resource,
so
they
may
create
a
kubernetes
cluster
in
Google
Cloud
gke
cluster
in
Google
Cloud
make
this
available
to
to
to
the
platform.
B
They
may
also
create
a
postgres
database,
for
example,
and
then
give
these
these
resources,
or
you
know,
pointers
to
these
resources,
tags
or
criteria
that
Define,
which
environment
they
can
be
used
in
so
kubernetes
cluster
for
the
staging
environment.
A
database
for
the
staging
environment
in
this
example
that
I'm
giving
here
okay.
B
And
then
we
have
developers
who
are
just
writing
their
app
code,
building
their
app
codes
into
a
into
a
container
and
then
pushing
that
to
a
registry.
Okay,
so
they
pushed
a
container
to
the
registry
and
then
they
actually
need
to
Define
how
that
workload
runs,
and
this
is
where
score
comes
in.
Okay,
so
score
is
a
workload
specification.
B
So
it's
a
smallish
piece
to
a
larger
puzzle,
all
right,
just
explaining
some
of
the
context
behind
the
larger
puzzle
here,
so
building
app
codes
in
a
Docker
container,
pushing
it
to
a
registry
reasonably
reasonably
well
defined,
and
then
we
get
to
the
workload
specification.
Okay,
so
the
platform
you
know,
maybe
object
that
we
call
an
application.
You
know
and
we
need
to
configure
that
application
object
with
specific
workloads
all
right,
so
a
typical
application
might
have.
B
You
know
a
handful
of
workloads
between
five
ten
workloads
to
build
out
the
entire
application,
so
each
workload
would
need
a
specification
so
in
this
pipeline
that
they
build
their
app
code.
They
push
this
specification
to
the
platform
and
that
specification
will
contain
information
around
what
the
container
or
what
the
workload
is
in
terms
of
the
container
image
and
the
resources
that
actually
depends
on
okay.
So
if
we
just
sort
of
type
out
a
a
rough
specification
here,
we
might
say
image
the
name
of
the
image
and
then
we
say
resources
and
I.
B
B
We
just
say:
I
need
postgres
right,
so
say:
risk
resources,
I
need
a
postgres
database.
I
need
some
storage.
B
And
you
know
the
facto
this
workload
is
going
to
go
on
kubernetes
anyway,
okay,
so
we
just
declare
the
resources
that
we
need
and
we've
already
sort
of
tagged.
This
application
object
within
the
platform
as
the
that
it
belongs
to
the
stage
environment.
B
Okay,
so
once
I've
got
my
workload
spec,
once
I've
got
my
workload
specification
defined
once
I
have
my
outpatient
code
pushed
or
built
and
pushed
to
the
image
registry
we
went,
we
need
to
go
and
deploy
that
application
so
at
deployment
time
and
what
happens
on
you
know
some
using
something
like
a
a
platform
orchestrator
product
is
the
the
orchestrator
would
say:
okay,
this
is
for
the
staging
environment,
so
it
would
know
that
we
need
to
push
this
image
and
run
that
image
on
the
kubernetes
cluster
in
the
staging
environment
and
then
also
says
we
need
postgres
and
we
need
some
storage.
B
So
it
would
look
for
the
available
resource
definitions
for
a
postgres
database
and
the
actual
relevant
environment
as
well.
So
it
would.
It
would
pick
those
up
and
attach
those
to
the
workload,
and
the
idea
behind
this
is
that
as
a
developer,
I
do
not
really
know
where
that
database
lives.
I,
don't
know
about
the
configuration
of
it,
but
I
do
know
and
have
confidence.
The
platform
engineering
team
have
set
that
up
to
absolute
best
practices,
absolute
company
golden
standards
that
conform
to
all
regulations
and
compliance
and
I
just
focus
on
I'm
writing
my
code.
B
A
No
nothing
at
the
moment,
but
there
was
a
comment,
though
nice
someone
said
so
that's
really
nice
to
hear
that
people
are
enjoying
the
content.
So
far.
Oh
there's
no
comment
I
see,
so
we
can
actually
maybe
tackle
it.
I
don't
see
a
question
mark.
Probably
we
can
take
your
take
on
it.
So
there's
someone
saying
that
their
humble
experience
in
a
platform
engineering
team
that
let
me
conclude
the
following:
don't
give
many
options
to
devs
example:
Auto
inject
resource
limits
is
for
historical
metrics
for
monitoring
systems.
A
Smart,
enable
or
Auto
scaling,
if
required,
reducing
the
inputs
from
Dev
increase,
reliability
and
consistency.
B
Yeah
I
absolutely
agree
with
all
that.
I
think
that's
a
great
comment.
It's
actually
probably
a
very
nice
segue
into
into
score.
Looking
specifically
at
this
wood
specification,
because
score
is
really
about
reducing
the
inputs
that
a
developer
has
to
give
only
exposing
things
that
they
care
about
and
that
they
should
know
about
rather
than
all
the
complexity
of
infrastructure.
Okay,
so
I
will
move
on
to
that
right
now,.
B
So
yeah
we're
looking
specifically
at
score
here
and
some
of
the
you
know
the
problems
that
developers
you
know
have
that
we
have
spoken
with
have
told
us
okay,
so
they
they
have
a
high
level
of
cognitive
load.
So
this
is
often
you
know
a
switch
in
between
different
tools
within
within
different
environments.
B
Or
you
know,
different
teams
have
different
sort
of
pipeline
tools.
Yeah,
look,
look
lots
of
switching
is
not
productive,
right;
okay,
inconsistency
between
environment
two,
so
if
you're
developing
locally
using
Docker
compose
and
then
in
production,
you're
using
you
know,
full
blown,
kubernetes,
multi-cluster,
multi-cloud,
even
very
different
environments,
and
you
can
see,
inconsistencies
there
and
then
infrastructure
management,
which
is
quite
a
quite
quite
problematic
for
developers,
not
spoke
to
many
developers
who
enjoy
managing
infrastructure,
and
this
also
the
infrastructure
management
piece,
creates
higher
cognitive
load
as
well.
B
B
Very
specifically,
so
you
know
taking
that
example
again
of
developing
locally
on
Docker
compose
kubernetes
for
production,
you
have
to
think
a
lot
about
sort
of
the
environment,
specific
configuration
and
then
just
platform
specific
configuration
as
well
right.
So,
if
we're,
if
we're
using
different
platforms
for
different
applications,
different
teams
yeah
there's
a
lot
of
consideration
that
goes
into
that.
B
So
what
we're?
What
score
is
advocating
is
a
workload-centric
development
model.
Okay,
so
ultimately
it's
the
workload
that
creates
the
value,
the
workload
all
those
workloads
doing
together,
create
this
application.
The
application
is
creating
the
value
infrastructure
is
super
important.
If
we
didn't
have
infrastructure,
where
would
we
run
our
workload,
but
it
is
ultimately
a
byproduct
of
a
workload
of
an
application.
B
Okay,
so
really
score
is
aiming
to
help
developers
and
platform
teams
to
help
developers
focus
on
the
workloads
rather
than
the
whole
Tech
stack
and
all
of
the
sort
of
complexity
that
goes
in.
That
text
act
to
run
the
application,
so
workload,
Centric
development,
just
focusing
on
the
workload.
B
So
it's
the
spec
is
yeah,
just
a
single
sources,
truth
across
different
platforms
across
different
environments
and
really
tightly
scoped
as
well.
So
this
is
a
nod
to
the
comment
that
was
made
in
the
chat
really
only
exposing
the
inputs
that
a
developer
cares
about
and
a
developer
needs
hiding
those
inputs
that
could
create
confusion,
create
extra
cognitive
load
and
create
production
instances
that
are
unfavorable
for
our
application
and
our
customers
and
a
completely
declarative
approach
for
infrastructure
management.
B
Okay,
so
in
the
context
we're
talking
about
here,
is
declaring
what
we
need
and
that's
being
given
them.
Okay,
so
obviously
there's
the
clarity
of
tools,
for
you
know,
infrastructure
as
code,
but
this
is
looking
at
as
a
developer.
I
declare
what
I
need
I
get
given
that
I,
don't
care
where
it
runs,
I,
don't
care
where
it
is
I,
don't
care
too
much
about
the
underlying
configuration
so
a
little
bit
about
the
tool
itself
at
quite
a
high
level.
B
There's
a
there's,
a
few
components,
so
there's
a
score
specification
right,
which
is
you
know
the
the
spec
that
can
be
run
across
multiple
different
implementations.
Okay,
so
implementation
relates
to
a
specific
platform
or
a
specific
piece
of
technology.
So
at
the
moment
we
have
score
compose.
We
have
score
Helm,
there's
School
Humana
tech
for
the
humanitek
platform.
Okay.
So
so
you
have
this
single
score
specification.
B
You
run
it
against
an
implementation
and
it
spits
out
a
platform.
Specific
configuration
file.
Okay,
so
I
could
be
deploying
to
multiple
Technologies,
multiple
types
of
platforms,
but
I
need
to
write
one
file
and
I
don't
get
have
to
care
about
sort
of
all
of
the
pieces
of
configuration
or
the
nuances
of
each
platform's
configuration.
A
Not
at
the
moment,
but
keep
them
coming
people,
and
or
did
we
we
did
get
confirmation
at
some
point
that
the
zoom
in
did
the
trick,
so
everyone
has
been
having,
after
that.
So.
B
And,
rather
than
looking
at
this
on
here,
we're
actually
going
to
look
at
in
a
demonstration.
Okay,
so
I'll
skip
to
a
demo
now
I'm,
using
this
sandbox
environment
and
I,
will
give
everyone
access
to
this
sandbox
environment
at
the
end
of
the
session
as
well.
So
you
can
play
around
to
your
heart's
content.
Okay,
let's
look
at
a
score
file
first,
so,
let's
set
out
a
situation
before
I
go
rushing
into
looking
at
code
on
the
screen.
B
B
This
is
probably
quite
a
maybe
a
simplified
situation.
Okay
using
some
of
the
you
know,
just
the
existing
implementations
that
we
already
have.
There
are
other
tools
out
there
that
can,
you
know,
tackle
this
type
of
problem
just
between
compose
and
helm.
But
you
know
score
is
supposed
to
be
very
pluggable.
It
is
very
pluggable.
You
can
write
your
own
implementations
for
your
own
platforms,
and
but
this
we're
just
given
an
example
here,
so
I
have
a
score
file
called.
B
Let's
actually
make
this
a
bit
bigger
now,
because
I'm
sure
there'll
be
complaints
or
suggestions,
so
I've
got
this
back
end
score
file.
So
if
we
look
at
this,
we've
got
I'm
just
going
to
sort
of
run
through
the
file
and
explain
it.
We
would
version
the
score
spec,
so
you
can
use
different
versions
and
and
metadata
simply.
We
can
just
simply
give
this
a
name
here
which
is
our
backend
workload
and
then
a
a
list
of
containers
or
a
container.
B
So
we've
got
a
simple
image
here
and
then
we
can
issue
commands
to
that
container
arguments
Etc
and
then
a
list
of
variables
as
well.
Okay,
that
we
want
to
inject
into
the
container
now,
as
you
can
see,
we're
not
sort
of
explicitly
declaring
the
variables
or
you
know
the
variable
values
we
have
got
placeholders
in
there,
okay,
so
the
idea
being
that
a
good
platform
should
be
able
to
resolve
these
placeholders
and
actually
inject
correct
values.
B
Okay,
so
if
we
quickly
just
go
back
to
this,
this
very
basic
drawing
we
the
idea
being
that
when
we
actually
do
this
deployment
of
this
application
and
that's
deployed
onto
kubernetes,
also
one
we've
specified-
you
know
postgres
in
this
instance,
I,
don't
know.
What's
going
on
with
that,
drawing
and
we've
specified
postgres
in
that
instance
that
will
take
the
configuration
from
the
sort
of
the
database
resource.
You
know
as
a
developer.
I
do
not
need
to
work
with
credentials.
I
do
not
need
to
understand
the
end
points.
B
That's
all
resolved
by
the
platform
and
injected
into
the
workload
something
I
I
didn't
talk
about
too
much
when
I
when
I
presented
this
wonderful,
whiteboard,
okay.
So
it's
the
platform
that
needs
to
be
able
to
implement
that.
So
we
can
look
here
and
we
can
say
then
we'd
start
declaring
resources,
so
we
can
actually,
in
this
instance,
declare
a
set
of
environment
variables
that
we
want
to
inject,
but
in
general
the
variables
that
we
use
in
say
for,
like
a
database
connection
string,
would
be
resolved
and
injected
via
the
platform.
B
So
here
I've
said,
I
need
a
database.
My
workloading
is
a
database,
the
type
of
database
is
postgres
and
then,
in
this
instance,
just
give
them
some
default
values
that
could
be
injected
into
the
into
the
configuration
and
then
I
have
to
find
another
yeah
the
to
find
another
resource
here.
Resource
dependency,
which
is
the
front
end,
so
we're
sort
of
dependent
on
this
on
this
front
end
workload
actually
to
build
our
application
and
in
the
front
end
I've
just
got
a
sort
of
a
basic
Alpine
image
that
serves
over
port
80..
B
So
I
will
execute
this
I
assuming
there's
not
any
questions,
because
I
I
probably
would
have
been
asked,
but
the
idea
being
that
wherever
I
run
this
file,
my
my
workload
is
going
to
be
consistent.
Whatever
platform,
that's
on,
you
know,
there's
nothing
specific
to
any
type
of
platform
within
this
definition.
B
C
B
And
hopefully
we
should
have
exactly
the
same
outcome
or
we
will
have
the
same
outcome
when
I
share
this
with
you
as
well,
so
you
can
actually
follow
through.
You
know
if
you're
interested
follow
through
with
the
the
guide
on
the
right,
I
am
I
found
this
useful
when
I'm
presenting
as
well,
because
I
can
just
copy
and
paste
so
there's
some
stuff
in
there.
That
explains.
What's
going
on.
B
This
is
also
important
that
there's
we've
got
this
score
specification
here,
but
there's
also,
we
actually
need
a
database
right.
This
is
just
Docker
Docker
running
locally.
There
is
no
platform
in
this
instance.
You
know,
so
we
need
to
actually
Supply
the
database,
so
we've
just
supplied
that
with
a
database
definition
for
a
in
a
score
in
a
composed
file.
A
B
Yeah,
it's
a
good
question,
so
score
itself
doesn't
really
handle
Secrets
sort
of
referencing
Secrets.
Okay,
so
you
know
on
this
on
this
connection
string
here.
This
would
all
be
secret
information,
okay,
so
the
DB
password,
that's
something
that
really
and
will
what
we
can
hint
at
some
of
this
and
show
show
a
little
bit
of
this,
but
it
would
be
injected
by
the
platform.
B
Okay.
So
in
this
instance
here
you
know
this
platform
orchestrator
or
this.
You
know
this
platform.
Sort
of
sketchier
has
a
lot
of
things
missing
on
the
actual
sketch
you
know,
so.
Naturally,
there
would
be
Secrets
management
components
of
this
platform,
and
you
know
we
we
could.
The
platform
would
be
able
to
inject
into
the
workload.
A
B
He's
so
the
interface
I
mean
if
I
understand
the
question
correctly,
we
can
Target
any
platform.
So
there's
there's
the
specification
which
you
know
has
a
schema
that
looks
you
know
is
represented
like
this
when,
when
it's
in
yaml
and
the
idea
being
that
we
can
really,
if
I
go
back
to
this
slide
here,
anyone
is
free
to
write
their
own
implementation
that
can
Target
a
specific
platform.
B
Okay,
so
you
may
have
your
own
custom
built
platform
by
your
platform,
engineering
team
and
you
want
a
standardized
way
for
them
to
you,
know,
develop
locally
and
then
actually
address
your
platform
or
you
know,
convert
to
convert
to
helm.
So
the
interface,
the
experience
is
around
just
having
a
single
specification
and
outputs
in
to
a
platform
specific
configuration
file.
Without
having
to
understand
that
platform,
specific
configuration
file,
you
need
to
understand
one
specification.
A
Happy
and
then
there
was
actually
another
question
from
the
same
asker.
How
are
we
managing
multi-environments
here
or
is
I
still
require
third
party,
like
Argo
CD.
B
So
yeah,
so
again,
that's
more
comes
down
to
the
the
platform.
You
know
the
platform
to
manage
that
you
may
have
something
like
yeah
I'll
go
see
there.
You
may
have
sort
of
a
platform.
Orchestrator
such
as
I,
don't
know
humanotech,
you
may
have
a
custom
build
platform,
but
if
I,
if,
if
I,
look
at
it
from
this
context,
so
I'm
trying
to
there,
we
go
if
I
have
sort
of
some
cloning
capability.
This
is
just
not
going
well.
B
I
didn't
think
it
was
there
as
one
object
right.
So
if
we
cloned
that
application
and
then
give
it
the
sort
of
the
tag
sort
of
prod
okay,
the
actual
workload
specification
is
really
going
to
look
exactly
the
same
right.
We
don't
want
the
workload
specification
to
look
any
different,
the
platform
orchestrator,
where
it
will
assign
different
resources
so
for
the
for
the
prods
for
the
product
application
or
the
product
deployment.
B
A
C
B
B
So
what
we're
going
to
do
is
we're
going
to
translate
these
these
score
files
to
compose
files.
Okay,.
B
So
I'll
actually
show
the
translations
here.
So
we've
got
this
back
end
compose
or
back
in
score.yaml,
it's
now
being
translated
to
a
back-end,
compose.yaml,
okay
and
then
we've
got
the
front
end
compose
dot,
yaml
as
well.
So
score
doesn't
actually
even
really
execute
those
files.
It
creates
translation
and
then
you
can
execute
those
files
against
the
platform
that
you
need.
B
Foreign
examples:
you
know
this
is
the
one
of
the
first
iterations
that
we
had
was
score,
compose
and
score
Helm.
Naturally,
you
know
platforms
that
provide
a
lot
more.
Would,
you
know,
be
more,
be
more
complex
and
their
configuration
files?
Look
at
what
a
lot
more
complex
as
well.
B
And
what
what
so
and
what
we
want
to
see
here
is
sort
of
this
workload
running
and
the
the
connection
string
echoed
out.
That's
what
the
workload
is
going
to
do.
It's
going
to
Echo
out
the
connection
string
to
the
database,
okay,
so
hey
Jimmy,
whoever
Jimmy
is
connecting
to
the
DB
and
there's
the
connection
string
there.
In
this
instance,
we
have
just
passed
in
the
default
values
that
we've
set
in
the
the
score
file,
but,
for
you
know
a
more
advanced
platform
that
uses
a
platform
orchestrator
a
platform
product.
B
These
would
be
retrieved,
you
know
from
the
resource
or
from
a
secret
manager
injected
in
okay.
That's
the
platform
really
to
implement
rather
than
score.
Score
is
yeah
agnostic
to
that
sort
of
platform.
It
is
just
a
specification:
okay,.
B
B
We
got
that
so
hopefully
that
makes
sense.
We've
used
a
a
file,
a
score
file
to
deploy
some
workloads
to
Define
some
workloads
onto
Docker.
Now
we're
going
to
take
that
exact
same
file,
okay
and
we
are
going
to
deploy
you
via
Helm
to
kubernetes
okay.
B
So
if
I
come
here-
and
these
are
the
exact
same
files,
translate
them
yes
into
the
editor
and
what
we've
got
is
sort
of
in
within
the
helm
implementation,
we
translate
to
a
set
of
values,
files
Okay,
so
we've
got
the
the
front,
end,
values
and
the
the
back
end
values.
B
And
then
we've
got
a
specific
sort
of
reference
workload
Helm
chart
and
that
these
values
are
fed
into.
Basically
that
was
the
implementation
was
built
foreign
jar
and
now
we're
actually
going
to
run
the
workloads
and
Stu
have
to
do
a
Helm
install
to
actually
run
these
workloads,
and
this
is
this
is
a
gke
cluster,
and
so,
if
I
do
sort
of
pubes
here,
I'll
get
put
yeah
yeah
you
get
pods
can't
me,
you
can
see
that
those
are
coming
up
on
gke.
Now,
okay,.
B
And
then
it's
actually
sort
of
output,
some
more
in-depth
information,
we're
going
to
tell
the
logs
of
the
backing
container
and
as
we
can
see,
we've
got
the
same.
You
know
we
come
to
the
same
conclusion:
hey
Jimmy,
we're
connecting
to
the
database
and
then
we've
got
the
database
connection
string.
That's
been
echoed
out.
B
Okay,
so
hopefully
we
can
see
how
we
can
use
a
single
file
such
as
this
written
in
you
know,
written
written
in
yellow
to
define
a
workload
and
run
that
workload
across
any
any
platform
that
that
can
that's
openly
supports
a
codified
way
of
defining
workloads.
That's
all
we
need
okay,
so
yeah.
B
We
are
looking
at
developing
more
contexts,
so
more
Integrations
with
other
platforms.
You
know
be
that
cloud
services
or
more
bespoke
platforms
as
well
and
you're
absolutely
free
to
develop
your
contribute,
your
own,
your
own
context.
B
So
we
have
this.
We
have
a
GitHub
organization
and
we
have
this
the
specific
spec
within
there.
Okay
and
there's
information
on
how
to
contribute
and
things
like
that.
So
I'll
probably
post
this
in
the
chat
afterwards
and
then
then
we
can
look
at
sort
of.
B
A
Perfect,
if
you
get
the
links
to
to
our
site,
we
can
get
them
to
the
chat.
A
B
Yeah,
we
only
released
this
at
the
back
end
of
last
year
really
so
it's
still
an
early
stage
project.
B
A
Perfect,
so
is
the
GitHub
page
that
you're
linking
to
so
when
we
got
you
through
the
chat,
the
right
place
to
find
the
contact
info?
Where
should
people
kind
of
they're
looking
to
reach
out
to.
B
You
so
if
you
go
on
this
I've,
just
posted
another
link,
called
score.dev
I,
believe
there
is
a
contact
us
page
there
or
you
can
create
a
discussion
or
just
even
send
a
support
request
on
on
GitHub,
but
there's
definitely
contact
information
on
score.dev,
which
is
the
website
for
the
school
project.
B
And
also
in
the
chat,
I've
I,
don't
know
if
you've
pasted
this
yet
but
there's
a
a
link
for
the
sandbox
okay.
So
if
you
follow
that
link
you'll
get
access
to
the
sandbox
it's
up
for
an
hour,
you
can
play
around
and
it'll
be
up
for
like
the
next
week,
so
yeah
feel
free
to
have
a
plan
that
send
any
feedback
our
way.
A
Perfect
and
now,
while
we
wait
for
to
kind
of
send
in
the
links
to
everyone
via
the
chat,
you
have
an
audience
question.
So
how
easy
it
is
to
write
my
own
converter
from
score
to
my
company
app.
B
So
it
is
a
plugable
system.
We've
tried
to
make
it
as
simple
as
possible.
Obviously
it
depends
on
the
complexity
of
your
of
your
sort
of
internal
specification,
but
if
you
want
to
talk
further
about
that-
and
you
know
get
some
of
the
development
team
involved
or
the
product
managers
from
the
from
the
score
project
and
we'd
be
happy
to
look
at
that
forever.
A
Great
the
question
I
actually
did
kind
of
elaborate,
with
I've
developed
a
young
spec
for
my
community.
These
apps.
A
B
Interesting,
so
maybe
trying
to
achieve
the
same
things
there
as
well
to
a
certain
extent
and
that's
what
you
know
has
been
noticed
as
well.
There's
lots
of
you
know.
Different
of
these
specifications
are
not
transferable
between
platforms,
so
I
think
there's
a
lot
of
value
in
having
just
a
a
more
standardized
specification.
You
know
one
that
can
be
applicable
to
different
teams
and
you
know
or
different
units
within
the
organization
two
across
organizations
as
well.
B
A
Perfect
and
we're
getting
the
links
into
the
chat
right
now.
They
are
at
least
on
the
YouTube
side.
So
no
worries.
C
A
B
Yes,
so
there's
a
essentially
a
boiler
play
Helm
chart
that
we
feed
values
in.
Obviously
you
can
use
your
own.
You
know
reference
your
own
boilerplate
that
you
know
is
more
suitable
for
yourself
as
well,
but
yeah.
That's
that's
the
fundamentals
of
it.
A
Perfect
and
I
hope
the
links
are
visible.
On
the
LinkedIn
side.
It's
not
I,
guess
for
for
someone
can't
see
the
links,
it's
essentially
dig
it
up
site
the
score,
mainly
and
I.
Think
from
there
our
score.dev
is
the
web
page
likely.
So
there
you
can
find
probably
a
lot
of
the
materials
as
well.
If
people
can't
see
the
links
there.
A
Is
there
an
integration
with
tools
such
as
tilt
used
for
local
development.
B
There
is
not
currently
I,
don't
know
if
till
person
either,
but
that
is
maybe
a
fantastic
project
for
yourself
and
yeah.
If
there's
enough
sort
of
interest
and
a
specific
sort
of.
C
Platform
or
deployment
Target,
then
we
will
look
into
developing
format
as
well.
C
A
B
Out
the
basics
of
it,
and
then
you
know,
need
some
help
from
The
Wider
Community
there's.
You
know,
starting
to
be
quite
a
big
Community
built
around
school
now,
which
is
core
or
a
lot
of
interest
at
least
anyway.
So
even
if
you
yeah
flesh
something
out
and
then
others
contribute
to.
A
Perfect
well,
there
was
someone
who's
commenting
that
they've
used
tilt,
but
not
much.
It's
a
new
shape,
part
of
as
far
as
their
concerned,
at
least
great,
that
there's
a
discussion
going
on
in
the
chat
as
well
I
like
seeing
that
that's
great
yeah.
Is
there
anything
else
that
you
want
to
kind
of
bubble
here,
while
people
might
be
typing
their
questions
in
final
call,
I
think
for
questions
if
anyone's
still
wondering
something
or
is
there
anything
that
you
want
to
share
comments.
A
Let's
see
if
anything
comes
in,
I
have
a
question:
while
we
see
if
anyone's
still
typing
away,
is
there
any
kind
of
sneak
peek
that
you
you
can
on?
What
does
the
future
of
math
look
like
for
score?
Is
there
anything
happening
in
the
future
and
what
does
it
look
like.
B
There's
a
there's,
a
couple
of
different
implementations
being
considered.
I
won't
commit
to
anything
right
now.
It's
not
my
place
to
but
yeah
just
obviously
evaluating
what
would
be
most
beneficial
to
the
community,
which
sort
of
you
know,
tools
that
we
need
to
interact
with
are
the
most
popular
and
then
moving
on
from
there.
B
The
ultimate
aim
of
score
is
I
will
say:
I've
probably
said
it
in
other
words
before,
but
it
is
really
to
provide
this
definitive
single
specification
for
deploying
or
defining
a
workload
so
that
that
is
the
old.
That
is
the
ultimate
aim,
and
it
may
take
many
many
different
Integrations
with
other
systems
to
be
able
to
get
there
so
yeah
and
we're
looking
to
go
that
way.
A
Perfect,
actually,
the
discussion
in
time
continued
a
bit
with
tilt
is
absolutely
amazing.
The
best
Dev
experience
when
it
comes
to
creating
setups.
You
need
to
try
it
so
I
love
the
discussion
going
on
there,
that's
nice
to
see,
and
then
Danny
said,
Thank
You,
Thomas
and
Annie,
which
is
lovely,
throw
is
here.
Thank
you
to
you
to
attending
and
thank
you
for
amazing
questions
to
everyone.
But
since
there's
no
new
questions,
I
think
we're
gonna
start
wrapping
up
perfect.
C
A
Yeah,
thank
you.
Everyone
for
joining
the
latest
episode
of
cloud
native
live.
It
was
great
to
have
a
session
about
one
step,
two
through
them
all.
We
really
also
love
the
interaction
and
questions
from
the
audience,
as
well
as
the
discussion
within
the
chat
within
the
audience.
That's
always
great
to
see,
and
as
always,
we
will
bring
you
the
latest
Cloud
creative
code,
every
Wednesday.
In
the
coming
weeks.
We
have
more
great
sessions
coming
up.
For
example,
next
week
we
have
a
session
on
showcasing
new
features
and
capabilities
in
YouTube.