►
From YouTube: CD EVENTS AND KEPTN DEEP DIVE | Beaming Ortelius
Description
Microservices, CI/CD Trends, GitOps, and yes DevOps are the topics of this podcast. Hosted by the techies on the Ortelius Open Source Community Team.
A
B
A
So
if
you
want
to
contribute
to
the
hotels,
go
ahead,
github.com,
slash,
hotelier,
slash,
hoteliers
and
join
the
community
and
start
contributing,
and
today
we
are
talking
about
two
cool
projects
in
the
cd
and
the
cncf
ecosystem
is
cd
events,
and
thank
you
very
much
for
sending
the
wonderful
chef
for
me
to
me
today
on
cda
city
foundation.
I'm
talking
about
captain
the
project
that
I
like
most
so
today.
I
am
joined
by
brad
mcguire
and
also
the
andreas
grabner
he's
a
from
the
developer
advocate
at
the
diner
trace.
A
C
Yeah
at
the
moment
I'm
living
in
australia-
that's
where
I
am
at
the
moment,
heading
to
colombia
in
two
weeks
for
a
month,
so
I've
been
south
america
for
a
while
and
currently
I'm
actually
working
on
gsoc
for
the
captain
and
flux
integration,
which
is
going
really
well.
So
hopefully
we
can.
If
we
have
time
we
can.
I
can
do
a
bit
of
an
update
on
that
as
well.
A
D
D
We
are
doing
full
stack,
monitoring,
full-stick
observability
and
my
goal
is
to
really
figure
out.
How
can
we
enable
the
community
to
leverage
observability
data
or
data
from
app
stability
platform
better
than
just
putting
it
on
the
dashboard,
and
you
know
creating
alerts
out
of
it?
There's
a
lot
of
automation
involved.
I
speak
to
a
lot
of
the
devops
community
and
the
srv
community
and
yeah
prior
to
that.
I
worked
for
a
company
over
the
performance
engineering
for
eight
years,
so
I've
been
around
for
a
little
while
and
located.
D
I
am
in
linz,
austria
and
I
know
brady
said
you're
in
australia.
It
means
for
you
it's
winter
for
us
it's
summer
we
are
experiencing.
I
think
the
third
heat
wave
too
early
in
the
year
already
and
I'm
sweating.
So
if
I'm
sweating,
I'm
really
sweating,
because
no
air
condition
here
in
my
place,
but
yeah
that's
what
it
is.
Thanks
for
having
me.
A
Yes,
absolutely
absolutely
we
have
a
wonderful
place
like
austria
is
a
very
wonderful
place
for
tourism
and
all
this
kind
of
stuff
and
his
sweating
is
everywhere
like
we
have
to
experience.
37
38
degrees
centigrade
is
40
most
around,
so
sweating
is
everywhere
that
most
part
of
the
globe.
You
see
a
lot
of
the
sweating
where
you
try
to
talk
to
the
people
about
the
internet.
A
So
thank
you
very
much
for
joining
and,
let's
introduce
you
dive
a
little
bit
about
like
what
the
captain
is,
because
I
see
this
tool
has
a
wonderful
two
parts
like
it's.
It's
able
to
understand
what
the
for
the
devops
people
is
and
for
the
sre
people
as
well.
Like
I
see
some
of
the
things
it's
giving
us
like,
auto
remediation,
auto
observability
delivery
and
best
practices,
slo
sli's
and
all
these
things
are
wonderful
for
people
who
are
really
into
that
space.
A
D
D
We
used
slack
for
notifications
and
then
we
actually
tried
to
build
an
end-to-end
delivery
pipeline
that,
after
every
state
you
know
is,
you
is
looking
at
observability
data.
Trying
to
figure
out
did
the
deployment
work
after
the
tests
were
executed.
Did
the
test
execution
was
that
successfully
did
we
include
any
regression
from
the
previous
build,
sending
our
notifications,
and
then
we
tried
to
do
the
same
thing
using
tools
like
ansible
tower
for
all
the
remediation
meaning.
D
D
Captain
I
think
now
is
solving
two
major
problems.
First,
observability
is
in
the
driving
seat
in
the
center
of
our
orchestration
that
we
do
because
every
time
you
want
to
go
back
to
observability
and
see
is
the
system
running.
Does
everything
work?
You
know
you
know
if
you
don't
have
any
regression
and
stuff
like
this,
but
and
the
second
big
problem
really
is
we
have
so
many
tools
out
there
and
they
all
have
proprietary
ways
how
you
communicate
with
them
proprietary
apis.
D
D
So
if
you
would
all
agree
on
a
standard,
it
would
make
the
life
of
everybody
easier.
This
is
where
you
know
cloud
events
and
cd
events
come
in
yeah,
so
captain
in
a
nutshell,
right
observability
into
the
driving
seat
of
orchestration
and
we're
using
an
open
event
standard
to
actually
then
talk
to
your
tools,
we're
not
replacing
your
tools,
we're
just
connecting
the
dots
and
we
have
observability
that
is
constantly
making
sure
that
your
system
is
actually
running.
Based
on
your
slo
definitions,
that's
kind
of.
A
Yes,
absolutely
absolutely-
and
I
think
the
like,
I
think
about
the
like
the
idea,
like
it's
a
tool
that
understands
underneath
the
tools
that
the
ecosystem
is
providing
and
leveraging
those
tools
to
help
you
make
your
devops
pipeline
efficient
and
more
like
generic.
The
way
you
write
before
it.
So
I
think
there
is
some
wonderful
moving
part
to
it.
A
So
now
that
steve
taylor
is
joining
us
from
dortelius
community
and
thank
you
very
much
steve
for
joining
us
on
the
call-
and
we
say
hello
to
you
as
well,
so
tell
us
about
how
the
utility
is
because
go
to
the
brand
afterward
and
tell
us
about
how
the
integrating
captain
is
out
of
my
cortelius
microservice,
because
brad
is
a
guy
who
introducing
us
to
this
wonderful
tool
back
then.
So
we're
really
we're
thankful
to
them
as
well.
B
So
when
you
look
at
how
applications
are
being
put
together
these
days
and
the
trend
towards
microservices
the
need
to
pull
together,
you
know
information
from
a
hundred
different
microservices
and
can,
and
when
those
100
microservices
each
have
their
own
pipeline
that
they're
going
through.
Then
that's
one
of
the
things
that
we
are
focused
on,
so
we
hook
into
the
pipeline
process
when
a
microservice
is
created.
B
That's
the
first
like
integration
point
and
then
on
the
deployment
side,
when
a
microservice
is
deployed,
we're
deploying
a
logical
set
of
them
together
because
there's
dependencies,
even
though
people
say
that
microservices
are
totally
independently
deployable.
Well,
it's
not
really
the
case
developers
aren't
that
good,
even
though
they
think
they
are
so
we
need
to
to
take
a
set
of
microservices.
B
That's
going
to
be
our
view
of
the
way
the
application
version
looks
and
we're
going
to
deploy
it
at
that
point.
So
those
are
our
two
integration
points
kind
of
like
where
we
hook
into
the
pipeline
is
one
when
the
microservice
is
created,
and
the
second
is
when
we
go
to
deploy
it
now,
when
we
get
into
the
whole
get
ops
process,
it
gets
even
more
complicated,
but
that's
like
the
high
level
of
of
where
we
are
with
ortelius.
A
Yes,
absolutely
absolutely.
Thank
you
very
much
describing
all
these
things.
I
know
the
go
go
to
the
brad
as
well,
because
he's
actively
involved
in
the
hoteliers
community
on
dc
integration,
the
to
that
on
to
the
captain
project
and
where
they'll
guide
us
through,
like
what
are
the
things
he
achieved
by
integrating
the
captain
project
in
the
hotel
in
the
rotaria's,
open
source
repository
and
what
is
currently
planning
at
the
g
sock
side
as
well.
C
Sure
I'll
probably
just
cover
the
ortillas
for
now,
but
so
maybe
going
back
like
when
I've
always
with
my
companies
adopted
open
source.
So
I
I
was
a
customer
of
dynatrace,
probably
maybe
three
years
ago
and
that's
when
I
started
seeing
you
know
the
use
for
captain
and
as
we
started
to
adopt
it
as
well,
we
would
maybe
suggest
changes,
etc
and
then
that's
when
I
I
came
into
that
ortillius
community
as
well.
C
So
I
guess
I'm
the
lucky
one
that
gets
to
sort
of
play
with
all
these
tools
and
then
get
them
working
together.
So
the
the
last
year
we've
been
working
with
steve,
pretty
closely
on
quite
quite
a
big
project,
actually
so
on.
It's
integrating
get
ups
with
event
driven
ci
cd,
so
we
use
argo
cd
and
then
we're
we've
integrated
that
with
captain
as
well,
because
one
it's
quite
a
steep
learning
curve.
C
So
we
started
seeing
that
okay,
we
actually
need
to
do
some
testing,
because,
if
we're
doing
these
deployments
with
the
canary,
what's
the
point,
if
there's
no
user
traffic
to
be
able
to
know
that
you're
getting
errors,
you
know
to
know
that
that's
failing!
So
that's
when
we
started.
You
know
integrating
into
this
this
process
the
the
testing,
the
observability.
C
You
know
the
quality
gates
and
and
then
we're
on
to
working
on
the
autelius
captain
service
at
the
moment,
which
will
then
integrate
with
that
to
be
able
to
do
the
cataloguing
and
in
the
and
the
orterious
features
so
that
that's
sort
of
a
high
level
of
the
project.
So
do
you
have
any
other
questions
about
that?
C
B
B
C
B
Exactly
yeah
and
that's
where
the
get
ops
model
really,
I
think
in
my
viewpoint,
struggles
is
when
you
get
a
large
number
of
environments,
if
you're
a
small
startup
company,
you
got,
you
know
alpha
release
going
out
to
some
environment
and
you
got
some.
You
know
you
may
not
even
have
qa
set
up
or
maybe
you
have
a
little
bit
and
then
you
have
your
development.
The
get
ops
for
that
process
to
move
things
along
with
a
couple
repositories
makes
a
lot
of
sense
and
it's
easy
to
do.
B
But
when
we
look
at
complex
production
level
applications
it
gets.
The
complexity
like
you
said:
brad
really
multiplies
pretty
quickly
and
that's
where,
when
when
brad-
and
I
first
were
starting,
we're
like
we
need
to
have
an
events
driven
process
to
deal
with
this
and
that's
where
brad
brought
in
captain
on
that
front.
A
Yes,
absolutely
absolutely,
and
I
think
we
brought
a
lot
of
the
attraction
about
the
events
like
I
see.
I
I've
been
a
developer
developer
for
the
dot-net
land
for
a
very
long
time.
I
see
a
lot
of
the
patterns
that
come
revolves
around
like
you
want
to
do
this
kind
of
thing
like,
let's
make
an
interface
out
of
it.
A
A
The
question
was
like:
how
are
you
managing
the
event
in
the
inside
the
captain
and
let's
see
some
of
the
services
that
you
can't
integrate
with
today,
but
you
have
a
mechanism
of
web
hook
and
kubernetes
job
to
integrate
with
those
kind
of
things.
Where
do
you
see
the
cd
event?
Space
is
moving
in
in.
In
regards
to
that,
your
work
with
the
captain
team.
D
Yeah,
so
I
think,
first
of
all,
maybe
just
to
explain
for
the
listeners,
but
this
is
a
new
concept
where
captain
is
a
new
concept.
Basically,
I
explained
in
the
beginning
how
we
started,
because
we
tried
to
build
these
pipelines
with
the
existing
tools
and
we
ended
up
with
a
lot
of
let's
say
scripts
in
let's
say
a
tool
like
jenkins
that
called
tool
abcd,
because
in
these
pipeline
approaches
you
have
a
hard
coded
process
and
hard
coded
tools.
So
you
have
a
process
step.
D
One
step,
two
steps,
three
step:
four,
and
then
you
have
two
a
b
c
and
d,
and
basically
the
key
concept
of
captain
is
that
you
declaratively
describe
a
process,
because
you
have
task
one
two,
three:
four:
we
call
them
tasks
and
we
kind
of
combine
them
in
what
we
call
a
sequence.
However,
we
loosely
couple
the
tools.
This
is
where
the
events
come
in.
D
That
means
what
really
captain
does
it:
orchestrates,
the
sequence
of
tasks
and
every
time
a
new
task
should
be
executed,
captain
really
issues
and
emits
an
event,
and
then
you
can
have
one
or
even
multiple
tools
subscribe
to
that
event
and
basically
say
hey
captain
I
can
do
deployment.
You
want
me
to
deploy
into
this
environment,
I'm
responsible
for
this.
D
I
can
do
it,
so
let
me
do
it,
but
it
can
also
be
a
second
tool
that
says:
hey,
I'm
slack
or
ms
teams
and
I'm
interested
in
deployment
events,
but
really
I'm
not
actively
doing
much,
I'm
just
passing
it
on.
So
we
also
have
the
concept
of
active
and
passive
kind
of
event
handling.
But
now,
where
do
cd
events
come
in?
When
we
started
with
captain,
we
really
quickly
ended
up
using
cloud
events
as
kind
of
like
the
core
standard
of
the
payload.
D
D
We
have
metadata
like
what
type
of
test
you
want
to
execute
functional
tests,
performance
tests,
real
user
tests
for
maybe
another
tool
like
observability,
you
said
what
type
of
metric
you're
interested
in,
so
we
basically
then
came
up
with
the
conclusion
that,
while
we
we
wanted
to
make
it
very
flexible
for
certain
tasks
like
deployment
test,
evaluate
how
we
called
it
notification,
there's
certain
piece
of
minimum
metadata
that
you
need
so
that
any
type
of
deployment
tool
actually
knows
what
to
do
with
it.
And
so
this
is
now
what
is
influencing
ct
events?
D
Cd
events
really
tries
to
say
what
type
of
tasks
do
we
have
in
an
end-to-end
delivery
pipeline?
What
type
of
tasks
do
we
have
as
part
of
all
the
remediation
and,
let's
figure
out
what
is
the
minimum
set
of
metadata?
That
tools
needs
to
actually
then
execute
a
task
if
they're
asked
to
execute
a
task,
and
so
now
this
is
what
we're
doing
through
cd
events.
D
It's
really
basically
finding
the
common
ground
of
of
data
that
you
need
when
you
call
a
certain
tool
that
should
do
a
certain
job
and-
and
I
think
once
we
have
figured
this
out
and
let's
just
say
we
are
agree
on
a
standard
for
how
should
the
deployment
event
look
like,
then
any
delivery
tool
that
implements
it
could
then
easily
be
integrated
without
any
additional
effort
into
an
orchestration
engine
like
captain
or
into
I'm
sure.
There's
auto
orchestration
engines
too,
that
will,
in
the
future
leverage
cd
events
right.
B
D
B
And
now
they
need
to
add
tests
and
then
they
need
to
add
security
scanning.
Then
they
need
it.
So
the
the
pipelines
keep
growing
and
become
more
complex
and
when
you're
talking
about
a
microservices
world
going
and
updating
all
those
across
multiple
repos
it
just
is
you
get
inconsistencies
and
it
just
is
way
too
much
work.
So,
with
the
like,
the
the
captain
events
it,
it
makes
it
so
much
easier
to
grow.
There's
no
bottleneck
really.
D
Yeah,
america,
that's
a
great
point
right
steve.
If
I
I
know
my
hands,
maybe
not
doing
it
justice.
But
if
you
have
build,
deploy
test,
evaluate
and
let's
say
the
test-
you
just
brought
up
the
test.
Maybe
right
now
your
organization
is
very
immature
and
the
only
egg
test
you
execute
is
maybe
a
functional
test.
So
you
have
one
tool
that
subscribes
to
that
next
month:
you're
adding
performance
tests.
So
that
means
you
have
a
second
setting
a
second
testing
tool
that
also
subscribe
to
the
same
event.
D
And
now
when
you
deploy
and
now
when
you
run
your
your
automation,
all
of
a
sudden,
you
get
synthetic
and
function
performance
tests
and
then
the
next
thing
might
be
security
tests.
But
the
good
news
is,
though,
you
don't
need
to
update
and
extend
any
existing
pipelines
that
might
be
even
copied
around.
D
Yeah
but
that's
not
only
bash
about
developers.
I
know
this
isn't
this
is
free,
it
seems
to
be
in
our
industry
we're
really
great
in
whoever
we
talk
to,
we
always
bashed
and
on
the
other
side
I
think
we
all
we
all
fall
victim
to
the
same
thing,
but
you're
right
I
mean
copy
pasting
in
the
end,
will
result
in
a
lot
of
technical
debt
because.
C
D
D
D
As
I
said,
your
own
integrations
in
case
your
tool
does
not
yet
natively
support
cd
events
and
the
the
majority
of
tools.
Don't
support
it
right
now
right
because
it's
still
a
standard
that
is
evolving,
but
I
think
we're
proving
right
now
with
all
the
work
we're
doing
that
we're
actually
solving
a
real
problem
in
a
real
pain,
and
I
think
this
is
what
matters
and
then
we
have
to
keep
the
community
behind
it,
and
hopefully
this
will
get
us
faster
to
a
real
standard
and
more
people
implementing
it.
A
A
It's
quite
difficult,
like
I
use
a
tool
a
it
sends
the
request
to
some
eventing
mechanism
and
it's
using
some
kind
of
a
language
that
I
need
to
understand
how
the
event
is
going
down
the
stream
and
then,
when
we
receive
the
event,
then
we
need
to
understand
what
are
the
basic
format
available
for
me
to
understand
what
to
do
with
that
event,
payload
that
I
getting
back
from
the
event.
So
it's
basically
a
channel
like
if
you
have
a
100
tools
in
the
devops
pipeline.
A
These
are
the
different
eventing
mechanism
and
hopefully,
like
25
of
the
tools
are
using
different
eventing
languages.
So
that's
a
huge
task
like
you
need
a
theme
that
is
extremely
doable
like
doing
nothing
just
to
understand
these
kind
of
stuff,
and
this
breaks
animation
like
we
doing
some
kind
of
stuff
that
we're
not
meant
to
do
and
despite
somebody
busying
understanding
some
kind
of
the
these
things
and
it's
making
the
vision
slow.
So
that's
a
real
challenge
for
everyone,
like,
I
think,
that's
a
great
stepping
moving
forward
to
the
right
direction.
A
Like
I
see
a
lot
in
the
kubernetes
space
is
we're
using
the
standards
like
csi
cni's,
cr
cris,
that's
everywhere,
like
it's
able
to
understand,
because
tomorrow
your
implementation
may
need
changes
and
you
need
another
tool.
What
should
you
do
if
you
don't
have
interfaces,
so
I
think
that's
a
great
step
in
moving
over
to
the
good
direction,
and
one
of
one
of
the
features
that
I
really
like
about
captain
is
is,
I
think,
that's
I
really
like
about
it
and
I'm
going
to
implement
it.
A
My
in
my
current
job
as
well
like
it's,
a
lighthouse,
a
service
and
also
the
auto
remediation
like
when
we're
moving
from
the
deaf
stage
to
the
production.
We
need
to
understand:
is
it
a
right
time
to
move
to
the
next
stage?
How
do
we
evaluate
myself
like?
Is
it
the
branches
like
we
don't
leave
what
why
we
should
we
move
it,
and
why
should
we
stop
it
and
in
the
captain
we
have
sli's
and
slos?
D
So
maybe
I
mean
again,
we
didn't
invent
anything
new,
slis
and
slos
come
from
google's
site,
reliability,
engineering,
movement,
right
slice
indicators.
So
how
do
you
capture
a
certain
piece
of
data
like
kind
of
like
a
kpi
right,
a
metric?
I
think
slice
is
just
a
maybe
a
cooler
more
modern
term
and
slo
is
your
objective
and
the
way
I
like
to
explain
it
right
now
and
steve.
You
mentioned
github's
earlier
right
with
github's
what
we
do.
D
We
are
basically
describing
a
technical
desired
state
because
you're
describing
I
want
to
have
five
instances
of
this
particular
container
and
10
instances
of
this,
and
I
want
to
have
xyz
and
then
what
your
deployment
system
does
or
your
github's
operator.
It
just
make
sure
that
whatever
you've
declared,
maybe
in
git
as
part
of
crds,
will
actually
be
applied
to
kubernetes,
and
so
you,
your
five
containers,
run.
D
But
honestly,
if
five
containers
run
or
10
containers
run
doesn't
matter
if
your
application
is
not
making
your
users
happy,
meaning
if
your
application
cannot
be
accessed
from
the
outside
world,
because
maybe
you
made
a
mistake
with
your
ingress
if
your
application
is
still
very
slow
and
your
end,
users
are
abandoning
you.
This
is
where
slos
come
in.
Slos
are
service
level.
Objectives
typically
would
say
something
like
my
system
needs
to
be
available.
99.99
of
the
time
my
system
has
to
have
a
certain
response
time,
because
otherwise
I
will
lose
users.
D
My
system
has
to
be
accurate.
That
means
when
people
are
searching
for
something
on
my
website,
then
the
actual
the
right
result
should
come
back
so
accuracy,
and
so
what
we're
doing
with
captain?
We
allow
you
to
specify
these
slos
right
and
with
this,
as
we
are
embedding
the
evaluation
of
these
slos
by
pulling
data
from
the
observability
platform
prometheus
dynatrace
data
dog
neuralic,
whatever
you
have
we're
pulling
it
in
as
part
of
the
automation
we
run
as
part
of
the
orchestration
and
can
therefore
always
say
hey
after
the
deployment,
your
system
is
still
healthy.
D
Well,
actually,
your
deployment
broke
something
because
now
your
end
users
can
no
longer
access
your
website
or
they're.
Now
you
know
I
don't
know
doing
something
else.
They
are
complaining
about
it.
So
I
think
what
we're
really
doing
and
coming
back
to
githubs
and
I
think
we
can
actually
elevate
githubs.
We
can
go
from
technical,
desired
state
management
to
business
desired,
state
management,
because
that's
really
what
we
do
with
captain.
D
We
were
at
kubecon
and
we
had
the
captain
booth
and
we
had
a
lot
of
people
that
came
in
just
close
by
was
the
the
argo
booth
and
with
a
lot
of
people
from
argo
coming
in
and
out
to
our
booth,
and
then
they
all
told
us
something
like
what
brad
what
you
said
right
I
mean
argo
is
great
and
I
think
it's
one
of
the
best
githubs
operators
out
there.
But
what
what
it
doesn't
do
it
doesn't
do
pre-deployment
validations
and
it
doesn't
do
post-deployment
validations
and
that's
exactly
what
we
are
doing.
D
One
of
the
use
cases
with
captain,
if
your
git
ops
operator,
like
argo
or
flux
or
any
other
tool,
is
detecting
a
drift
in
your
technical
desired
configuration
instead
of
just
applying
it
and
be
done
with
it.
It
hands
over
control.
To
captain
captain
then
says
all
right.
I
have
a
configuration
change
that
should
be
applied,
but
before
I
will
validate,
is
your
system
even
ready
for
deployment,
because
maybe
currently
the
system
is
broken
or
you
want
to
deploy
into
production?
But
maybe
you
don't
have
enough
error
budget
anymore.
D
So
you
want
to
ask
another
human
being,
maybe
for
approval
if
you
really
want
to
deploy
because
potentially
you're
breaking
your
slas,
so
we're
basically
handing
over
control
to
captain
captain
can
do
pre-deployment
validations
by
pulling
data
from
your
observability
platform,
then
obviously
captain
triggers
through
the
event
same
event,
mechanism
a
tool
like
argo
and
say
argo.
Now
you
do
your
job.
What
you're
good
in
and
once
argo
is
done,
then
captain
does
a
post
deployment
evaluation
by
in
production.
Let's
say:
look
at
the
slos:
is
the
system
still
available?
D
A
Yes,
absolutely
absolutely.
Those
are
the
critical
points
for
every
business,
like
your
application
is
up
and
running,
and
you
want
to
make
sure
when
something
goes
bad
at
it.
Do
you
call
3
am
at
night
your
developer
to
fix?
That
might
be
it's
taking
time,
it's
be
traveling
from
home
to
office,
and
when
that
time
you
don't
make
your
application
video
outage,
and
nobody
done
that.
But
the
captain
does
the
auto
remediation
evaluate
before
doing
something
and
after
if
you
apply
the
remediation,
it's
also
evaluated
like
is
it.
A
D
Yeah,
I
think
the
only
last
important
thing,
because
I
made
this
mistake
many
times
when
I
talk
about
captain-
it
always
sounds-
captain
can
do
this,
and
this
and
this
captain
itself
doesn't
remediate.
Captain
doesn't
deploy,
captain
doesn't
test
captain
orchestrates
and
at
the
core
has
the
lighthouse
service
that
always
validates
against
the
observability
platform.
That
means
what
you
need
to
have
in
place.
You
need
to
make
a
decision
on
what
tool
you
use
for
deployment.
D
A
It's
help
you
the
with
the
yaml
file
in
the
kubernetes
space
and
orchestrating
the
tool
that
you
want
to
need
it.
So
I
think
that's
really
is
kind
of
a
wonderful
everybody
listening
to
really
enjoy
the
conversation
like
we
have
those
tools
available
as
this
movement
of
time
and
also
like
going
to
the
steve
on
the
open
source
side.
B
Number
of
changes
that
are
gonna
that
are
starting
to
happen
with
the
microservices
architecture
and
if
you
have
a
hunter
microservices
and
a
hundred
developers,
and
they
all
wanna,
just
make
one
simple
change
a
day.
That's
a
hundred
changes
a
day
that
you're
making
to
production,
and
you
you
can't
do
that
manually
and
you
can't
do
that
through
a
more
static
pipeline,
because
it's
going
to
start
stepping
on
top
of
each
other
and
that's
where
the
events
driven
pipeline
can
orchestrate
that
much
easier
at
that
level.
B
So
that's
one
of
the
things
I
see
being
able
to
handle
that
type
of
load
that
we're
putting
through
our
pipeline
these
days.
Now,
that's
just
one
change!
You
know
I
I'll
make
three
to
four
changes
a
day.
Sometimes
so
you
know
you're
into
the
thousands
of
changes
a
day
happening
that
you
needed
to
coordinate
and
validate
and
make
sure
that
you
have
a
healthy
environment
in
production,
as
things
are
moving
that
quickly.
At
that
speed,.
A
A
So
it's
difficult
like
if
some
changes
is
going
to
the
github
and
whole
system
is
down
somebody
cloning
and
running
the
code.
Well
now.
What
should
I
do?
Where
should
I
go
to
that?
Like
the
tools
have
that?
Having
that
place,
I
think
make
our
life
a
lot
easier
and
we
feel
more
relaxed.
That
is
system
is
not
going
to
be
hard.
Anybody
can
use
it
even
because
we
have
different
time
zone
as
well.
A
They
have
so
many
issues
that
can
open
source
community
has
and
when
we
look
at
the
open,
kubernetes
community,
the
way
the
contribution
comes
from
the
different
companies,
the
different
people
involved
into
that.
I
think
these
system
not
just
help
solve
the
enterprises
need,
but
also
the
open
source
need
as
well,
because
we
want
to
have
those
tools
available
for
us
as
well,
and
also
a
good
now
going
to
the
brad
on
this
discussion
around
like
we.
A
We
know
because
me
I
see
the
brad
is
a
wonderful
community
person,
always
he's
been
the
community
rock
star.
I
guess
in
the
captain's
face
I
see
a
some
captain
tweet
as
well,
so
people
who,
like
about
sub
technologies
like
they
see
that
there
are
some
benefits
to
that
and
they'll
learn
about
it.
What
should
you
ask
the
individual?
How
should
you
tell
this
tool
to
other
individuals
in
the
company
in
the
country
or
in
the
local
communities?
What
are
the
different
way?
C
Yeah,
I
guess
just
finding
out
what
your
actual
problem
is,
because
sometimes
you
might
not
even
need
the
tool,
but
just
understanding
what
your
you
know:
business
outputs
are
and
the
value
that's
going
to
bring
and
then
you
can
to
get
started
normally.
You
know,
I
see
a
lot
of
people
contributing
that
you
know
they.
They
don't
actually
adopt
or
try
the
tool
and
understand
how
it
works
to
start
with.
C
So
I
think
I'd
like
to
see
more
people
trying
to
adopt
the
tool
first
and
actually
use
it
before
you
know,
starting
to
just
to
contribute
like
a
couple
of
lines
of
code,
but
but
I
think
just
doing
like
proof
of
concepts
and
and
blogs
you
know
like
you,
produce
some
great
content
by
the
way.
I
I
always
like
your
your
your
post
that
you
do
and
just
sort
of
yeah
just
looking
about
and
seeing
what
tool
fits
good
for
you.
C
A
Yes,
absolutely
100,
like
it's
so
difficult,
like,
I
think,
and
some
of
the
people
saying
in
the
comment
that
andrea's
explanation
is
great
and
I
always
learn
a
caption
up
to
this
time
because
of
the
wonderful
explanation
from
the
nbs.
Thank
you
very
much
mia
for
joining
in
the
podcast
and
listening
to
us
today,
and
you
can
share
your
question
if
you
have
any
so
I
won't.
Let
takes
much
of
your
time,
but
we're
just
winding
up
the
discussion
here.
A
D
So
I
think,
as
you
probably
know,
we
are
still
on
a
zero
dot
x
release,
so
our
big
next
goal
is
to
going
to
be
to
get
to
1.0
and
that's
also
where
we
are
trying
to
define
now
what
do
we
still
need
to
get
to
mondodo?
I
think
one
of
the
things
we've
learned
in
the
last
couple
of
months
based
on
feedback.
We
need
to
have
a
github
operator
for
captain
people
want
to
make
sure
that
they
can
use
crds
to
define
captain
project
services
and
stages
and
everything
one
of
our
colleagues,
thomas
schutz.
D
He
already
implemented
the
githubs
operator
now
the
question
is:
how
can
we
get
this
really
into
the
core
of
the
product?
That's
one
of
the
things
and
yeah
really
driving
cd
events
to
the
next
level
and
also
then
fully
implementing
whatever
stand
that
comes
out
of
it.
I
think
these
are
the
the
major
things
I'm
looking
forward
to
detroit.
D
So
that's
going
to
be
good
yeah.
Maybe
the
other
thing
I
know
it's
so
I
talked
about
argo
a
lot
earlier.
We
have
a
lot
of.
We
had
a
lot
of
interest
in
argo
and
hopefully
people
will
now
really
look
into
how
to
implement
these
pre-deployment
post-deployment
validation
with
captain.
But
argo
is
just
one
of
the
tools
flux.
I
see
a
lot
of
interest
also
on
flux,
and
I
think
it's
also
part
of
google,
some
of
code
to
actually
implement
the
flux,
integration
and
there
might
be
others
and
the
neck.
D
The
last
thing
I
want
to
say,
because
if
you
think
about
it
and
maybe
steve,
I
want
to
talk
with
you
about
offline
at
some
point.
One
of
the
challenges,
at
least
that
I
see
that
that
we
would
try
to
solve
for
business,
is
getting
visibility
into
pipelines.
That
means
how
often
do
you
deploy?
How
long
do
these
pipeline
runs?
How
many
builds
are
failing
right
in
the
devops
world,
we
call
these
the
dora
metrics,
the
devops
research
metrics,
and,
if
you
think
about
it,
we
can
obviously
hook
into
all
of
the
different.
D
Let's
say
web
hooks
of
jenkins.
Of
of
I
don't
know
argo
and
then
somehow
get
this
data
into
central
storage.
I
think
google
has
a
good
sample
project
for
this.
To
then
send
data
to
a
certain
table,
so
it's
a
certain
database
and
then
they
have
like
a
little
project
and
it
does
the
visualization.
But
if
you
really
get
cd
events
standardized
and
people
are
here-
we
go
yeah.
You
are
working
on
the
flux,
integration,
perfect.
D
If
you
really
have
cd
events
and
ncd
events
is
going
to
drive
the
orchestration
in
the
future,
then
it
will
be
very
easy
to
come
up
with
all
of
these
business
level.
Metrics
how
many
deployments
to
run?
How
long
do
they
run?
Where
do
things
slow
down?
Do
we
have
projects
where
all
of
a
sudden,
we
have
more
order
remediation
being
executed
as
part
of
a
deployment
which
would
then
tell
us
that
there's
a
deterioration
of
of
quality?
So
I
think
I'm
really
looking
forward
to
this
standard.
B
Yeah
and-
and
I
think
one
of
the
things
I've
kind
of
been
seeing
around
cd
events
is
a
way
to
kind
of
store.
Historically,
the
events
that
have
happened,
so
you
can
kind
of
groom
through
them
and
get
those
trends.
So
that's
one
of
the
things
I
can
see
in
the
future
that
cd
events
is
probably
gonna,
they're
they're,
more
focused
on
the
event
standard
right
now,
but
down
the
road.
I
think
we're
gonna
have
to
persist
at
that
data.
D
Exactly
yeah,
so
we
also
have
plans
from
the
dynadry
side.
I
mean.
First
of
all,
captain
right
is
monsters
that
wants
to
stand.
That
is
a
true
standard
and
captain
is
using
in
these
events.
Captain
will
automatically
have
all
these
events
because
we
keep
we
keep
it
in
our
in
our
back
end
event
database,
but
also,
I
would
see
any
observability
vendor.
That's
not
only
dyna
trace,
but
I'm
sure
data,
dog
and
your
relic
and
all
of
them.
A
B
Yeah
so
one
of
the
things
that's
we're
trying
to
that
brad's
been
working
real
hard
on
he's
and
he'll
dive
into
a
little
more.
Our
get
ops
process
around
ortelius,
managing
applications,
logical
applications
and
how
the
get
ops
model
applies
to
that
dealing
with
hundreds
of
microservices
I'll.
Let
brad
talk
to
that
because,
since
he's
been
heading
that
up
more
on
the
other
side,
we
have
some
other
interesting
stuff
happening
with
blockchain
and
blockchain
ledgers
to
persist
and
record
the
versions
of
components
and
applications
in
immutable
fashion.
B
A
C
Yeah
sorry
mihaw's
on
on
the
call,
as
well
she's
working
with
me
very
hard
on
the
flux
integration,
so
we
actually
have
a
prototype
of
it
working
at
the
moment.
So
in
flux
they
have
a
flux,
notification,
controller
and
that
can
send
events
to
well,
not
events.
It
can
send
they're
called
notifiers,
so
they
can
notify
slack
teams
etc.
So
at
the
moment
you
can
they're
just
sending
like
a
static
payload,
so
you
can't
change
it.
C
So
what
we're
working
on
is
at
the
moment
we,
the
the
flux
payload,
will
come
through
as
an
event
and-
and
we
can
essentially
we
grab
that
and
we
turn
that
into
a
cloud
event
and
then
we
can
push
it
over
to
captain
to
start
to
process
them
into
the
argo
one
as
well.
So
I
have
a
proposal
ready
to
actually
I'd
like
to
change
it
on
the
flux
side,
so
I
know
what's
involved
to
do
it
on
there,
so
we
actually
want
to
bring
that
code
into
flux.
C
So
then
we
don't
have
to
have
integration
that
we
have
to
manage
and
support,
because
at
the
moment
you
we
want
to
implement,
implement
a
go
template
similar
to
argo
notifications,
and
so
you
there's
a
concept
of
a
provider,
an
alert.
So
you
get
the
alert
that
something's
happened.
So,
whether
that's
a
home
release
has
updated
its
version.
They
get
repositories
out
of
sync
customize
yeah,
there's
quite
a
few
there,
and
then
you
can,
in
the
provider
you'll
be
able
to
send
the
metadata.
C
So
the
captain's
service
name,
the
project
and
everything
that
you
require
or
it
could
be,
it
doesn't
have
to
be
forgotten.
It
could
be
for
tikton
or
jenkins
or
anything,
and
then
that
will
as
you
you
template
it
out,
and
then
that
will
just
forward
that
cloud
event
on
so
yeah
we're
looking
to
present
it
maybe
next
week,
just
the
prototype
that
we
have
and
then
have
a
discussion
around
it
and
then
see
what
folks
think.
But
it's
a
quite
exciting
project.
A
Yes,
absolutely
absolutely
and
we're
looking
forward
to
that,
because
we're
looking
forward
to
that
integration
for
a
very
long
time-
and
hopefully
it's
it's
awesome.
The
developer
and
devops
people
need
about.
So
I
have
learned
so
much
during
the
conversation
with
all
through
all
of
you
guys,
but
it's
so
many
information.
So
I
try
to
wrap
up
and
try
my
best
to
conclude
the
conversation
as
well.
So
you
look
at
the
captain.
A
It's
giving
you
the
automated
observability
quality
gate,
slis
slos
devops
pipeline
generic
way,
and
you
can
talk
to
them-
andreas
over
the
internet
like
on
twitter
or
linkedin
anyway,
about
the
captain,
what
it
does,
how
to
get
start
working
with
it.
So
you
keep
an
eye
on
that
project
as
well
and
if
you're
part
of
the
microservices
team
and
looking
forward
to
laboring
using
some
open
source
tools,
we
have
ortelius
github
repositories.
A
Can
I
try
to
connect
with
every
because
he's
been
actively
he's
moving
a
lot,
a
lot
of
the
places
every
time
we
talk
to
them
so
hopefully,
in
future
we
makes
come
up
with
his
own
youtube
channel,
explaining
the
travel
and
living
philosophies
around
the
world
so
and
you
can
talk
to
them
about
any
captain
integration
or
flux.
Integration
he's
been
a
wonderful
person
to
hang
out
with
you,
so
tricky
takeaway
from
the
all
conversation
here
is:
keep
an
eye
out
on
the
captain.
A
Cd
events,
the
next
big
things
I
think
in
the
devops
pipeline
or
devops
eventing
mechanism-
go
explore
that
out.
Links
are
available
on
the
chat,
so
go
check
that
out
as
well
and
hope.
This
conversation
find
helpful
in
in
your
current
challenges
that
you
are
facing
and
we
will
meet
you
again
might
be
in
the
github
site
or
in
the
microservices
side.
I
don't
have
plan
yet
so
far,
but
we
come
up
with
another
good
speakers
around
the
cncf
and
cdf
ecosystem.
So
thank
you.