►
Description
In this episode, Tero Ahonen will be speaking about his new perspective on DevOps practices from real life experience, give hint about must-have tooling for a successful DevOps adoption
Twitch: https://red.ht/twitch
A
All
right
good
morning,
everyone
and
thank
you
for
joining
us
today
for
another
open
shift,
coffee
break
episode.
So
today
we
will
have
a
great
conversation
with
my
dear
friend,
zero
he's,
been
our
co-host
for
quite
some
time
now
and
he's
our
I
would
say,
guest
for
for
as
long
as
he
he
wishes,
and
today
we
will
speak
about
all
things
devops.
So
that's
that's
quite
a
lot
to
to
handle
terror,
but
I
hope
we're
going
to
have
a
nice
conversation
today.
B
A
A
B
B
B
B
A
B
C
A
All
right
so
for
for
those
who
are
just
joining
for
the
first
time,
my
name
is
jafar
shravi
and
I
work
as
a
tech,
marketing
manager
for
openshift
prior
to
that.
I've
been
an
openshift
consultant
for
for
about
five
years
and
I'm
I'm
very
happy
to
you
know
to
help
people
adopt
container
technologies
and
get
better
with
the
with
openshift,
so,
okay,
so
terror.
Our
main
topic
today
is
devops
right.
B
A
A
B
It's
a
this
is
a
nice
question.
The
answer
is
always
different
because
it
varies
and
the
short
answer
is
devops
is
a
culture.
It's
a
cultural
way
of
doing
things
like
devops
way.
So,
whatever
you
do
in
your
organization
that
helps
you
to
like
be
more
efficient,
better
quality
whatever
there
is
between
a
feature
and
go
in
production
and
then
run
in
production.
Everything
that
you
do
there
between
can
be
called
as
devops
and
when
you
like,
not
let's
say
not,
you
can
call
everything
devops.
B
How
would
I
say
the
increase,
the
devops
culture
in
the
organization
so
that
they
can
have
small
parts
of
the
development
process
automated
or
use
some
specific,
tooling
automatic
building
testing
whatever
so
devops
is
basically
whatever
happens,
and
you
define
your
devops
if
there
is
no
like
ciamac
said
it.
When
we
have
a
last,
we
had
a
kidops
and
devops
episode.
That
devops
is
a
culture,
and
gidops
is
a
way
to
like
implement
that
culture
instrument.
A
B
Kidops
is
a
tool:
devops
is
culture,
okay
and
some
some,
but
he
said
to
me
actually,
just
before
I
read
left
right
had
that
he
asked
me
that
what
is
the
most
important
tool
for
development
in
a
devops
culture
and
yeah,
and
the
answer
is
pretty
pretty
simple
and
really
old
to
its
kit,
so
that
you
might
think
about
it's.
It's
kubernetes,
it's
containers,
it's
your
development
ide,
but
actually,
if
you
think
about
it,
it
version
control
system,
probably
skip
it.
A
A
Yeah
yeah
sure,
so,
let's
so
thanks
first,
I
I
would
say
we
are
trying
you
know
to
to
to
set
the
the
ground.
So
even
even
people
that
don't
have
much
of
an
understanding
of
of
that
topic
can
maybe
you
know
catch
up.
So,
of
course
we
we
see
that
the
the
word
topics
is
a
contraction
of
the
word.
Devops
is
a
contraction
of
two
words,
so
we
see
dev
and
ops
again,
just
you
know,
for
the
the
main
viewers
who
are
just
you
know.
A
A
B
But
you
all
have
seen
the
the
comic
that
there
is
a
dev
that
throws
a
binary
over
the
world,
jobs
yeah
and
that's
basically,
that's
not
devops
and
that's
the
that's,
the
old
way
of
doing
that
developers
create
a
binary
and
then
they
deploy
it.
So
they
send
it
somewhere
and
then
operators
do
whatever
they
like
to
get
it
running,
to
maintain
it,
and
if
there
is
a
bug
there
is
an
probably
a
jira
ticket
or
something
that
hey
there's
a
bug,
can
you
fix
it
and
then
developers
ask?
B
Can
you
send
me
some
log
files
so
that
I
I
know
what
is
the
error
message?
So
this
is
the
old-fashioned
way
of
doing
that.
There
is
no
visibility
whatsoever
between
the
development
process
and
the
operations
and
running
and
everything
was
insanely
slow.
I
I
remember
working
with
a
customer
way
before
red
hat,
that
you
always
had
to
create
a
ticket
to
get
the
locks
from
production
and
that
might
take
days
yeah.
So
how
can
you
be
like
agile
and
fast
and
fix
issues?
A
B
B
Since
I've
been
doing
on
development,
I've
been
developer
for
20
more
than
20
years,
so
the
development
part
of
the
precess
support
was
really
close
to
my
heart
and
the
devops.
Let's
say
five
years
ago,
devops
was
was
a
term
and
there
were
really
good
companies
that
tried
to
boost
the
term.
There's
a
company
in
finland
that
arranges
devop
days
and
their
developed
days
globally
to
introduce
the
concept
of
devops
to
the
duty
audience.
B
But
no
one
really
understood
what
the
devops
was
then,
and
there
was
these
unicorn
companies
that
they
devops
and
the
problem
was
that
there
was
not
enough
tool
just
because
even
the
devops
culture.
You
need
those
that
tooling
to
implement
that
culture
to
do.
Or
you
have
to
implement
those
tools
yourself
and
when
the
devops
got
going.
B
A
Yes,
exactly
so
yeah,
I
I
totally
agree
with
that
with
you
and
I've
been
sharing
the
same
experience
where
mostly
you
know
when
we
were
speaking
about
devops
it's
basically,
how
do
you
get
your
code
as
fast
and
secure
as
possible
from
dev
to
prod
and
most
of
the
focus
was
on
like
ci
cd,
it
was
like
there
was
a
confusion
between
ci,
cd
and
devops,
whereas
of
course,
devops
is
much
bigger
than
that.
Automation
is
a
big
pillar
of
devops
for
sure,
and
automation
can
touch
many
areas.
A
It
can
touch
like
testing.
As
you
said,
you
can
touch
provisioning
of
infrastructure.
It
can
touch
deployment
of
your
applications,
so
automation
can
be
at
the
heart
is
at
the
heart
of
devops,
of
course,
because
you
are
trying
to
avoid
all
those
manual
tasks
as
much
as
possible
to
have
repeatable
processes.
A
But
yes,
I
agree
that
devops
is
not
just
like
okay,
let
me
commit
my
my
change
and
then
oh
there's
a
container
running
with
the
new
version
in
in
production.
That's
that's
a,
I
would
say
a
very
simplistic
way,
but
it
it
helps
basically,
as
you
said,
sell
the
id
when
I'm
saying
sell,
not
in
in
the
meaning
of
like
really
contraction
with
the
customer.
A
Of
course,
that's
that's
an
end
goal
at
some
point
but
like
to
having
to
have
the
conversation
with
the
customers
about
how
they
are
doing
things,
how
they
are
pushing
code
into
the
different
environments,
how
they
are
provisioning,
the
environment,
how
they
are
testing
the
applications,
how
they
are
getting
feedback
from
production
when
they
want
to,
you
know
improve.
Maybe
the
performance
of
their
applications
fix
bugs,
as
you
said,
get
logs.
A
B
B
There
is
zillion
tools
to
deploy
those
containers
and
for
developer.
That
is
awesome
because
they
develop
usually
the
developers
task
and
when
they
do
a
commit
and
it's
merged,
and
it's
built
and
deployed
feature
done
next
feature.
But
then
it
comes
to
the
what
I
actually
once
I
had
done,
the
five
years
of
pre-sales.
B
My
role
is:
help
engineering
help
us
re
teams
to
do
their
job
better,
and
what
you
see,
then,
is
that
there
is
a
lot
of
other
stuff
in
devops
than
just
shipping,
your
code,
your
code,
yeah,
and
then
what
developer
like?
We
touch.
This
like
observability
once
that
one
important
task
is
to
developers
should
know
what's
happening
in
the
production
like.
If
there
is
a
bug
that
the
happening
in
production,
it's
a
deliver.
B
Developers
should
have
access
to
the
locks
and
see
the
production
locks
so
that
they
are
asked
that
there
is
no
like
secret
information
in
there
just
because
the
customer
data,
but
there
shouldn't
be
a
process
to
get
the
blocks.
It
should
be
just
a
tool
that
I
can
read
the
logs
so
that
this
you
said
that
this
is
like.
You
said
that
devops
term
comes
from
development
operations.
This
is
something
that
developers
do
something
related
to
operations.
B
B
B
B
You
might
be
releasing
really
often,
but
every
second
release
have
to
be
rolled
back
because
of
the
bug
yeah.
So
let's
say
that
you
released
once
per
week
earlier
and
then
you
had
a
tooling
you
release
files
per
day
advice
per
week,
but
every
second
release
you
have
to
roll
back
because
there's
a
bug.
So
basically
you
are
not
any
effective.
You
still
have
a
complete
like
successful
release
once
per
week.
A
Yeah
yeah
so
yeah
that
so
that
that
means
that
so
yeah
I
let's
let's
pause
for
a
second
and
try
to
make
that
more.
I
would
say
visual.
So
I
I
love
music,
so
I'm
I'm
gonna
try
to
have
a
visual
image
that
depicts
what
you
are
talking
about.
So
imagine
that
you
are
like
you
know,
playing
at
a
huge
concert
and
you
you're
playing
guitar,
but
you
don't
have
the
feedback
like
you,
don't
know
what
you
are
playing,
so
everybody
is
doing
their
thing.
A
You
are
strumming
or
playing
your
solos,
but
you
don't
hear
what
you
are
doing.
So
basically
you
can
get
pretty
pretty
lost
because,
although
you
feel
like
you
are
doing
your
thing,
you
don't
know
if
it
fits
well
with
the
other
guys.
You
don't
know
if
the
the
audience
is
hearing
anything
because
you
basically
don't
have
the
feedback,
you
don't
hear
what
you
are
doing
and
you
know
when
you
are
playing
concert.
You
have
those
feedback
amps.
A
Basically,
that
gives
you
monetary
monitoring
what
you,
the
other
guys,
are
doing,
and
also
what
you
are
doing
so
yeah
I'd
say
that
that
feedback
from
production
is
basically
the
same
thing
is:
okay:
we've
we've
done
some
stuff,
we've
deployed
the
application
faster.
Maybe,
but
is
it
better?
Is
it
working?
Is
it
improving?
A
Do
we
have
less
bugs,
etc,
etc?
So
that's
that's
the
like
the
the
importance
of
that
continuous
feedback
loop,
but
now
that
it
takes
it
takes
us
to
another
correlated
question
which
is
so.
What
do
we
basically
track?
So
how
do
we?
Okay?
We
have
a
continuous
feedback,
but
of
what
like
what
should
be
in
there.
What
do
we
need
to
to
monitor
to
to
have
the
the
correct
information
to
basically
be
able
to
diagnose
the
application
and
troubleshoot
and
compare
and
know
if
we
have
improved
performance
and
stuff
like
that?
B
That's
a
really
good
question
and
usually
the
answer:
is
you
get
what
you
measure
and
yeah
yeah?
So
you
the
the
problem,
usually
is
that
in
organizations
you
have
persons
and
teams
and
those
goals
have
been
linked
to
apis.
Let's
say
you
have
to
do
10
deployments
this
quarter.
That's
your
goal,
so
the
the
idea
is
that
the
team
will
do
the
10
deployments
and
okay,
fine
10
deployments
check.
We
got
our
target,
we
got
our
bonus.
A
C
B
B
A
Money
to
that
yeah,
but
let's
pause
on
that,
because
it's
very
interesting
and
it
shows
how
tricky
it
can
be
so
yeah
we're
saying:
okay.
Is
it
better
to
have
four
deployments
that
raised
no
bugs
than
one
that
raises
five
bugs,
for
instance?
But
what
is
like,
because
you
have
released
earlier,
that
one
deployment
it
gave
you
or
your
users
enough
time
to
you
know
to
go
through
some
new
features
and
then
you
get
bugs
and
then
you
are
able
to
fix
those
bugs.
A
So
then
it
gets
better
than
the
four
deployments
where
you
didn't
catch
the
bugs.
So
you
know
it
can
be
tricky,
as
you
said
to
to
say.
Oh,
this
is
like
the
z
kpi
and
it's
going
to
to
fix
all
our
problems,
because
it's
basically
always
relative
relative
to
to
something
there
are
quantitative,
kpis
and
qualitative
kpis.
B
Yeah-
and
I
think
that
like
it
is
for
organization
that
hasn't
like,
doesn't
have
an
a
long
devops
history-
they
don't
know
the
kpis,
they
don't
know
the
velocity,
they
don't
know
how
many
plants
they
do.
So
it's
very
hard
to
actually
do
these
measurements,
but
one
one
is
investment
for
development
tips.
Is
that
devops
teams?
Is
that
how
many
deployments
and
how
many
rollbacks.
C
B
B
A
A
It
was
a
very
big
e-commerce
shop,
so
one
of
the
biggest
e-commerce
shops
in
france
and
we
we
were
working
on
their
devops
transformation,
basically
and
one
of
the
the
key
topics
that
we
wanted
to
address
at
some
point.
So
everything
was
automated
infrastructure.
Provisioning
was
automated
application.
Deployment
was
automated,
so
basically
they
were
doing
many
many
deployments
per
week.
A
So
one
of
the
the
the
topics
that
we
at
some
point
we
wanted
to
address
was
basically
what
you
said
like
the
lead
time
to
have
a
feature
released
into
production.
But
it's
it's
not
easy
to
have
that
because
you
need
to
have.
We
spoke
about
tooling,
and
you
know
what
you
need
to
have
across
the
the
the
whole
devops
chain
and
what
usually
lacks
is
like
traceability.
A
You
know
somewhere
where
you
capture
the
business
requirement.
It
can
be
a
spreadsheet,
it
can
be
a
tool
like
jira,
or
you
know
this
type
of
more
agile
ways
where
you
define
your
user
stories
etc.
And
the
question
was:
how
do
you
keep
track
like?
How
do
you
know
what
feature
has
been
deployed
in
what
binary
actually
or
if
we
speak
about
containers?
A
What
container
images
like
what
tags?
What
releases
implement?
What
feature
so
we
had
to
think
about.
You
know
all
the
links
that
you
need
to
get
from
the
business
requirement
to
the
user
stories
to
the
features
to
the
code
like
to
the
commit
to
the
comments
to
the
test,
sets
that
go
with
it
to
the
release
tags
that
implement
that
specific
feature.
So
you
can
have
the
whole
trace.
A
You
know
all
the
way
up
from
development
into
production,
and
then
you
can
say
okay,
so
now
for
this
release,
we
have
implemented
these
five
releases.
We
have
implemented
these
five
features.
Okay,
so
yeah
it
was
not
easy
to
to
set
up
all
that.
You
know
traceability
along
the
the
chain
because
you
need
to
have
the
proper
approach
like
the
the
the
right
people
need
to
to
speak
together
to
to
understand
that
you're
as
a
developer.
A
A
A
So
again
you
have
to
introduce
some
new
kpis
towards
like
what
value
does
what
each
feature
bring
to
your
application
in
terms
of
whatever
you
want.
It
can
be
in
terms
of
money.
It
can
be
in
terms
of
quality
perception
from
your
customers.
It
can
be,
you
know,
customer
satisfaction,
etc,
etc.
So
you
know
and
and
then
your
kpis
start
to
to
be
linked
together
and
then
you
can
say.
Okay,
we
have
delivered
that
value
because
because
you
have
the
whole
thing
yeah
to
go
back.
B
That's
the
like
the.
If
I
had
a
magic
wand
and
unicorns,
I
would
that's
like
the
the
best
solution
that
you
have
a
business
feature
that
provide
that
brings
money
to
the
the
into
the
house.
And
then
you
have
features-
and
you
know
that
I
implemented
this
feature
and
that
increased
our
revenue,
five
kilos,
so
that
you
have
excess
money
and
actually
what
we
in
the
mobile
games
game
refinery
is
one
part
of
bungle
and
in
there
we
provide
analytics
that
because
we
know
what
the
market
is
in
mobile
games.
B
B
So
then,
if
you
have
10
features
in
the
backlog,
it's
easy
to
check
that
we
take
those
three,
because
those
bring
the
80
percent
of
of
the
revenue
from
all
those
10
10
features.
So
it's
really
easy
to
then
prioritize
what
we
do,
because
those
features
bring
money
and
that's
like
in
the
software
development.
B
A
B
A
B
Yeah,
because
also
they
there's,
if
you
have
a
bug
that
users
cannot
lock
in,
we
know
that
how
much
the
company
is
losing
money.
That's
really
easy
to
like
measure,
because
there
are
metrics
from
the
history
so
that
okay,
we
lose
100
000
per
day,
so
we
should
fix
it
pretty
fast.
So
there's
at
the
end
of
the
day,
it's
always
money.
B
A
Well,
speaking,
about
features
that
you
know
you
can
map
to
direct
value
or
money
just
a
funny
example,
but
this
morning
my
wife
was
doing
some
online.
You
know
grocery
shopping
and
after,
like
45
minutes
of
doing
her
e-commerce
stuff,
she
checked
out,
but
everything
was
lost
and
we
she
couldn't
like
go
through
the
the
order
and
she,
basically,
you
know,
has
to
go
back
to
okay.
It
doesn't
work
all
these.
You
know
e-commerce
stuff,
let's
go
back
to
real
life
and
then
so
that's
you
know,
that's
a
pure
loss.
C
B
Yeah
yeah,
that's
that's
true,
but
we
actually
now
that
we
went
to
the
kpis
and
how
you
defined
actually
that
this
was
a
spin-off
like
you
asked
about
kpis,
but
we
got
off
the
track,
but
the
most
important
kpis
for
the
application
is
revenue.
How
much?
Of
course,
revenue
and
money
can
be
in
different
companies,
it
can
be
a
different
kind
of
it
can
be,
it's
might
not
be
concrete
money,
but
it
might
be
services
and
so
on
and
so
forth.
A
B
That
always
has
to
be
the
whole
organization
and,
let's
say
as
a
re-team
devops
team
development
team
that
needs
to
be
the
driving
force,
because
if
you
try
to
have
something
different
and
actual
value,
then
you
are
basically
fooling
yourself.
If
you
have
a
like
how
many
requests
per
seconds
my
services
can
can
take
it.
It
might
be
that
okay,
we
are
taking
a
lot
of
requests,
but
those
actual
requests
are
coming
from
a
monitoring
agent.
They
are
not
actually
really
users,
so
there
has
to
be
like.
B
Automated
way
of
collecting
the
information
and
see
that,
if
you
don't
have
like,
if
you
are
a
webshop
like
the
grocery
store,
you
know
how
much
your
sell
is,
how
you
know
how
much
you
sell.
That's
a
concrete
value,
it's
easy
to
measure,
but
then,
if
you
don't
have
that
concrete
value
you
have
to
somewhere
from
other
metrics,
you
have
to
complain
like
collect
the
enough
metrics
to
know
that,
with
this
amount
of
requested,
this
amount
of
unit
users,
via
generally
every
average,
creating
this
amount
of
value.
B
B
So
those
kind
of
this
is
more
like
do
sre
teams
that
should
work
close
with
at
one.
The
sri
teams
were
really
close
with
devops
that
the
each
service
should
have
an
kpi
or
a
service
level
sla
so
that
the
teams
know
when
the
service
is
working
and
when
it's
not
working
and
then
because,
if
you
don't
have
this
visibility,
you
just
don't
know
where
you're
doing
the
correct
things,
and
then
it
goes
back
to
the
the
development
teams.
B
C
B
Calculate
that
okay,
this
change,
actually
we're
losing
money.
Yeah
right,
that's
the
simple
calculation.
It's
not
always
that
simple,
and
also
the
the
like
this
kind
of
dashboarding
monitoring
alerts
is
now
that
I
have
learned
it.
I
think
that
it's
the
most
important
thing
in
devops,
the
observability,
so
that
you
have
a
feedback
in
scrum.
It
was
very
well
defined
the
feedback
loop.
What
happens
you
get
feedback,
what
you're
doing,
and
then
you
assess
your
doing
based
on
the
feedback,
but
in
devops
it.
B
B
A
So
that's
a
different
e-commerce
partner
and
those
ones
were
happy
openshift
and
they
are,
I
hope,
happy
openshift
customer.
So
that's
that's
cool
to
see.
You
know
that
they
are
implementing
those
type
of,
I
would
say,
new
e-commerce
services
based
shops,
etc,
and
one
of
the
the
nicest
things
that
I
have
seen
when
I
went
to
their
devops
plateau.
As
we
say
like
the
devops
room,
where
you
have
different
types
of
people
like
you
have
networking
guys.
A
You
have
storage
guys,
you
have
so
it's
a
mix
of
different
skills,
but
within
the
same
team
and
they
had
their
their
monitoring
screens
are
all
over
the
place
and
one
of
the
nice
metrics
that
they
had
so
they
they
have.
I
think
more
than
five
five
different
brands
like
in
each
brand
is
a
big
brand
in
itself
and
basically
they
had
the
dashboard,
like
all
the
technical
stuff.
A
For
each
like
e-commerce
brand
and-
and
I
I
thought
that
it
was
like
you
know
great,
I
would
say
devops
adoption
and
mindset
because
they
are,
you
know
they
are
tying
their
technical
stuff
through
the
business
value
to
the
revenue
and
they
are
continuously
monitoring
the
two
topics.
Together.
You
know
they
are
monitoring
and
within
the
same
team.
A
A
Yeah-
and
they
were
also
implementing
things
like
you-
know,
canary
releases
and
a
b,
testing
and
stuff
like
that,
like
trying
new
features
and
and
seeing
the
impact
on
on
their
revenue
like
they
release
a
new
feature
or
change
the
the
website,
design
or
maybe
shorten
the
checkout
process
and
stuff
like
that,
and
they
they
check
the
impact
and
they
compare
to
to
the
previous
version
or
previous
day,
and
they
can
instantly
know
okay.
So
now
we
we
know
that
we
have
improved
whatever
kpi.
They
are
monitoring
or
no.
Okay,
guys,
you
see.
A
B
Yeah
and
that
that's
that's
also
one
thing
that
I
learned
when
moving
from
pre-sales
to
actual
engineering
that
when
doing
deployments
in
demos
and
presets
it's
a
different
thing:
it's
you
deploy.
You
have
a
rolling
deployment,
yeah
yeah
everything
works,
but
when
you
run
hundreds
of
millions
of
requests
per
hour,
you
have
hundreds
of
replicas
when.
C
A
A
B
Know
what
you're
thinking
about,
but
then
you
cannot
force
developers
to
go
to
the
metrics
and
follow
the
metrics,
follow
the
dashboards
because
they
have
code
to
write.
So
then,
like
what
prometheus
provides
out
of
the
box
and
a
lot
of
companies.
You
select
that
when
you
have,
when
you
know
your
team's
kpi,
you
can
create
an
alert
based
on
the
kpi.
B
If
your
25
percentile
is
lower
than
x
a
y
chat
and
have
an
alert
so
that
it's
a
proactive
way
of
knowing
that
something
is
wrong
and
it
is
very
easy
to
implement
and
it
is
key
for
for
the
productivity
for
the
devops
team,
the
developers
so
that
they
don't
have
to
use
time
to
follow
the
metrics.
But
they
are,
they
are
being
told
when
something
from
when
they
can
see
the
metrics,
and
this
is
one
thing
that
easy
to
implement
and
you
should
implement
in
your
devops
environment
yeah
in
the
first
phases
like.
C
B
A
Yeah
exactly
but
then
you
can.
You
can
set
different
channels
for
that
and
have
alerts
and
subscribe
to.
Oh
okay.
So
that
brings
us
to
another
topic
that
we
wanted
to
to
talk
about,
which
is
basically
okay.
Yes,
for
sure
it's
it's
good
to
catch
stuff
in
production.
It's
it's
good
to
know
what
happened!
It's
good
to
know.
You
know
to
have
that
feedback,
but
is
there
isn't
there
a
way
to
to
detect
these
things?
A
B
Yeah
left
shift
left
basically
yeah.
It
is
why
it's
left
just
because
in
all
the
diagrams
development
is
always
in
the
left
side
and
operators
in
the
right
side,
yeah.
So
what
it?
What
it
means
is
that
you
more
move
tasks
that
have
been
done
by
someone
else
than
developers.
You
move
those
tasks
for
developers.
B
A
B
First
shift
left
topic
was
unit
testing.
I
would
say
that
you
actually
developers
write
the
code,
you
don't
ship
it
to
the
tester
where
testers
test
it
do
some
basic
testing
and
then
it
goes
forward
in
the
pipeline,
but
actually
unit
tested
you
in
that.
Let's
say:
that's
different
development
you'd
write
the
test.
Yes,
then
you
write
the
code
to
match.
B
That's
a
good
example
of
safety
left.
The
test
team
responsibly
went
in
some
level
to
cover
so
that
the
test
driven
development
and
also
then
we
saw
a
tooling
like
selenium
or
this
so
that
you
can
actually
do
user
interface
testing
as
part
of
the
build.
You
can
like
record
the
scripts
that
you
do
so
that
when
you
have
appealed,
you
actually
do
some
basic
linking
in
the
user
interface.
B
But
now
and
there's
a
good
tooling,
also
say
you
need
so
so
forth
and
also
with
new
rest
interfaces.
You
can
actually
with
quercus.
You
can
run
a
containerized
test
environment.
Just
in
the
comment
line
that
you
can
test.
Everything
and
unit
tests
are
always
run
when
you
have
a
code,
so
it
is
actually
not
that
much.
It's
part
of
development
and
you
don't
think
about
it
testing
anymore.
A
B
B
C
B
Earlier
developers
coded
they
wrote
something
and
then
the
binary
was
deployed
and
the
security
was
meant
that
there
was
a
security
officer
who
worked
with
the
operations
they
created,
an
insanely,
secure
environment
with
ssl
and
tls,
and
everything
now
like,
let's
I've,
wrote
that
some
qrgos
code
today
with
tls.
So
now
you
define
in
the
development
phase
that,
where
is
the
certificate
you
can
generate
the
certificate
with,
let's
say
so,
developers
can
actually
create
the
dls
certificates.
B
C
A
B
Loop,
continuous
feedback
in
the
credit,
your
development
environment.
So
you
have
instant
feedback,
so
you
don't
have
to
go
to
the
pipeline
and
then
pipeline
field,
and
then
you
have
security
scanning
and
everything,
and
after
a
couple
of
hours
you
get
back
that.
Okay,
this
library
has
a
vulnerability.
You
need
to
update
yeah,
then
you
start
over.
B
So
this
is
really
good
and
now,
of
course,
there
are
also
tooling
that
there's
nuke
stack
rocks
and
a
lot
of
companies
are
building
these
tools
that
I
would
say
that
they
try
to
make
the
security
path
invisible
for
the
developers
so
that
the
code
that
is
produced
is
secure
by
default,
that
that
is
really
good,
and
it's
like
done
right,
and
I
think
that
next
might
be
that
when
enterprise
is
called
public
cloud,
there
has
been
actually
in
the
cloudcast.net.
There
was
a
good
topic
in
about
the
cloud
public
cloud
course.
B
So
it
is
kind
of
one
thing
that
if
you
have
10
replicas
running
and
it
uses
eight
gigs
of
memory
and
every
you
have
a
unit
price
for
memory
in
the
public
cloud,
you
know
how
much
it
costs
yeah.
So
then
you
have
a
non-functional
requirement
saying
that
we
need
to
lower
the
costs
so
that
we
can
scale
more.
So
it's
very
easy
to
then
like
okay.
B
Maybe
we
should
have
more
performant
code
so
that
we
can
run
less
memory
so
that
you
actually
start
seeing
the
full
infra
costs
on
the
features,
and
I
think
that
that's
that's
next
thing,
but
I
I
like
that
still
the
shifting
left
the
security
devsecops
it's
coming.
It's
that's
good.
I
think
next
will
be
that
the
safety
left
costs
and
whatever
whatever
next
shifting,
left
ops.
So
there
is
only
then.
A
A
A
You
don't
always
understand
why
you
you
get
that
very
big
bill
yeah
until
you
spend
like
a
lot
of
time
going
into
the
details
of
that
stuff.
So
that's
one
of
the
areas
where
I
see
customers
trying
to
you
know
implement
that
automated
billing,
which
is
tied
to
to
to
consumption,
which
is
again
tied
to
metrics.
A
A
A
So
no
one
knows
that
it's
running
you
keep
it
in
your
closet
and
then,
when
you
need
it,
you
deploy
something
on
it
and
of
course
it
got
a
lot
of
time,
a
lot
of
money
because
you
are
wasting
resources,
but
now
we
are
shifting
more
towards
a
on-demand
infrastructure
consumption
where,
for
instance,
as
you
said,
okay,
you
hit
your
merge
button.
You
have
a
feature
branch
development,
maybe
where
basically
you
you
provision
automatically
all
the
infrastructure
that
you
need
to
build.
A
Your
application
run
your
tests
for
that
specific
release
and
check
that
everything
is
good.
You
get
your
results
back
and
then
you
decommission
the
the
ephemeral
infrastructure
or
containers
or
whatever
you
have
provisioned.
I
think
it's
it's
much
easier
to
do
it
today
without
spending
too
much
time
into
automating
stuff
than
it
was
before.
So
I
believe
that
this
will
definitely
help
reduce
you
know
the
the
costing
side
of
of
things
so
yeah,
that's
also
part
of
the
you
know.
A
Part
of
the
devops
is
like
how
you
can
automate
provisioning
and
d
provisioning,
because
if
you
are
not
decommissioning
your
environments,
it's
good
to
automate
the
provisioning.
But
if
you
don't
automate
the
deep
commissioning,
then
there's
a
whole
issue
that
you
are
not
addressing,
which
is
like
the
ongoing
and
always
up
costs
of
your
iq
infrastructure.
B
But
then,
when
you
go
inside
under
the
kubernetes,
you
see
that
you
only
actually,
because
each
content
is
not
using
the
amount
of
memory
you
are
giving
you're
actually
running
twenty
percent
of
the
of
the
actual
hardware
utilization
and
then
you
are
wasting
money.
Eighty
percent
wasted
money.
This
is
one
of
the
kpi.
So
how?
A
B
Yeah,
how
much
money
you
spend
to
run
this
amount
of
performance?
So
if
I
have
10
times
more
customers,
will
the
cost
be
10
times
more
or
will
it
be
twice
so
this
confessed
estimation,
because
not
many
startups,
let's
say,
can
handle
like
from
10
users
to
100
users
and
at
the
same
time
costs
went
to
100
000
to
1
million.
So
you
you
have
to
be
aware
from
the
feature
beginning
yeah
from
the
beginning,
how
much
it
cost
to
run
the
stack.
A
All
right
so
terrell,
we
are
five
minutes
overtime,
but
it's
really
interesting.
So
thanks
a
lot
for
being
here,
we
have
one
question
from
jean
in
the
chat
he
says
so
yeah
I
I.
It
would
be
good
to
enter
that
from
your
perspective,
like
so
how
developers
debug
apps,
is
it
directly
on
production,
kubernetes
or
operative
clusters,
or
do
they
need
to
reproduce
it
locally
or
in
development
cluster?
So
what's
what's
your
take
on
that
you've
been
a
developer.
How
did
you
do
it
before?
How
do
you
do
it
today.
B
It
depends
my
favorite
answer,
but
it
has
been
made
way
easier
to
develop
locally.
Personally,
I
don't.
When
I
do
something
I
write
something
I
don't
run
on
my
local
element.
I
run
it
in
a
command
line
or
container.
I
don't
learn,
run
it
in
a
kubernetes
environment,
so
it's
easier
to
debug
debug.
But
then
you
have
this.
You
have
these
problems
that
okay,
it
only
happens
in
the
production.
It
only
happens
with
production
data,
let's
say
at
game
refinery.
B
B
You
have
one
of
those
it's
running,
but
it
varies
and
also
it
depends
what
you
need
to
test.
If
you
need
the
whole
stack,
you
need
10
mic
services.
You
need
a
couple
of
databases,
it's
very
hard
to
build
the
environment,
so
you
can
run
everything
in
containers
in
local
environment,
but
it's
hard
to
maintain.
B
So
if
you're
developing
one
microservice,
then
you
usually
use
your
development
or
staging
environment
to
map
the
rest
of
the
environment
from
there.
So
you
run
one
microservice
locally,
but
exactly
but
some
some
some
problems
are
kubernetes
so
that
they
only
happen
in
kubernetes.
Then
you
have
to
go
there
in
the
goodreads
environment
and
remote
debugging.
If
it's,
depending
on
the
in
the
tech
stack
that
you're
using
java,
it
is
pretty
well
working
that
you
do
remote
debugging.
A
A
If
it's
impacting
data
or
if
it's
just
visuals
what's
what's
sure,
is
that
whatever
you
do,
you
need
to
make
sure
that
you
can
push
it
to
production
as
fast
as
you
can
and
as
securely
as
you
can
meaning
that
if
you
develop
locally,
then
you
make
sure
that
you
have
maybe
an
automated
pipeline
that
can
push
your
fix
and
deliver
it
to
production,
of
course,
never
go
to
your
container
and
and
and
make
all
changes
within
your
production
application.
That's
a
no-go,
but
yeah.
C
A
B
A
A
You
know,
I
think
we're
gonna
have
a
follow-up
on
that,
because
it's
a
very
broad
topic.
There
are
many
things
that
we
haven't
discussed,
but
at
least
you
know,
we
have
covered
some
some
some
key
areas
of
of
what
we
call
devops
and
what
we
need
to
address.
So
thanks
a
lot.
It
was
nice
to
have
you
and
have
your
your
your
view
as
an
outside
you
know
of
the
outside
world,
it's
always
great
to
to
have
that.
Yeah.
B
A
We
do
things
that
would
be
nice.
That
would
be
cool
all
right.
Thank
you
very
much.
Sarah
thanks
for
everyone
who
has
been
with
us
today,
don't
forget
that
there
are
always
great
shows
coming
up
on
the
twitch
channel,
so
you
can
go
on
red
hat,
twitch.tv,
redhat,
openshift
channel
and,
of
course,
everything
will
be
available
on
replay
also,
so
thank
you
very
much
wish
you
a
great
day
and
we'll
see
you
again
in
in
two
weeks.