►
From YouTube: Cloud Native Buildpacks: A Paradigm Shift for Enterprise App Builds - Stephen Levine & Ben Hale, Piv
Description
Cloud Native Buildpacks: A Paradigm Shift for Enterprise App Builds - Stephen Levine & Ben Hale, Pivotal Software, Inc.
The Cloud Native Buildpacks project was initiated by Pivotal and Heroku in January 2018 and joined the Cloud Native Sandbox in October 2018. The project aims to unify the buildpack ecosystems with a platform-to-buildpack contract that is well-defined and that incorporates learnings from maintaining production-grade buildpacks for years at both Pivotal and Heroku.
In this presentation, Stephen Levine and Ben Hale (CNB Project Owners at Pivotal) will discuss the features and benefits of Cloud Native Buildpacks in the context of the core CF Buildpacks and CF Java Buildpacks projects in the CF Extensions PMC. Topics will include using buildpacks outside of CFAR, and upcoming changes to the current Cloud Foundry buildpacks.
About Ben Hale
Ben Hale leads Pivotal’s Java Cloud Foundry efforts including being a founding member of the Cloud Native Buildpacks CNCF Sandbox project and leading the Cloud Foundry Java Buildpack. In addition to this work, he’s very involved in the Reactive Programming scene founding the Reactive Relational Database Connectivity (R2DBC) project, being a spec lead and committer on the RSocket Reactive networking protocol, and being a long-time contributor to Project Reactor. In what little spare time he has left, Ben loves riding his bike, especially in the high mountains of the Italian Dolomites.
About Stephen Levine
Stephen Levine is a Pivotal product manager and software engineer. He is the Cloud Foundry Project Lead for CF Local, CF Dev, and the core CF Buildpacks, as well as a co-owner of the Cloud Native Buildpacks project in the CNCF's Cloud Native Sandbox.
https://www.cloudfoundry.org/
A
I'm
Steven
Levine,
and
this
is
Ben
Hale,
so
we're
founders
of
the
cloud
unit
build
packs
project
along
with
Terence
Lee
and
Chuck
Kutner
at
Heroku.
The
cloud
native,
build
packs
is
kind
of
a
next-gen
build
pack,
API
and
tooling
for
pill
pack
for
platforms
to
implement.
You
know
build
packs
that
follow
the
same
sort
of
specification.
It
moves
two
moves
everything
to
container
standards
like
the
OCI
image
format
and
docker
registries.
A
So,
like
I
mentioned,
this
project
is
a
collaboration
between
pivotal
through
cloud
foundry
and
Heroku,
and
it
entered
the
C
and
C
F
about
six
months
ago.
All
right
so
the
first
thing
I'm
gonna
do
is
walk
you
through
a
case
study
of
what
it's
like
to
patch
a
high
CDE
in
open
SSL
in
sort
of
thoose
in
the
docker
file
model
and
the
Cloud
Foundry
model
today
and
then
in
the
cloud
native
build
packs
model,
and
this
was
a
real
CVE
from
2016.
A
It
was
I,
think
a
malicious
cypher
text,
denial
of
service
owner
ability.
So
if
you
have
a
no
js'
app,
that's
built
using
a
dagger
file,
it's
built
using
a
series
of
sort
of
connected
images
or
really
using
the
layers
from
a
series
of
connected
images.
So
you
might
have
an
operating
system
packages.
A
You
know
base
image
from
operating
system
vendor
like
canonical
that
someone
might
build
and
nodejs
image.
On
top
of
that
that
provides
nodejs
and
then
somebody
might
install
their
application
dependencies
on
top
of
that
and
creating
another
image
that
might
that's,
probably
gonna,
be
the
end
user
who's
gonna,
launch
the
image
and
production.
A
So
when
there's
a
vulnerability
in
open
SSL,
that's
gonna
be
in
a
very
sort
of
bottom
layer
of
that
and
that
the
operating
system
packages
layers,
and
so,
if
you're,
a
big
enterprise
and
you
have
500
node.js
apps,
that's
gonna
take
a
long
time
to
get
all
those
patched,
especially
if
you
did
not.
If
you
don't
manage
your
darker
files
very
well.
A
So
if
you,
if
your
developers
all
grab
different
base
images
from
different
places
and
different
node
versions
from
different
places,
when
there's
a
CVE,
it
can
take
a
really
long
time
for
them
all
to.
You
know,
pick
up
the
things
that
patch
those
vulnerabilities
from
upstream
sources.
So
who
knows
how
long
that
would
take
for
500
apps?
If
you
do
docker
files
better
and
you
have
your
corporation-
has
a
trusted
nodejs
image
and
they're
all
based
on
a
bunch
of
Trustee
or
something
like
that
or
dynamic.
A
So
in
cloud
foundry
we
have
a
special
model
for
dealing
with
this.
We
keep
the
application
bits
that
are
generated
by
a
build
pack
separate
from
the
operating
system
layer
and
we
use
a
contract
called
ABI.
Compatibility
which
is
ABI
is
application,
binary
interface
interface.
It
means
that
when
we
look
at
those
bottom
layers
and
change
them
out,
we
don't
we
make
sure
that
the
packages
that
change
or
just
have
security
patches
and
that
they
continue
to
be
dynamically.
Linked
to
you
know
the
build
application
or
the
build
application
doesn't
have
to
be
rebuilt.
B
A
A
A
A
A
You
can
sort
of
do
rebasing
without
changing
the
IDs
of
each
of
the
layers
kind
of
arbitrarily.
You
can
do
this
directly
on
the
registry
without
downloading
individual
players.
It's
just
that
the
docker
file
model
wasn't
built
against
this
idea,
and
so
you
can't
sort
of
take
advantage
of
it
with
docker
files
and
for
there's.
Also
a
feature
in
new
docker
registry
is
called
cross.
Repo
block
mounting
where
you
can
sort
of
have
a
one
repository
refer
to
layers
in
another
repository
without
having
to
copy
layers
between
them.
A
So
now
I'll
talk
a
little
bit
about
the
new
build
peg
API
that
we're
providing
and
sort
of
compared
to
the
cloud
201
right
now,
so
in
Cloud
Foundry,
we
have
all
these
scripts.
We
have
detect
supply
finalize
and
release,
and
this
new
API
things
get
a
little
bit
simpler.
So
we
combine
the
supply
step
that
supplies
Dependencies.
A
The
final
line,
step
that
sort
of
does
last
preparation
on
the
app
and
the
release,
step
that
generates
the
start
command
into
one
bin,
build
script,
things
get
a
little
simpler,
but
then
to
support
really
modular
multi
build
pack
mode
where
you
can
have
lots
of
small,
build
packs
that
are
transparent
working
together.
The
detection
phase
across
all
the
build
packs
has
some
metadata
that
gets
fed
into
the
build
phase,
and
so,
if
you
look
at
that
detect
and
build
sort
of
scripts,
we
had
two
phases
that
are
handled
by
the
platform
to
that.
A
So
during
this
detection
phase
an
optimal
group
of
build
packs
is
selected,
and
then
they
all
have
to
agree
that
this
is
a
good.
This
app
is
a
good
candidate
for
those
build
packs.
During
the
analysis
phase,
we
look
at
the
previously
generated
image
and
pull
metadata
down
about
it,
so
that,
during
the
build
phase
we
only
have
to
regenerate
layers
that
need
to
change.
We
actually
leave
layers
that
don't
need
to
change
on
the
registry.
We
don't
build
them,
we
don't
read
them
at
all,
so
it's
very
efficient.
A
So
I'm
gonna
take
you
through
what
this
looks
like
sort
of
step
by
step
and
so
for
an
application.
That's
using
you
know
in
the
cloud
finder
case
for
Ruby
we'd
probably
have
three
build
packs
and
node
we'd
probably
have
four
build
packs,
but
in
the
simple
example
I'm
going
to
say,
this
is
one
application
that
has
Ruby
no
dependencies
and
pretend
that
we
just
have
one
monolithic,
Ruby,
buildpack
and
one
monolithic
node
build
pack
just
to
kind
of
make
it
easier
to
understand.
A
So
during
the
detection
phase,
the
first
the
Ruby
build
pack
runs
and
this
it
can
actually
happen
in
parallel
to
some
extent,
but
I'm
not
going
to
go
into
that
exactly
when
the
Ruby
little
Peck
runs.
It
looks
at
the
app
and
says
yes
I'm
a
good
candidate
for
this,
and
it
moves
on
to
the
node.js
build
I'm.
Sorry,
it
generates
some
metadata
about
what
it
saw
in
the
application.
Then
the
nodejs
build
pack
runs,
looks
at
the
app
and
says
yep.
This
is
a
good
node.
App
also
generates
some
metadata
about
the
node.js
version.
A
A
If
you
have
that
Ruby
node
node
AB
analysis
runs
and
doesn't
do
anything
because
it's
the
first
build
build,
runs,
installs
Ruby
does
bundle,
install
and
stops
node
doesn't
PM
install
the
new
layers
are
exported
to
the
image
and
then
in
a
second
build
when
the
apps
changed,
and
maybe
in
this
case
just
the
node
and
node
modules
and
gems
changed
but
the
rest
didn't.
Then
we
read
metadata
about
those
layers.
C
Ok
before
we
head
into
the
demos,
does
anybody
have
any
questions
about
what
we
just
saw
there
No,
ok,
so
I'm,
going
to
do
demos
of
three
new
things
that
you
can
do
with
cloud
native,
build
packs
that
you
weren't
previously
able
to
do
or
we're
not
able
to
do
particularly
easily,
and
all
of
these
are
going
to
be
centered
around
that
pack
CLI.
That
I
did
in
the
demo
yesterday
and
since
I
have
a
bit
more
time
today.
C
I
can
explain
to
you
a
little
bit
more
about
what
exactly
is
going
on,
so
the
the
cloud
need
to
build.
Pack
specification
differs
significantly
from
the
previous
bill
pack
spec,
because,
in
addition
to
defining
sort
of
what
a
build
pack
expects
to
be
called
right
so
like
whether
you're
going
to
call
bin
detect
bin
build
things
like
that
and
what
your
obligations
are
as
a
build
pack
implementer.
It
also
defines
the
other
side
of
that
interaction
as
well
in
a
way
that
we
never
did
before.
C
It
defines
how
the
platform
interacts
with
build
packs
themselves
and
sort
of
the
the
implementation
of
that
that
specification
right.
The
two
sides
coming
together
is
something
that
we
call
the
light
cycle
and
the
life
cycle
is
really
interesting.
We
have
a
reference
implementation
that
we
know
is
going
to
be
used
inside
of
you
know,
Cloud,
Foundry
and
pivotal
products,
but
expected
to
also
be
used
inside
of
Heroku
as
well.
So
since
we
have
this
thing,
this
lifecycle
thing
it
turns
out.
It's
just
a
go
binary.
C
We
can
wrap
that
on
a
bunch
of
different
platforms.
We
can
wrap
it
for
a
cloud
foundry.
We
can
wrap
it
for
Heroku
and
we
can
wrap
it
in
this
pack,
CLI
that
I'm
gonna
use
today,
so
that
pack
CLI
then,
is
just
a
very
thin
wrapper
that
exercise
it's
exactly
the
same
code
we'd
expect
to
everywhere
else.
So
the
first
demo
that
we're
going
to
we're
gonna
jump
off
with
is
basically
an
extension.
A
demonstration
of
what
we
just
saw
Stephen
talked
about.
C
So
we're
going
to
do
a
PAC
build
here,
build
I'll,
make
sure
I
build
the
correct
one,
okay,
and
so
we're
just
going
to
build
the
same
thing
we
did
yesterday
in
the
demo.
We're
gonna
build
a
pre,
compile
java
application.
I
really
wanted
to
come
in
here
and
show
you
all
that
for
the
first
time
on
the
java
build
pack
side,
you
can
actually
build
from
source
now,
but
the
conference
internet
is
slow
enough
that
that's
just
not
gonna
happen.
It
begins
with
downloading
all
of
maven.
C
So
I'm
pretty
sure
you
all
wanted
to
get
out
of
here
before
that
was
done.
So
we
see,
as
we
saw
yesterday,
there's
a
build
pac
group
up
here
that
we're
gonna
skip
because
it
happens
to
be
the
one
that
has
riff
our
function
is
a
service
in
it.
But
in
this
particular
case
we
had
our
second
one
that
has
an
open
JDK,
build
pack
in
the
JVM
application
build
pack
in
here,
and
so
we
see
that
we
get
this
contribution
of
open,
JDK
1102
to
a
launch
layer.
C
Basically
we
have
the
it
says:
it's
reusing
the
cache
download
so
offline
build
pack
style.
We
have
the
the
Tartar
file
there
and
we
have
to
untie
it
onto
the
file
system,
and
then
we
have
to
upload
that
data
to
a
registry
somewhere,
and
so
you
sort
of
think
to
yourself
well
that
can't
possibly
take
that
long.
In
reality,
it's
about
a
second
and
a
half
two
seconds
to
do
something
like
that,
but
we're
working
on
eking
out
every
single
second,
in
our
build
packs
right.
C
We
want
to
make
sure
that
you
can
get
into
running
situations
as
quickly
as
possible.
This
is
really
really
critical
in
something
like
a
function
as
a
service
kind
of
environment
and,
as
I
said,
project
RIF
earlier
on
right.
We
are
actually
already
have
a
customer
for
these
build
packs
if
you
have
ever
used
anything
from
Project
RIF
or
if
used
the
PAS
or
sorry
PFS
beta
product,
and
things
like
that,
they
already
use
cloud
me
to
build
packs
for
this
another
place
that
we've
another
platform
that
has
opted
to
use
that
lifecycle
reference
implementation.
C
That's
that's
attached
to
the
image,
but
not
the
data
attached
to
the
image
and
do
a
comparison,
and
if
you
are
satisfied
that
what
that
layer
was
created
from
ur
that
that
metadata
matches
what
you
think
it
is
previously,
then
you
can
just
go
ahead
and
say:
oh
I'm,
gonna
reuse,
this
layer,
I,
don't
need
it
and
I
don't
need
to
rebuild
it.
I!
Don't
need
to
spend
that
second
to
two
seconds
building
it
and
another
bit
of
time
uploading
it
question
it.
C
Alright,
so
the
question
is:
what
exactly
is
the
contract
of
the
metadata
that
you
put
you
attach
to
each
layer?
The
contract
is
actually
only
between
you
and
yourself
in
the
future
right.
So
the
question
of
whether
or
not
I
am
going
to
rebuild
this
JRE
is
only
for
me
to
look
at
a
piece
of
what
everybody
else
should
consider
to
be
completely
opaque
metadata.
So
you
could
imagine,
for
example,
version
11.10.
C
C
If
you
know
your
source
code
or
your
compiled
code
is
Java
8,
then
you
need
to
make
sure
that
you
request
a
Java,
8
JVM,
and
you
expect
that
the
open,
JDK
build
pack
will
provide
that
for
you.
Maybe
you
know.
Eight
101
and
then
eight
202
and
then
eight
303,
but
you've
asked
for
Java
8
and
you're
gonna
get
Java
8.
C
So
just
to
give
you
a
comparison
of
what
this
looks
like
when
you
run
it
with
PAC
or
you
run
it
in
a
life
cycle,
we
only
download
the
metadata
about
the
image
and
not
actually
the
image.
I
can't
reproduce
that
particularly
easily
I
mean
I
can
type
about
11
different
commands
and
get
that,
but
we're
gonna
I'm,
just
gonna
pull
the
whole
thing.
So
you
can
see
what
it
looks
like
so
on
that
image.
C
There's
some
metadata
that
looks
like
this
for
each
individual
layer,
and
so
these
are
layer
names
right
here,
tell
sort
of
the
shah's
and
the
data
that
we've
opted
to
put
into
it.
And
so
this
bit
here
is
opaque.
But
what
we've
chosen
to
do
is
we
represent
build
pack
dependencies
I.
Think
I
can
do
a
cat.
C
Like
this,
we
represent
a
dependency
sort
of
like
this
inside
of
a
Tamil
representation,
and
we
use
this
to
say:
if
any
of
this
has
changed,
I
want
to
rebuild
a
layer.
This
hasn't
changed,
then
I
just
want
to
use
it,
as
is
the
key
thing.
Obviously,
is
this
sha
right
here
as
long
as
I
planned
on
untiring
the
exact
same
binary
I
had
before
I?
Don't
need
to
do
it
again,
so
yeah,
let's
go
back
here
again,
represent
it
all
in
here,
but
it
doesn't
have
to
be
this
dependency.
C
C
Okay,
so
that's
avoidance
of
layer
creation.
Next
thing
we're
going
to
talk
about
is
the
way
we
get
to
use
multi
build
pack
and
that
modularity
that
I
showed
off
yesterday
to
say:
okay,
I
want
to
do
some
sort
of
replacements,
some
sort
of
modification,
but
I
want
to
do
it
without
forking,
my
entire
build
pack.
So
a
really
common
thing
inside
of
the
Java
build
pack
was
I,
don't
want
to
use
open.
Jdk
I
have
Oracle
I
run
on
top
of
eight
of
us,
alright
run
on
top
of
Azure
or
I'm.
An
sa
p.
C
Customer
and
I
want
to
use
sa
p
machine
again.
Instead,
so
I'm
going
to
show
you
what
we
call
a
builder
dot
Tamil
file,
the
plan
is,
unless
you
plant,
unless
you
go
out
and
use
pack
CLR
the
pack
CLI
today,
you
shouldn't
really
ever
have
to
see
this.
We
expect
this
to
be
sort
of
managed
by
the
platforms,
but
it
does
give
you
sort
of
a
really
low
level
view
of
us
acting
as
a
platform.
What
exactly
we're
doing
so?
C
The
first
thing
is:
there's
a
definition
of
all
of
the
build
packs,
basically
just
a
bag
of
all
of
the
build
packs
that
you
might
have
access
to,
and
so
we
have
things
like
s
AP
machine.
We
have
all
the
stuff
for
project
riff,
a
bunch
of
stuff
around
nodejs
and
NPM
and
of
course,
all
of
the
Java
build
packs
as
well.
Then,
once
you
have
those
you
organize
them
into
groups
and
groups
are
both
ordered
and
described
optionality,
and
so
right
now.
C
The
second
group,
the
one
that
detected
that
we
saw
before
is
one
that
starts
with
open.
Jdk,
then
contributes
a
build
system.
Optionally,
JVM
application
is
required
that
New
Relic
and
then
so
on
and
so
on
from
there.
So
what
we
want
to
do,
though,
is
as
I
said
before:
we
don't
want
to
use
the
cloud
foundry
open,
JDK.
We
want
to
use
s
AP
machine
instead,
which
is
an
open,
JDK,
compatible
variant
available
from
s
AP,
as
you
might
expect
so,
I'm
going
to
go
back,
I
need
to
do
a
builder.
C
Open
source
is
going
to
take
a
second
to
actually
do
probably
sure
to
kick
that
off.
What
we're
doing
is
we're
creating
a
builder
image
in
order
to
guarantee
that
there
is
sort
of
a
controlled
environment
where
your
application
is
built,
the
same
way
every
single
time.
We
actually
create
an
image
with
all
of
the
build
packs
and
all
this
metadata
inside
and
when
your
application
is
handed
to
us.
We
start
that
up
inside
of
a
container,
and
then
we
actually
build
your
application
in
that
controlled
environment.
That's
way
you
can
guarantee
you
get.
C
Reproducible
builds
not
just
on
a
given
platform.
You
you
know
we're
not
saying
that
the
environment
is
consistent
between
Cloud
Foundry
and
another
bit
of
Cloud
Foundry.
We're
actually
saying
it's
consistent,
potentially
across
all
of
these
different
platforms,
the
same
on
pack
CLI
as
it
is
on
Cloud
Foundry
as
it
is
on
Heroku.
C
C
If
you
have
a
fork,
you
need
to
make
sure
that
you
consume
that
and
get
all
of
the
security
fixes
and
improvements,
and
things
like
that.
This
takes
that
out
of
your
hand
as
long
as
you're
always
staying
up
to
date
with
s
AP
machine.
The
fact
that
you've
swapped
it
out
instead
of
using
the
open
JDK,
means
you're
going
to
stay
up
to
date
without
a
huge
amount
of
effort.
C
Okay
and
then
the
final
thing
that
we're
going
to
demonstrate
here
is
what
I
call
a
cross-cutting
build
pack,
one
of
the
things,
especially
APM
vendors,
really
like
about
this
new
thing
is
previously.
If
you
wanted
to
integrate
so
your
new
relic
and
you
wanted
to
integrate
into
the
build
packs,
you'd
run
into
situations
where.
C
Sorry
totally
lost
my
train
of
thought
here:
you'd
run
into
situations
where
integrating
into
the
Java
build
pack
happened.
One
way
integrating
into
the
node
built
pack
happened.
Another
way
and
there's
very
good
reasons.
We'd
want
that
integration
into
Java
build
pack
to
be
consistent
with
all
of
the
other
integrations
into
the
Java
patent,
build
pack.
If
you're
a
Java
developer,
you
should
expect
to
configure
these
integrations
in
the
same
way
to
find
which
versions
of
the
dependency
you're
supposed
to
use
in
a
good
way
and
the
same
thing.
C
True,
on
the
node
side,
you
expect
all
the
integrations
into
node
to
look
very
similar
to
one
another.
But
now,
if
we've
got
this
modularity,
we
have
this
possibility.
Instead
of
being
consistent
with
each
language
that
we
can
have
a
vertical
slice
effectively,
we
can
say:
New
Relic
needs
to
be
sort
of
consistent
with
itself
across
multiple
languages,
so
we'll
go
ahead
and
do
a
build
to
the
Java
one
and
I'll
add
New
Relic
configuration
so
effectively,
while
this
kicks
off
adding
in
that
end
file
at
the
end
effectively.
C
What
this
does
is
that
end
file
exposes
what
you
guys
think
of
as
vcap
services
as
a
service
payload
for
actually
binding
to
New
Relic.
It's
likely
going
to
change
name
to
CNB
services,
to
be
cloud
native,
build
pack
and
portable
across
multiple
platforms.
Again,
because
one
of
the
key
things
is,
we
want
this
image
to
be:
go,
be
able
to
go
to
a
bunch
of
different
places,
but
fundamentally
the
payload
is
exactly
the
same.
C
And
a
different
one
that
one
here:
if
we
go
ahead
and
run
that
same
thing,
but
again
putting
the
end
file
with
a
New
Relic
configuration
in
it,
we
go
ahead
and
fire
that
thing
off
we'll
see
that
it
starts
connecting
to
New
Relic
I'll.
Let
it
go
the
whole
way
out
and
demonstrate
that
it
is
actually
has
made
a
connection.
Well,
one
of
the
key
things
you'll
you'll
see
in
these
new
build
packs.
We've
taken
the
opportunity.
This
isn't
something
you
technically
couldn't
do,
but
it
was
something
we
didn't
do
very
often.
C
We
actually
now
only
resolve
service
credentials
at
run
time.
They
never
get
baked
into
the
image
and
in
the
old
days
there
were
many
places
all
over
the
Java
build
pack
I
know
you
know
very
very
explicitly
where
we
baked
in
service
credentials
into
the
droplet
itself.
The
service
was
bound
during
staging
time,
which
is
still
a
requirement,
but
then
we
would
like
read
the
license.
Key
right,
write
it
onto
the
file
system
in
the
configuration
file
for
New
Relic.
C
Now
we've
been
really
really
explicit
because
we
want
this
portability
between
all
these
different
platforms
and
all
these
different
environments,
even
though
it
is
much
harder
to
do.
We
will
only
resolve
those
things
at
runtime,
so
when
I
say
much
harder
to
do
literally,
every
single
integration
we're
doing
at
this
point
has
some
little
helper
application.
Yet
another
go
application
that
has
to
be
contributed.
So
I've
got
go
apps
and
go
apps
and
go
apps
at
this
point.
C
C
We've
got
a
java
application
and
somewhere
in
here
it
says
it's
reporting
to
New
Relic
right
here,
but
without
making
any
changes
I'm
telling
you
that
they
we
are
using
the
exact
same
New
Relic
build
pack,
we
did
before
I
want
to
do
a
pack
build
again,
but
this
time
we're
going
to
build
a
node
NPM
application.
This
application
is
basically
hello
world
as
I.
Remember
it
we're
making
sure
that
an
New
Relic
is
on
the
environment
again,
because
we
still
need
a
signal
right.
C
We
still
need
to
know
that
it
is
appropriate
for
me
to
add
the
no
js'
agent,
even
though
we're
not
going
to
the
values
in
it.
We
do
need
to
know
that
the
service
is
there
to
make
sure
that
all
the
binaries
that
are
necessary
are
available.
The
alternative
is
for
me
to
pack
in
all
of
the
40
integrations
into
every
single
one
of
your
applications
and
trust
me.
You
really
don't
want
me
to
do
that
so
off.
We
go
we'll,
go
ahead
and
do
another
docker
pull
of
this
particular
application.
C
And
not
the
Java
one
then
hit
one
this
time
around.
It
is
somewhere
in
here
starting
a
new
relic
for
nodejs
and
tells
us
that
this
is
where
we
are
streaming
all
of
our
data
to,
and
so
one
of
the
last
things
I
want
to
do
here
in
our
last
couple
of
minutes
is
I.
Do
want
to
show
you
what
sort
of
a
modern
build
pack
actually
looks
like
I'm
going
to
use
this
new
relic
build
pack
as
an
example
of
it.
C
So
what
you're
going
to
find
out
if
you
are
familiar
with
the
build
packs
as
they
exist
today,
specifically
the
Java
build
pack,
we
are
switching
over
to
go
from
from
Ruby
as
it
was
before.
There
are
reasons,
historical
reasons
why
it
was
Ruby
originally
mostly
because
sort
of
predates
the
existence
of
go
and
then
so
many
people
had
forked
it
that
migrating
was
going
to
be
kind
of
a
problem
and
be
horribly
breaking,
but
to
be
sort
of
good
citizens
inside
the
cloud
native
computing
foundation.
Go
is
a
good
choice.
C
We're
gonna
do
it
you're
not
required
to
as
part
of
the
spec.
The
spec
basically
says
that
there
must
be
a
/bin
build
and
a
/bin
detect
write
whatever
language
those
executables
are
in
doesn't
matter.
You
could
write
it
in
bash,
as
some
of
our
samples
are
right,
but
in
our
particular
case
we've
chosen
go
and
I
wanted
to
sort
of
show
you
the
kind
of
things
that
we're
doing
to
get
this
cross-platform
behavior.
So
we
have
sort
of
a
language
binding
that
we
call
Lib
build
pack
that
sits
on
top
of
the
specification.
C
If
you're
a
go
developer,
I
expect
there
to
be
more
live,
build
pack
equivalents
for
other
programming
languages.
People
can
write,
build
packs
in
anything
that
they
really
choose
to.
But
what
we're
doing
effectively
here
is
say:
hey.
Is
there
a
new
relic
service
if
there
is
a
new
relic
service
and
it
has
a
license?
Key
credential
I
might
be
able
to
participate,
and
if
that's
the
case,
someone
else
has
told
me
that
this
is
a
JVM
application
right.
C
This
is
one
of
those
other
key
things
about
the
modularity
is
we
saw
a
lot
of
people
when
they
were
in
situations
where
they
were
trying
to
do
a
multi,
build
pack
kind
of
deployment
that
they
were
having
to
detect
in
multiple
places?
Whether
or
not
is
this
a
java
application?
Is
this
a
node
application?
C
Is
this
a
ruby
application
and
all
of
them
use
different
sort
of
heuristics
to
determine
whether
or
not
those
things
were
true
now
what
we
want
to
do
is
there
is
some
Authority,
the
JVM
application
build
packed
in
this
case
that
defines
this
is
what
it
means
to
be
a
JVM
application.
It
knows
about
Java,
knows
about
Copland.
It
knows
about
Scala,
knows
about
all
of
these
different
languages
that
make
up
the
JVM
ecosystem.
So
now
the
note
the
sorry,
the
new
relic
bill
pact
never
needs
to
detect
it.
It
just
needs
to
say:
hey.
C
Am
I
a
JVM
application
if
I
am
I
want
you
to
participate,
basically
contribute
the
Java
agent
dependency
in
the
future
on
the
node
side,
if
this
is
a
node
application
right,
if
someone
else
has
detected
this
for
me,
then
I
want
to
participate
in
it
by
adding
that
agent
dependency
there.
We
also
sort
of
blindly
ask
for
Python
at
Python
is
available.
Since
one
of
the
new
relic
agent
dependencies
can
be
natively
compiled
if
pythons
around
and
falls
back.
C
Okay,
so
end
of
the
demo,
as
we
announced
yesterday,
our
first
public
beta
came
out
earlier
this
week
that
PAC
CLI,
that
you
saw
me
playing
around
with
I
highly
encourage
you
to
use
it
all.
The
build
packages
so
make
demoing
here
are
available
inside
of
that
and
they're
all
based
on
your
favorite,
open
tube
based
operating
system.
Image
finally
feel
free
to
join
us
on
our
slack
to
discuss
this
pretty
vibrant.
C
In
fact
it's
so
the
question
is
previously:
we
had
very
little
bit
little
visibility
about
what
was
contributed
into
a
build
patter
into
an
application.
When
a
build
pack
was
used,
it
seems
like
there's
going
to
be
less.
The
answer
is
actually
there's
going
to
be
significantly
more.
One
of
the
contracts
is
that
we
build
a
bill
of
materials
every
time
a
build
pack
contributes
something
to
a
layer.
C
It
has
the
opportunity,
and
certainly
we
take
it
very
heavily
to
describe
exactly
what
was
put
on
to
that
particular
layer
so
that
whole
dependency
thing
where
it
said
it's
open,
JDK,
11
version,
blah
blah
blah
has
this
shot
and
in
more
input,
most
importantly,
to
a
lot
of
people.
It
has
this
license
attached
to
it.
That
will
all
be
in
metadata
attached
to
the
image
itself,
so
you
can
literally
query
against
a
registry
and
find
out
exactly
what
was
put
in
there.
C
Our
build
packs
will
also
go
through
on
the
Java
side,
something
that
people
have
really
really
wanted.
For
a
long
time.
We
will
enumerate
like
all
the
jar
file
dependencies
in
your
spring
boot
application
or
your
web
application
and
do
a
best-effort
like
we're
not
going
to
resolve
them
back
to
names.
But
we'll
say
it's.
You
know
spring
core
version,
5.2.1
adopt
release
and
those
will
be
exposed
through
the
same
Bill
of
Materials
as
well.
So
I
think,
that's
probably
way
more
than
you
were
expecting
yeah.
C
Yeah,
it
was
one
of
those
things
like
we
knew
that
this
was
an
issue,
but
every
other
time
we
tried
to
solve
this
problem.
We
tried
to
solve
it
by
kicking
data
back
to
the
cloud
controller
and
we
basically
said
we're
not
going
to
wait
for
the
cloud
controller
to
sort
of
demystify
a
priority.
It
will
be
part
of
the
specification,
because
it's
that
important
it
will
attach
to
each
individual
image.
D
A
We
haven't
like
fleshed
out
the
integration
with
cloud
controller
yet,
but
we're
sorry,
oh
yeah,
repeat
the
question.
Sorry:
what
will
this
integration
look
like
with
cloud
controller
in
how
will
cloud
controller
expose?
You
know,
what's
in
these
images
and
what
bill
packs
are
built
with
and
and
all
those
things,
so
we
haven't
figured
out
the
integration
with
cloud
controller
yet,
but
because
we're
exposing
all
this
metadata
on
the
images
we
can,
we
can
expose
the
through
cloud
controller
and
I.
Think
when
we're
looking
at
this
we're
looking
at
it
like.
A
Can
we
have
a
more
declarative
model
for
images
where
you're
saying
this
is
what
I
wanted
my
image
and
you're
having
the
platform
continue
to
build
images
to
meet
that
instead
of
having
developers
go
I
want
to
restage
this
now
because
I
think
there
may
be
see
these
in
it
right.
We
want
to
move
to
things
automatically
get
rebuild,
and
then
your
pipelines
could
pick
up
on
them
automatically
and
get
promoted
through
environments
and
kind
of
yeah
be
more
proactive
about
that
as
a
platform,
because.
C
It
one
of
the
sort
of
insidious
bugs
that
people
don't
realize
is
it's
one
thing
for
the
for
operators
to
make
sure
build
packs
are
staying
up-to-date
so
that
every
newly
staged
application
is
up-to-date.
But
then
you
also
have
to
keep
track
of
all
of
the
applications
that
aren't
regularly
restaged
right
and
I
know.
A
lot
of
you
know,
companies
that
do
the
former
and
haven't
even
thought
that
the
second
one
is
a
factor
for
vulnerability
yeah.
C
A
You
can
do
that
right
now,
so
we,
the
packs
Eli
that
Ben
just
showed
you.
It
works
on
a
local
workstation.
You
can
build
your
images,
they
build
the
exact
same
way
they
would
in
a
platform.
We
actually
did
the
local
integration
before
the
platform
integration
this
time,
so
you
can
yeah
all
works.
It's.
C
C
When
the
relay
ring,
as
in
the
rebase
right,
so
the
only
thing
that
we
are
committed
to
rebasing
at
this
time
is
the
operating
system.
The
operating
system
has
a
a
guaranteed
ABI
compatibility
and,
while
I'm
not
saying
canonical,
has
never
broken
a
bi
compatibility,
we
sort
of
depend
on
it.
For
you
know,
tens
hundreds
of
millions
of
rebase
is
across
Cloud
Foundry
over
the
last
five
years.
I.
C
Mean
I
I,
don't
think
so.
I,
don't
think
we're
going
to
add
any
flags
in
there
simply
because
it
goes
it's
almost
impossible
for
us
to
tell
after
the
fact
or
it's
alright
before
an
application
starts
that
it
might
break
so
then
you
basically
have
the
health
checks,
as
applications
are
started
up
right,
I.
Think.
A
There's
sort
of
two
levels
to
this
right:
there's
the
talking
about
the
operating
system
package
level
and
the
application
layers
and
being
able
to
rebase
that
out
from
under
the
application
layers
right
and
that
that
contract
is
very
tight.
We
do
this
on
Cloud
Foundry
already
in
production
for
lots
and
lots
of
apps.
It's
never
broken.
A
We
never
had
a
report
of
it
being
broken,
so
we're
not
very
worried
about
that,
because
it's
just
security
patches
from
operating
system,
vendors
that
do
lots
of
testing
right,
but
then,
at
the
application
level
the
contract
between
those
layers
is
is
very
strict
in
a
different
way.
It's
sort
of
enforced
to
be
everything's
installed
in
these
different
directories
and
there's
a
very
particular
contract
between
there
so
that
there
isn't
a
possibility
of
layers
the
order
of
layers
mattering
there
or
anything
like
that.