►
From YouTube: Introduction To Keptn // DoK Talks #80
Description
https://go.dok.community/slack
https://dok.community/
With:
Brad McCoy - Head of Cloud Engineering, Moula
Adam Gardner - Automation Architect, Dynatrace
Bart Farrell - Presenter
ABSTRACT OF THE TALK
Keptn is an event-driven orchestration platform with SRE best practices (declarative pipelines, quality gates and automated remediation) available "out of the box". This talk will be an introduction to Keptn, the core usecases and Keptn in the wider IT ecosystem
BIO
Brad started his career as a Software Engineer at TripAdvisor and then got into DevOps and moved into Fintech where he led the Cloud Engineering Innovation team at Temenos. Brad is an advocate for cloud-native and open source technologies. He contributes to the CNCF Security Technical Advisory Group. He also runs the GitOps working group for Ortelius a project of the CD Foundation.
Adam is an Automation Architect and Keptn contributor with a hint of Java development and Search Engine Optimisation. SCUBA diver and craft beer drinker. Not all at the same time.
A
A
Us
out
there,
and
but
most
importantly,
this
is
your
time
to
be
to
be
sharing
with
us,
your
your
doubts,
your
curiosities,
your
interests,
etc.
So,
please
feel
free
to
ask
questions.
You
can
always
ask
questions
here
in
the
chat.
We
can
continue
the
conversation
later
on,
in
slack
just
a
quick
reminder,
because
I've
been
saying
this
a
lot.
A
We
have
our
cfp
open
for
our
kubecon
collocated
event
that
will
be
on
october
12th
and
you
are
all
invited
registration
is
now
open,
but
I'll
leave
a
link
here
for
the
cfp.
In
case,
you
would
like
to
submit
a
talk
if
you
want
to
submit
a
talk,
just
two
basic
criteria:
it
needs
to
be
focused
on
writing,
stable
workloads
on
kubernetes,
all
right
databases,
operators,
all
that
good
stuff,
and
we
want
it
to
be
incorporated
and
end
user
focus
all
right
to
avoid
just
strict
vendor
pitches.
A
A
C
Awesome,
muted,
I'm
adam
gardner,
I'm
day.
Job
is
an
automation
architect
at
at
diner
trace
and
in
my
spare
time
and
for
fun,
I
guess
you'd
say
I
helped
contribute
to
the
captain
community,
which
is
what
we're
here
to
talk
about
today.
Fun
fact
he
put
me
on
the
spot
there
I
do
like
scuba
diving,
as
I
put
in
my
bio,
and
I
guess
the
fun
fact
is
after
two
years
of
working
remotely,
I
still
can't
figure
out
how
to
unmute
myself
on
a
zoom
call.
A
C
A
B
B
Sure
so
my
name
is
brad
mccoy,
I'm
head
of
cloud
engineering
at
mueller
and
that's
in
melbourne,
australia,
I'm
actually
living
in
new
zealand.
At
the
moment,
though,
and
yeah
I'm
here
today-
adam's
been
mentoring
me
in
captain,
so
we're
almost
doing
a
bit
of
a
world
tour
around
communities
so
we're
starting
with
dark,
which
is
my
favorite
one
by
the
way
and
then
we're
the
second
one.
We
will
go
to
the
cncf,
islamabad,
nice
and
then
doing
a
bit
of
a
world
tour
around
the
communities.
B
Talking
about
captain
learning
a
lot
of
cool
stuff
on
the
way
meeting,
some
cool
people
so
yeah,
it's
good
to
follow
us
on
the
adventure
and
fun
fact.
I've
probably
been
in
the
doc
community
for
about
maybe
eight
months
a
year
and
brad-
and
I
probably
talk
once
a
week-
and
this
is
the
first
time
we're
actually
speaking
or
let
own
video
so
yeah.
So
it's
really
exciting
to
be
here
and
yeah.
A
For
sure,
for
sure,
for
sure
very
good
point
said:
that's
your
brad
is
a
is
a
dok
is
a
doc
veteran.
I
mean
if
we
think
about
it.
We've
been
around
for
for
just
over
a
year
and
you've
been
very,
very
active,
and
I
think
that's
it's
just
a
nice.
It's
a
nice
way
to
sort
of
show
that
the
spirit
of
community
and
all
the
different
people
that
I've
met
because
of
you,
people
that
we've
interacted
with
together
in
the
community.
That's
been
very
good.
I
will
also
say
a
fun
fact
about
brad.
A
A
B
Yeah
sorry
adam
works
for
diane
trace.
I
I've
been
I'm
a
big
fan
of
donald
trace
as
well,
so
we
we
meet
through
mutual
friends.
It
they
have.
A
conference
called
perform,
go
so
we
we
met
there
and
then
yeah.
We
just
we're
big
in
sort
of
the
sre
space
as
well,
so
three
mutual
friends
of
diana
trace
and
then
just
now
in
different
communities,
so
adam's
and
captain
I'm
in
ortillius
and
we're
actually
looking
at
joining
them
together
as
an
integration
piece
as
well,
which
is
quite
exciting.
B
C
A
B
A
B
A
C
Yeah,
it's
really
interesting
actually,
because
day
to
day
those
terms
are
very
fluid
and
I
find
that
they
mean
whatever
people
want
them
to
mean
in
a
lot
of
ways.
People
have
sort
of
just
given
themselves
sre
or
devops
title
in
the
role
but
yeah.
I
think
the
industry
needs
help
defining
that,
but
but
I
think
brad
would
be
the
best
one.
To
I
mean:
that's
your
role,
isn't
it
brad?
So
it's
it's
in
it's
it's
an
evolving
space.
Let's
put
it
that
way.
Yeah.
C
A
So
that
everyone
understands
that,
like
how
we're
talking
about
it
today,
you
know
there
are
sre
principles.
They
talk
about
these
pillars.
We
talk
about
things
like
that,
but
is
something
that's
still
evolving.
You
know,
devops,
you
could
say,
is
still
evolving
in
some
regard,
although
it's
something
that
we've
been
hearing.
B
B
I
think
in
a
lot
of
the
google
books
that
they
bring
out,
they
say
that
sre
implements
devops,
so
that
that's
quite
a
big
thing,
if
you,
google,
that
sre
implements
devops
and
that
will
give
you
quite
a
good
understanding
of
those
differences
of
what
they
are.
Those
two
are
for
me.
You
know:
site
reliability,
engineering,
it's
not
about
putting
out
fires
and
then
not
fixing
the
issue
and
band-aid
fixing
it.
So
you
want
to
be
it's
about
making
tomorrow
a
better
day.
So
the
incident
comes
up.
B
You
see
the
incident
and
instead
of
just
fixing
it
you
want
to
improve
it.
So
it
doesn't
happen
again.
So
so
that's
the
difference.
It's
that
automation
and
that's
where
I
see
captain
coming
into
that
as
well,
because
you'll
notice
there's
a
lot
of
or
pronounced
captain.
But
it's
almost
like
an
automated
engineer.
That's
doing
these
tasks
for
you
as
well,
so
yeah,
it's
an
exciting
new
space
that
well,
it's
probably
not
new
anymore,
but
there's
a
lot
of
opinion
about
it
and
yeah.
B
That's
sort
of
my
take
on
sre
and
I
thought
just
before
we
start
as
well.
I
think
there
might
be
a
little
bit
of
glossary
so
that
could
we
need
to
talk
about
slas,
slos
slis,
so
they'll
probably
come
up
in
today's
talk.
So
sla
is
the
agreement
you
make
with
your
clients
or
users.
So
let's
say
I'm
going
to
tell
the
doc
community
that
my
microphone
will
be
99
working
on
this
talk
and
then
you
have
slo,
which
is
the
objective
your
team
must
hit
to
meet
that
agreement.
B
So
adam
will
talk
a
lot
about
the
slos
today
because
that's
a
big
part
of
the
captain
and
it's
allies,
the
the
real
numbers
of
your
performance,
so
the
service
little
level
indicators.
So
if
anyone
throughout
the
talk
needs
a
bit
of
us
to
explain
that
more
just
please
let
us
know,
because
if
you're
starting
off
it
can
be
a
little
bit
confusing
with
all
those
s's
going
around
for
sure
for.
A
Important
to
sort
of
unpack
those
to
get
a
better
idea
about
about
what
the
differences
are,
what
why
those
are
important
as
well,
the
one
thing's,
the
one,
the
hell,
but
also
the
white,
so
anyway,
we
can
get
onto
that
on
the
go.
That
being
said,
yeah,
if
you
wanna,
I
don't
know.
If
one
of
you
wants
to
share
your
screen,
we
can
start
the
presentation
if
you're
ready.
C
Okay
and
the
obligatory,
let
me
know
when
you
can
see
it
perfect,
cool,
okay,
so
yeah
today
we're
going
to
talk
a
brief
introduction
about
captain
pronounced
captain,
not
captain
the
reason
it's
called.
That
is
because
that
is
the
german
phonetic
pronunciation
of
captain
and
sticking
with
the
whole
kubernetes
and
containers
and
the
nautical
theme
the
original
developers
of
the
project
thought.
Well,
let's
stick
with
the
nautical
theme
and
call
it
captain.
So
I'm
still
waiting
for
my
captain's
hat
jurgen,
just
a
shout
out
there,
but
there
we
go.
C
What
is
what
is
captain
and
why
would
you
consider
using
it?
So,
as
brad
said,
and
as
I
experience
on
a
day-to-day
basis,
there
are
a
lot
of
different
ways
to
do
things
and
what
we're
trying
to
do
is
give
you
a
helping
hand.
Basically,
so
it's
an
event-based
control,
plane
warning
a
lot
of
buzzwords
in
this
and
I'll
unpack
these
as
we
go
through,
but
it's
an
event-based
control
plane
for
continuous
delivery
and
automated
operations.
C
Basically,
what
that
means
is
we're
trying
to
build
a
tool
that
gives
you
sensible,
defaults
and
some
core
capabilities
out
of
the
box,
so
think
about
modeling
pipelines.
Think
about
how
do
I,
between
the
stages
of
my
as
my
application,
goes
from
dev
to
staging
to
production?
How
do
I
ensure
quality
of
those
microservices?
How
do
I
prevent
the
microservice
going
from
dev
to
staging
or
staging
to
production
if
it
is
not
sufficient
quality?
How
can
I
put
a
gate
in
there
to
actually
prevent
that,
and
once
it
is
in
production?
C
How
can
I
actually,
if
an
issue
does
go
wrong?
How
can
I
again
have
some
sort
of
magic
tool
to
roll
that
back?
If
it
goes
wrong,
how
can
I
fix
that
application
in
production,
so
some
of
the
guiding
principles
of
captain
are,
it
must
be
open
and,
of
course,
captain
is
open
source,
but
what
we
mean
by
that
actually
is
that
it's
open
to
other
tooling
captain
isn't
prescriptive.
C
Deliberately
so
isn't
prescriptive
in
what
tooling
you
are
using.
You
are
going
to
be
using
your
best
fit
tooling,
for
whatever
you
and
your
company
think
captain
is
not
going
to
come
across
and
say
that's
wrong.
You
must
use
x,
y
or
z
instead,
in
fact,
captain
does
the
exact
opposite
and
it
says
bring
your
own
tooling
and
we
will
work
with
it.
C
Everything
again
must
follow
a
guitar
approach,
another
buzzword,
but
basically
what
we're
saying
here
is
every
change.
The
captain
makes
must
be
stored
in
ultimately
in
a
git
repository
as
the
source
of
truth
and,
as
I've
said
you'll
see
this
later
on,
but
we're
going
to
give
you
some
guide
rails
for
devops
and
sre
in
terms
of
sensible
defaults
for
things,
but
also
pre-built
capabilities
like
the
quality
gates.
C
So
there
are
three
core
use
cases
for
captain
and
the
first
one
actually
starts
before
you've,
even
onboarded
your
application.
So
you
know
as
a
good
engineer,
devops
or
sre
engineer.
You're
gonna
need
observability
of
that
application,
so
captain
will
actually
go
ahead
and
set
up
your
monitoring
and
observability
for
you.
It
will
create
all
of
the
necessary
bits
of
configuration
if
necessary,
it
will
create
the
alerts.
It
will
create
dashboards
so
that
when
you
do
start
onboarding
your
application,
you
have
visibility
on
day.
One.
A
C
That's
an
excellent
question,
usually
a
bit
of
of
everyone:
they're,
typically
technical
people
start
thinking,
they're
technical
metrics,
but
actually
better
quality,
slos,
really
focus
on
the
user
contract,
the
user
experience
so
think,
front
end
and
again
there
are
books
written
on
this
topic
and
there
are
whole
conferences
about
slos,
but
as
if
you're,
just
starting
out
think
about
what
you're
trying
to
achieve
with
that
micro
service.
So
if
it's
a
a
shopping
basket
api,
what
are
the
common
things
that
you
want
to
achieve?
C
Folk
start
your
journey
there
and
then
expand
from
there
if,
if
you're,
starting
with
things
like
cpu
and
memory,
consumption
you're,
probably
not
in
the
right
ballpark,
if
that
makes
sense,
because
they're
more
they're,
important
metrics
but
they're,
not
necessarily
technical
metrics,
because
they
don't
necessarily
correlate
to
a
user
impact,
they
might
but
yeah
try
and
focus
initially,
at
least
on
the
user,
impacting
items
very,
very
good.
Thank
you.
C
Cool
so
the
third
use
case,
as
I
said
now,
we're
shifting
into
production.
So
imagine
your
microservice
has
made
it
all.
It's
all
its
way
through
the
pipeline
and
you're
running.
Quite
happily,
and
then
you
have
a
problem.
So
two
things
you
need
here.
You
need
an
alert
or
a
problem
source
from
somewhere
and
you
need
to
provide
captain
with
a
remediation
sequence
and
basically
that
remediation
sequence
defines
what
happens
when
you
receive
this
problem.
C
C
I
know
to
trigger
a
scale
up
of
the
pods,
for
example,
then
captain
will
wait
a
little
while
and
it
will
evaluate
the
slos
that
you
again
that
you've
defined
previously
and
captain
is
basically
with
that
saying-
has
the
scale
up
fixed
the
problem
and
if
so,
of
course
everything
is
fine,
the
problem's
remediated
and
if
not,
what
is
next
in
my
remediation
sequence,
do
I
do
another
scale
up
event?
Do
I
do
something
else?
Do
I
escalate
it
to
and
create
a
ticket?
What
is
the
kind
of
workflow
involved
with
that?
A
No,
I
think,
yeah
thinking
about
that.
Once
again,
is
that
in
in
seeing
this
I
mean,
and
also
just
for
a
timeline
sake,
how
you
know:
how
long
has
it
been?
How
long
has
you
know
captain
been
going
on
as
a
project
and
in
what
would
have
been
those
sort
of
learnings
from
seeing
this?
Because
one
thing
is
the
initial
idea
of
this.
A
A
C
Yeah
we
started
so
the
project
started,
I
think
two
years
ago,
if
I'm
not
mistaken
and
we
started
with
a
very-
we
tried
to
be
quite
prescriptive
in
the
way
that
we
opinionated,
I
guess
is
the
word.
So
we
tried
to
say
right.
This
is
how
you
should
work,
but
actually
the
the
feedback
from
the
community
has
been
that's
great
and
they're
great
for
guide
rails.
C
But
of
course
everyone
wants
much
bigger
flexibility
in
that.
So
just
in
the
latest
release
of
captain
0.8,
we've
we've
expanded
that
greatly,
so
that
you
can
basically
create
your
own
sequences
and
you
can
really
really
be
flexible
in
what
captain
is
doing
and
when
it
is
doing
it
and
how
things
are
triggered.
So
that's
kind
of
the
biggest
piece
of.
C
Cool
so
yeah
yeah.
I
said
at
the
beginning
that
captain
is
bringing
your
own
tooling
and
obviously
that
that
begs
the
question
of
well.
How
does
that
actually
work?
How?
How
can
we
have
such
a
flexible
mechanism
that
allows
just
any
tool
to
kind
of
plug
into
it?
So
three,
there
are
three
kind
of
logical
layers
to
this:
the
captain
control
plane,
which
is
kind
of
the
central
brains,
the
api
layer.
C
It's
all
the
you
know
it
holds
the
definition
of
the
environment
and
then,
on
the
right
hand,
side
you've
got
your
tooling.
So
this
is
the
execution
plane,
and
this
is
where
your
two
language
now
that
can
be
kubernetes
based
of
course,
or
it
can
actually
be
non-kubernetes
based.
So
in
that
respect,
if
you
had
a
service
that
was
listening
to
the
api,
you
could
you
can
use
this.
You
can
use
captain
without
kubernetes.
C
The
control
plane
still
needs
to
be
deployed
on
kubernetes,
but
but
the
execution
planes
can
live
outside,
but
in
any
case,
the
the
glue
that
sticks.
These
together
are
open
source
cloud
events,
so
everything
that
happens
in
captain
is
basically
a
cloud
event
that
that
gets
triggered
and
they
have
a
certain
syntax
and
it
is
obviously
sh
captain
event,
whatever
event
triggered
and
now,
of
course,
there
is
a
life
cycle
where
the
events
say
started
in
progress
finished.
So
that's
the
responsibility
of
your
services.
C
A
C
C
So
skipping
back
now
that
we've
got
a
kind
of
view
of
of
how
captain
is
working,
the
automated
observability,
that
is,
the
command
that
you
run.
Obviously
the
captain
cli
to
configure
monitoring.
So
you
say:
captain
configure
monitoring,
prometheus
dynatrace,
whatever
tool
that
you
bring
again,
we
can
work
with
any
observability
or
monitoring
tool
in
the
case
of
prometheus.
What
captain
will
then
go
and
do
is
start
configuring
prometheus
for
monitoring
services,
managed
by
captain
it
will
configure
grabbing
the
alerts
from
alert
manager
translating
those
alert
payloads
into
the
open
source
cloud
event.
C
C
So
the
next
use
case
the
multi-stage
delivery
with
quality
gates.
Basically
every
you
start
captain
with
a
shipyard
file
again
staying
with
the
nautical
theme.
A
shipyard
file
defines
your
stages
and
they
are
analogous
to
your
pipeline
stages,
your
sequences,
which
are
broad
sequences
of
tasks,
and
then
obviously
you
have
tasks.
C
C
So
these
again
are
broad
sequences
of
things,
so
you
might
have
a
deployment
sequence,
for
example,
and
then
within
the
sequences
you
have
tasks
so
task,
one
task,
two!
So
in
my
deployment
I
might
do
a
generating
load,
run
a
test,
evaluate
my
deployment
and
so
on
and
so
forth.
They
would
be
at
the
task
level.
C
A
A
C
C
So
you
need
three
things
for
the
captain:
quality
gates
and
the
quality
gates
themselves
are
actually
pre-built
into
captain,
so
you
get
that
kind
of
for
free,
as
you
install
captain.
So
the
first
thing
you
need
is
an
sli,
an
indicator
provider,
and
that
is
basically,
where
are
my
metrics
coming
from
so
prometheus
dynatrace,
whatever
source
the
metrics
are
coming
from,
then
you
need
to
tell
captain
how
to
interact
or
what
those
sli's
are.
C
So
in
this
case,
we've
defined
two
we've
got
a
50th
percentile
and
the
90th
percentile
and
you'll
see
here
that
this
is
prometheus
this.
So
this
is
basically
telling
captain
how
to
retrieve
those
metrics
from
prometheus.
Now,
of
course,
this
will
be
different
syntax,
depending
on
your
tooling
provider.
C
Then
you
go
ahead
and
create
an
slo
definition
which
says:
okay
in
my
slo,
I'm
gonna
have,
in
this
case
one
indicator.
My
90th
percentile
response
time
now,
if
captain,
if,
when
you
retrieve
this
metric,
if
it
is
less
than
or
equal
to
plus
10
and
I'll,
come
back
to
this
in
a
moment
and
an
absolute
value
of
less
than
a
thousand
milliseconds,
then
for
this
metric
it's
a
pass
if
it's
obviously
above
a
thousand
milliseconds
and
plus
10,
but
less
than
1200
milliseconds.
C
C
C
C
So
you
can
run
these
evaluations
on
demand
and
you
get
a
pass
warning
or
a
fail
and
you
get
a
percentage.
And
here
you
see
that
if
my
total
score
for
this
evaluation
is
above
90,
then
it's
a
pass.
It's
good
enough
quality
to
progress
to
the
next
stage
and
then,
of
course,
with
that
result,
you
can
use
that.
However,
you
see
fit,
you
can
use
that
in
other
pipeline
tools
like
like
jenkins
or
to
to
progress
the
build
or
fail
the
build,
and,
if
you're,
using
captain
to
manage
your
artifact.
C
C
B
A
This
might
sound
really
silly,
but
you
know
from
a
customer
perspective.
Would
someone
ever
say?
Well,
I
don't
percent,
I
want
a
percent,
you
know.
Why
am
I
you
know
my?
Why
am
I
paying
for
something
that
you're
you're
telling
me
is
going
to
fail
with
a
certain
degree
of
frequency?
How
do
you,
how
do
you
package
that
and
and
still
convince
someone
that
this
is
you
know
a
valid
technology.
B
If,
if
my
internet
provider
only
says
that
I'm
going
to
give
your
business,
let's
say
99.96,
you
can
never
be
truly
100
available.
So
I
I
guess
a
lot
of
it
comes
down
to
other
factors
that
aren't
your
business.
You
know
like
other
providers
as
well,
but
the
most
I've
heard
for
the
sla
I
think,
is
on
the
amazon
s3
bucket,
which
is,
I
believe,
it's
99.9
and
eight
nines
or
eleven
nines
of
availability,
which
is
quite
crazy
of
durability.
A
Here,
as
well
too,
is
that,
while
sre
is
very
much
a
technical
role,
there's
you
know
these
key
business
concepts
that
have
to
be
kept
in
mind
and
obviously
direct
contact
with
the
customer
and
having
you
know,
one
thing
is
to
understand
it,
but
another
thing
is
the
importance
to
be
able
to
explain
it,
put
it
in
simple
terms
and
show
them
what?
Because
you
know
it's
like
you
know,
why
am
I
gonna
buy?
You
know
a
product
that
that
you're.
B
C
A
B
B
Let's
say,
let's
say
you
do
a
crazy
marketing
campaign
for
black
friday.
You
you
put
strain
on.
Let's
say
database
calls
captain
can
then
as
a
remediation
process.
It
can
remove
that
future
flag
to
stop
that
stuff
as
well.
So
that's
actually
quite
a
good
use
case
for
for
captain
when
you're
doing
like
crazy
marketing
promotions
as
well.
C
However,
you
see
fit
so
yeah
to
your
point.
Brad
close
group
remediation
needs
three
things:
the
problem
event,
of
course,
from
captain
itself
or
a
third
party
provider
funneling
in
those
events,
and
then
you
bring
you
write
a
remediation
action
yaml
file
again,
and
basically
this
one
is
saying:
okay,
when
I
get
a
problem
type
of
response
time
degradation.
So
when
my
response
time
degrades
what
am
I
going
to
do
about
it?
C
Well,
I'm
going
to
toggle
a
feature
flag
and
I'm
actually
going
to
toggle
the
feature
flag
to
be
off,
so
I'm
going
to
disable
that
promotion,
because
for
some
reason
that
promotion
has
caused
an
issue
and
then,
of
course
you
need
a
tool
to
actually
kind
of
be
able
to
action
this,
because
captain
itself
isn't
a
a
remediation
provider.
So
you
bring
your
tooling
you
bring
whatever
you
want
service
now
unleash
helm
to
scale
things
or
whatever
tool
you
wanna.
You
wanna,
provide.
C
Again,
the
kind
of
workflow
of
that
you've
got
your
incoming
problem
into
captain's
control
plane,
and
this
is
kind
of
a
page
duty
aspect.
What
I
was
picturing
before
and
then
captain
sends
the
action.trigger
to
do
it.
Do
an
action
and
the
only
server
says
yeah.
I
know
how
to
do
that
action,
I'm
going
to
turn
that
feature
flag
off
as
an
example.
C
C
C
So
let's
have
a
look
at
the
litmus
project,
so
the
litmus
project
has
one
stage,
remember
the
stages
model,
your
dev
staging
of
production,
but
you
can
use
that
in
any
way
you
see
fit.
In
this
case,
we've
got
a
single
stage
that
we're
running
chaos
tests
in
and
if
I
flick
to
the
sequences
first
of
all
have
a
look
at
one
that
passed
so
what's
happened
here
is
someone
or
something
has
asked
captain
to
start
the
delivery
sequence.
C
C
And
there's
a
sequence
called
delivery
and
then
there
are
a
number
of
tasks,
deployment
with
some
properties
and
then
a
test
task
and
then
finally,
an
evaluation
task.
So
we
as
humans
would
say
to
captain.
Please
captain
start
the
delivery
sequence
in
the
chaos
stage
and
that's
exactly
what
you're
seeing.
C
C
Captain
sends
the
open
source
cloud
event,
which
is
basically
a
json
payload
and
the
event
type
is
deployment
triggered
and
if
I
drop
this
down,
you'll
see
that
actually
the
helm
service
is
listening
for
that
deployment
triggered
event.
The
helm
service
has
put
its
hand
up
and
says
yep.
I
know
how
to
do
a
deployment.
Let
me
go
away
and
do
that
and
then
helm
comes
back
and
says:
yep
I'm
passed.
I've
successfully
deployed
your
artifact,
then
flick
back
to
the
shipyard
file,
so
we're
done
with
the
deployment.
What
do
we
do?
Next?
C
We
do
the
test,
so
captain
automatically
knows
to
trigger
that
test.triggered
event
and
what
happens
there?
Some
other
tooling
puts
its
hand
up
and
says
I
I
know
how
to
do
a
test.
I
know
how
to
respond
to
that
event,
and
in
this
case
two
services
have
actually
put
their
hand
up,
so
you
can
have
multiple
services
listening
to
the
same
event,
so
you
can
build
really
really
complicated
workflows
with
any
tooling
that
you
provide
in
this
case
litmus
and
jamieta
have
put
their
hand
up
and
said.
C
C
So
the
lighthouse
service
is
something
you
get
out
of
the
box
with
captain
and
basically
that's
what
does
all
of
the
work
and
there
we
see
the
get
sli
and
there's
the
prometheus
sli
service
going
and
retrieving
the
metrics
from
prometheus
and
what
you
get
at
the
end
of
this.
You
can
see
the
evaluation
in
this
case
passed
and
we
got
a
score
of
100.
C
And
scroll
down
see,
these
are
my
metrics
that
I'm
looking
at
these
are
the
values
that
we
pulled
back
out
of
prometheus
and
these
are
the
criteria,
so
any
metric
less
than
200
milliseconds
in
this
case
is
a
past
and
of
course
we
we
met
that.
So
we
passed
and
we
got
a
score
and
everything
was
good.
So
here
you're
seeing
a
history
of
every
evaluation
that
captain
has
run.
C
You
see
the
result
of
each
individual
sli,
so
one
sli
can
fail
and
one
can
pass
and
then
but
then,
as
I
say,
captain
will
sum
that
up
and
give
you
an
overall
score
for
the
build
and
so
as
a
tooling
would
would
usually
respond
to
this
event.
So
it's
a
progress
or
failed,
build
you'd
be
looking
at
the
total
score,
but
as
a
devops
engineer
or
as
a
as
a
developer,
you
probably
want
to
know
what
houses
my
metric
on
this
evaluation
so
and
you
can
see
that
as
well.
C
C
A
You
know
installation
getting
everything
running.
You
know
particularly
we're
thinking
about
people
that
are
getting
started
out.
Obviously,
there's
a
community
to
support
this,
so
people
have
dallas
they
could
they
can
address
that
there?
What
seems
to
be
what
seemed
to
be
some
of
the
common
challenges
that
people
have
when
starting
to
work
with
something
like
captain.
C
A
Yeah,
I
suppose
this
is
supposed
to
be
getting
involved
in
catholics.
Yeah
brad's
experience
is
going
to
be
very
relevant
right.
Brad
is
as
a
you
know,
because
can
you
just
tell
us
about
when
you
started
using
it
and
the
things
that
you
found,
or
perhaps
you
didn't
take
into
consideration
or
different
experiences
that
you've
had
with
other
kinds
of
technologies
how's
that
been
for
you.
B
Yeah,
I
guess
when
I
started,
I
deployed
it
with
argo
cd
and
then
I
guess
one
thing
is
captain's,
quite
cli
focused,
so
I
would
almost
like
it
to
be
a
little
bit
more
declarative.
I'm
not
sure
if
that's
on
the
roadmap,
but
I
found
that
I
was
you
know
generally
I
like
to
have
everything
defined
and
get,
but
I
found
that
I
was
using
the
cli
a
little
bit,
not
not
too
much,
but
I
guess
there's
a
little
bit
of
cli
work
in
there
as
well.
B
I
I
guess
I'm
not
saying
that,
like
the
cli
is
really
good.
I
I
would
just
like
to
if
it
was
like
a
like
a
kubernetes
object,
where
you
can
just
deploy
that
yaml
for
everything
instead
of
having
to
run
the
cli.
Sometimes
maybe
you
even
can,
but
I
felt
that
there's
a
little
bit
of
cli
work
in
there,
but
I'm
sure
that's
on
the
roadmap
to
to
give
you
both
both
options
in
a
declarative
way.
Instead
of
imperative.
A
B
B
That
will
tell
you
a
lot
about
what
organizations
are
facing
like
what
problems
they're
having
and
they
talk
about
percentages
around
downtime
fixing
issues
that
kept
them
will
really
help
those
values
go
down.
So
in
terms
of
yeah,
it
just
really
gives
you
that
automation
and
not
having
to
manually
you
know,
ring
some
up
in
the
middle
of
the
night
and
it
takes
them
a
while
to
sign
onto
their
computer
and
and
and
find
these
issues.
It's
really
good
to
automate
those
issues
and
that
remediation.
A
B
A
A
Factor
but
then
the
other
thing
is
yeah.
If
you
had
it
three
in
the
morning,
you've
gotta
wake
up.
You
gotta
start,
you
know
addressing
something
on
unlimited,
you
know
amount
of
sleep
and
how
you're
going
to
be
able
to
calculate
things
having
something
that's
simplifying
those
processes,
I
think,
obviously,
is
doing
a
great
deal
of
good
in
a
technological.
A
At
the
most
inopportune
times
when
things
when
things
happen,
but
whether
it's
christmas
or
new
year's
or
any
one
of
these
other
special
days,
people
have
to
be
monitoring
that
and
perhaps
of
those
times
even
more.
When
there's
you
know
classic
example,
talking
about
downtime
and
also
chaos.
Engineering
is
a
netflix
example
where
I
believe
it
was
christmas
eve
and
shut
down.
You
know
all
of
a
sudden.
Everyone
has
to
talk
to
their
in-laws.
You
know
it's
like
a
terrifying
experience,
so.
A
A
The
database
reliability
engineer:
do
you
feel
that
a
lot
of
these
principles
in
terms
of
the
you
know
the
the
pillars
of
sre
when
we
talk
about
observability,
metrics
and
things
of
that
nature
and
also
slows
sli
slas
also
will
be
applying
to
there
is
a
book
about
dbre.
I
haven't
read
it
yet.
I
know
I
need
to,
but
do
you
imagine.
A
A
B
Yeah,
because
I
actually
listened
in
on
that,
because
that
was
one
of
my
my
interest
and
he
I
think
we
should
post
a
link
for
that,
because
he
he
described
that
very,
very
well.
I
think
I
even
commented
on
it
after
he
finished.
That
was
really
good
talk,
but
the
answer
is
yes.
I
I
see
that
that
it's
already
getting
into
that
that
data
space
as
well,
and
especially
when
we're
doing
you
know
we're
hearing
all
these
names
like
data,
ops,
ml,
ops,
it's
really
starting
to
integrate
or
shift
left.
B
If
you
like
into
that
those
other
teams
which
is
really
cool
to
see
yeah,
so
you
can
start
seeing
the
team
topologies
where,
instead
of
having
a
traditional,
just
a
data
like
data
engineering
team,
you
will
have
one
devops
engineer
on
team,
a
data
engineer
and
you
you're
doing
more,
like
domain
teams
opposed
to
just
you
know
traditional
use
of
the
data
guys
you
you
sit
down
on
that
side
of
the
office.
So
it's
really
good
to
see
the
collaboration
in
those
teams
and
the
new
ways
of
working.
A
Yeah
no
and
I
just
linked
the
talk
that
you
mentioned,
which
is
called
from
dba
to
sre,
showing
that
journey
of
going
and
so
and
that's
the
thing
is
like
there
is.
There
is
a
technological
side,
there's
also
the
responsibility
side,
there's
the
other
part
of
as
well
too,
that
I,
I
can't
stress
enough,
is
working
with
customers
and
and
having
to
take
that
into
account
and
it's
it's
something
that
I
don't
want
to
say
that
isn't
for
everybody
and
it's
something
that
can
be
learned.
But
it's
something!
That's
that's!
That's.
A
A
Paying
you
know
how
much
am
I
paying
you
like?
You
know
this
kind
of
mentality
that
that
will
come
up
going
back
to
to
to
captain
just
a
little
more
background
about
the
team
of
people
that
are
working
on
this,
because
I
think
it's
always
really
nice
with
open
source
projects
to
understand
more
about
the
makeup
of
the
folks
that
are
working
on
this
and
that
are
adding
value
that
are
making
captain
what
it
is.
Can
you
tell
us
a
little
bit
more
about
that
adam?
A
C
Yeah
so
it
it
originally
came
from
people
like
jurgen
and
andy
grabner,
and
but
now
really
it
is
open
source.
It's
across
the
world
and
one
of
the
core
captain
contributors
remain
people
like
jurgen,
you
know
been
there
from
the
beginning,
really
understand
the
core
concepts
of
of
what
the
core
of
captain
is,
but
as
you've
seen.
The
key
part
to
this
is
that
we
encourage
people
to
bring
their
own
tooling.
C
So,
for
example,
I
have
written
the
jira
service
that
hangs
off
the
side
of
captain,
so
anyone
can
contribute
their
their
service
and
their
tooling,
because
that's
the
whole
point,
no
one
can
be
an
expert
in
every
single
integration
of
every
tool.
So
it's
really
interesting
to
see
the
breadth
of
ideas
and
the
breadth
of
other
tooling
that
people
are
bringing
brad.
You
mentioned
argo
we've
seen
litmus
we've
seen
k-6
getting
involved.
There's
there's
a
lot
of
good
stuff
going
on.
B
I
I
think,
as
we
move
into
more
event-based
architecture,
you
know
with
microservices
over
monolithic.
I
think
it's
going
to
become
a
trend,
so
I
would
start
to
see
more
open
source
tools
actually
like
we
have
argo
events.
We
see
that
as
being
quite
a
trend
at
the
moment,
so
I
would
say
yes,
definitely
there'll
be
more
bring
your
own
tools
for
sure,
because
a
lot
of
people
don't
want
to
reinvent
the
world.
They
know
that
you
know
one
one
tool.
You
know
it's
very
good.
B
A
I
think
it's
a
great
point,
and
and
and
also
as
well,
because-
and
I
have
told
this
story
like
five
million
times
when
sometimes
when
people
get
because
of
having
so
many
different
tools,
I
think
it
kind
of
makes
people
open
their
eyes
and
see
from
different
perspectives.
We
actually
had
a
live
stream
this
week.
A
That
was
just
about
tooling,
but
the
speaker
prefaced
it
by
saying
I'm
looking
at
this
very
much
from
someone
as
someone
who's,
you
know
very
passionate
about
get-offs,
and
so
my
my
background
in
my
way
of
looking
at
things,
my
objectives,
you
know
thinking
about
that.
You
know
the
things
that
I'm
going
to
be
looking
for
are
going
to
be
based
on
on
on
this
sort
of
way
of
looking
at
things
and
obviously
other
folks
are
going
to
have
a
different
strategy.
I.
A
What
I've
also
find
interesting
about
tulane
and
precisely
what
came
up
in
that
session
was
the
emotional
attachment
that
sometimes
goes
on
to
tooling
and
and
seeing
very
large
battles
and
organizations
about
whether
it's
this
one
or
that
one,
and
sometimes
that
can
be
about
internal
power
struggles
and
things
of
that
nature.
Because
at
the
end
of
the
day
I
mean
they
are
they're
tools
and
they
can
be
very
nice.
But
I
don't
want
to
say
they're
just
tools,
because
people
work.
A
B
C
Yeah
so
split
that
into
two
kind
of
sides
to
this
the
core
and
then
the
tooling,
so
the
core
will
be
expanding
the
ability
to
further
split
out
the
control
plane
versus
the
execution
plane.
We
want
to
give
people
the
biggest
possible
flexibility
to
bring
their
own
tooling
and
use
that,
however,
they
see
fit.
So
is
that
one
execution
plane?
Is
it
multiple
execution
planes?
C
C
A
And
somebody's
asked
a
question
about
how
you
know
you
did
comment
on
that,
but
keeping
in
mind
the
other
established,
devops
automation
tools.
Is
there
anything
that's
kind
of
like?
Well,
we
see
where
this
is
going,
so
we
want
to
keep
that
in
mind
so
that
we
don't
because
we
don't
lose
a
competitive
edge.
Is
there
anything
in
particular
that
that
has
come
up
along
the
way
or
that
you're
keeping
in
mind
for
that
road
map?.
C
A
A
B
B
C
A
A
Can
be
difficult
and
also
very
often
involves
putting
you
know,
biases
aside,
and
you
know
trying
to
empathize
with
another
person
see
where
they're
coming
from
also
being
clear
about
object.
You
know
we're
talking
about
bands
like
having
been
in
bands
and
and
I'm
not
in,
I
haven't
continued
with
any
of
them.
They've
all
stopped
for
whatever
reason,
but
you
know
sometimes
it's
the
right
place,
but
the
wrong
time
or
you
know
the
right
people
and
the
mixture
doesn't
work
out
or
someone
ends
up
having
different
plans.
A
Person
is
the
easiest
way
to
get
involved
in
open
source
and
also
when
you're
dealing
with
folks.
You
know
just
in
captive.
You
probably
have
people
in
lots
of
different
time
zones,
which
makes
your
calls
probably
very
interesting
or
that
you
have
to
duplicate
it
anyway,
but
that's
sort
of
the
nature
of
it.
So
I
think
there's
a
lot
to
be
learned
from
that.
That's.
B
A
A
A
A
Welcoming
nature-
and
you
know,
and
also
once
again,
these
travel
times
we're
going
through
a
little
bit
of
kindness
goes
a
very
long
way.
I
think
it's
very
refreshing,
that's
why
these
open
source
spaces
make
it
so
easy
for
these
ideas
to
just
start.
You
know,
operating
and
and
gaining
traction
before
we
finish
adam
can
ask
one
other
question:
is
there
anywhere
we
can
find
recordings
of
your
music.
C
A
C
A
Work
this
out,
he
has
good
taste
in
music
and
I
think
that's
if
you
don't
have
good
taste
in
music,
you're,
probably
not
going
to
be
a
very
good
musician
or
you
could
be
a
good
performer.
But
but
in
the
sense
like,
I
think
also
it's
it's
interesting
is
that
you
know
the
more
music
that
you
listen
to
or
like
the
more
tools
that
you
interact
with
you,
the
broader
your
perspective
gets,
and
you
really
get
enriched
by
that
and.
A
That
there's
any
particular
kind
of
music
that
like
I
will
never
listen
to
there's
something
that
I
might
prefer
more
than
others,
but
I
think
every
kind
of
music
has
something
to
offer
you
in
the
same
way
that
a
tool
whether
you
like
it
or
not,
there's
something
good
in
that.
So
try
to
find
that
you
know,
and
don't
just
you
know,
harp
on
something
because
either
it's
popular
or
it's
not
popular
things
like
that.
I
think
there's
definitely
something
you
can
learn.
A
B
A
A
Gentlemen,
I
wish
you
the
best
of
luck
on
your
world
tour.
Adam
wish
me
luck
as
I
try
to
find
your
music
and
I'm
hoping
that
we'll
be
able
to
see
each
other
sometime
in
a
coup
con
in
in
the
us,
in
europe
and
in
australia,
new
zealand
and
anyway.
I
hope
you
both
enjoy
the
rest
of
your
day
as
I
am
starting
mine.
Thank
you
very
much.
It
was
great
having
both
of
you.