►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
FinOps Summit: Cost Visibility and Optimization in Kubernetes
Managing the visibility and optimization of costs is hard enough in the Cloud, the introduction of Kubernetes adds another layer of virtualization to manage. This 90-minute, single-track event will focus on how to do cloud financial management in a cloud native container environment. Topics to be covered: Why Cloud Financial Management is harder in Kubernetes Introduction to the FinOps Foundation and launch of Certified partner programs Shifting responsibility for cloud spending to product teams Implementing cost accountability and allocation in Kubernetes Strategies for ensuring developers take action on cost actions on optimizations. Managing the complexity of spending in a cloud native container environment
https://sched.co/dfTz
A
Good
morning
and
afternoon
everybody,
my
name
is
j.r
stormant,
and
I
am
the
executive
director
of
the
phenops
foundation
and
the
phenoms
foundation
is
a
part
of
the
linux
foundation,
which
is
a
we're.
A
sister
organization
to
cncf,
which
I'm
sure
you're
all
familiar
with
today.
We're
going
to
be
talking
about
phenoms
and
vinops
is
the
practice
of
cloud
financial
management.
A
Excellent,
so
what
before
we
get
started,
I
wanted
to
talk
a
little
bit
about
the
challenge
of
confidential
management
for
kubernetes,
but
why
does
this
space
exist?
Why
do
we
find
that
managing
finances
in
cloud
is
a
challenge
and
I
think
where
we
happen
to
start
with,
that
conversation
is
really
going
back
to
the
world
of
data
centers
and
what
happened
when
an
organization
needed
to
get
access
to
hardware.
A
In
that
case,
they
would
think
of.
You
know
what
requirements
they
needed,
what
hardware
they
needed
and
they
would
then
go
and
build
a
business
case
and
go
to
their
procurement
teams
right
and
those
procurement
teams
would
essentially
evaluate
that
business
case
and
they
would
come
back
with
the
money
for
the
hardware
that
was
needed
now.
In
this
model
there
were
pros
and
cons
right,
so
you
had
essentially
engineers
working
as
requesters.
A
Spend
was
really
predictable.
You
know
you
knew
what
you
were
gonna
spend.
You
know
how
it
was
gonna
work,
but
the
bad
news
was
you
had
really
long
procurement
cycles
and
really
there
was
a
high
cost
of
failure
for
projects
right.
If
you
spent
the
money
and
then
went
to
change
it,
it
was
already
out
the
door.
A
So
suddenly
these
engineers
can
spin
up
resources
wherever
they
need
whenever
they
want
and
the
entire
dynamic
shifts
to
this
world,
where
they
can
go
straight
to
the
money.
Now
the
engineering
teams
and
ops
teams
essentially
have
the
credit
card
that
can
buy
whatever
resources
they
need.
So
this
makes
the
procurement
people
and
finance
people
unhappy
and
not
only
unhappy.
It
also
puts
them
in
a
spot
where
they
really
can't
do
their
fiduciary
job
to
the
company.
A
A
That
last
line
is
really
important
because
cloud
financial
management
phenoms
are
not
necessarily
about
spending
less
money
in
cloud.
It's
about
making
choices
that
give
you
the
best
outputs
for
that,
because
in
a
lot
of
cases,
we
find
that
spending
more
in
cloud
actually
may
be
successful,
right,
you're,
migrating,
more
resources
out
or
over
to
cloud
or,
potentially
you
know
your
business
is
growing.
A
So
when
phenoms
is
implemented
and
we're
going
to
talk
a
bit
about
what
that
looks
like
today,
specifically
in
a
kubernetes
world,
some
good
things
happen.
So
the
first
of
those
is
these
teams
now
start
to
get
act
together
as
one
instead
of
engineering
operations,
teams
running
a
loan
doing
their
thing
and
finance
procurement
teams
trying
to
port
on
it
later
they're
coming
together
to
make
decisions.
So
you
get
that
instant
procurement,
you
get
agility,
but
with
predictable
budgets
and
costs
and
really
lowering
the
cost
of
failure.
A
A
I
think
corey
quinn
calls
it
cloud
economics,
there's
cloud
cost
management,
there's
all
types
of
names,
so
these
are
all
different
words
for
ways
to
get
that
most
value
out
of
cloud.
I'm
going
to
refer
to
it
here
as
fenops,
because
it's
it's
fast
and
short
and
easy,
but
in
your
practice
and
the
people
that
we
work
with
and
have
met
over
the
years
doing,
this
have
literally
hundreds
of
different
titles
and
names
for
what
they
call
this,
but
they
all
center
around
a
core
set
of
practical
principles
and
a
consistent
set
of
stakeholders.
A
So
I'm
not
going
to
read
each
of
these
on
here,
but
the
idea
with
these
principles-
and
these
were
developed
with
the
practitioners
within
the
phenops
foundation
and
then
in
collaboration
with
aws
last
year,
are
really
focused
on.
How
do
we
bring
those
teams
together
to
collaborate?
Well,
so
they
can
start
to
make
those
decisions
and
a
key
thing.
A
The
third
point
which
we're
going
to
talk
a
lot
about
here-
and
we
talked
a
lot
about
the
open
source
summit
in
june-
is
that
you
really
want
everyone
to
take
ownership
for
their
cloud
usage
right.
This
is
about
driving
accountability
out
to
the
edge,
so
those
individual
teams,
and
sometimes
there's
hundreds
of
them
in
an
organization-
can
get
access
to
accessible,
timely,
up-to-date,
accurate
and
granular
reporting
about
what's
happening,
alerting,
whether
it
be
anomalies
or
reporting
or
anything
else
or
dashboarding,
so
that
they
can
start
to
take
actions
now.
A
A
B
A
Discounts-
and
the
idea
here
to
the
sixth
is
really
to
move
everybody
to
a
world
where
we're
taking
advantage
of
the
variable
model
of
cloud
right
too
often
migrations,
whether
it
be
newer
sort
of
cloud
native
companies
or
those
aspiring
to
be
cloud
native
or
older
enterprise,
end
up
running
cloud
really
like
a
data
center
right.
They
leave
everything
all
the
time
on
all
the
time.
A
So
what
does
that?
Look
like
engineering
metrics,
you
know,
there's
a
lot
of
things
that
engineering
teams
in
particular
track
and
are
used
to
tracking
and
thinking
about
engineers,
don't
like
inefficiency,
typically
they're
thinking
about
latency
and
memory
and
cpu
and
requests
all
these
different
areas
for
engineering
teams
and
we're
focusing
a
lot
of
our
efforts
and
conversations
today
around
this
group.
Because
of
the
audience
of
the
summit.
A
So
that
brings
us
to
what
we're
covering
today,
which
is
sorry.
My
screen
share,
just
dropped
off
there,
which
is
phenops
for
kubernetes,
and
I
wanted
to
give
you
a
little
introduction
to
the
phenoms
foundation
and
what
we're
going
to
be
drawing
on
from
here,
because
all
the
speakers
that
you're
going
to
be
hearing
from
today
are
part
of
the
phenom
foundation
and
all
the
best
practices
that
we
talk
about
are
drawn
from
this
group.
B
A
Regardless
of
what
cloud
you're
using
or
what
vendor,
or
what
management
tool
or
open
source
or
anything
else,
so
we
host
a
lot
of
virtual
events.
We've
got
another
one
this
afternoon
happening
that
I'll.
Tell
you
about
later
on,
aws
savings
plans.
We've
got
an
active
meetup
community
around
the
world.
We've
got
a
slack.
That's
got
a
lot
of
folks
having
conversations
and
these
people
come
together
to
do
a
second
point
to
help
advance
not
only
the
discipline
but
also
their
careers.
A
This
is
a
nascent
and
evolving
space
and
we
find
that
it's
really
hard
to
go,
say
hey.
I
need
to
hire
a
cloud
financial
manager
or
a
cloud
business
office
person
or
a
cost.
Optimization
person,
there's
not
a
college
program
for
that,
there's,
not
typically
a
dedicated
jobs
board.
Although
if
you
go
to
our
website,
we
do
have
a
jobs
board.
A
So
we
do
a
lot
of
work
around
education,
training
and
development
of
these
people
and
the
third
area,
where
we
are
very
excited
to
be
partnering
with
the
linux
foundation
in
this
new
chapter,
is
building
out
open
source
standards
around
this
nascent
space.
So
this
is
looking
like
you
know:
what
are
the
capabilities
of
a
phenoms
team?
You
know
what
sort
of
kpis
should
they
be
looking
at,
what
does
a
proper
chargeback
or
allocation
or
tagging
model?
A
A
This
came
out
of
I
used
to
be
a
co-founder
of
cloudability
and
working
in
the
the
cab
there
we
kept
hearing
people
say:
hey,
we
we
don't
just
want
to
talk
about
technology.
We
want
to
hear
about
the
best
practices
we
want
to
talk
to
each
other.
We
want
to
understand
the
discipline
so
as
we
started
to
scale
this
out,
we
realized
we
needed
to
really
make
it
a
clearly
open
source,
vendor-neutral,
best
practices,
organization,
and
we
just
joined
the
linux
foundation
to
do
that
and
we're
seeing
some
really
exciting
participation.
A
The
the
beating
heart
of
the
organization
are
our
practitioner
members.
These
are
the
people
in
end
user
companies
who
are
actually
doing
fin
ops
we've
got
about.
As
of
yesterday,
we
broke
2000
of
those
individuals
and
they're
in
there
really
defining
and
talking
best
practices
in
our
slack
in
the
various
areas
and
taking
advantage
of
things
like
the
certifications
that
we
offer
and
contributing
to
the
lexicon.
We
launched
a
book
last
year
with
o'reilly
called
cloud
phenops,
which
is
really
a
collection
of
the
stories
and
best
practices
from
these
individuals
oops.
A
So
one
of
the
things
that
we
are
announcing
today
and
that
we
hinted
at
the
open
source
summit
is
the
addition
of
new
vendor
member
programs.
We've
been
completely
focused
on
practitioners
to
date,
bringing
in
that
that
sort
of
best
practice-
and
we
heard
from
the
practitioners
two
consistent
themes
over
the
last
year.
One
was
that
there's
a
lot
of
expertise
in
the
clouds.
A
So
as
part
of
this,
we
launched
three
programs
that
we
announced
at
the
open
source
summit
in
june.
The
first
is
the
phenoms
training
partner
program.
The
second
is
the
phenom
certified
platform
program
and
the
third
is
the
phenops
certified
service
provider
program
and
each
of
these
programs
following
the
cloud
native
computing
foundation
and
linux
foundation.
Models
are
based
on
companies
joining
our
foundation
and
hitting
a
certain
set
of
criteria
to
be
a
part
of
these
so
very
excited
to
announce
today.
A
B
A
The
additional
nine
partners
listed
here
on
the
screen
cloud
easier
cloud,
soft
cloud,
wise
lots
of
clouds,
contino
cube,
cost,
neos,
opsani,
prosper,
ops
and
tim
spirit,
so
you're
going
to
learn
more
about
all
these
on
our
website.
As
I
talk
about
these
programs
and
we'll
hear
from
a
few
of
these
companies
today
as
part
of
the
content
that
we
are
covering,
so
let's
look
at
each
of
the
individual
programs.
A
I
think
this
is
the
program
that
we've
heard
the
most
from
practitioners
that
they
wanted,
which
was
a
program
that
maps
capabilities
of
finnops
against
individual
service
providers.
We
built
a
very
nascent
set
of
these
capabilities
that
we're
beginning
to
map
providers
against
the
initial
program.
Partners,
for
this
are
the
ones
listed
here
on
the
screen,
we'll
be
doing
a
lot
of
work
in
the
coming
months
to
really
grow
that
list
of
capabilities
along
with
the
members,
the
practitioners
and
the
clouds
themselves
to
further
define
these.
A
C
B
A
A
We
have
offered
a
number
of
certifications
and
trainings
through
the
phenox
foundation,
we've
heard
from
practitioners
that
they
want
to
both
be
able
to
get
these
in
their
regional
areas
and
get
it
specialized
and
focused
and
customized
into
services
that
both
platforms
and
consultancies
offer.
So
this
program
is
very
much
based
around
the
model
of
offering
training.
We
offer
instructor-led
courses
that
we've
been
doing
now,
for
I
think
we've
done
15
or
20
of
them
now
in
the
last
few
quarters.
A
Virtually
these
are
now
also
going
to
be
offered
by
the
private
and
custom
training
partners,
the
phenom's
training
partners,
as
well
as
the
free
intro
to
phenox
course
it's
available
on
edx
and
then
the
certifications,
the
first
one
on
the
right
is
available.
Now
it's
now,
through
the
linux
foundation,
the
phenox
certified
practitioner
with
additionals
coming
down
the
road,
so
big
shout
out
to
the
four
phenox
training
partners,
cloudability
cloudhealth
cloud
easier
and
continue.
A
All
of
these
are
now
certified
to
offer
these
trainings
and
then
in
are
essentially
going
to
be
resellers
of
the
phenom
certified
practitioner.
Certification,
which
will
for
consistency,
stake
still
go
through
the
linux
foundation
to
ensure
that
everyone
meets
the
same
standards
and
the
last
program
is
the
phenom
certified
service
provider
program.
This
one
is
really
geared
and
focused
on
companies
who
provide
services
around
phenops,
whether
that
be
consultancy
or
advisory
services
in
this
area.
A
As
part
of
this
excited
to
announce
today
that
we
have
added
a
number
of
new
individuals
to
this,
mike
fuller,
who
is
the
co-author
of
the
book,
is
going
to
be
the
tech
chair
from
atlassian
excited
to
also
add
eugene
kostov,
who
is
from
aptio
cloudability.
He
was
formally
on
the
aws
insights
team
and
building
out
their
products,
john
mclaughlin,
who
is
from
cloudhealth
vmware
we're
going
to
hear
from
one
of
his
colleagues
later
today,
matt
leonard,
who
is
billing
product
lead
for
google
cloud.
A
He
formerly
did
this
for
aws
and
for
microsoft,
so
great
expertise
there
and
debo
from
his
team
is
going
to
be
talking
today.
Ashley
romatko,
who
shared
a
ton
of
best
practices
over
the
last
year
in
the
foundation
from
pearson
and
joe
daly
from
nationwide
who's,
also
been
one
of
the
core
contributing
members.
We
will.
A
Additional
folks
in
the
coming
months,
that
will
be
by
the
charter,
which
is
on
github.
If
you
want
to
read
it,
it's
structured
really
to
be
a
combination
of
practitioners,
general
premier,
members
and
industry,
appointed
people
who
will
really
flesh
out
and
build
the
lexicon
of
best
practices
over
time.
A
So
jumping
back
after
all
those
announcements.
And,
of
course,
I'm
already
on
over
time,
which
I
told
the
speakers
I
wouldn't
let
them
do
to
this
world,
where
you've
got
all
these
services
teams.
Looking
for
money
and
bypassing
procurement,
we're
now
going
to
introduce
for
the
topic
today.
What
happens
in
the
world
of
kubernetes
with
this
happening,
and
what
I
wanted
to
highlight
as
an
intro
is
that
the
world
of
kubernetes
adds
layers
and
layers
of
virtualization.
A
On
top
of
this
challenge,
we
had
before
in
cloud
which
is
trying
to
figure
out
what's
idle,
what
resources
to
remove,
trying
to
figure
out
what
to
right
size,
whether
it
be
it
used
to
be
instances,
and
now
you
need
to
do
clusters
and
name
spaces
and
figure
out
resource
utilization.
For
those
it
adds
complication
to
this
challenge
of
figuring
out.
What
to
recommend
to
teams?
What
do
they
spin
up
spin
down?
How
do
they
size
their
resources.
D
A
Makes
it
much
more
difficult
to
start
to
report
out
wastage
to
these
teams
right
the
areas
of
okay,
you've
said
you're
going
to
use
this
thing
now.
What
are
you
really
using
the
real
challenge
here?
I
think,
and
as
a
number
of
our
speakers
are
going
to
get
to,
is
around
the
world
of
how
do
we
start
to
take
all
these
differently
sized?
You
know
buckets
of
spend
not
buckets
in
the
aws
sense,
but
buckets
in
the
sense
of
clusters,
labels
name
spaces
to
figure
out
how
to
then
allocate
those
out
to
individual
teams.
This.
A
Challenges
of
thin-ops
cloud
financial
management
is
getting
chargeback
accurate
so
that
we
can
get
to
that
world.
We
talked
about
the
nirvana
of
helping
teams,
make
better
decisions,
so
with
all
of
that,
I'm
very
excited
to
introduce
our
lightning
talks.
Today.
All
these
speakers
are
going
to
be
contributing
content
to
what
is
going
to
be
a
white,
an
open
source
white
paper
that
is
launching
in
november
of
cloud
native
con
on
this
topic.
A
This
is
our
lineup
today,
I'll
let
each
of
them
introduce
ourselves
and
the
instruments
themselves,
rather
in
the
interest
of
time
for
this,
but
a
great
mix
of
practitioners,
clouds
and
cloud
management
vendors
who
are
going
to
help
us
unpack
this
problem.
At
the
end
of
this,
we
are
going
to
do
a
q.
A
A
we've
had
some
questions
coming
in
we'll
speak
to
as
many
of
those
as
possible,
and
we
have
just
launched
the
phenom
swag
store,
I'm
wearing
one
of
the
shirts
today,
the
spin-offs
on
the
back
here
for
everybody
who
asks
a
question
that
we
take.
That
we
think
is
a
good
question,
we'll
be
giving
you
a
25
gift
card
to
go,
buy
an
awesome,
phenom,
t-shirt
or
sticker,
or
something
like
that.
So
please
get
your
questions
ready
and
excited
to
hear
from
each
of
our
speakers.
E
E
So
a
bit
of
context
on
live
ramp,
I'm
the
head
of
global
cloud
operations
for
live
ramp.
We
are
headquartered
in
san
francisco
and
have
about
1
300
employees.
We
have
over
200
developers
and
we
transform
data
for
marketing
companies.
For
the
most
part
we
help
them
connect
to
their
customers,
and
in
support
of
that,
we
had
an
on-premise
data
center
in
san
francisco.
E
E
There
are
representatives
from
the
cmp
space
here
I
it's
quite
a
bit
of
an
art
to
develop
software
for
developers,
and
we
certainly
appreciate
all
the
software
that
was
available
to
us
when
we
were
trying
to
solve
this
problem
and
then
the
other
thing
I
would
note
is
that
if
you
are
a
person
on
the
call
who's
new
to
finnops
and
you're,
trying
to
understand
how
it
can
help,
you
solve
your
your
your
problems
related
to
cloud,
spend
and
coupe.
I
would
definitely
join
the
finops
foundation.
D
E
We
discovered
that
someone
else
had
perfectly
synthesized
and
articulated
all
the
points
that
we
were
beginning
to
explore
and
things
that
were
already
brewing
in
our
minds,
based
on
the
pain
that
we
are
experiencing
ourselves
and
when
we
join
the
foundation
and
the
slack
channel.
This
excuse
me
this
group
that
it
has
we
discovered
conversations
that
were
like
incredibly
relevant
to
the
problems
that
we
were
trying
to
solve
and
we
spent
literally
months
going
through
the
conversations
and
figuring
out
what
we
should
do
as
a
company
ourselves.
E
E
E
There
are
petabytes
of
data
going
back
and
forth
every
day
on
behalf
of
our
customers,
and
we
were
migrating
because
we
were
in
a
data
center
in
san
francisco
and
for
those
of
you
don't
know,
san
francisco
is
active
earthquake
country.
We
were
in
a
data
center
that
we
had
joined
when
we
were
a
fledgling
startup
and
we
didn't
have
3
000
hadoop
nodes.
We
we
just
had
10
and
then
50
and
then
100
and
then
400
and
we
began
to
outstrip
their
capacity
as
well.
E
We
also
wanted
to
give
our
developers
the
opportunity
to
deploy
infrastructure
by
api,
and
we
could
do
that
with
gcp
and
aws
and
those
vendors,
and
so
we
embarked
on
this
on
this
massive
migration.
We
did
planning
for
about
six
months
and
then
the
execution
took
about
a
year.
We
ran
our
on-premise
data
center.
At
the
same
time
that
we
were
migrating
to
the
cloud
now,
when
we
first
deployed
kubernetes,
we
were
using
core
os
on
physical
hardware
in
our
on-premise
dataset,
and
that
gave
us
some
tools.
E
E
E
They
weren't
excited
about
managing
their
own
environments,
and
that
was
a
surprise
to
us,
but
it
seemed
to
make
sense
because
you
know
if,
if
they
can
spend
their
time
doing
some
other
work,
that's
related
to
production
that
delivers
more
value.
For
the
company,
there
isn't
a
great
reason
for
them
to
run
and
manage
their
own
cluster.
E
E
But
I
think
today,
name
spacing
within
gke,
does
that
I
think
that
we
would
probably
try
to
use
cloud
run
where
possible
and
it
eliminates
you
know
the
the
the
issue
of
responsibility
and
it
makes
it
easier
to
attribute
cost
as
well.
I
think
the
vendors
have
come
in
and
provided
very
interesting
tooling.
That
allows
you
to
attribute
costs
within
kubernetes.
E
I
think
using
a
cmp
is
probably
a
good
thing
now.
I
I
don't
want
to
advertise
on
their
behalf,
but
I
think
it
would
be
very
difficult
for
us
to
properly
attribute
cost
for
gke,
specifically
if
we
were
only
using
the
native
tooling
provided
by
google.
Now
they
do
a
great
job
of
releasing
new
apis
every
quarter
and
the
abilities
in
the
central
console
improve
consistently,
but
there's
a
super
set
of
features
that
we
find
with
the
cmps
that
made
it
very
compelling
for
us
in
particular,.
E
Number
one
use
the
phenops
foundation,
slack
group
as
a
means
to
discover
other
people's
pain.
That
looks
a
lot
similar
to
the
pain
that
you're
about
to
go
through
and
learn
from
it
and
incorporate
that
information
into
your
design.
I
would
say:
read
the
finnops
book.
If
you
can
get
it
it's
it's
a
great
synthesis
of
all
the
information
that's
been
in
the
groups
and
conversations
apparently
for
the
last.
E
D
All
right
well
hello
to
all
the
attendees
and
thanks
for
joining
us
in
these
very
unusual,
but
still
meeting
in
information
times.
I
just
wanted
to
go
ahead
and
and
make
sure
that
I
take
the
chance
to
thank
sasha
for
all
the
advice
given
there
and
he's
a
great
tea
up
for
me,
because,
as
a
customer
and
someone
who's
really
looking
at
this
very
carefully,
I
think
that
there's
nothing
that
can
replace
experience
to
go
alongside
advice.
So
let
me
go
ahead
and
share
my
screen
here
and
get
started
myself.
C
D
My
career
in
terms
of
the
cloud
space
started
at
aws,
where
I
was
working
at
the
marketplace
and
I
really
focused
there
on
really
helping
introduce
people
to
software
that
allowed
them
to
utilize
cloud
infrastructure
and
the
best
ways
to
do.
Other
functions
like
manage.
Fire
firewalls
deal
with
cloud
application,
development
controllers
and
other
things
like
that,
and
I
kind
of
transitioned
into
google
to
look
at
the
scope
of
how
people
are
dealing
with
cost
management
and
all
the
elements
that
go
along
with
it.
D
So
that
includes
metering
and
telemetry
and
includes
looking
at
their
data
as
it
flows
through
not
just
billing
systems,
but
commerce
systems
usage
systems
that
we
control
here
at
google
and
then,
of
course,
where
I
am
now
and
cost
management.
So
I
work
with
matt
leonard
who's,
a
member
of
the
phone
ups
foundation,
core
group
of
members
to
help
here
as
a
team
lead,
and
I
really
focus
on
making
sure
that
customers
can
understand
their
costs
as
a
as
respective
containers
of
value.
D
For
their
workloads,
so
when
we
think
about
gcp
as
a
vendor
in
this
space,
really
think
about
gke
and
google
cloud
platforms,
as
you
can
see
here,
we've
done
a
lot
of
work
to
make
sure
that
we
really
have
a
dashboard
that
allows
people
to
really
control
things,
but
not
necessarily
have
to
dive
super
deep
into
the
world
of
compute.
In
order
to
manage
things,
it's
really
to
flexibly
define
resources
that
are
scalable
with
your
application
right.
D
So
we've
heard
a
lot
of
reasons
that
folks
love
to
roll
with
gke
the
idea
that
it's
it's
native,
that
you've
got
kubernetes
and
gku
really
working
together,
so
that
upgrading
your
nodes,
and
by
that
we
mean
your
clusters
and
all
the
things
that
come
with
them
is
easy.
We
get
those
releases
well,
we
have
gke
and
docker
working
well
together,
so
gkes
can
schedule
those
containers
based
on
the
requirements
and
configurations
that
you
manage,
which
is
a
nice
way
to
be
able
to
do
it,
especially
if
you're
familiar
with
docker
and
containerization.
D
Networking
is
a
lot
easier
because
you're
managing
your
network
scaling
and
connections
at
various
granularities,
whether
it's
the
pod,
the
cluster,
the
node
and
it's
all
managed
in
single
place.
So
you're
dealing
with
auto
scaling,
an
automatic,
node
creation,
a
deletion
based
on
whether
or
not
the
master
sees
that
the
policy
is
going
to
be
correct
right
and
all
that
drives
towards
price.
As
long
as
you're
flexibly
able
to
define
your
pay
as
you
go
structure
or
because
really
it's
managed
commute,
compute,
sorry
and
you're.
D
Dealing
with
committed
use
discounts,
there's
a
lot
of
different
ways
for
you
to
get.
When
you
know
your
stable
usage
discounts
on
what
you're
actually
trying
to
deal
with
in
terms
of
your
compute
storage
and
other
needs.
So
we've
heard
that
a
lot
of
folks
are
very
happy
and
and
are
continuing
to
dive
deep
and
into
using
gke.
D
I
need
to
schedule
which
workload
right
and
when
people
come
to
talk
to
us
about
that,
they
end
up
talking
about
a
lot
of
different
elements
in
terms
of
financial
governments
and
operations,
which
is
hey.
We've
got
a
financial
plan.
We
want
to
make
sure
that
we
stick
within
a
certain
amount
of
spend,
or
we
want
to
make
sure
that
our
spend
scales
appropriately
with
our
workloads.
D
So
whatever
teams
might
be
using
kubernetes,
we
want
to
make
sure
that
they
have
the
ability
to
make
scaling
decisions
at
their
levels,
as
well
as
the
larger
level
for
the
whole
group
and
then
restricting
usage
and
costs
where
it
does
not
generate
value
or
just
learning
that
I
can
shut
things
down
and
not
have
to
really
think
about
it.
In
terms
of
you
know
the
micro
management
of
your
compute
storage
and
other
resources.
D
Beyond
that,
it's
ideas
for
cost
savings
continually
as
you
get
better
and
more
mature
at
managing
your
spend
forecasting,
more
spend
and
limiting
surprises,
just
as
I
mentioned
before
in
the
previous
slide.
You
know
beyond
that
trust
between
I.t
and
finance
project
level
spend
and
even
in
containers
other
than
just
projects,
but
maybe
the
flexible
ways
that
you
want
to
define
how
your
infrastructure
looks.
You
want
to
be
able
to
make
sure
that
you
can
communicate
those
costs
to
the
various
stakeholder
groups
right.
So
all
that
scales
into
predictability,
everybody
really
wants
to
know.
D
D
It's
accountability.
So
that's
thinking
about
the
idea
that
you
have
flexible
ways
to
organize
your
resources
and
allocate
an
attribute
you
cost.
So
you
can
do
chargeback,
which
is
the
ability
to
say,
hey,
look
devops.
We
want
to
make
sure
that
you
know
you've
spent
this
much,
and
this
is
what
you're
responsible,
for
maybe
that
is
or
is
not
over
your
budget,
and
that
might
be
true
for
several
other
groups
within
your
organization
as
well
or
just
showing
them.
D
You
know
what
they're
spending
and
showing
them
the
variance
and
the
change
in
the
spend
you've
got
control,
which
is
really
just
controlling
for
overspending,
reducing
the
predict,
reducing
the
the
runaway
costs
that
might
come
from
maybe
having
a
little
bit
of
neglect
from
one
part
of
your
infrastructure
versus
being
alerted
being
able
to
have
programmatic
controls.
Once
you
realize
there
is
some
kind
of
aberration,
so
you
can
deal
with
that
appropriately
and
finally,
intelligence,
the
ability
for
google
cloud
specifically
to
be
an
advisor
to
you
and
say
hey.
D
D
So
you
know
it's
helpful
to
think
about
this
in
terms
of
a
few
examples
and
sasha
just
gave
ones
which
is
really
helpful
for
us,
but
we've
been
hearing
a
lot
of
things
as
customers
move,
because
there's
a
lot
of
different
areas
of
maturity
that
they
have
in
terms
of
their
cloud
journey.
So
we've
heard
from
customers
who
are
saying:
hey,
we're
moving
from
data
centers
directly
into
more
of
a
kubernetes
type
of
scaling
or
a
gke
type
of
scaling,
so
that
we
can
focus
on
having
apps
and
containerization
define
our
infrastructure
usage.
D
We
have
folks
who
are
coming
from
compute
engine,
we're
saying
hey.
I
manage
my
vms.
I've
now
got
thousands
of
them,
that's
kind
of
a
pain.
How
can
I
cluster
them?
So
they
more
better
aligned
to
our
our
applications
that
we
need
to
find,
and
so
the
first
idea
here
that
we
talk
about
in
terms
of
those
customers
that
they
they
may
move
from
many
projects
or
other
definitions
of
their
workloads
to
application
defined
workloads.
D
So
they
want
to
say
instead
of
having
a
thousand
projects,
say:
hey
many
of
these
customers
are
contributing
to
a
single
application,
whether
it's
the
front
end
or
the
back
end
of
it,
and
we
want
to
define
our
infrastructure
by
that
application
instead,
so
we're
moving
to
kubernetes.
So
we
can
actually
use
that
as
a
way
of
defining
and
deploying
those
workloads.
D
Then
another
example
is,
you
know,
dealing
with
the
idea
of
having
those
clusters
and
those
workloads
defined,
but
having
named
teams
to
name
spaces,
so
the
ability
to
flexibly
define
a
name
space,
that's
going
to
be
a
cost
container,
you'll
be
charging
in
internally
or
keeping
track
and
monitoring
your
costs.
According
to
that
name,
space
and
therefore
those
name
spaces
have
different
things
deployed
in
them
for
the
dedicated
functions
that
that
part
of
a
cluster
or
pod
or
node
may
define,
and
then.
D
Right,
we
find
that
a
lot
of
people
are
using
kubernetes
labels
to
help
define
what
a
workload
may
be
used
for,
and
their
hope
is
that
by
having
those
those
kubernetes
labels
available,
they
can
again
look
at
the
costs
across
those
labels
so
that,
if
there's
an
application,
that's
spanning
across
clusters
in
terms
of
utility
or
there's
a
team
that
spans
across
many
clusters,
they
can
use
that
kubernetes
label
to
organize
them
right.
But
in
all
these
strategies
they
want
to
make
sure
they
understand
what
their
cost
drivers
are.
D
E
D
Vertical
structures
of
all
the
pieces
of
infrastructure
that
people
are
using
like
cores
memory,
persistent
disk
network
egress,
you
know
different
ways
to
manage
this
workload,
including
cloud
run
and
those
data
procs.
Some
of
these
other
tools
that
are
going
to
work
alongside
the
infrastructure
and
the
applications
that
you're
making
and
then
you
overlay
the
workload
definitions
on
top
of
those,
so
that
might
be
at
the
granularity
of
a
pod
or
it
might
be
granularity
of
an
application
or
project.
D
And
the
idea
is
that
you
don't
want
to
have
to
think
about
the
cost
containers
in
terms
of
just
one
or
the
other,
because,
yes,
google
cloud
charges
for
the
cores,
use
the
memory
disks
and
all
that.
But
if
it's
much
more
helpful
for
you
to
think
about
your
costs
in
terms
of
your
application,
then
you
want
to
be
able
to
include
a
little
bit
of
each
of
those
infrastructure
departments
in
a
total
cost
of
ownership
for
your
workload.
D
So
that's
really
what
we're
trying
to
drive
to
and
help
to
make
sure
that
you
can
understand
and
manage
your
costs.
The
same
way
that
you
manage
your
workloads
so
just
driving
in
a
little
deeper.
What
does
that
mean?
It
means
that
we've
got
all
these
these
different
types
of
containers
on
the
left.
Right,
you
see
the
building
hierarchy
or
folder
project
you've
got
resources,
as
I've
mentioned
just
in
the
previous
slide.
D
Your
sub
customers,
the
customers
who
are
who
are
working
to
you
to
do
all
the
things
on
the
right,
everything
from
invoicing
and
dealing
with
audits,
to
cost
allocation,
answering
questions
and
doing
analysis,
forecasts,
budgets
and
variation.
Optimization
quotas
and
caps
know
when
to
stop
these
things
right.
So
this
is
the
general
space
that
we're
dealing
with
in
terms
of
managing
costs.
D
The
same
way,
you
do
your
workloads
in
the
kubernetes
world
for
us,
so
the
types
of
questions
that
we
tend
to
see
tend
to
be
more
of
you
know
how
do
I
deal
with
costs
versus
utilization
right?
So,
if
you're,
actually
spending
based
on
the
requests
that
kubernetes
is
making
for
your
behalf,
you
know
how
do
you
deal
with
the
utilization?
There
I
mean
kubernetes.
The
gke
team
is
really
working
to
help
deal
with
recommendations
there.
How
can
I
focus
on
forecasts
and
budgets?
D
How
can
I
present
these
costs
and
do
accountability
for
chargeback
and
showback?
You
know
how
can
I
manage
kubernetes
as
a
platform
across
multiple
clouds?
You
know,
and
even
sasha
talked
a
little
bit
about
shared
resources
right.
One
thing
that
we
find
particularly
interesting
is
that
folks
are
looking
for
ways
to
manage
network
egress,
which
may
not
necessarily
be
proportionally
something
that
you
want
to
allocate.
D
To
say
here
is
there's
a
lot
of
questions
that
we
see
here,
there's
a
lot
of
things
that
we
want
to
answer,
but
we're
really
driving
towards
a
new
experience,
and
this
is
something
that
we're
continually
and
iteratively
working
on
to
help
you
think
about
monetization
flexibly
moving
across
your
workloads
right.
So
you
know
I
don't
want
to
go
too
much
into
detail
just
for
the
sake
of
time,
but
you
can
see
on
the
right.
D
The
user,
experiences
of
reporting
budgets
and
alerts
billing
export
are
really
going
to
help
with
that,
and
you
know
we're
really
driving
to
to
give
people
tools
like
gk
usage
metering,
which
allows
you
to
flexibly
manage
by
namespace
and
label
and
and
those
cost
managements
or
anthony's
doing
multi-cloud
management
and
building
native
gke
and
anthony's
features.
So
that's
just
kind
of
the
tip
of
the
iceberg.
There.
D
We
understand
a
lot
of
the
things
that
you
want
to
do
in
this
space
and
I
want
to
make
sure
that
casey
gets
a
chance,
of
course,
and
in
this
wrapping
to
you
to
talk
a
little
bit
about
how
they
see
it.
But
you
know
I'm
happy
to
answer
any
questions
and
give
lots
of
materials
in
terms
of
dealing
with
cloud
management
and
cost
management
from
a
gke
and
gcp
perspective.
So
let
me
hand
that
over
to
casey
and
thanks
so
much
for
listening.
B
B
B
B
Are
we
seeing
it
now?
Okay,
great
thanks
for
that.
So
you
know
one
thing
that
we've
been
working
on
quite
a
bit
at
cloud
ability
for
the
last
few
years
is
really
digging
into
the
challenges
that
everybody's
been
illustrating
regarding
cost
allocation,
as
well
as
optimization
in
the
kubernetes
world.
So
I'm
going
to
spend
the
next.
You
know
seven
or
eight
minutes.
You
know
digging
into
some
of
those
challenges,
some
best
practices
around
solving
those
challenges
and
how
you
can
use
some
of
those
to
overcome
the
same
problem
in
your
organization.
B
So
let
me
just
dive
right
into
that,
and
I
want
to
start
through
a
customer
story.
So
you
know
in
kind
of
mid
early
to
mid
2017.
We
had
a
lot
of
customers
that
start
started
to
come
to
us
with
questions
around
this,
so
one
in
particular
large.
You
know
technology
company,
utilizing
multiple
clouds
through
a
variety
of
acquisitions
and
they
were
working
on
transitioning
to
kubernetes.
B
B
You
start
to
lose
visibility
into
consumption
of
these
shared
clusters
that
everybody's
using
the
same
cluster.
You
know,
there's
really
a
need
to
allocate
that
usage
to
the
correct
cost
centers.
You
know
we're
going
to
talk
a
little
bit
about
some
of
the
best
ways
to
do
that
and
the
reality
here
is
it's
not
just
one
or
the
other
right.
You
know.
Every
team,
you
know
that's
using
kubernetes
is
likely
to
have
some
kubernetes
cost,
but
some
non-kubernetes
cost
and
you're
really
going
to
want
to
look
at
that
all
together.
B
B
That's
going
to
be
critical
to
start
pulling
that
data
and
associating
with
with
the
cloud
billing
data
you're,
also
going
to
want
to
label
your
kubernetes
resources
to
align
with
those
cost
centers,
whether
that's
application,
team
business
unit
etc
and
then
you're
going
to
want
to
unify
that
with
the
more
traditional
resource
tag
keys,
so
you're
doing
that
in
a
unified
way.
That's
going
to
give
you
that
ability
to
allocate
holistically.
B
So
with
that
you
know
you're
going
to
be
able
to
allocate
the
costs.
You
know,
based
on
those
kubernetes
constructs
you're
going
to
be
able
to
analyze,
buy
those.
You
know
in
critical
cost
centers
that
you
need
to
be
charged,
do
charge
back
for
and
then
in
the
end,
you're
gonna
be
able
to
perform
full
allocation.
B
You
know
across
kubernetes
and
non-kubernetes
workloads,
you
know
and
provide
those
teams,
the
insights
they
need
to
perform
better.
So
let's
dig
a
little
bit
deeper
into
some
of
those
challenges.
So
obviously
you
know
somewhat
over
oversimplified
picture
here,
but
here's
kind
of
the
traditional
way
that
we
used
to
do
this
and
have
done
this.
For
years
you
know,
teams
tended
to
have
dedicated
resources.
B
You
know
in
this
case
we're
looking
at
three
different
apps
multiple
services
across
different
cloud
providers,
but
relatively
straightforward
in
terms
of
allocation.
We
can
use
tags,
you
know,
tag
key
value
pairs,
you
know,
and
then
you
look
in
the
billing
data
analyze
that
go
ahead
and
there's
your
allocation
in
the
kubernetes
world.
This
breaks
down
right.
So
you
know
those
vendor
tags
are
not
enough.
We're
sharing
clusters
the
same
set
of
vms
that
we
looked
at
on
the
previous
screen.
B
You
know,
but
it
but
the
you
know,
they're
shared,
there's
no
way
to
just
use
the
a
specific
tag
you
know,
and
on
top
of
that,
there's
going
to
be
and
jr
talked
about
this
at
the
beginning,
there's
going
to
be
some
waste,
some
idle
resources
and
are
also
going
to
want
to
understand
how
we
can
allocate
that
back
to
the
right
place,
it's
actually
more
complex
than
that
right.
It's
the
reality
is
it's
both
right.
We're
gonna
have
both
situations.
B
So
let's
talk
about
how
we
can
help
with
this.
So
the
first
thing
is:
we
talked
about
collecting
utilization
data
right
so
pulling
this
utilization
data
from
the
underlying
cluster
resources,
so
memory,
cpu,
network,
etc.
By
container
object
types,
you
know
name
space
deployment
daemon
set.
Whatever
is
important
for
you.
You
know
to
allocate
by
as
well
as
those
label
key
value
pairs.
Then
you
want
to
associate
that
utilization
data
with
the
underlying
cluster
cost
for
that
allocation
and
one
just
shameless
plug.
B
B
B
How
does
it
come
together
right?
So
so
the
first
thing
you
know
you're
able
to
visualize
your
kubernetes
crop
costs
across
cluster
name,
space
and
label.
You
know-
and
you
can
see
in
this
case,
you're
breaking
down.
Maybe
what
what
event
originally
was
a
single
line
item
for
ec2
by
the
specific
specific
usage
of
that
by
that
specific
name,
space
and
team
you're
also
able
to
visualize
your
kubernetes
and
non-kubernetes
costs
together
right.
So
in
this
case
we're
looking
at
a
squad.
B
You
know
this
squad
has
some
kubernetes
and
non-combinators
are
using
some.
You
know
some
ec2
some
cloud
watch,
but
also
have
some
things
running
on
kubernetes
clusters,
we're
looking
at
this
all
in
a
single
dashboard.
You
know
and
giving
the
ability
to
do
that
in
one
location
based
on
having
pulled
this
data
and
then,
lastly,
you
know
this
customer
was
able
to
pull
all
this
data
together.
B
You
know
and
create
single
dashboards.
So
then
they,
you
know
across
all
these
different
constructs.
All
these
costs
are
accounted
for.
One
thing
that
was
incredibly
critical-
you
know
to
this
customer
as
well
was
was
accuracy
right.
So
we've
talked
a
little
bit
about
this.
You
know
before,
but
you
know
in
terms
of
the
utilization
data.
You
also
want
to
pull
this
request
information
right.
So
if
somebody
has
a
request,
that's
traditionally
consistently
over
their
actual
usage.
That's
what
you
want
to
use
to
allocate,
because
no
one
else
is
able
to
use
those
resources.
B
You
also
want
to
factor
in
things
like
node
pinning.
You
know
all
workloads
may
not
be
running.
You
know
on
all
nodes
within
the
cluster,
so
that's
also
critical.
You
know
to
make
sure
that
you're,
bringing
in
and
also
you
know,
true
costs
here
right,
so
not
not
necessarily
list
price
from
the
cloud
providers,
but
you
know
maybe
you've
got
some
ris
or
committed
use
discounts
running
on
these
resources.
B
You
want
to
look
at
all
of
that
and
factor
that
in
so
you
make
sure
your
teams
are
actually
looking
at
the
accurate
costs
and
then
the
last
thing
that
I
would
say
before
you
know
handing
it
over
to
jonathan
would
be
reporting
on
idle,
you
know
and
so
making
sure
you're.
Looking
at
the
idle
resource
resources
in
the
cluster,
you
know
providing
that
to
your
teams.
This
was
critical.
E
C
Sorts
of
awesome
content
here
we
have
more
to
come,
so
I'm
gonna
continue
the
theme
of
trying
to
be
concise
and
keep
things
on
time.
I
will
also
start
with
a
quick
thank
you
to
kubecon
to
the
finnops
foundation
and
jr,
not
for
only
putting
the
phenoms
foundation
together
but
kicking
off
this
discussion
here
and
inviting
kadel
to
participate
as
well
as
this
fantastic
panel.
C
This
really
is
a
topic
that
I
think,
we've
seen
be
more
and
more
relevant,
as
organizations
not
only
evolve
their
finnops
practices
but
of
all
their
applications.
In
parallel,
I
feel
like
those
two
things
have
gone,
have
gained
particular
traction
over
the
past
like
couple
years
kind
of
in
parallel,
which
is
interesting
and
cloudhealth
has
been
a
bit.
I'm
not
going
to
talk
too
much
about
cloud
health,
I'm
going
to
kind
of
take
a
lens
of
a
lot
of
stuff
that
jr
sasha,
debo
casey
talked
about
around.
C
How
do
you
like
allocate
shared
resources,
but
just
in
our
experience,
cloudell
has
been
doing
the
kind
of
this
modern
app
lens
of
phenops
for
the
past
few
years.
Just
trying
to
take
some
of
that
experience
into
some
key
questions.
We
find
useful
to
ask
yourself
so
with
that
I'm
going
to
just
share
a
couple
sides
that
may
be
useful
for
that
dive
right
in
and
then
we'll
take
it
from
there
and
see.
If
I
can
share
my
screen.
C
C
This
is
kind
of
a
basic
framework
that
cloud
elf
uses
just
to
help
facilitate
conversations
and,
and
one
of
the
things
I'm
looking
forward
to
at
the
phenops
being
part
of
the
phenoms
organization
is
just
like
jr
said:
finding
that
common
language-
maybe
parts
of
this
evolve,
but
what
we
found
helpful
is
just
this
kind
of
natural
evolution
of
this
reporting.
This
cost
allocation.
How
do
I
get
that
clear
visibility?
What
are
my
costs?
My
team's
cost
versus
your
team's.
C
When
I
look
at
that
highly
complex
cloud
bill
and
then
from
there,
how
do
I
optimize
what
are
my
optimizations
versus
your
optimizations
so
on
and
so
forth?
How
do
I
do
that
is
on
a
regular
basis
through
ongoing
governance
automation
and
how
does
that
kind
of
plug
into
all
my
business
systems,
so
you
know
eventually,
maybe
becomes
autonomous,
but
digging
straight
into
the
kind
of
kubernetes
lands,
again
kind
of
five
key
questions.
C
I
I
like
I
like
to
highlight
some
of
these
we've
covered,
but
I'm
gonna
kind
of
also
paint
the
the
lens
of
the
different,
disparate
teams
that
we
work
with
here.
So
nothing's
cookie
cutter
here.
No
two
works
looked
the
same.
In
particular,
I
think
some
of
these
lessons
come
from
just
the
differences
in
the
challenges,
as
well
as
the
commonalities
between
a
startup.
That's
cloud
first
started
with
kubernetes.
All
your
apps
are
modernized
and
the
kinds
of
challenges
you
see
there
versus
a
really.
C
You
know,
let's
say
a
50
000
person,
10
000
enterprise,
that
is
part
of
their
like
casey
said
they
got
a
really
mixed
environment.
Some
modern
apps,
some
more
legacy
apps
how
to
do
this
all
together,
but
across
the
board.
It's
it's
just.
The
first
question
is
what
what
do
you
want?
What
do
what
do
you
want
to
report
on?
So
we
learned
in
the
recent
talks
about
all
the
options
we
have
to
report
on
them.
But
what
do
you
actually
care
about
right?
So
I
think
what
we've
seen
is.
C
C
I,
like
jr,
said
bucket:
I
actually
use
bucket
icons,
coincidentally,
go
into
like
a
microservice
cost
bucket,
which
is
very
granular
right
or
for
a
lot
of
organizations
can
be
very
granular,
but
the
reason
why
this
top
line
question
is
important
is
what
what
matters
to
the
rest
of
the
business,
because
then
often
we'll
see
the
finance
side
of
the
house
saying
well.
All
I
really
care
at
the
end
of
the
day
is:
how
much
did
this
product
line
cost
me?
C
Maybe
you're
a
small
organization
you're,
really
just
focusing
on
your
your
first
product,
maybe
you're
a
much
larger
organization.
You've
got
number
of
products
and
really,
how
does
that
align?
You
can
get
started
without
answering
this
across
the
entire
organization,
but
it's
going
to
be
a
question.
That's
going
to
keep
coming
back
like
what
is
the
language
you
use
within
the
organization?
What
are
those
buckets?
How
do
those
buckets
align
and
then
that
gets
to
the
question
of
like
oh
okay?
Well,
what
metadata
are
we
using
for
those
buckets?
C
I'm
diving
straight
to
the
kubernetes
example,
like
casey
said
for
a
lot
of
organizations.
It's
not
just
kubernetes.
It's
okay:
how
does
this
align
with
my
tags,
but
given
kubecon
zooming
into
the
kubernetes
side,
even
on
small
teams,
but
especially
in
larger
enterprises,
you
quickly
see
even
just
what
a
cluster
means.
It's
you
know
it's
easy
at
cloudhealth!
I'm
sorry
cubecon
here
there's
a
lot
of
talks
about
great
best
practices,
but
it's
very
easy
in
kubernetes,
which
is
so
flexible.
C
C
This
team
uses
clusters
in
that
way,
I
think
more
commonly
name
space
differences
and
you
know
one
team
using
namespace
across
the
team
or
to
or
other
other
teams
using
namespace
to
signify
like
a
microservice
or
my
app
centric
construct
confusion
around
oh
well,
everybody
uses
this
app
label,
we've
aligned
great,
but
what
does
app
actually
mean?
Is
it
a
microservice?
Is
it
the
whole
application
and
then,
of
course,
just
the
general?
What
are
all
the
other
labels
you
use?
What
are
some
of
the?
C
Casey
touched
on
this.
This
is
another
interesting
question.
When
we
talk
about
okay,
specific
to
the
kubernetes
side,
we're
now
also
talking
about
shared
resources.
Let's,
let's
just
take
the
compute
of
my
worker
nodes.
That's
often
one
of
the
biggest
costs
generated
by
kubernetes,
I'm
scaling
up
a
big
application.
I
got
lots
of
worker
nodes,
lots
of
instances
vms
whatever
they
are,
cost
me
a
lot
of
money.
How
do
I
share
that?
C
I've
got
a
pod
from
one
team
on
the
same
worker
note
as
a
pod,
but
also
on
the
same
node
as
a
pod
from
another
team.
How
do
I
divvy
that
up
and
there's
kind
of
this
is
maybe
oversimplifying
it,
but
in
in
my
I
think.
The
whole
theme
here
is
to
kind
of
take
this
very
complex
landscape
and
ask
some
very
simple
questions
to
help
guide
us-
and
here
I
think
the
common
trade-offs
we
see
are
resource
requests
versus
actual
usage
right.
C
So
I
can
see
what
did
what
did
my
workloads,
my
team's
workloads,
ask
of
kubernetes
that
then
got
spun
up
and
because
they
got
spun
up,
they
accumulated
cost
somebody's
got
to
pay
for
that
cost.
For
that.
For
that
reason
we
see
a
lot
of
organizations
moving
are
using
research
requests
as
that
common
metric,
but
the
flip
side
is
well
what,
if
I
asked
for
my
app
asked
for
x,
x
and
y
amount
of
resources,
but
it
didn't
use
them.
I
that's
not
fair.
C
What
kind
of
incentives
do
you
want
to
create
across
the
development
teams
or
whoever
it
is
that's
setting
that
yaml
or
those
terraform
templates
or
whatever?
It
is?
That's.
That's
configuring,
your
your
resource
requests
and,
by
the
way,
there's
tools
out
there
to
help
you
like
the
vertical
pod,
auto
scaler,
which
is
open
source
which
can
help
you
say
you
know
hey
this.
This
pod
keeps
asking
for
4
cpus,
but
it
really
only
ends
up
using
a
quarter
of
one.
C
So
hey,
maybe
next
time
you
want
to
not
ask
kubernetes
for
so
many
resources,
they're
costing
us
a
lot
of
money
and
align
your
request
to
what
you
actually
end
up
using
that's
kind
of
the
nirvana
state,
but
you
never
you're,
never
in
that
perfect
zone.
So
what
are
the
incentives
you
want
to
set
up?
And
I
think
you
know
we-
we
see
folks
thinking
about
that
as
they
choose
which
which
metric
to
use
here.
C
How
are
we
doing
on
time?
Just
a
few
more
minutes
here,
just
wrap
up
the
phone
we'll
pass
over
to
web
from
cubecon
cubecost
question
four:
who
pays
for
the
common
services
now,
in
some
environments
this
is
kind
of
inconsequential,
or
it
seems
really
small
but
similar
to
that
question,
which
actually
was
covered
by
the
left
side
of
the
idle
vital
time
who
pays
for
that
ilc
view
time,
there's
also
who
pays
for
something
like
a
service
mesh?
We
just
rolled
out
istio
overhead's,
pretty
small,
but
you
know
it's
still.
C
It
still
costs
some
infrastructure
to
have
a
sidecar
container
for
every
sidecar
pod
for
every
pod.
How
do
we
pay
that?
How
do
we?
How
do
we
pay
for
that?
Do
we
do?
Is
there
like
a
central
kind
of
infrastructure,
a
cost
center?
You
know
it's
kind
of
the,
maybe
more
traditional
way
of
doing
I.t
way
of
doing
things.
Some
folks
still
do
that
in
some
ways
that
that's
fine
or
is
it
more?
You
know
to
the
whole
point
of
the
finnops
side.
C
How
do
we,
how
do
we
share
and
kind
of
allocate
dynamically
some
fair,
some
fair
dynamic
allocation
of
some
of
these
costs,
and-
and
I
I
call
this
out
as
a
question,
because
different
teams
will
have
different
answers
and
finally,
this
is
kind
of
a
broader
topic
than
a
straightforward
question
is
what
are
my
upper
optimization
opportunities?
I
think
the
good
news
is
group
managers
is
very
flexible.
The
bad
news
is
or
that
the
challenge
side
of
that
is
there's
a
lot
of
opportunities
for
waste.
C
I
mentioned
the
pod,
you
know
the
pod
scaling
or
pod
sizing
a
challenge,
there's
also.
How
do
you,
how
you're
auto
scaling
your
your
nose
and
your
pods?
I
think
there's
plenty
of
talks
at
kubecon
over
the
past
years,
talking
about
best
practices
of
operating
the
platform
operating
infrastructure,
auto
scaling,
there's
no
right
sizing
or
using
the
right
node
for
your
for
your
application
and.
B
C
C
Environment
in
most
cases
here
I'll
give
you
a
discount
and
those
because
that's
often
a
finance
centric
conversation,
that's
that's
very
relevant
for
fin-ups,
but
maybe
isn't
always
coming
up
at
kubecon.
I
thought
I'd
kind
of
build,
a
quick
summary
of
some
of
the
options
out
there
in
the
industry.
This
is
far
from
a
perfect
table.
It's
just
kind
of
to
start
the
discussion
kind
of
summarize
those
resources
with
that
wish.
You
all
well
on
your
your
your
your
cloud
maturity
journeys
and
I
will
pass
it
over
to
web.
F
F
So,
like
jonathan
mentioned,
my
name's
web
brown,
I'm
co-founder
and
ceo
of
of
coupe
cost
really
quickly
a
little
bit
about
us
myself
and
my
co-founder
previously
built
infrastructure
monitoring
solutions
at
google.
We
worked
on
external
cloud
services
as
well
as
internal
container
based
infrastructure
and
for
the
last
two
years,
while
running
coop
cost,
we've
been
exclusively
focused
on
cost
visibility
and
optimization
solutions
for
kubernetes
centric
infrastructure.
F
So
we
provide
visibility
and
help
teams
with
non-kubernetes
cost,
but
a
lot
of
our
users
are
do
have
a
meaningful
kubernetes
footprint
that
is
oftentimes
growing,
very
quickly,
our
company's
based
in
san
francisco,
and
we
have
a
distributed
engineering
team
and
we
have
over
a
thousand
of
active
deployments
of
coupe
costs
across
all
the
major
cloud
providers
as
well
as
on-prem.
Even
air
capped
environments.
F
F
F
Secondly,
if
we,
if
we
just
look
at,
why
teams
move
to
kubernetes
in
the
first
place,
it's
really
about
developer
empowerment,
right
it's
about
enabling
portability
and
innate
or
enabling
higher
velocity.
More
transparency,
et
cetera,
and
what
we
see
is
that
these
cloud
management
decisions
are
not
excluded.
It's
really
about
helping
developers,
make
the
best
decision
for
the
broader
team
organization
and
that's
about
letting
them
have
a
decentralized
decision-making
process
without
overwhelming
them.
F
And
then
third,
is
we
have
this
rapidly
evolving
open
source
ecosystem
around
kubernetes,
so
outline
a
couple
of
solutions
like
helm
and
prometheus
and
service
meshes
like
linker
d,
and
what
you
see
is
that
every
part
of
the
application
life
cycle
is
changing,
how
applications
are
delivered?
How
they're
observed
how
they're
managed,
on
an
ongoing
basis
from
a
security
perspective,
networking
perspective
et
cetera,
and
that
obviously
has
has
major
changes
in
terms
of
how
you
actually
manage
spin
effectively
in
these
new
environments.
F
So
with
that,
I'm
going
to
walk
through
kind
of
how
we
see
teams
actually
navigate
this,
and
the
first
is
around
embracing
the
right
platform
features
and
tools
for
your
organization
and
where
you
are
in
your
kubernetes
journey
like
jonathan
and
a
couple
of
others
have
already
mentioned
here.
Is
that
context
really
matters?
F
What
we
see
oftentimes
is
as
a
really
small
team.
That's
you
know
just
starting
with
kubernetes.
It
may
be
okay
to
to
not
have
owners
right,
the
team
small
enough
to
to
know
who
owns
this
cluster
or
even
this
namespace
etc.
But
then,
as
that
grows,
you
may
rely
more
and
more
on,
say,
namespace,
annotations
or
namespace
labels
and
then,
as
that
grows,
you
may
need
to
get
more
granular,
because
teams
and
departments
and
project
sizes
are
growing.
You
may
move
to
say
controller
level
annotations
and
then
finally,
you
may
work
your
way.
F
All
the
way
up
to
emission
controllers,
which
is,
is
kind
of
like
a
gatekeeper
for
individual
workloads
that
will
enforce
or
require
an
owner,
whether
it
be
a
team
or
a
project,
lead
etcetera.
So
I
think
that's
just
one
example
where
we
see
oftentimes
the
solution
depends
on
again
your
organization
and
where
you
are
in
this
journey,
so
second
again
about
really
empowering
engineers
to
make
great
decisions
in
this
area,
and
it
starts
by
kind
of
understanding.
You
know
the
day-to-day
here
and
it's
that
as
developers,
we're
constantly
overwhelmed.
F
We've
got.
You
know,
100
things
going
on
at
once,
so
really
being
super
targeted
with
both
the
requirements,
as
well
as
the
recommendations
and
insights
that
you're
delivering
to
developers
and
and
secondly,
to
really
enable
developers.
We've
seen
that
by
bringing
data
to
workflows
and
tools
that
they
already
use
in
their
day-to-day
can
make
this
a
lot
easier
for
them
to
make
great
decisions
here.
One
example
is
using
our
metrics
or
other
metrics
to
be
writing.
F
B
F
Right
next
to
that
that
existing
data-
and
then
third
is
again
really
about
embracing
this
growing
and
oftentimes
transparent
ecosystem.
A
lot
of
this
around
the
cncf
just
see
tons
of
new,
like
opportunities
for
for
teams
to
have
more
control
and
more
focus
on
just
privacy,
security,
flexibility,
etc.
F
And,
ultimately
you
know
this
is
about
again
giving
developers
the
right
tools
at
the
right
time
to
to
manage
spend
effectively.
One
example
is
seeing
teams
leverage,
open
source
solutions
like
prometheus
and
alert
managers,
alert
manager
to
streamline
their
process
for,
seeing
and
then
acting
on,
real-time
cost
data
through
budget
alerts,
etc.
F
So
we've
seen
a
lot
of
teams
just
be
really
successful
by
deeply
integrating
into
kind
of
the
growing
open
source
ecosystem.
Here,
we've
actually
taken
a
you
know,
a
very
similar
approach
with
our
product.
All
of
our
product
is
built
on
open
source.
You
know
open
core,
tooling
and
just
see
that
as
a
great
opportunity
for
for
this
ecosystem
to
have
more
transparency
and
more
control
as
time
goes
on.
F
So
in
summary,
here
really
quickly.
We
do
think
that
kubernetes
brings
a
lot
of
new
complexity,
but
we
also
think
that
the
tools
and
frameworks
to
manage
this
complexity
are
arriving
as
well
and
we're
incredibly
optimistic
about
it
as
a
as
a
platform
and
a
broader
community
and
ecosystem
in
terms
of
ultimately
driving
costs
down,
while
also
giving
all
these
great
benefits
like
faster
delivery,
portability,
etc,
etc.
F
A
Fantastic,
thank
you,
everybody.
It
was
great
to
see
very
similar
talk
tracks
through
this,
even
though
we
didn't
all
see
each
other's
slides
ahead
of
time
so
clearly
all
focusing
on
the
right
right
areas
in
the
space.
So
we're
going
to
do
about
10
minutes
of
q.
A
now
and
I've
taken
a
few
questions
that
have
come
in.
If
you
want
to
put
more
in
the
chat,
please
do
that
and
we'll
kind
of
go
through
these
and
feel
free
speakers.
A
I'm
gonna
pass
one
to
each
of
you,
but
then
you
know
others.
If
you
want
to
join-
and
let
me
know
so,
let's
start
with
sasha
and
you
know
sasha.
You
came
up
in
sort
of
a
devops
engineering-centric
world
and
have
only
sort
of
more
recently
sort
of
in
the
last
year
to
gotten
into
this
financial
side
of
things
you
know,
can
you
speak
a
little
bit?
We
had
a
question
come
up,
which
was
you
know
how
finnops
is
related
to
devops
and
devsecops.
E
Yeah
yeah
thanks
for
sending
the
question
my
way,
so
just
for
some
context.
You
know
I
I've
been
active
in
the
agile
space,
for
you
know
at
least
a
decade
now,
and
when
I
first
heard
of
finnops,
I
was
at
the
conference
in
las
vegas
in
in
mike
fuller's
class
actually
and
when
he
was
describing
phenoms.
E
I
kept
making
this
internal
connection
in
my
head
to
concepts
and
principles
from
from
agile
and
from
devops,
and
where
I
saw
it
intersect
very
clearly
for
me
was
on
the
concept
of
responsibility
and
control
and
bringing
together
teams.
So
for
those
of
you
who
are
you
know
the
the
two
people
who
haven't
heard
of
devops
on
the
call
like
just
to
reiterate
like
the
principles
there
are,
that
you
know
it's
a
collaborative
culture
made
up
of
you
know
different
teams
that
come
together
to
deliver
their
product.
E
The
the
problems
that
we
were
trying
to
solve
with
devops
were
around
speed
of
delivery,
and
we
previously
would
have
two
separate
teams
that
we
would
be
responsible
for
getting
code
into
production.
You
would
have
an
operations
team
and
a
development
team
and
then
sometimes
a
qa
team
as
well,
and
you
know
they
would
send
the
product
in
production
serially
and
they
all
had
different
kinds
of
responsibilities
and
at
some
companies
you
had
different
teams
reporting
to
different
vps,
who
were
all
responsible
for
this
now.
E
The
problem
was
that
when
there
were
issues
they
would
all
point
fingers
at
each
other
and
developers
couldn't
have
access
to
production
either
to
solve
things
quickly
by
collapsing
everyone
onto
the
same
team
by
recognizing
that
it's
collaboration
and
that
we
needed
to
give
developers
more
responsibility
for
their
for
their
product.
We
were
able
to
solve
that
problem,
and
so
finops
is
collaborative
by
default.
E
It's
bringing
together
finance
procurement
and
engineering
into
a
conversation
where
they're
all
needed
to
actually
make
the
right
decision,
and
it
gives
developers
that
degree
of
control
that
they
always
wanted.
They
have
a
cloud
api
and
they
can
deploy
it
well,
but,
along
with
that,
is
the
corresponding
responsibility
of
managing
your
spent
and
being
aware
that
cost
is
a
dimension
of
your
application's
responsibility.
So
that's
sort
of
how
I
see
the
two
intersecting
and
combining
for
me.
They
are
simply
extensions
of
the
agile
concepts.
A
Yeah
fantastic:
I
found
that
when
we
were
writing
the
intros
to
finnops
in
the
book,
I
I
just
I
kept
finding
quotes
from
you,
know
the
agile
manifesto
and
those
areas
that
were
just
resonating
so
much.
It
was
really
really
cool
to
see
all
those
intersection
points,
so
that's
very
much
the
ethos
of
it
awesome.
So
next
question:
I'm
gonna
pass
this
one
to
web
and
there
have
been
a
few
questions
around
this
area
of
allocating
costs
within
kubernetes.
You
know
people
have
asked
you
know.
A
What's
the
best
way
to
map
costs
to
an
app
team
or
shared
cluster,
you
know
what
do
you
map
to?
Maybe
just
summarize
that
it's
like
you
know
what
what
do
you
see
as
the
most
common
mistakes?
Maybe
that
people
make
when
trying
to
figure
out
that
allocation
strategy?
Where
do
they
start?
Where
should
they
be?
Looking
in
the
beginning.
F
F
I
think
if,
if
I
could
summarize,
I
think
the
biggest
mistake
or
challenge
we
make
is:
is
teams
kind
of
not
taking
the
time
to
disseminate
the?
Why
the
and
really
think
through
as
a
broader
team,
the
why
and
that
could
be.
Why
are
we
allocating
you
know
shared
resources,
the
way
we
are
or
why
are
we
allocating
idle
costs?
A
Fantastic
yeah,
that's
always
the
hardest
challenge.
I
think
of
anything.
Ops
process
is
getting
that
allocation
strategy
right
because
without
it
you
don't
actually
have
accountability.
People
say
that's
not
my
resource
awesome.
So
I'll
pass
this
one
to
casey.
We've
gotten
I've
been
collecting
trying
to
merge
questions
three
or
four
around
the
aspect
of
optimization
sort
of
we've
been
talking
inside
the
containers,
but
what
about
outside
of
them
right
so
of
the
resources
of
you,
know,
reservations
or
savings
plans
scaling
of
those.
B
Yeah
so,
and
thanks
to
that,
I
think
there's
in
webb
got
it
some
of
these
as
well.
So
I
think
I
I
generally
think
about
this
in
in
maybe
three
different
fronts
here
right,
so
we've
got
the
concept
of
cluster
right
sizing,
so
you
know
the
underlying
nodes:
are
they
the
right
size?
We
have
the
right
amount
of
them.
There's
some
help
you
can
get
with
the
auto
scalers.
B
You
know
in
terms
of
that,
we
also
you
know.
Web
mentioned
this
as
well
the
the
concept
of
request
over
usage
right
and
believe
it
or
not.
It's
still,
you
know
using
kubernetes.
We
still
see
a
lot
of
over
provisioning,
at
least
in
the
data
that
we
see
right
so
so
kind
of
tracking
that
you
know
request
over
usage.
If
it's
consistent,
you
know
over
a
period
of
time,
there's
clearly
some
changes
you
can
make
and
while
there
may
not
be
some,
you
know
immediate
cost
savings.
Maybe
that
just
increases
the
idle
bucket
right.
B
You
know,
then,
gives
you
an
opportunity
to
further
scale
those
those
underlying
resources
right
and
then,
and
then
the
last
one
which
you
touched
on
jr.
But
is
you
know
that
what
I
would
call
financial
optimization
so
each
each
cloud
provider?
You
know
whether
it's
ris
savings
plans,
communities
discounts,
you
know,
gives
you
instruments,
you
know
to
save.
B
A
It
introduces
an
interesting
set
of
optimization
challenges
in
within
optimization
challenges,
a
little
bit
of
inception
happening
when
you
start
to
factor
in
all
those
things
cool.
So
jonathan,
let's
do
one
for
you,
you
all
sort
of
touched
a
bit
on
this
and
and
it's
come
up
in
a
few
different
variations
in
the
questions
of
the
strategy
for
dealing
with
unallocated
and
idle
or
wasted
costs.
A
C
Yeah,
that's
a
good
question.
Well,
I
think
you
know
just
product
management
hat
when
we
were
doing
this
discovery
with
customers
a
few
years
ago
and
has
kind
of
persisted
the
resource.
I
talked
about
this
a
little
bit.
The
resource
request
proportion
model
became
very
attractive
because
it
kind
of
automatically
takes
care
of
this
problem
doesn't
have
other,
but
it
has
other
caveats
right.
So
if
teams
kind
of
like
squeeze
in
workloads
without
resource
requests.
Well,
that
also
has
to
be
managed.
C
There's
some
tools
in
kubernetes
I
mean
you
can
have
like
default
resource
requests
which
really
help
with
that.
But
we've
we've
actually
seen
this
as
a
customer
preferred
organization
preferred
model
to
just
incentivize
the
right,
the
right
operations
of
kubernetes
and
how
teams
all
plug
into
kubernetes.
C
That
said,
I
do
see
this
evolving
now
and
folks
saying
well,
maybe
I
want
to
like
in
this
other
app
in
this
environment.
I
still
get
all
that
logic
and
all
those
tradeoffs.
Nevertheless,
I
want
to
just
split
and
see
exactly
what
this
app
costs
based
on
exactly
how
much
resources
it
used,
and
I
think
you
know
there
continue
to
be
ongoing
questions.
Well,
what
about
the
rest
of
the
stuff?
Maybe
it
just
goes
to
the
bu
right,
it's
not
that
team,
but
it's
not
like
central
either.
C
It's
like,
maybe
some
like
interim,
like
mid-tier
group.
If
that
makes
sense,
you
know.
So
it's
not
like,
like
my
product
team,
that
works
on
it,
but
it's
also
not
a
central
I.t
team
for
the
whole
company,
it's
like
whatever,
whatever
be
you
or
or
your
your
team
reports
into
I've,
seen
that
maybe
become
attractive
for
that.
So
it
still
has
some.
A
Yeah
excellent
sounds
like
most
things
in
phenomenal
things.
There's
there's
not
one
right
answer:
it
depends
on
the
organization,
wait
one
more
question
and
then
we'll
wrap
it
right
up
on
time.
There
was
a
question
around
open
source
tooling
for
this
work
for
enforcing
governance
and
tagging.
You
know
one
of
the
the
systems
we
looked
at
in
the
foundation.
Did
a
presentation
was
cloud
custodian,
sasha
anywhere
else.
Can
you
share
some
context
or
anything
you've
seen
out
there
around
the
type
of
tooling.
E
Yeah
I
mean
I
would
give
it
up
to
webb
and
like
we,
we
love
using
his
tool.
I'd
also
suggest
that
we
take
a
look
at
live
ramps,
open
source
tooling,
as
well.
We
open
source
kdt
which
allows
you
to
parametrize
your
coupe
cluster
settings.
We've
released
that
into
the
wild
as
well,
and
then
there
is
a
phenoms
for
engineers
channel
in
the
fin
ops
foundation,
slack
group
as
well.
So
that
is
a
great
place
to
learn
about
what's
available
for
developers.
A
If
anybody
wants
to
stay
on
a
little
bit
longer,
I
know
we're
up
on
time.
Debo
can
you
speak
a
little
bit
to
the
challenges
of
sort
of
combining
usage
data
and
cost
data
and
gke
and
and
sort
of
what
what
you
know
things
are
people
are
likely
to
run
into
when
they
start
this
journey
of
trying
to
understand
their
container
costs.
D
Yeah
I
mean
it's
been
touched
on
a
little
bit
by
by
some
of
the
other
colleagues
that
we've
had
talking
here,
but
when
it
comes
to
combining
usage
data
and
cost
data,
I
think
what
people
are
particularly
looking
most
to
do
is
to
say.
Okay,
at
what
level
do
I
really
want
to
label
my
usage
so
that
I
can
make
sure
that
the
costs
are
clear.
D
But
the
easiest
way
to
get
the
most
value
out
of
that,
at
least
for
for
that
tool,
is
to
make
sure
that
they've
labeled
their
applications
appropriately
with
the
cost
centers
the
departments,
whatever
they
have
so
from
that
aspect,
labeling
their
usage,
so
that
it
makes
sense
in
terms
of
the
cost
containers
that
they
ultimately
want
to
see
has
been
a
big
thing
that
that
people
should
be
doing
and
we'll
be
releasing
some
some
tools
in
the
very
near
future
to
help
deal
with
that.
So
thinking
about
that
early,
the
second.
D
So
if
you
know
yourself
that
you're,
not
necessarily
using,
is
utilizing
as
much
as
you're
requesting
you
may
be
doing
that
on
purpose,
because
you
want
to
have
that
that
capability
there
when
you
need
it.
But
if
you
know
that
your
workloads
are
fairly
stable,
you
want
to
see
what
cost
optimization
work
you
can
do
right.
So
I
think
those
two
big
things
you
know
labeling
and
uses
optimization
versus
request.
Optimization
have
been
the
big
sticking
points
for
people
getting
started.
A
Officially
well
over
time,
and
I'm
told
we
actually
need
to
wrap
up
someone
to
thank
everybody
for
joining,
especially
the
speakers
and
everyone
who
asked
questions
if
you
asked
a
question
that
we
didn't
get
to
we're
going
to
try
and
chase
them
asynchronously
afterwards,
a
couple
things
to
think
about
for
later
today
today
is
fenops
day
we've
decided,
so
we
have
another
event
happening
later
today.
That
is
specifically
on
aws
savings
plan
strategy.
A
You
can
find
out
more
about
that
on
the
finops.org
blog
we're
going
to
follow
that
with
one
on
cud
strategy
and
azure
ri
strategy
as
well.
So
if
you
want
to
get
involved
with
that
or
join
the
slack
or
connect
with
any
of
the
folks
here
or
the
2000
practitioners
definitely
go
over
to
finops.org,
where
you
can
get
signed
up,
and
hopefully
we'll
see
you
as
part
of
the
conversation
as
we
move
forward.
So
thank
you,
debo
sasha,
casey,
jonathan
and
webb,
really
a
pleasure
and
for
everybody
who
joined.
I
appreciate
your
your.