►
From YouTube: A Guide to Event-Driven SRE-Inspired DevOps
Description
While software architects have broken their monoliths into event-driven service architectures, many DevOps architects are still building monolithic inspired release pipelines. This results in complex pipeline code, tight integration of process and tools, lengthy diagnostics sessions to fix broken pipelines and puts strains on the underlying resources that build, deploy, test and validate.
In this session we introduce a new approach: Event-driven Continuous Delivery and Operation Automation for modern DevOps! This approach decouples the declaration of processes for delivery and remediation from tooling. It uses an “everything as code” approach which includes deployment, testing, quality gate, observability, promotion and remediation definitions.
One open source tool which implements this new approach is Keptn which was heavily inspired by Google’s SRE practice around SLIs & SLOs. Join us, see Keptn in action and get inspired on what the future of DevOps tooling can look like.
A
Well,
thank
you
so
much
for
having
me
again.
You
said
I'm
hosting
it,
but
still
actually
you
give
me
you
give
me
the
opportunity
here
to
speak
about
something
that
is
very
dear
to
my
heart
and
that
I've
been
with
a
team
in
the
back
been
driving
over
the
last
year
and
a
half
or
two.
So
let
me
actually
start
sharing
my
screen
because
I
think
at
some
point
you
might
get
tired
of
just
seeing
my
video.
A
A
Whether
these
are
your
microservices,
your
serverless
or
also
your
traditional
applications,
so
I
think
one
of
the
uniquenesses
is
we're
not
just
targeting
the
cloud
native
space,
even
though
we
were
born
there,
but
we
have
architectured
it
in
a
way
and
put
some
thoughts
in
delivering
operational
opera
automation
for
both
types
of
applications,
the
modern
cloud
native,
serverless
apps,
but
also
any
type
of
traditional
apps
a
day.
I
always
say
I'm
a
devops
activist
at
dynatrace
and
at
night
or
whenever
I
have
time,
is
I'm
a
deaf
rl
for
captain.
A
A
So
if
you
have
questions
put
them
into
a
q
a
because
this
helps
me
to
better
see,
you
know
which
questions
I've
already
answered
and
also
feel
free
to
interrupt
or
like
post
them
in
as
they
come.
You
don't
have
to
wait
until
the
end,
because
then
you
can
also.
We
can
also
make
this
a
little
more
interactive
cool.
A
Well
then,
I
would
say:
let's
get
started,
so
what
is
captain
actually
captain?
Is
you
know
a
couple
of
things,
but
I
believe
the
best
thing
is
it
is
a
or
the
best
way
I
can
describe
it.
Is
it's
a
self-service,
devops
control
plan?
So
what
does
that
mean
you?
Whoever
you
are?
You
might
be
a
developer,
you
might
be
in
operations,
you
might
be
an
sre.
You
might
be
a
performance
engineer.
A
What
you
can
do
with
captain
is
you
can
pick
your
use
case?
Captain
is
automating
different
use
cases
around
progressive
delivery
is
one
of
those
slo-based
quality
gates
is
another
one,
and
actually
the
slo
based
quality
gates
are
key
to
all
of
the
use
cases.
To
be
honest
with
you,
there's
also
sre
automation,
sre
automation
is
all
targeted
around.
You
have
an
application
or
a
new
service
that
you
want
to
make
sure
it
is
actually
reliable.
A
So
their
captain
can
orchestrate
the
execution
of
performance
and
scalability
tests,
including
chaos,
xp
running
chaos,
experiments
and
then
still
validate
that
your
system
behaves
as
expected.
Even
under
let's
say
rough
conditions
and
another
use
case
would
be
all
the
remediation,
which
means,
if
something
happens
in
production,
whether
this
is
related
to
your
deployed
service,
your
application
or
even
to
the
infrastructure,
then
captain
can
orchestrate
automated
other
remediation
tasks
for
you
or
complete
workflows.
A
So,
whoever
you
are.
You
pick
the
use
case
that
you
want
to
automate.
Then
you
bring
your
configuration.
You
will
see
that
in
my
examples
later
on
in
my
live
demo,
that
everything
is
obviously
it's
declarative,
you
declare
your
delivery
workflows.
You
declare
your
slis
and
slos.
You
declare
the
workload
that
you
want
to
simulate
and
you
declare
your
runbooks
and
the
nicest
thing
I
believe
from
captain
is
captain
is
not
just
another
tool
that
can
do
everything
on
its
own.
No
captain
is
really
connecting
to
your
tools.
A
It
is
orchestrating
processes
and
connecting
to
your
tools.
So
that
means
you
can
bring
whatever
tools
you
like.
If
you
are
deploying
microservices,
you
want
to
use
helm
or
you
want
to
use
spinach
or
argo.
You
will
go
with
it.
If
you
have
existing
jenkins
pipelines,
then
already
execute
some
tests
or
deploy.
Do
it
if
you're
using
prometheus
for
monitoring
great,
if
you
use
dynatrace
or
any
of
the
other
apm
vendors.
A
Also
great,
as
I
said,
you
can
run
on
kubernetes,
but
I
mean
cap
itself
needs
to
run
on
kubernetes,
but
the
target
platform,
where
captain
should
execute
these
workflows
on
they
can
be
anywhere
so
pick.
Your
use
case
bring
your
configuration,
connect
your
tools
and
then
captain
configures
or
automates
the
configuration
of
your
monitoring,
because
we
need
monitoring
data
for
the
quality
gates
for
the
performance
evaluation.
A
We
need
it
for
figuring
out
if
you're
executing
all
the
remediation.
If
your
system
is
back
to
a
healthy
state,
it
configures
your
delivery,
it
understands
and
configures
your
liability
tools
and
also
your
remediation,
and
it
provides
all
these
use
cases.
Well,
whatever
use
case,
you
pick
as
a
self-service,
which
means
you
can
either
integrate
this
into
your
existing
delivery
pipeline
through
an
api
call.
Captain
obviously
has
an
api.
You
can
trigger
all
these
workflows.
A
A
I
think
this
is
the
key
and
also
the
part
of
my
my
my
title
of
the
talk
is
we
are
doing
this
through
an
event
driven
process
orchestration
engine,
so
everything
captain
does
is
event
driven.
Everything
is
declarative.
That
means
you
define
you
declare
declaratively
define
your
process,
we
store
all
the
stuff
in
git
and
you
can
obviously
trigger
it
through.
A
You
know
your
git
hooks
everything
is
centered
around
slo,
so
every
workflow
that
captain
provides
is
always
looking
at
your
key
service
level
indicators
and
your
objectives,
because
everything
captain
does
it
also
automatically
validates
if
your
system
at
the
end
is
in
its
desired
state
and,
very
importantly,
we
are
connecting
to
these
different
tools
through
open
standards,
we're
using
cloud
events
here.
So
it's
very
easy,
therefore,
to
integrate
new
tools
or
to
replace
tools
and
to
put
in
new
things
in
your
in
your
workflow
all
right.
So
why
are
we
doing
all
of
this?
A
Why
do
we
build
captain?
Well,
we
started
building
captain
quite
before
this.
The
latest
date
of
devops
report
came
out,
but
I
thought
this
was
actually
interesting
timing
two
weeks
ago,
and
I
know
that
some
of
the
cdf
community
have
already
written
reports
on
it,
that
63
percent
of
organizations
have
reserved
are
building
internal
self-service
delivery
platforms,
which
is
interesting
because
yeah,
because
we
think
we
want
to
we
want
to
help
here.
Why
do
we
want
to
help
or
what
do
we
want
to
help
with?
A
The
thing
that
captain
really
addresses
around
delivery
is
our
new
approach
to
delivery,
he's
addressing
the
problem
that,
when
you're
using
traditional
delivery
platforms,
a
lot
of
people
are
wasting
a
lot
of
time.
I've
actually
just
watched
the
previous
cdf
webinar
from
code
fresh,
and
I
think
he
was
the
speaker
was
making
a
similar
claim.
So
you
will
see
some
similarities
here.
A
We
also
focus
a
lot
on
automation,
automation
of
mental
tasks
along
delivery,
but
also
manual
tasks
along
all
the
remediation,
and
I
want
to
go
through
all
of
these
and
then
really
go
and
and
show
you
some
live
demos
on
how
captain
actually
how
it
feels
and
how
it
works.
So,
the
first
one-
and
this
is
the
one
that
allows
me
to
explain-
also
the
architecture
is
if
you
are
moving,
if
we're
trying
to
figure
out.
A
What's
the
next
gen
of
internal
delivery
platform
as
a
self-service,
and
if
you
are
going
towards
picking
existing
tools
that
we've
used,
maybe
for
10
15
20
years
that
work
great
for
the
monolithic
apps,
then
you
may
soon
run
into
bottlenecks
and
actually
spend
a
lot
of
time
in
getting
these
pipelines
up
and
running
or
keeping
them
running.
So
what
does
this
mean?
I
just
want
to
show
you
a
quick
example.
A
I
know
that
you
can
use
jenkins
to
generate
jenkins
pipelines
to
make
things
a
little
easier,
but
still
in
the
end,
there's
no
clear
separation
of
concerns,
or
you
just
have
to
put
a
lot
of
effort
in
it.
The
other
challenge
that
we
have
seen
as
we
moved
from
traditional
monolithic,
apps
to
more
smaller
components.
Microservices.
A
Obviously,
we
picked-
let's
say
jenkins
in
our
case
as
the
delivery
tool
of
choice,
because
that's
what
we
knew
so
we
started
off
with
a
jenkins
pipeline
that
could
then
deploy
our
containers
and
then
the
first
service
was
successful.
Then
we
added
more
services
to
the
project.
They
made
some
slight
modifications
into
the
initial
pipeline
and
then
this
went
on
and
on
until
we
had
many
different
pipelines
and
then,
if
something
breaks
now
it's
really
hard
to
figure
out.
Why
does
it
break
who
made
that
code
change
initially?
A
A
It's
actually
an
event
driven
approach
to
delivery
and
with
this
saving
all
of
these
headaches
also
allowing
you
to
scale
and
allowing
you
to
get
to
keep
an
overview
of
what's
actually
really
going
on
and
really
easily
identifying
in
case
there
is
a
problem.
Why
there's
a
problem?
So
let
me
explain
this
to
you
what
this
really
mean,
what
this
means.
A
A
A
You
are
capabilities
that
can
do
then
one
or
one
or
maybe
other
one
or
more
of
these
actions,
and
in
order
to
connect
these,
just
as
we
do
when
we
rip
monolithic
architectures
into
into
services,
we
need
something
that
then
triggers
the
right
services
at
the
right
time
to
execute
an
end-to-end
business
process.
In
our
case,
it's
a
delivery
process
and
we're
using
eventing
to
then
connect
them
with
the
tools
or
the
features,
the
capabilities
that
can
do
an
individual
job.
A
So
if
whoever
orchestrates
the
process
on
the
left
says,
hey
I'm
executing
a
process
right
now
and
I'm
at
the
deploy
stage.
So
now
I'm
sending
out
an
event
that
says
I
need
to
deploy
container
number
one
in-depth
with
the
blue
green
strategy.
It's
an
event
that
is
sent
out.
It
can
be
received
by
one
or
many
tools
or
services,
as
we
call
them,
as
I
would
call
them
that
can
do
deployment.
But
then
maybe
one
tool
says
no.
A
A
So
this
is
really
what
it
means
to
have
an
event-driven
approach
to
delivery,
a
workflow,
a
process
on
the
left
capabilities
on
the
right
and
then
whoever
orchestrates
the
process
sends
the
right
events
at
the
right
time
that
are
then
handled
by
these
tools.
So
really,
in
the
end,
to
sum
it
up
process
definition
tool
definition,
and
this
is
exactly
what
we
have
done
with
captain.
This
is
exactly
what
drove
the
architecture
and
the
implementation
of
captain.
So
what
is
captain?
A
Besides
its
funny
name,
you
may
say
red
captain
is
the
german
phonetic
for
a
captain
that
is
able
to
ship
your
containers
or
your
application,
safe
from
development
into
the
safe
harbor
of
production
captain
when
you
install
it
it's
a
container-based
solution,
so
it's
a
service-oriented
architecture
that
is
using
eventing.
Obviously,
when
you
install
it
on
kubernetes,
that's
our
target
platform
to
install
captain
itself,
you
get
the
control
plane,
which
is
the
central
logic
unit.
That
is
orchestrating
processes
for
delivery
and
also
for
all
the
remediation
so
for
operational
tasks.
A
You
have
to
specify
the
use
case
and
they
you
declare
the
workflow
that
should
be
executed.
There's
two
examples
here:
the
one
the
shipyard
this
is
for
the
defining
delivery.
So
here
you
can
see
dev,
staging
and
prod,
where
you
also
specify
direct
deployment
in
depth,
blue,
green
and
staging
canary
in
production.
What
type
of
testing
should
happen?
What
type
of
excel
is
a
restylane
you
have
and
then
on
the
right
side
top
right
remediation.
A
This
would
be
for
hey
in
case
our
monitoring
tool,
detects
a
high
failure
rate
or
maybe
a
full
disk
on
our
infrastructure
in
production.
Then
I
want
to
first
clean
that
directory,
maybe
also
adjust
the
log
level,
so
you
specify
which
action
should
be
taken.
So
you
declare
what
should
happen
and
then
the
who
does
it
is
something
that
the
execution
plane
is
then
acting
upon.
A
A
You
can
see
a
couple
of
names
on
the
bottom
here
for
the
different
types
of
tools.
The
nice
thing
about
this
separation
is
on
the
one
side.
You
specify
your
process
and
on
the
other
side,
you
specify
the
tools
you
can
have
multiple
tools
that
can
do
a
similar
thing,
so
they
can
all
subscribe
to
the
same
event
and
then
basically
decide
when
a
process
is
executed.
Who
is
that
actually
taking
the
action?
A
The
nice
thing
with
this
is
also
you
can
change
the
process
without
having
to
worry
about
which
tools
are
currently
integrated
in
this
process,
because
this
happens
decoupled
through
events.
You
can
also
switch
tools
without
having
to
worry
about
updating
all
of
your
pipelines
where
the
current
tool
is
used.
So
if
you're
switching,
let's
say
from
helm
to
spinnaker
from
jenkins
to
argo,
if
you're,
using
if
you're,
switching
from
prometheus
to
dynatrace-
or
I
don't
know
from
from
chain
meter
to
neo
tissue
from
a
testing
perspective-
you
just
change
the
tooling
configuration
and
that's
it.
A
Hopefully
this
makes
sense,
because
if
it
makes
sense,
then
the
next
thing
will
also
make
sense.
The
beneficiary
is
whoever
then
triggers
these
workflows
in
captain,
and
I
want
to
show
you
the
delivery
workflow.
So
if,
if
I
have
a
developer
here
that
says,
I
have
a
new
artifact,
please
captain
you
go
and
do
continuous
delivery.
A
Then
captain
will
orchestrate
the
execution
of
that
process
that
is
specified
and
then
with
this
it
sends,
as
you
can
see
here,
different
events
that
are
then
picked
up
by
different
tools
and
with
this
the
process
gets
executed
in
this
case.
In
the
end,
it's
moving
an
artifact
from
left
to
right
over
multiple
stages
and
so
on
and
so
forth.
So
I
hope
this
makes
sense
by
the
way
I
know
some
people
may
have
joined
late.
A
If
you
have
any
questions
put
them
into
the
q
a
feature.
I
have
done
here
on
the
left
side
feel
free
to
interrupt
me.
Ask
me
questions
at
any
time.
My
goal
is
really
to
also
learn
from
you,
get
your
feedback
and
see
if
stuff,
that
we've
built
actually
makes
sense
and
actually
solves
problems
or
what
else
you
are
requiring
for
this
to
maybe
consider,
as
as
an
as
a
new
as
a
tool
that
you
want
to
use
in
your
organization.
A
So
this
is
the
architecture.
Now
let
me
go
into
a
demo.
The
demo
that
I
have
is
a
three-stage
pipeline,
and
I
want
to
really
show
you
how
this
works
and
instead
of
just
playing
out
the
the
the
animation
here,
I
just
go
into
my
into
my
tool.
So
what
I
have
here
captain
is
kit,
based,
as
I
told
you,
or
what
that
means
is
captain
is
always
storing
all
of
its
configuration
in
git.
Everything
starts
from
a
delivery
perspective
with
a
shipyard
file,
so
this
is
the
shipyard
file
that
I
mentioned
earlier.
A
Let
me
zoom
in
here
it's
a
little,
maybe
small,
but
now
it
should
be
a
little
bigger.
So
initially,
when
I
created
a
captain
project,
so
captain
is
organized
in
projects
and
then,
if
you
say
I
have
a
new
project
and
in
my
case
this
is
called
the
captain.
O7
simple
note
project
I
specify
which
stages
I
have.
I
have
three
stages
and
in
every
stage
I
can
specify
what
should
happen
in
the
stages.
Really,
I
define
and
declare
the
process.
What
type
of
deployment
strategy
should
happen?
A
What
type
of
test
strategy
approval
strategy
you
can
also
specify,
as
captain
orchestrates
the
process
and
pushes
an
artifact
from
one
stage
to
the
next.
It
is
always
deploying
then
it's
running
test
and
then
it's
evaluating
its
slos
and
the
evaluation
always
results
in
either
pass
warning
or
fail,
and
therefore
you
can
also
specify
what's
the
approval
strategy
into
staging
when
something,
for
instance,
comes
out
of
depth.
Do
you
want
to
automatically
deploy
everything
that
is
passed
or
like
what
I
said
in
production,
whether
it's
past
or
warning?
A
A
You
also
see
here
deployment
strategy,
blue
green
or
have
an
automated
remediation
strategy
in
production,
which
means
when
something
is
deployed
in
production,
blue
and
blue
grain
and
some
problem
happens.
Captain
is
able
to
also
revert
or
can
execute
any
type
of
remediation
workflow
that
you've
specified
based
on
the
problem
that
comes
in
because
maybe
the
problem
is
not
related
with
your
blue
green
deployment,
but
maybe
with
an
infrastructure
issue,
and
then
captain
can
make
sure
to
execute
tasks
that
solve
this
issue.
So
this
is
the
initial
sheet
bet
file.
A
So
what
I
have
done,
I
have
created
a
captain
project,
so
in
initially
obviously
I
had
to
install
captain
in
my
case,
captain
runs
on
an
eks
and
I
have
a
couple
of
projects
here
already,
as
you
can
see
on
board
at
the
one
that
I
want
to
focus
on
today.
Is
the
captain
note
7
project?
If
I
click
on
environment,
I
I
see
my
three
stages.
I
see
def,
I
see
staging
and
I
see
prod.
A
If
I
click
on
dev.
I
also
see
what
was
the
last
thing
that
was
deployed
build
number
three
at
1851.
This
was
just
shortly
before
I
I
started
the
webinar.
I
also
get
the
link
here
you
can
see
here.
This
is
not
a
very
exciting
app.
It's
a
node.js
app
that
gets
deployed
through
helm,
I'm
using
the
built-in
help
capabilities
of
captain
to
deploy
it
into
my
kubernetes
cluster
in
staging.
A
This
was
actually
from
a
previous
round
of
build
number
four
that
was
kind
of
rolled
back,
because
I've
been
playing
around
a
little
bit
with
different
builds,
and
you
can
already
see
a
little
preview
of
what
I
wanted
to
show
you
later
on.
But
what's
interesting
here
right.
If
you
look
at
this,
I
showed
the
environment
screen.
That
shows
me
the
three
stages
on
the
service
screen.
A
A
The
way
this
works,
so
one
of
the
option
is,
I
can
use
the
cli
as
you
can
see
here
I
can
say
captain.
Let
me
actually
kick
it
off
and
then
explain
it.
So
captain
is
event
based,
meaning
every
process
that
you
want
to
execute.
You
also
need
to
trigger
captain
and
say
now
it's
time
for
you
to
trigger
a
particular
process
in
a
particular
project,
and
then
you
can
give
it
some
information
about
what
this
process
should
be
in
some
context.
In
this
case,
I'm
saying
captain
for
the
captain
007
project.
A
A
If
this
would
be
a
problem
event
that
I
sent
in
it
would
then
execute
the
remediation
workflow.
If
I
would
just
say
captain,
please
evaluate
this
there's
an
evaluation
event.
Captain
would
just
trigger
the
quality,
get
evaluation
so,
depending
on
the
event
that
you
that
you
send,
in
which
we
call
the
root
event
or
the
trigger
event
of
a
process.
A
Captain
then
executes
the
process
that
you've
specified
in
a
project,
and
now
it
is
actually
kicking
off
the
process,
which
means
build
number
four,
which
I've
just
specified
should
now
be
kind
of
sent
along
the
way.
So,
let's
go
back
to
the
url
to
the
ui.
We
call
this
the
captain's
bridge
by
the
way.
So
now
I
can
see
at
1924
that's
my
local
time.
A
Captain
already
started
initially
processing
that
configuration
change
event.
What
actually
happens
with
this?
This
is
also
very
interesting.
I
said:
let's
go
from
build
number
three
to
build
number
four
I've
decided
to
use
helm
initially.
I
also
uploaded
some
helm
charts
and
if
you
do
that,
then
what
captain
also
does
right.
Remember
that
I
had
this
here
I
had
my
my
git
repo
for
every
stage.
Captain
also
has
automatically
creates
branches,
def,
prod
and
staging.
A
The
first
thing
that
captain
did
is
it
sent
out
an
event
to
trigger
a
configuration
change
in
the
git
repo,
in
my
case,
I'm
using
git
right
could
also
be
maybe
some
other
version
control
system
that
I
have
I've,
also
synced.
It
uploaded
uplinked
it
with
my
github
project
here.
So
I
can
see
it
and
then
once
this
is
done,
then
captain
continues
with
the
process
and
say:
hey
configuration.
Changes
have
been
applied
to
git
now
it's
time
to
do
the
actual
deployment,
and
in
my
case
this
is
done
by
helm.
A
I
have
a
helm
service
could
also
be
an
argo,
could
be.
A
jenkins
pipeline
could
be
an
azure
devops
pipe
and
a
gitlab
pipeline,
depending
on
what
remember,
whatever
tool
capability,
whatever
capability
you,
you
enable
and
listen
to
a
certain
event
which
captain
sends
to
a
trigger
action.
That
tool
then
goes
in
and
does
its
job,
and
I,
in
my
case
it
was
helm
so
now
in-depth.
I
should
have
built
number
four.
That
means,
if
I
go
back
to
my
dev
page
from
earlier,
where
I
initially
loaded
it
with
build
number
three.
A
If
I
refresh
this
now
now,
I
have
build
number
four
deployed.
The
next
thing
that
will
happen
test
will
be
executed
now,
which
tests
will
be
executed.
In
my
case,
I
decided
to
use
j
meter,
so
I
enabled
the
g
meter
subscription
and
what
does
j
meter
do
when,
when
we,
when
we
kick
off
g
meter,
just
as
any
tool
that
participates
in
a
captain
workflow,
you
can
upload
the
tool
specific
configuration
files
to
the
respective
branch
in
the
github
repo.
A
So
hopefully
this
makes
sense
again
as
a
reminder,
if
you
have
any
questions,
let
me
know.
Let
me
just
quickly
go
back
to
build
number
three
and
let
me
show
you
how
build
number
three
kind
of
went
on
so
there
was
dev
deployment
test
finished
in
dev.
I
didn't
have
specified
any
additional
slas,
so
you
can
specify
slice
and
slos.
The
only
thing
that
I've
specified
is
just
take
the
result
of
my
g
meter
test.
So
whenever
a
tool
is
triggered
and
it
sends
package
result,
it
basically
sends
back
an
event.
A
You
have
full
access
to
that
event,
that's
a
cloud
native
event
and
then
it
goes
on
right.
So
there's
a
question
that
just
comes
in
from
florian
when
there
are
multiple
consumers
for
a
given
event
is
the
execution
ordered?
Well
is
the
execution
or
the
well-defined
good
question
so
in
the
current
version
that
I'm
showing
you
this
is
0.7.3,
the
order
is
not
well
defined.
That
means
captain
sends
out
an
event
and
then
tools
that
want
to
participate.
A
The
second
thing
is,
with
0.8
you're
much
more
flexible
to
define
how
your
workflows
should
look
like,
because
if
you
remember
what
I've
shown
you
in
the
beginning,
this
is
kind
of
my
shipyard
file,
which
actually
means
we
have
a
very
opinionated
way
of
which
events
are
sent.
There's
always
a
configuration
change,
then
a
deployment
and
a
test,
and
then
an
evaluation.
A
So
there's
no
flex,
no
flexibility
with
0.8.
We
change
this,
which
means
you
can
actually
specify
exactly
what
type
of
events
should
happen,
and
you
can
add
additional
ones,
and
you
can
then
also
tell
say
you
know,
which
which
tool
should
then
basically
or
which
capability
should
be
triggered
in
which,
in
which
sequence?
So
we
give
you
this
flexibility
with
0.8
and
florian.
Let
me
know
if
this
answers
your
question.
A
A
There's
multiple
lines
here:
every
line
represents
a
metric,
a
service
level
indicator.
Captain
is
retrieving
these
values
from
your
monitoring
tool.
It
could
be
prometheus,
it
could
be
dynatrace,
it
could
be
any
other
monitoring
tool
or
any
other
data
source,
and
then
it
is
retrieving
that
value.
In
my
case
right,
it
is
retrieved
by
dynatrace.
A
So
dynatrace
sends
back
the
raw
data
for
every
metric,
but
then
what
the
uniqueness
of
captain
is
captain
has
a
component
that
is
called
the
lighthouse
and
the
lighthouse
is
then
taking
these
individual
values
and
comparing
it
against
your
slos,
which
you
can
also
specify
in
a
file.
So
I
can
specify
my
individual
slo's
my
criteria,
my
passion
warning
criteria
for
every
metric
captain
analyzes
it.
This
is
why
you
see
green,
yellow
and
red,
and
it
then
also
calculates
an
overall
score,
which
is
the
normal
gets
normalized
between
0
and
100..
A
So
in
this
case
I
actually
got
a
score
of
92..
If
I
zoom
in
a
little
bigger
here
right,
I
got
a
score
of
92,
which
means
pass.
I
get
to
see
all
the
individual
results
and
which
one
has
kind
of
violated.
You
can
compare
with
a
static
threshold
or
you
can
also
compare
with
the
previous
build,
there's
multiple
options
and
based
on
that
grading
or
score.
Captain
then
decides
whether
to
continue
or
stop
that
process.
A
We
also
give
you
options
here
to
look
at
the
individual
raw
data
that
comes
in
right,
so
build
of
a
build.
You
can
see
trends
and
so
on
and
so
forth,
and
if
everything
is
good,
then
it
continues
into
the
next
stage.
So,
let's
see
what
build
number
four
is
right
now
build
number
four
made
it
through
into
staging
now,
which
is
great.
That
means
in
staging.
I
can
refresh
now
we've
built
number
four
here
tests
should
execute.
Now
these
tests
run
a
little
longer
so
we'll
revisit
this.
A
I
just
showed
you
all
of
this
right.
This
is
just
my
my
typically
the
demo
that
I've
just
done
but
visualized
and
highlighted
in
in
a
way
in
case.
Let's
say
my
demo
would
not
work
for
whatever
reason
good.
Then
let
me
go
to
oh
yeah.
Another
thing:
not
only
do
I
obviously
have
the
demo,
and
you
can
obviously
do
this
yourself.
You
can
go
through
our
tutorials.
We
also
have
users
that
have
done
this.
A
For
instance,
a
very
common
use
case
is
that
you
use
your
existing
ci
tools
that
build
your
containers
and
push
them
to
the
registry
like
patrick,
is
doing
they're
using
gitlab
ci
so
and
then,
once
the
container
image
is
built
and
pushed,
then
the
trigger
captain
for
delivery,
all
right
so
integratable
through
the
api.
So
let
me
just
show
you
this
quickly.
A
I
showed
you
the
the
bridge
here,
which
is
the
ui,
but
then
you
also
have
a
captain
api
where
you
can
then
send
any
type
of
event.
You
have
full
access
to
the
configuration
system,
meaning
you
can.
You
can
create
services,
you
can
create
projects,
you
can
upload
resources,
so
you
can
basically
interact
with
the
config
repo
behind
the
scenes.
A
A
very
common
use
case
is
actually
so
captain
holds
its
own
config
repo,
but
if
you
have
your
repos,
where
you
have
your
source
code,
your
tests
already,
then
a
very
common
use
case
with
a
lot
of
our
users.
Is
you
keep
all
the
stuff
there
and
when
your
ci
is
done,
and
then
triggers
captain,
you
basically
just
upload
the
recent
files
from
your
sewers
repo
to
the
captain
repo
and
then
just
you
know,
pull
it
over
or
push
it
over
and
then
trigger
captain.
A
A
A
That
builds
deploys,
runs
your
tests,
but
then
there's
typically
a
phase
where
you
have
somebody
manually
looking
at
the
data
like
flora-
and
you
were
just
asking
how
about
canary
analysis
so
whether
this
is
looking
at
the
functional
test
results
and
then
trying
to
figure
out
if
the
selenium
test
fails.
Is
this
really
a
problem?
This
is
a
key
critical
feature
or
if
you're
running
performance
tests-
and
let's
say
your
response,
time
stays
great,
but
all
of
a
sudden
you
have
50
more
memory
consumption.
A
You
see
five
percent,
five,
more
five
percent,
more
pots
or
ten
percent
more
pots
on
kubernetes
to
to
deliver
the
same
response
time.
Is
this
still
good,
yes
or
no,
or
if
you
had
monitoring
data,
there's
so
much
data?
So
what
does
this
tell
me-
and
this
typically
means
more
data
to
look
at
the
the
longer
it
takes
if
you
do
it
manually
and
therefore
we
are
bringing
in
an
automated
approach
based
on
slice
and
slos,
and
we
call
it
salinas
solo
based
quality
gates.
So
what
that
means?
A
We
didn't
come
up
with
any
new
concepts.
To
be
honest,
I
also
don't
think
that
google
came
up
with
a
brand
new
thing.
I
think
they
just
did
a
great
job
in
coming
up
with
some
great
terms
and
then
really
showing
their
practices
to
the
world.
So
in
case
you've
never
heard
about
the
sre
practices
from
google,
what
they
basically
say
we're
looking
at
service
level
indicators,
we
call
them
so
slis,
it's
basically
something
that
is
measurable.
Like
the
error
rate
of
your
login
transactions,
then
you
specify
your
objectives.
A
So
what
is
the
success
criteria
of
that
metric?
So,
for
instance,
login
error
rate
must
be
less
than
two
percent
over
30
day
period
once
it
runs
in
production,
that's
a
clear
objective
of
success
and
then
what's
an
sla,
you
may
wonder:
slas
is
kind
of
what
happens
if
we
miss
our
slos.
That's
typically,
then,
for
some
slos,
maybe
a
business
agreement,
a
legal
contract
or
maybe
you
are
losing
users
right.
A
If
you
are
on
an
if
your
e-commerce
shop,
for
instance,
and
your
page
gets
slower,
people
cannot
log
in
or
check
out
so
something
very
simple
slice
metrics
as
to
all
your
objectives
and
slas.
What
happens
if
we
miss
our
objectives
again,
google
did
a
great
job
here
in
explaining
this
great
video
material
out
there
so
check
it
out
really
great.
So
now,
what
does?
Why
do
I
bring
this
up
because
we
see
more
and
more
are
now
one
more
organizations
are
using
slis
and
slos
for
production
monitoring,
so
that
means
they
actually
know.
A
What
is
the
success
criteria
for
a
particular
service
over
a
particular
time
frame,
and
this
could
be
the
classical
metrics
like
throughput
error
rate
response
time
could
also
be
something
like
conversion
rate
user
experience,
number
of
shopping
carts
and
then
I
purchased
was,
I
don't
know
whatever
it
is
right,
but
we
say
well.
This
is
great.
If
organizations
already
start
thinking
about
what's
important,
but
why
not
do
it
earlier?
Why
only
do
it
in
production?
A
A
But
then
the
additional
thing
we
do
is
not
only
against,
let's
say,
has
to
be
faster
than
100
milliseconds.
We
also
allow
you
to
compare
it
to
your
previous
evaluations
to
see.
Was
there
any
regression?
I
think
florian.
This
is
to
your
point.
We
can
do
this
also
with
canaries
in
production,
so
we
can
actually
pull
out
data
from
one
canary
and
then
compare
with
your
baseline
or
with
the
previous
builds.
A
But
the
concept
is
very
simple:
right
can't
it's
it's
that
we
did.
We
didn't
really
reinvent
the
wheel.
It's
not
rocket
science.
The
way
it's
implemented,
I
think,
is
still
unique
because
remember
captain
is
an
event
driven
system.
That
means
you
can
really
plug
in
any
type
of
monitoring
data
source
or
any
type
of
data
source.
Because
captain,
when
you
ask
captain
to
evaluate
a
quality
gate,
it
basically
sends
out
an
event
and
says
hey.
I
need
this
data
from
you
now.
What
is
this
data?
A
As
a
user
of
captain
you
upload
or
you
specify
in
a
yaml
file?
What
are
your
slis
and
these
are
done
by
a
data
provider,
so
there's
an
sli
file
for
prometheus
one
for
dyna
traits
from
from
near
tis,
one
for
whatever
other
tool
you
have,
and
it
specifies
an
indicator
name
like
error
rate
and
next
to
it
a
tool
specific,
let's
say:
query
language,
then
you
specify
slos.
A
This
is
now
independent
of
the
monitoring
tool.
This
is
something
the
lighthouse
does
where
you
can
specify
your
pass
and
your
warning
criteria,
and
you
also
specify
a
total
score,
because
what
captain
does,
if
you
ask
captain,
please
evaluate
the
quality
gate
for
me
for
a
particular
time
frame.
So
this
is
actually
the
captain
cli.
That
shows
you
how
you
would
just
execute
this
piece
of
the
process,
not
the
whole
delivery,
but
maybe
just
the
quality
gate.
So
that's
why
you
can
also
integrate
this
into
your
existing
pipelines.
A
So
then
captain
sends
an
event
and
say
I
need
the
quality
gate.
I
need
the
slis
and
then
all
the
tools
that
want
to
participate
send
back
the
results
and
once
that
is
done,
captain
analyzes.
It
compares
it
against
the
slos
grades.
Every
metric
gives
it
the
either
one
point
if
it's
good,
if
it's
past
half
a
point,
if
it's
warning
and
zero
points,
if
it
fails,
but
you
can
also
change
weights.
A
So
that's
the
default
weight
of
one,
but
you
can
also
say
a
certain
metric
is
more
important
and
you
can
also
specify
key
metrics.
So
you
can
say
number
of
database
calls
is
the
most
important
metric
or
response
time,
and
if
this
fails,
the
rest
should
fail.
But
in
the
end,
what
captain
does
it
returns?
A
total
score
between
zero
and
one
hundred
percent
and
one
one
way
we
did
it,
so
we
have
it
available
for
prometheus
for
neotus.
A
As
I
said
I,
during
the
day
I
work
at
dynatrace,
so
I
want
to
quickly
just
show
you
how
we
did
this
with
dynatrace.
You
just
build
a
dashboard,
put
all
of
your
metrics
on
it
that
you
would
normally
manually
look
at,
but
then
captain
is
pulling
these
metrics
fully
automatically
and
then
calculates
that
score.
So
that
means,
if
I
go
back
to
my
example
here
by
the
way,
build
number
four
now
made
it
all
the
way
through.
Remember
build
number
four
made
it
in
staging.
A
A
Is
that
captain,
basically
automated
this
process
me
normally
looking
at
the
dashboard
with
a
bunch
of
key
metrics
from
my
infrastructure,
from
my
from
my
services
from
my
transactions,
whatever
you
can
put
whatever
you
want
on
it,
and
then
you
specify,
if
I
zoom
in
here,
a
little
bit
on
every
tile.
What
is
your
pass
and
warning
criteria?
A
You
can
also
specify
different
weights.
As
you
can
see
here,
you
can
make
individual
metrics
a
key
transaction,
and
then
you
can
also
specify
overall
pass
and
warning
criteria
and
also
how
you
want
to
compare
builds
if
you
want
to
compare
just
with
one
previous
build
with
multiple
previous
builds.
What
type
of
compare
function
so
you
can.
You
could
really
go
crazy
here,
but
this
is
basically
where
my
data
comes
from.
Captain
pulls
it
in
evaluates
it,
and
now
tells
me
this
would
be
ready
to
go.
I
can
also
go
to
the
environment
view.
A
Remember
here:
def,
staging
and
prod,
so
in
prod
we
have
build
number
three
right
now.
Remember,
I
think
still
the
case,
if
I
refresh
yes,
but
now,
because
my
quality
gate
went
through,
I
can
also
see
it
here
with
the
results.
I
can
now
say:
yes
go
off
and
and
and
deployed,
and
now
the
process
continues,
because
you
know
captain
continues
sending
out
these
events.
A
So
the
great
thing
about
this
is,
I
believe,
right.
This
quality
gate
is
is
very
or
this
slo-based
approach
is
engrained
and
kept
and
everything
captain
does
part
of
delivery,
but
you
can
also
execute
it.
Stand
alone,
stand
alone.
Here's
an
example:
I
have
a
different
project
that
is
called
quality
gate
and
I
typically
just
use
this
from
a
jenkins
pipeline
all
right.
So
here
you
can
see
that
this
process
was
actually
triggered
by
jenkins.
A
I
had
a
jenkins
build
that
was
deploying
something
and
then
running
a
test
and
then,
when
whoever,
whichever
tool
triggers
a
captain
process,
can
also
send
metadata
like
it
was
build
123.,
it
was
this
jenkins
job.
Here's
the
url
back
to
my
jenkins,
and
then
you
see
here
this
process
is
very
small
compared
to
the
other
one,
because
it's
just
retrieving
the
metrics
and
then
it's
giving
me
a
result.
A
So
that's
also
you
can
you
can
use
this.
You
see
every
time
a
build
was
executed
or
a
quality
gate,
and
if
I
go
back
then
obviously
here
we
see
for
every
single
for
delivery
in
every
stage.
What
was
the
final
result
of
the
quality
gate?
We
also
see
it
here
and
yeah.
Now
this
is
going
on,
configuration
has
changed,
and
now
the
deployment
should
have
many
second
and
they
should
hopefully
then
make
it
into
into
production.
A
That's
been
deployed
now
that
means
now
improv
build
number
four
is
in
broad
now
florian
again
to
your
question,
I'm
doing
a
blue
green
deployment
here.
This
is
what
I
specified
in
my
shipyard.
That
means
my
helm
service
is
actually
has
initiated
when
I
initially
onboarded
it
created
a
canary
deployment
with
a
virtual
service
using
istio.
So
it's
now
deploying
broad
it's
now.
A
It's
now
observing
how
it's
doing
and
then
calls
a
quality
gate,
evaluation
and
based
on
that
result
is
either
switching
back
or
keeping
it
in
now
build
number
four
has
some
built-in
problems.
That
means
I'm
actually
expecting
it
to
roll
back,
but
this
is
also
to
your
question.
Can
we
use
this
for
evaluation
of
blue
greens
or
canaries?
Yes,
absolutely,
and
I've
also
had
people
asking
me.
How
does
this
work
in
with
tools
like
argo
or
spinnaker?
Can
you
also
use
this?
Of
course
you
can?
A
A
That
means,
if
you
have
a
look
at
our
captain
sh
and
if
you
go
to
our
docs
and
then
there
is
the
install
and
I
think,
under
the
install,
you
should
have
all
of
the
instructions
here
right
on
how
to
how
to
run
it.
We
tried
to
do
a
good
job
with
keeping
the
documentation
up
to
date.
Another
cool
thing
is
the
tutorials
there's,
also
a
complete
tutorials
page
here,
and
there's
also
instructions
on
openshift.
So
you
can
tell
your
friend
that
this
works
all
right.
A
So
let
me
let
me
cover
the
last
topic.
Oh
yeah,
another
example
actually
for
the
quality
gates.
Remember
a
cool
use
case
is
you're
using
gitlab,
for
instance,
for
your
whatever
you
have
for
a
deploy
test,
and
then
it's
very
easy
to
just
integrate
captain
quality
gate.
So
this
is
why
we
right
we
give
you.
I
know
we
captain
can
do
a
lot,
but
essentially
what
it
does
it
orchestrates
processes,
around
delivery
and
all
and
operation
automation,
and
the
nice
thing
is.
A
You
can
also
pick
out
an
individual
piece
of
this
process
and
then
integrate
it
into
your
existing
tools
that
may
already
own
the
implant
process,
or
you
can
flip
it
around,
and
you
can
say,
captain
should
own
the
end-to-end
process
and
then
call
and
trigger
individual
tools
that
do
an
individual
job
pretty
well,
and
you
can
stick
with
the
tools
that
you
like
and
with
this
with
captain,
slowly
kind
of
automate,
more
and
more
things
all
right.
Last
section.
A
By
the
way,
if
people
have
questions,
please
use
the
q
a
feature
the
last
one
I
just
quickly
glance
over
it.
We
have
also
built
captain
for
automating
operational
tasks,
because
we've
seen
a
lot
of
organizations
spending
a
lot
of
time
in
manual
troubleshooting
and
remediation
of
problems
in
production.
A
To
solve
this,
we
also
just
apply
the
same
event
driven
or
srv
driven
remediation
workflow,
which
means
you
can
use
captain
and
let
your
monitoring
tool
or
whoever
in
your
in
your
infrastructure,
whatever
tool,
is
detecting
a
problem.
Send
this
problem
to
captain,
like,
in
my
case,
conversion
rate,
dropped,
root,
cause
cpu
pressure.
A
What
you
can
then
specify
in
captain.
Besides
the
shipyard
that
I
showed
you
earlier
for
delivery,
you
can
also
specify
a
so-called
remediation
workflow
for
order
remediation.
It
looks
something
like
this
where
you
say
for
a
particular
problem.
I
want
to
execute
this
action
and
then
another
action.
So
what
captain
does
it
says
all
right?
I
have
a
remediation
workflow
for
this
particular
problem.
First
action
is
scale
up
so
remember
what
captain
does
it
sends
an
event
and
whatever
tool
you
have
plugged
in
can
then
execute
direction.
A
So
we're
using
the
same
evaluation
concept,
but
then
captain
sends
in
events
to
your
monitoring
tools
and
say:
hey,
first
of
all,
I'm
interested.
Do
you
still
see
the
problem
open?
So
if
your
monitoring
tool
keeps
track
of
problem
status,
he
will
always
ask
it,
but
then,
additionally,
it
says
any
other
additional
slice
and
slows
you
want
to
validate.
A
If
it's
good
great,
if
not,
it
continues
the
workflow
and
triggers
the
next
action,
then
reevaluates
and
hopefully
everything
is
good.
If
not
the
last
step
might
be
escalate,
it
could
be
an
escalation
step.
So
this
is
great.
I
think
a
lot
of
people
would
love
this,
but
then
a
lot
of
people
fear
that
this
is
really
dangerous.
If
we
do
this
fully
automatically
in
production,
and
then
I
say
yes,
it
might
be
dangerous,
but
I
think
what
the
real
thing
here
is.
A
This
is
code
advancing
production
and
I
think
every
code
that
ends
up
in
production
should
be
tested,
and
this
is
why
I
really
like
the
integration
that
we
have
with
tools
like
litmus
litmus
chaos,
engineering
or
gremlin
or
chaos
monkey,
because
you
can
actually
do
test
driven
operations.
Now,
because
the
idea
is,
if
you
in
a
pre-prod
environment
can
let's
say,
execute
some
loads
to
simulate
some
production
traffic
and
then
enforce
chaos.
A
The
first
thing
you
can
do
you
can
validate
your
monitoring
and
alerting
works
correctly,
and
then,
if
you
send
it
to
captain,
then
with
captain,
you
can
actually
then
start
defining
and
refining
your
workflows,
your
remediation
workflows
and
actually
figure
out
in
a
pre-product
in
a
safe
kind
of
test
environment.
Does
my
remediation
process
and
all
the
code
that
sits
in
these
actions
actually
work
or
not.
A
A
A
We
are
using
as
much
declaration
as
possible.
Obviously,
as
you
saw
where
the
process
is
in
configuration,
everything
is
stored
in
git,
it
slows
our
centerpiece
to
whatever
we
do.
We
always
validate
that
every
action
we
take
is
still
making
sure
your
systems
operate
under
your
success
criteria
and
everything
is
based
on
standards.
Why
we
built
it?
If
you
remember
the
first
slide
that
I
ahead,
we
know
that
a
lot
of
you
out
there
are
trying
to
find
out
what
is
the
next
delivery?
A
A
You
can
get
started
with
our
tutorials
that
I've
shown
you
earlier,
but
there's
also
a
lot
of
more
content
and
also
a
slack
channel
that
you
can
see
here
on
that
slide
and
I've
used
up
almost
all
the
hour,
but
I
still
have
a
couple
of
minutes
left.
So
I
want
to
say
first
thanks
for
cdf
to
give
me
that
space
to
talk
about
captain
the
event
dream
approach.
B
A
A
B
A
So
whenever
they
change,
then
these
changes
can
trigger
captain
to
then
make
sure
that
all
of
the
right
tools
are
getting
triggered
to
then
make
sure
that
what
you
want,
what
you
declared
and
get
is
actually
applied,
and
I
think
that's
the
that's
why
it's
not
mutually
exclusive.
I
think
it's
a
perfect
match
and-
and
that's
and.