►
Description
Destroying Non-Production - Saving 44% on Cloud - Shlomo Bielak, Benchmark Corp.
Speakers: Shlomo Bielak
The only reason non-production persists is due to ineffective SDLC/CICD processes. 44% of resources in a cloud are non-production systems. 76% of those workloads are idle because of release cadences and our fear of recreation. We have developed true Cloud Native CI/CD pipelines that make the SDLC so efficient that we add a new state to non-production, destruction. Collect your telemetry and metrics, shift security together, promote your code, & destroy those resources. Saving money and capacity for others (cloud & on-prem). We will demonstrate this using our advanced pipelines that delivers environments and applications together some marked for destruction. We call it On-Demand-Non-Production!
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Welcome
to
cdcon
2021,
I
am
one
of
the
speakers:
bilac
cto,
at
benchmark
corp,
I'm
going
to
cover
the
topic
of
one
of
our
inventions
to
redesign
the
sdlc
destroy
non-production.
Essentially,
we've
coined
the
term
non-production
and
permanence.
We've
prepared
this
specifically
for
all
the
continuous
delivery
practitioners
out
there
that
are
looking
for
new
methods
that
are
not
rear-view
mirror.
A
I
want
to
cover
a
little
bit
about
ourselves,
because
I
think
it's
important
to
understand
that
we
are
pioneering
cicd
solutions
with
burden-centric
approach,
where
we
do
very
unique
measurements
when
it
comes
to
burning.
We
help
other
organizations
measure
that,
with
our
own
ip
I'm
going
to
share
today,
one
of
our
nine
reinventions
of
the
sdlc.
A
It
comes
from
previous
expertise
as
a
head
of
sre
and
a
cso
at
ncr,
which
is
a
fortune
500.
and
we're
now.
Engineering
new
methods
based
on
client
practices
and
implementation,
so
we're
the
builders,
the
architects,
the
pioneers
and
we're
participating
on
a
multitude
of
different
organizations
trying
to
contribute
back
intellectual
property.
So
we
advance
our
sdlc
and
the
best
practices
that
are
out
there
and
change
what
the
rear
view
shows.
A
A
What
we
mean
by
that
is
the
creation
of
artifact
and
the
delivery
of
that
to
non-production
and
the
promotion
process
that
gets
it
into
a
production
environment
is
key.
If
you
don't
have
that
capability,
it's
really
hard
to
remove
the
non-production
system,
because
you're
not
getting
confidence
for
fraud,
how
you
achieve
that
is
basically
taking
two
pieces
that
are
generally
independently
constructed
in
organizations
because
baileywicks
are
independent
and
there
is
some
convergence
that
occurs,
but
it
changes
the
overall
architecture
and
archetype
of
a
ci
cd
process.
A
We
have
unique
reinventions
of
how
to
do
qa
automation
and
how
to
converge.
These
two
pipelines
today
we're
going
to
talk
about
how
I
get
to
non-production
destruction
and
what
that
looks
like
and
what
your
benefits
are.
The
clock
at
the
bottom
with
the
pop
is
my
invention.
I
just
didn't:
have
this
a
way
to
distinguish
once
I
use
it
and
I'm
finished,
it
doesn't
need
to
exist
anymore
because
it
doesn't
provide
any
value.
So,
let's
try
to
get
into
this.
A
One
of
the
key
pieces
is
spend
and
if
you're,
if
you're,
not
controlling
your
spend
either
on
the
refresh
budget
of
your
on-premise,
which
is
part
of
your
hybrid
architecture
or
if
your
public
spend
is
continuing
to
grow
because
you
know
you
just
had
advanced
and
adopted
additional
data
centers
and
you
didn't
manage
or
change
how
you
operate.
You're
basically,
gonna
blow
your
budget,
that's
one
of
the
things
that
spiceworks
found
is
or
the
largest
reason
for
people
to
not
succeed
in
cloud
was
spend
or
exceeding
their
expected
spend.
A
There
are
metrics
you
need
to
consider,
and
this
is
going
to
come
to
why
the
non-production
and
permanence
is
key
and
it's
it's,
because
you're
no
longer
buying
your
car
you're,
now
renting
or
leasing
the
car
and
the
idea
behind
that
is.
If
I
leave
a
car
in
my
driveway
and
I'm
not
using
it,
I
wouldn't
want
to
spend
on
it.
So
you
have
to
change
the
method
of
how
you
operate
in
the
cloud
and
how
do
you
achieve
that
using
the
sdlc?
A
If
I
leave
things
sitting,
it
costs
me
money
cloud
native
gives
you
the
ability
to
create
and
destroy
more
frequently
and
easily
and
reliably,
and
you
only
need
to
persist
when
you
need
to
right.
There's,
obviously
areas
that
with
data
we
have
to
talk
about,
but
we're
not
going
to
get
into
you
know
the
customer
data
permanence,
but
essentially
gartner
did
a
study.
They
are
not
looking
at
it
the
same
way
I
was,
I
read
their
the
article
and
recognized
that
the
their
their
focus
was
on
overspending
oversizing.
A
My
focus
was
if
the
metrics
are
true.
I
need
to
remove
as
much
as
I
can
and
I
needed
a
solution
so
44
of
spend
on
that
study
basically
said
it
was
non-production
systems.
You
can
probably
go
back
to
your
engineering
department.
You'll
find
out
the
budget's
extremely
large.
That
is
my
background.
Is
r
d
over
that
time.
A
76
of
it,
it
sat
in
the
driveway
doing
nothing.
It's
just
sitting
idle.
We
wouldn't
leave
our
car
three
quarters
of
the
week
sitting
doing
nothing
when
we're
not
using
it.
So
this
is
how
we're
operating
non-production
so
non-production
lives
today
due
to
inefficient
sdlc
best
practices,
it's
entirely
wrong.
Rsdlc.
A
It
has
many
gaps
and
I'm
only
covering
one
of
the
corrections.
We
must
include
a
destroy
stage
as
part
of
the
sdlc
process.
After
confident
levels
of
metrics
are
collected,
analyzed
and
parsed
to
promote
the
code
to
the
next
environment,
at
which
point
the
environment
that
collected
the
metrics
that
are
giving
us
that
confidence
is
destroyed.
You
don't
need
it
anymore.
There
is
no
customer
value
and
I
reiterate,
coming
from
an
engineering
department,
there's
no
customer
value
in
non-production
none.
A
A
I'm
gonna
move
into,
let's
also
investigate
what
it
does
to
you.
If
you
reduce
your
burden,
everybody
knows
that
burden
is
our
focus,
but
it's
also
a
measurement
that
you
can
do,
and
this
is
just
a
snippet
from
one
of
our
applications.
We
measure
all
of
our
customers
right.
So
if,
if,
if
non-production
value
is
only
confidence
or
production,
then
I
don't
want
things
to
persist
because
it
causes
toil
and
it
supports
brittleness
the
longer
I
keep
something
running,
the
less
likely
I'm
going
to
find
problems
with
it.
A
We
find
that
a
very
small
slice
is
production,
like
you
can
see
here
that
almost
80-90
percent
is
non-production
systems
80
to
90
percent
of
bird-
and
I
know
engineers
won't
believe
me
or
devs
won't.
Believe
me,
I'm
sure
the
ops
understand
that
it's
true,
almost
80
to
90
percent
of
burden
is
non-production.
We
persist
these
environments.
I
I
just
there's
no
reason
we
need
to
work
on
delivering
apps
more
consistently
through
pipelines.
We
need
to
work
on
delivering
our
infrastructure
with
those
applications
get
some
qa
automation
done.
A
A
I'm
going
to
show
examples.
These
are
example
pipeline.
I
know
we're
at
cdcon.
The
bottom
one
is
an
example
of
jenkins
cicd,
depending
on
some
of
the
providers
that
you
use
the
git
lab
github
actions,
azure
pipelines,
whatever
you're
using
jenkins
or
blue
ocean.
Whatever
your
choices,
all
of
them
have
the
capability
of
redesigning
this
dlc
and
how
they
all
function.
All
of
these
function
the
same
way
yet
they're
three
independent
live
demos
of
different
products,
but
they
achieve
the
same
methods.
A
I
create
my
infrastructure.
I
build
my
artifact.
I
check
my
artifact.
I
deploy
that
artifact.
I
do
performance
testing.
I
collect
my
metrics
and
pass
my
security
gates,
destroy
that
environment
and
then
go
through
the
next
promotion
process
and
that
destroyed
piece
saves
you
50
50,
almost
of
your
budget.
The
reason
being
is
you
have
total
cost
to
operate,
non-production,
which
is
a
big
budget
and
the
actual
dollars
spent
on
either
the
infrastructure
required
for
all
of
them
to
persist
or
the
cloud
spend
where
these
environments
run.
A
This
is
an
example.
I'd
like
to
share,
look
reuse.
What
you
got
don't
get
me
wrong.
You
could
add
this
capability
in
any
of
your
pipelines
today.
You
just
have
to
think
differently
and
orchestrate
at
a
higher
level.
In
this
example,
this
was
a
a
cloud
native
methodology
for
google.
This
was
implemented
at
clients
before
the
clock
and
the
pop
is
essentially
the
context
behind
blowing
away
the
build
environment
blowing
away
the
non
the
non-production
environments,
which
could
be
staging
performance,
development
qa
again,
you're
gonna
have
so
few
environments
persisting.
A
You
won't
need
so
many
of
them,
because
you
can
just
bring
them
up
with
the
profile
you
require
and
destroy
them
afterwards,
rather
than
having
so
many
persist.
Our
need
to
persist
is,
what's
actually
causing
the
inefficiency
of
this
dlc.
Only
production
needs
to
persist.
There
are
some
very
big
advantages
and
I'm
going
to
get
to
them
after
this,
which
is
essentially
by
destroying
non-production,
we
reduced
a
tutorial.
A
A
This
is
the
most
important
piece
that
I
didn't
touch
on
yet
because
I
wanted
to
build
up
to
this
is,
if
I
don't
persist,
environments
I
can
match
production,
100
data
size
because
I'm
not
leaving
the
environment
that
would
eat
up
dollars.
The
only
reason
non-production
doesn't
look
like
production
is
because
we're
trying
to
save
money
on
it,
because
we
know
it's
going
to
sit
there
forever.
That
is
wrong.
No
one
needs
access
to
these
environments.
These
environments
and
deliveries
need
to
be
entirely
orchestrated.
A
They
need
to
be
created
by
that
orchestration
destroyed
by
that
orchestration,
and
then
we
will
increase
the
confidence
to
production
to
the
point
of
100
reliability.
I
know
that
challenges
google's
sre
practices,
we've
published
white
papers
on
this,
it's
entirely
possible.
You
can
achieve
100
availability
and
reliability
if
all
the
previous
stages
are
duplicates
of
production
under
considerable
stress
and
burden,
but
you
run
them
for
very
short
periods
of
time
based
on
need
and
then
destroy
them.
A
You
can't
copy
prod,
otherwise
your
budgets
will
be
so
big
now
the
core
of
everything
and
why
we
do
burden
focus
is
automation,
and
I
you
can
claim
me
saying
this
automation
adds
toil
anybody
that
focuses
on
animation.
Automation
will
not
solve
any
of
their
business
problems;
they
will
only
add
burden
and
smee
domain
expertise
to
their
resources
and
increase
the
requirements
of
their
talent,
pool
orchestration
of
the
automation
and
its
capabilities
removes
toil,
that's
building,
repeatability
and
outcomes
in
a
rapid
fashion.
A
That's
how
you
get
continuous
improvement,
I'm
just
giving
you
pieces
of
it
that
if
I
do
go
down
that
path,
I
need
to
have
very
strong
business
cases
for
benefits
so
that
I
can
spend
that
upfront
time
to
build
it
because
it
does
take
extra
work,
but
the
payout
is
any
velocity.
You
want
it's
not
fast.
A
It's
not
slow.
It's
chosen
velocity,
because
that
is
the
metric.
You
need
to
enable
that's
the
capability.
You
need
to
enable
it's
not
about
fast
or
how
many,
because
those
metrics
lie
chosen.
Velocity
is
independent
of
burden
with
burden.
You
have
fixed
speed,
remove
the
burden
you
have
chosen
velocity.
This
is
key.
A
I
just
wanted
to
say
thank
you
very
much
to
the
continuous
delivery
foundation
for
putting
the
cdcon
together
and
I'm
looking
forward
to
seeing
you
in
the
in
the
q
a
thank
you
so
much
for
having
me.
I
hope
I
wasn't
too
passionate
here,
but
I
thought
this
was
a
really
cool
session
that
I
could
share
with
you,
some
of
our
insights
that
we're
doing
with
our
customers
today
thanks
so
much
and
take.
A
A
I've
run
them
on
google
aws
vmware.
I
haven't
done
it
in
azure,
but
the
context
behind
it
has
openshift
as
a
cluster.
I
think
it's
about
32
minutes.
D2Iq
is
about
28
minutes.
Gke
is
a
little
less
than
that
depends
on
how
fast
they
come
up,
but
it's
an
entire
cluster.
It's
not
namespaces
you're
codifying
the
namespace,
the
project
requirements,
the
pod
requirements,
your
helm
requirements.
A
You
deploy
the
entire
environment
as
needed.
If
you
have
multiple
applications
within
a
cluster
and
they're,
not
independent.
Obviously,
you
would
only
be
destroying,
as
you
said,
particular
name
spaces,
but
you
really
can
create
the
option
where
you
don't
even
persist
the
clusters
themselves,
because
everybody's
running
their
independent
pipeline,
but
you
only
need
to
check
the
one
that's
needing
to
release,
so
none
of
them
should
persist
and
when
it's
needed
it'll
build,
so
a
state
file
can
include
its
integration
requirements
within
the
terraform.
A
So
if
you
include
the
integration
requirements,
you
would
deploy
all
the
dependency
applications
within
the
one
you
need
to
test
so
that
you
wouldn't
get
in
a
stuck
position
where
the
apps
you
need
to
test
with,
don't
exist.
This
is
where
it
gets
a
little
more
complex,
but
the
the
benefits
are
are
fast.
A
We
do
this
for
our
clients
today
on
a
regular,
regular
basis.
It
is
our
norm
of
sdlc
it
just
I'm
sharing
with
the
world
now,
because
it's
changed
our
lives
right,
the
brittleness
is
gone
and
deployment
is
at
any
pace.
You
want
I'm
open
to
any
questions
that
you
have.
It
doesn't
have
to
be
specific
to
this.
This
is
just
one
of
nine
reinventions
of
the
sdlc
that
I
was
trying
to
share.
A
I
thought
it
was
very
relevant
to
sres
and
cdcon,
but
if
you
have
hopefully
I'm
audible
can
someone,
let
me
know
if
I'm
audible,
yes,
I'll,
call
it
sean.
Yes,
okay,
good!
If
you
have
any
questions
like
in
depth,
I
can
jump
into
any
any
any
depth
you'd
like
or
if
you
have
just
generalized
questions
on,
why
we
went
down
this
path,
but
I
would
say
it's
on
the
upper
end
of
sre
capabilities.
A
I
if
you
need
I'll
I'll,
make
sure
that
people
get
them.
The
the
most
important
piece
really
is
the
qa
automation.
I
can't
cover
that
in
this.
In
this
amount
of
time
the
qa
animation
I
I've
done
independently
at
unscripted
unscripted.
If
you
want
to
look
it
up,
I
did
a
conference
last
week,
or
maybe
it
was
this
week.
I
don't
know
I
do
a
few
where
you
can
watch
qa
automation,
observability
for
non-prod.
A
Forget
production
was
the
session
name,
so
should
the
practice
be
scheduled
or
office
hours
or
on
demand,
so
I
kind
of
find
it
should
be
get
triggered.
But
not
everybody
lives
that
way.
So
what
you
could
do
is
you
can
integrate
change
management
as
part
of
the
process
where,
if
you
need
to
add
scheduled
or
office
hours,
it
would
go
to
the
itsm,
such
as
a
servicenow
field,
where
you
have
a
approved
change
window
or
the
status
within
jira.
A
In
your
workflows,
however,
you'd
like
it,
the
pipelines
should
depend
on
your
itsm
or
or
your
meaning,
your
your
your
tickets,
that
you're
tracking
your
releases
where
it
would
use
that
to
decide
when
to
run
those
integrations
are
available
in
all
ci
cd
providers.
Maybe
you
have
to
enhance
them
a
little
bit
using
a
rest
apis,
but
that's
how
we'd
be
doing
it
today?
If
you
want
on
demand,
it's
get
triggered
if
you
want
scheduled
or
office
hours,
it's
based
on
the
itsm
approved
stages
generally.
A
That
only
applies
to
staging
and
non-production,
while
the
other
environments
don't
really
need
to
have
scheduled.
As
long
as
you
have.
One
piece
which
is
very
important
is
a
awaiting
a
weighting
of
each
of
your
releases
so
that
if
one
person
releases
and
commits
at
the
same
time,
you
do
you
don't
have
con
convoluted
results
in
a
shared
deployment
or
a
shared
performance
test
using
the
same
environment,
because
terraform
will
build
out
the
components
as
required.
But
it's
not
going
to
tell
you.
A
Someone
else
is
running
a
test
at
the
same
time,
so
you
do
need
to
wait.
Your
releases
that
way
an
environment
run
doesn't
go
over
another
commit
within
another
resource
that
shares
the
same
resources.
I
I
it
happens,
natively
in
some
providers.
I
know
hardness.
Does
that
where
you
can
actually
do
performance
weighting,
where
release
pipeline
itself
has
an
environment
weight
and
if
it's
100,
nothing
else
can
run
it
all
gets
queued
in
their
deployment
pipeline.
A
Any
any
more
like,
I
hope
that
helped
yeah
I
I
know
I
go
all
over
the
place
and
I
generally
run
hyper.
That's
because
I
ate
some
cake
right
before
the
session,
so
I
have
a
sugar
high,
I'm
trying
to
think
we
have
a
lot
of
clients
today
that
haven't
recognized
these
transformations
and
what
essentially
happens
is
their
budget
gets
ballooned
and
they
don't
have
funds
to
hire
people
like
yourself.
A
That's
the
key
is
support
the
talent
pool
by
doing
people
metrics,
which
is
the
burden
of
the
pipeline
itself,
and
the
moment
that
you
drive
those
hours
of
the
pipeline
down
to
almost
zero.
That
is
when
you
can
run
at
any
velocity
you
want,
which
is
really
what
an
srv
should
be
targeting,
because
that's
providing
val
value
to
the
business
at
the
rate
and
pace
the
business
wants
rather
than
misconstrued
metrics,
which
hurt
all
your
talent
pool.
A
I
don't
know
how
many
people
here
I've
been
in
an
organization
where
I
met
my
metrics,
but
the
reality
was
a
lot
of
work
and
it
doesn't
need
to
be.
There
should
be
a
lot
of
work
on
innovation,
not
a
lot
of
work
on
deployments
themselves.
It's
just
very,
very
poor,
sdlc
best
practices-
I
don't
know
how
else
to
say
it,
but
if
you,
if
you
look
what
published
by
gartner
and
others,
the
sdlc
is,
is
not
a
logical
process
today,
it
needs
a
lot
of
improvements.
A
Do
I
have
this
methodology
documented
via
github
or
something
I
can
publish
if
you,
if
you
want
to
you,
can
reach
out
to
me
I'll
put
my
email
out
there.
I
do
have
the
pipelines
in
github
that
I
can
share
just
put
my
email.
I
am
quite
open
with
sharing.
I
think
it
would
be
nice
if
someone
could
have
a
copy
of
the
pipeline,
especially
jenkins.
I
kind
of
feel
like
jenkins
is
where
most
development
teams
are.
A
We
do
have
it
for
github
actions,
azure
pipelines,
git
lab
jenkins
and
harness
we
do
it
across
all
the
ci
cd.
The
reason
being
is
every
customer
is
different,
but
the
process
at
which
the
sdlc
runs
is
consistent.
Every
single
one
has
the
same
stages
and
promotion
methods.
It's
just
what
is
great,
like
that's
the
definition
of
why
we
did
this.
What
is
a
great
archetype
of
cic?
What
is
a
great
archetype
that
supports
sre
practices
and
confidence
for
production?
A
And
surprisingly,
it's
destruction,
you,
you
can't
persist
drift,
you
can't
persist
brittleness,
you
can't
hide
anything
and
you
match
prod
as
close
as
possible,
because
you
don't
run
it
for
long
and
no
one
wants
to
give
you
money,
so
it
matches
really
well
and
then,
if
you
really
move
observability
into
non-production,
I'm
not.
I
wouldn't
be
surprised
if
everybody
here
runs
an
apm
in
prod,
but
in
non-project
you
couldn't
afford
it,
remove
it
from
prod
focus
that
budget
on
non-prod,
build
your
confidence
and
then
prod
is
a
non-event.
A
This
is
this
is
our.
This
is
again
one
of
those
really
poor,
sdlc
methods.
Thinking
prod
is
where
the
value
is.
It
is
true,
it's
the
customer
value,
but
the
value
has
to
the
confidence
has
to
be
built
in
non-prod.
I
don't
want
to
go
too
many
different
avenues,
but
if
you
do
very
great
observability
matching
production
100
reliability.
I've
done
for
year,
like
it's
not
hard
to
achieve
100
availability
for
a
year.
A
It's
just
you
have
to
build
up
to
that
capability
and
then
make
sure
that
your
observability
is
higher
or
equivalent
in
nonprof
than
in
than
in
prod,
which
is
one
of
the
greatest
mistakes
we
make
today.
Is
we
protect
where
the
customers
are,
but
we
don't
protect
the
confidence
that
goes
into
it?
It's
it's.
I
just
so
many
things
I'd
like
to
share,
but
that
is
that
is
key.
A
I
I
touched
on
it
that
qa
automation
is
one
of
the
prerequisites,
but
the
reality
is
we
don't
spend
in
non-production
our
observability.
Yet
how
do
I
then
build
confidence
for
what
goes
to
the
environment,
so
I'm
being
proactive
in
the
wrong
environment
which
is
astonishing
to
me,
which
is
why
I've
I've
changed
for
years?
The
way
I
operate
is
non-prod
is
where
I
invest
and
then
destroy,
and
then
production
is
nothing.
You
run
it
at
9am.
A
You
run
it
at
10am,
you
run
it
whenever
you
want
nothing's
gonna
happen,
you've
done
a
rinse
and
repeat
of
duplicate
environments
under
considerable
stress,
higher
than
prod
prod
ain't
going
to
fall
over
their
duplicate
environments,
they're
coded
the
same.
The
only
difference
is
I've
destroyed,
non-prod
even
more
than
well,
obviously
much
more
than
probably
you
don't
destroy
prod,
but
you've
seen
the
brittleness
and
and
pushed
it
to
its
limits.
A
A
A
No
more
okay,
perfect!
I
mean
I
don't
want
to
just
take
up
people's
time.
I
thank
those
for
attending.
Hopefully,
you've
taken
away
different
methods
and
it
excites
you.
These
types
of
things
are
really
exciting
and
it
makes
your
lives
better
because,
to
be
honest
with
you,
I
take
this
from
an
empathy
approach.
I've
been
an
sre
for
many
years.
It's
a
hard
job,
it's
a
hard
job
because
you
know
what's
better
but
also
you're
a
hero.
A
It's
the
removal
of
the
hero
that
I'm
trying
to
do
here
is
deployments
should
occur
without
the
sre.
It's
the
confidence
towards
production
that
the
srv
should
focus
so
that
the
non-event
and
his
evenings
and
weekends
are
protected.
That
is
my
focus.
The
removal
of
talent
heroics,
and
that
is
where
sres
will
then
become
more
abundant,
because
it's
not
a
very
high
task
or
burden
job
that
you
have
to
be
here.
All
the
time
kind
of
feel
burnout
was
the
only
option
with
the
old
methods
thanks
so
much
for
joining.