►
From YouTube: GitLab - Ops Section - Direction Q&A
Description
B
Does
but
the
live
stream
is
not
working.
Ok
welcome
everyone.
This
is
an
ops
section.
Direction
page
QA
there's
been
a
lot
of
updates
to
both
the
structure
of
the
direction
pages
in
general,
so
across
the
sea,
ICD
and
ops
pages,
but
also
the
ops
one
specifically,
and
we
wanted
to
give
everyone
an
opportunity
to
have
a
QA
there's
an
issue
specifically
for
this
discussion,
where
we
can
have
it
a
a
sink.
But
this
is
the
synchronous
opportunity
to
ask
questions.
I'll
start.
B
My
name
is
Kenny
Johnson
I'm,
the
director
of
product
management
covering
the
ops
stages,
I'll
start
with
introductions
of
the
products
team,
and
then
we
will
I'll
do
a
brief
overview
of
the
content
in
both
ops
and
monitoring,
configure
stages
and
then
we'll
open
up
questions
and
there's
a
live
note
stock.
You
can
find
on
that
issue
for
anyone
who
wants
to
queue
up
questions
as
we
go
through.
Okay,
so,
as
I
said,
Kenny
Johnston,
director
of
product
for
ops
tech,
covers
configure
and
monitor
Daniel.
C
D
E
B
So
I
think
there's
been.
You
know,
five
to
six
M
ARS
over
the
course
of
the
last
couple
of
months.
I'd
love
to
see
that
increased,
so
I
would
encourage
other
team
members
to
contribute
to
M
ours,
but
the
the
overview
is
I'll.
Give
my
TL
DR
from
the
top
of
my
head,
so
apologies
I'm,
not
exact
on
these
numbers,
but
the
ops
tool
market
is
large.
B
It's
actually
in
some
cases
larger
than
the
dev
tool
market,
because
there's
more
mature
tools,
I
think
in
general,
there's
some
feeling
that
the
ops
side
of
the
kind
of
total
DevOps
market
requires
some
significant,
significantly
higher
R&D
investments
to
build
those
tools
because
you're
dealing
with
larger
datasets,
and
so
there
seems
to
be
a
premium
to
that.
People
are
willing
to
pay
there's
also
a
component
of
especially
in
the
monitor
space
space.
There's
a
higher
overall
market
likely
because
you're
also
paying
for
the
raw
storage
costs
in
these
tool.
B
So
when
you
have
sat
stools
like
a
data
dog
or
New
Relic,
where
they're
storing
data
in
a
SAS
solution
for
you,
you're
you're,
also
at
kind
of
having
to
bundle
in
this
higher
infrastructure
cost
of
actually
storing
the
raw
content
of
your
metrics
that
you're
monitoring.
So
that
leads
the
market
kind
of
having
a
higher
premium.
I
guess
you
can
think
of
it.
Those
players
in
this
space,
as
I
mentioned,
are
clearly
in
the
monitor
stage.
B
There
are
consolidating
vendors
Splunk
is
bought
victor
ops
and
a
couple
another
synthetic
monitoring
tool
that
I'm
forgetting
the
name
of
signal
signal
FX.
I
think
it
was
recently
so
there's
consolidation
in
that
market
around
the
players.
Moving
to
this
one
op
school
kind
of
world
in
the
configure
stage,
Victor
and
I
were
actually
just
talking
about
this.
Today
it
seems
to
be
more
fragmented.
B
There
are
some
tools
that
are
becoming
at
least
a
new
style
of
configuration,
management
tool,
hashey
Corp
and
their
tool
set,
including
terraform,
comes
to
mind,
but
they're
also
a
kind
of
split
of
the
former
generation
of
tools
of
puppet
chef
and
ansible
that
people
use
for
configuration
management
and,
in
general
there,
that
the
connection
between
management
of
infrastructure
and
applications
is
becoming
more
blurred.
Where
you
see
things
like
infrastructure
as
code,
where
you're
managing
that
infrastructure,
like
it
was
code,
so
the
tooling
for
managing
infrastructure
is
changing
more
to
look
like
developer
tooling.
B
Customers
do
you
like
where
this
is?
This
next
statement
is
kind
of
how
we
power
our
current
customers
are
using
it.
I
would
say
our
our
vision
for
the
ops
stage
overall.
Is
that
get
lab
becomes
the
first
tool
that
operations
professionals
are
people
who
are
responsible
for
operating
applications
in
production
environments,
look
at
when
they
wake
up
in
the
morning.
I
don't
think
we're
there.
B
Yet
customers
tend
to
use
us
more
for
the
there's,
like
a
direct
quote,
that
we
heard
from
a
customer
that
hey
I
use
New
Relic
for
most
of
my
applications,
but
if
there's
a
new
Greenfield
application,
that's
cloud
native
and
can
you
Prometheus
and
I
might
save
a
couple
bucks
on
my
New
Relic
costs
by
not
having
to
use
it.
So
our
adoption
in
these
stages
is
I
would
call
it
Masons,
there's
significant
opportunities
for
us
to
grow
here.
B
Some
of
the
challenges
you
know
existing
players
with
a
lot
of
R&D
investment
and
I
put
one
other
here.
That
I
would
just
highlight
that
by
we
don't
have
as
much
dogfooding
in
this
space
as
we
do
in
others.
Obviously,
because
we
have
a
ton
of
developers
and
our
operations
team
are
not
using
our
operations
tooling,
at
least
not
so
the
rate
that
we
like
so
we're
our
pace
of
learning
is
slower
and
I.
Think
that's
a
challenge
that
we'll
talk
about
later
some
opportunities
I.
My
kind
of
TLDR
on
this
opportunities
is
there's.
B
Definitely
a
market
realization
that
developers
are
kind
of
the
kingmakers
in
these
tooling
and
that
we're
asking
developers
in
this
DevOps
worlds
to
own
more
of
the
operations
process,
and
so
the
developer
buying
power
is
increasing
and,
as
a
result,
you
have
people
who
don't
have
as
much
pure
operation
skills
available
to
do
pure
operations,
and
so
there's
kind
of
this
notion
of
how
do
you
teach
developers
to
do
some
of
these
operations
test?
And
how
do
you
enable
them
to
do
that?
B
Well,
that
means
that
a
developer,
focused,
ops
tool
kind
of
like
has
a
clear
path
for
a
success
in
this
market.
We
have
some
consolidation
in
how
people
do
operations
because
of
the
adoption
of
kubernetes.
So
that
means
that
we,
we
were
an
early
adopter
of
kubernetes,
and
we
frequently
hear
this.
This
quote
that
give
up
is
the
most
common
way
to
deploy
to
kubernetes,
because
we
make
it
very
easy
and
integrated,
and
that
means
that
if
we
kind
of
lean
into
that,
we
can
continue
our
our
lead
in
the
operation.
B
B
Evolution
that
is
going
on
in
this
space
has
has
the
potential
to
benefit
us,
and
there
are
things
that
our
customers
already
do.
Are
you
heard
on
stage
at
London,
commit
where
there
are
a
number
of
customers
talking
about
how
they
were
using
git
lab
to
manage
their
infrastructure,
so
a
clear
opportunity
for
us
to
lean
in
themes
that
we've
defined
or
this
again
leaning
into
source
control?
B
How
do
we
define
both
the
infrastructure
that
my
application
is
being
deployed
to
the
application
so
obviously,
and
the
observability
or,
like
my
response
systems
in
code,
I,
think
that
is
a
clear
thing
that
we
want
to
emphasize
again
with
our
roots
and
source
control
management,
and
our
kind
of
like
robust
CIC
capabilities
means
that
we
can
and
should
be
early
proponents
of
this
infrastructure
and
observability
as
code
market
push.
We
talked
about
server
ability
and
the
other
one
is
the
feedback
loop
right,
the
I
think
from
an
Operations
perspective.
B
Victor
and
I
were
talking
about
this,
like
the
most
important
metrics
to
be
alerted
on
for
you
as
a
developer.
Who's
not
staring
at
a
screen
in
a
NOC
all
day.
To
know
like
oh
man,
I
got
a
respond
to
this,
but
then
give
you
tools
so
that
you
can
triage
it
quickly,
but
also
build
your
ability
to
triage
the
next
one.
B
Time
and
iteration
is
really
critical
and
then
operations
for
all,
which
is
really
I'd,
mentioned
this
earlier,
like
starting
from
the
developer
and
building
tools
that
enable
the
developer
to
do
operations
that
doesn't
require
this
kind
of.
Like
dedicated.
You
hear
about
large
software
companies
that
have
dedicated
infrastructure,
cost
managers
or
site
reliability
engineers
or
these
other
kind
of
specialized
functions
that
we
really
want
to
focus
on
the
developer
first
and
enabling
the
developer
to
handle
these
tasks.
And
then
this
last
one
is
really
about
a
growing
trend.
B
The
industry
calls
it
no
ops,
it's
a
little
bit
of
a
misnomer,
there's,
still
a
bunch
of
operations,
tasks
that
need
to
be
done,
but
you're
requiring
less
direct
infrastructure
management
as
a
result
of
things
like
serverless
and
some
other
initiatives.
I
think
our
auto
devops
is
kind
of
a
step
in
that
direction.
Just
in
general
three-year
strategy.
We
talked
about
being
this
kind
of
consolidating
around
kubernetes
being
the
place
where
infrastructure
professionals,
land
on
a
daily
basis,
there's
a
notion
of
supporting
a
team
that
provides
the
infrastructure
as
like
a
platform
teams
is
something.
B
We've
been
hearing
a
lot
from
analysts
that
there
are
this
new
notion
that
platform
teams
might
kind
of
serve
as
the
internal
paths
for
development
teams,
so
that,
for
instance,
kubernetes
infrastructure
is
run
by
the
platform
team
and
then
the
developer
teams
land
their
applications.
On
that
infrastructure,
so
they
don't
have
to
think
about
it
as
much
and
then
yeah
the
whole
infrastructure
and
observability
is
code
that
those
processes
are
defined.
We
have
of
C
ICD
capabilities
in
the
next
12
months
for
ops.
We
talk
about
most
important
dogfooding
building
our
logging
capabilities.
B
We
really
want
to
work
on
the
dashboarding
for
the
purposes
of
triage
and
instrumentation.
So
again,
I
think
the
notion
that
people
will
stare
at
a
knock
at
a
big
screen
and
only
when
they
see
a
something
go
blip
realize
that
something's
wrong
is
is
out
the
window
today
in
in
modern
operations
lexicon,
but
really
you
need
some
visualization
or
in
order
to
instrument
where
you
wants
to
be
where
you
want
to
be
alerted,
and
then,
when
you
are
alerted
to
triage,
that
incident
management
gives
us
a
high
focus
on
that
feedback
loop.
B
So
focusing
on
how
do
you
learn
from
an
incident
and
put
those
changes
back
into
code
and
then,
as
we
said,
infrastructure
is
code.
We
talked
about
a
couple
of
things
that
we
won't
invest
in,
which
is
one
this
notion
that
individuals
will
attach
their
own
personalized
kubernetes
cluster
to
a
project.
We
want
to
focus
more
on
that
platform
user.
B
Specific
applications,
we're
gonna,
focus
less
on
that
and
then
the
app
instrumentation
across
some
legacy
programming
languages,
we're
focused
on
skating
where
the
puck
is
headed.
So
there
are
a
set
of
languages
that
are
the
more
modern
set
that
are
used
to
deploy
cloud
native
applications
that
we
should
focus
on
making
it
easy
to
instrument.
First
and
foremost,
the
rest
is
kind
of
our
roadmap
for
the
items,
but
hopefully
that
gave
you
a
good
verbal
overview
of
this
page
and
and
I
will
stop
for
questions
or
comments.
F
F
I
know
that
our
like
the
way
we
have
it
structured
right
now
means
that
we
don't
have
to
store
customer
data
for,
for
you
know,
the
monitoring
features,
but
if
that
changes
in
the
future,
that
might
be
a
huge
costs
us
for
for
our
comm,
offering
so
I
I
guess
I
just
wondered
if
you
had
any
thoughts
on
on
that
and
how
our
current
pricing
model
would
have
to
change.
Yeah.
B
I'll
give
my
thoughts
and
then
Sarah
and
dove,
if
you
have
want
to
add
like
I,
would
just
say,
I.
Think
you're,
spot-on
I
would
posit
that
in
some
future
world
we
do
have
been
calm,
a
SAS
based
offering
that
includes
the
bundling
of
storage
in
some
centralized
way
and
that
we
charge
for
that
similar
to
how
we
charge
for
CI
minutes.
B
Like
with
your
plans,
you
get
a
certain
set
number
and
then,
if
you
have
overages,
there's
a
way
to
purchase,
overages
I
will
say
that
that
pricing
mechanics
is
also
because
the
majority
of
our
business
comes
from.
Self-Managed
is
a
little
bit
of
a
differentiator,
because
today
again
like
our
products,
if
their
developers
are
using,
it
comes
bundled
with
all
these
other
tools
that
their
developers
are
using
and
then
their
internal
teams
get
to
manage
the
cost
of
that
storage
and
there's
no
premium
on
top
of
the
software
cost
for
it.
B
So,
there's
a
little
bit
of
like
it's
kind
of
what
we're
approaching
this
in
the
West
SAS
way,
but
I
do
think
that
there
are
there's
an
opportunity
there,
because
our
our
pricing
will
look
really
good
compared
to
you,
the
other
players
in
the
space
but
I
think
for
comm.
We
would
certainly
want
to
be
in
a
position
where
we'd
have
some
other
SKU
price
point
for
overages
Sara
yeah.
D
I
think
it's
for
mice,
I
think
your
response
is
spot-on.
We'll
definitely
need
to
do
some
changes
on
the
pricing
and
calm
as
we
introduce
even
elasticsearch,
and
we
want
to
store
metrics
and
I.
Don't
see
it
as
a
challenge,
I
see
it
as
an
opportunity
actually
and
I
guess.
This
is
something
that
we
just
stopped
planning
I
mean.
A
We
have
the
same
so
instead
of
just
mapping
to
our
own
for
pricing
tiers
between
core
and
ultimate
we're
now
also
having
to
make
a
choice
and
have
an
opinion
on
which
platforms
within
this
other
tool,
our
users
also
have
to
have
so
I
see
challenges
with
pricing.
From
that
perspective,
as
we
try
to
move
quickly
and
the
other
vendors
in
market,
it's
going
to
be
helpful
if
we
can
lean
on
work
done
by
other
tools,
but
if
we're
not
owning
it,
we're
now
at
their
their
whim
for
what
they
choose
to
price.
D
B
E
Yes,
so
I
mentioned
a
few
times
that
we
are
actually
ready
to
go
into
deployment.
I
totally
understand
that
we
are
leader
in
terms
of
technologies
that
we
want
the
first
people
to
make
these.
It
might
lead
us
right
to
usage
as
well.
So
the
question
is:
do
we
know
actually
how
many
you
know
weekly
or
daily
deployment?
There
are
yeah.
B
It's
a
great
question:
I'll
say
Mike
I
asked
the
source
of
that
quote.
Originally
I
think
it
was
from
a
talk
that
Kelsey
Hightower
gave
just
from
his
experience,
he's
seen
that
a
lot
of
people
who
are
deploying
to
kubernetes
are
using
get
that
because
of
our
integration,
makes
it
really
easy
and
like
their
out-of-the-box
pipelines
for
it,
but
Daniel
I,
don't
know.
If
you
can
comment
on.
We
also
have
metrics
of
how
many
kubernetes
deploy
clusters
are
getting
attached
to
our
instances
from
usage,
ping
and
other
sources.
C
That's
right,
so
we
we
have
visibility
in
two
ways,
so
the
first
one
is.
The
number
of
clusters
are
being
created
within
good
lab,
B,
that
in
gke
or
you're
adding
an
existing
cluster
from
another
platform.
That's
the
first
one
and
then
the
second
one
is
the
total
number
of
auto
devops
pipelines
and
there's
a
bit
of
a
challenge
there,
because
in
all
the
DevOps
we
don't
really
segmented
by
stage
on
our
metrics
right.
We
know
it's
an
audit
of
ups
pipeline,
but
we
currently
don't
know
which
stages
of
that
pipeline.
C
Let's
say
you
chose
to
ignore
or
you
or
you
didn't
execute
on.
So
one
of
the
that
that's
going
to
be
one
of
our
themes
in
configure
I
think
for
next
year
is
going
to
have
more
sophisticated
telemetry.
So,
for
example,
we
say
we
have
certain
number
of
auto
devops
pipelines
that
may
or
may
not
deploy
kubernetes
right,
because
that
deploy
part
is
only
available.
C
So
that's
going
to
be
another
thing
that
we
are
going
to
add
telemetry
to,
but
roughly
I
I
can
tell
you
that
over
the
past
year,
on
average,
we've
had
about
just
shy
of
a
million
pipelines
in
Auto
DevOps
that
run
monthly
and
I'm
looking
at
the
most
recent
months,
and
that
is
around
700,000
for
the
month
of
September.
So
we
can't
assume
that
all
of
those
have
deployed
at
kubernetes.
But
we
know
that
probably
a
large
number
half
so
we'll
work.
To
kind
of
add
that
that
level
of
detail
to
the.
G
So
considering
we're
trying
to
enable
teams
that
might
not
have
your
deep
knowledge
of
operations
because
of
the
skill
shortage,
you
know
what
role
should
I
use
a
friendly
and
rich
GUI
play
in
stress
in
our
strategy
and
at
what
stage
in
the
maturity
lifecycle
should
have
possibly
become
a
focus.
Yeah.
B
Actually,
it's
so
Sarah
I,
sarin
and
I
had
a
really
interesting
conversation
with
an
analyst
on
Friday
about
the
need
for
there's
a
new
movement
in
this
space.
Some
of
us
attended,
monitor
AMA
in
June
and
heard
from
a
guy
named
John
all
Spa,
who
spoke
about
a
new
discipline
called
human
factors,
engineering
which
is
really
about.
How
do
we
help
humans
understand
complex
systems?
B
But
if
we
start
from
the
goal
of
it's
important
for
humans
to
be
able
to
quickly
understand
this
complex
system
and
how
it
is
failing
in
a
complex
manner,
we
can
think
about
new
UI
experiences
that
would
Mabel,
then
so
I
know
we're
number
of
team
members
have
come
from
organizations
that
I've
done
this
and
have
tooling
to
do
it.
So
I'd
love
to
give
them
an
opportunity
to
speak,
but
I
do
think
you're,
spot-on,
Jean
that
the
importance
is.
B
It
is
even
higher
because
we're
talking
about
professionals
that
don't
have
deep
Operations
experience
and
we
need
to
give
them
as
part
of
their
workflow
of
understanding
even
before
triaging.
An
ability
to
quickly
understand
this
complex
system
that,
like
a
a12
factor,
cloud
native
application
that
has
tons
of
different
sub
services,
is
a
very
complex
system
that
we
need
to
give
people
tooling
and
that
will
likely
mean
visualization
to
help
them
understand.
But
again
others
can
contribute.
I
know
lots
of
people
have
come
from
companies
that
have
done
this
exact
thing:
Aaron
and
Sarah
I'm.
H
I
A
I
A
Think
that
also
aids,
us
in
companies
who
come
to
us
with
the
purpose
of
nominees
gitlab,
because
it's
going
to
help
me
with
my
DevOps
transformation
versus
those
that
come
that
are
already
more
progressive,
aren't
necessarily
they're
going
to
enjoy
and
find
use
in
this.
But
those
that
we
can
make
that
configuration
our
instrumentation
more
accessible
to
I
think
is
where
we
have
huge
opportunity
at
this
time
and
I
have
another
comment
for
the
other
part
of
this
strategy,
which
is
uncanny.
Correct
me.
B
Yeah
I
think
I
think
that
the
extent
that
we're
targeting
this
team
group
of
people
who
don't
have
a
lot
of
experience
with
those
two
aiyo,
let's
take
the-
how
do
I
configure
alerting
example
right
like
today,
we
I
think
we
started
with
that,
primarily
in
GUI,
right
and
I.
Don't
think
that
was.
That
was
an
important
step
to
take,
because
it
shows
people
that
hey
you're
looking
at
a
graph
and
you
can
add
an
alert
to
it.
So
some
of
those
workflows
feel
like
they
should
be
user
interface
centric.
B
Obviously
we
have
to
iterate
our
we're,
not
gonna,
like
all
of
a
sudden
bang
land,
some
revolutionary
new
interface.
We
have
to
think
about
how
to
iterate
through
that,
and
maybe
there
are
cases
where
that
configuration
less
graphical
configuration
is
the
starting
point,
but
I
guess
I
would
also
I
think
that
the
my
current
understanding
of
that
is
not
complete.
If
you
were
to
tell
me,
hey
developers
only
wants
to
do
configuration
in
text
format
and
that's
their
most
comfortable
thing
and
maybe
that's
a
place
to
start.
H
If
you
look
at
companies
like
data
dog,
like
Hoshi,
Corp
they're,
everything
is
really
tight.
It
looks
really
nice.
It's
really
easy
to
use.
It
makes
my
job
easier
makes
finding
the
information
that
I
need
easier,
getting
started
easier,
so
I
think
if
we,
if
we
can,
that
and
for
people
that
aren't
technical,
they
can
dive
into
those.
You
know
the
set
up.
H
B
Yeah
I
would
say
that
maybe
maybe
I
could
ask
this
question
of
the
Gila
have
developers.
You
know
we
hear
a
lot
that
people
love
gitlab,
right
and
I
think
that
they've
loved
get
lab
because
it's
comprehensive
and
because
the
user
experience
is
friendly,
intuitive
organized
for
the
way
that
their
brain
is
thinking.
B
G
B
Yeah
it's
a
great
way
of
framing
it.
I
mean
my
my
immediate
response
is
now
but
I
don't
know
like
I
guess:
I,
don't
there
seems
to
be
a
starting
point
of
that
of
that
we
may
be
like
short-shifted
our
GUI
capabilities
to
date
into
the
extent
that
we
have
done
and
I
think
we
probably
need
to
adjust.
I,
don't
I
mean
our
experience
to
date.
B
G
You
know,
I
understand
the
concepts
behind
it
and
so
on,
but
coming
yeah
I
know
it
gives,
at
three
months
now
so
and
having
having
to
try
and
get
used
to
the
people
of
configure
and
and
all
the
functionality
and
stuff
I
found
it
as
a
new
user
to
be
challenging
and
so
I'm
thinking,
yeah,
a
rich
GUI
or
something
less
integrated
might
have
made
that
experience
easier
and
I'm
thinking
no
like.
That
might
not
be
where
we
are
in
terms
of
our
strategy.
G
It
will
configure
specifically
that
I
focus
on
so
I'm
more
just
kind
of
like
trying
to
gauge
it
as
we
as
we
grow,
configure
as
we
become
you
know,
and
what
what
stage
do
we
say?
You
know
what
at
this
point,
we
I'm
not
saying
we
shouldn't
have
a
focus
on
it
now
already
I'm
saying
at
what
stage
do
we
want
to
really
make
it
a
priority
to
create
a
a
user
friendly?
You
know
like
what,
for
me
feels
ancient
something
that
is
around
way.
We
want
it
to
be
the
entry
point
for
new
customers.
G
B
Okay,
so
let
me
break
that
into
two
things:
one,
the
state
like
the:
what
stage
are
we
in
I
just
want
to
like
review?
There
are
other
stages
other
than
configure
that
are
like
secure.
For
instance,
last
year,
at
the
start
of
last
year
was
most
of
the
categories
were
minimal,
defend
is
like
one
is,
one
is
minimal
and
the
rest
are
still
planned.
Those
are
places
where
I
could
see
the
argument
like
yeah.
We
should.
B
We
really
need
to
be
focused
on
breath
here
and
that
kind
of
comprehensive
workflow
might
not
be
as
critical.
I
would
think.
That
configure
is
past
that
at
this
point
right
like
configure,
we
should
be
starting
to
think
more
about
the
user,
workflows
and
journeys,
and
if
that
means
in
investment
it
more
in
yeah,
I,
think
I'm
stuck
because
I'm
not
sure
we're
improved
UX
would
improve
that
flow.
But
if
you
have
specific
points
where
you'd,
like
you
just
said,
I've
been
out,
you've
been
onboarding
and
trying
to
understand.
B
If
those
are
current
pain
points,
we
should
be
tracking
those
and
working
with
the
product
team
to
knock
them
out.
So
yeah
I'll
go
back
to
your
original
questions
like
when
I
think
now
is
when
we
shouldn't
be
I
kind
of
Daniel
and
Victor
are
in
charge
of
prioritization
for
those
teams,
so
I'm
sure
there
are
tough
decisions
to
be
made,
but
we
should
be
continually
bringing
those
up
and
I
know.
B
I
Think,
from
my
standpoint,
as
far
as
like
the
rich
UI
goes
like
there's
varying
degrees
of
that
and
for
when
we
start
to
optimize
for
those
job
to
be
done,
like
Kenny
mention
like
our
customers
are
gonna
dictate.
Some
of
that.
You
know
when
we
start
to
work
on
those
things
and
optimize
those
workflows.
You
know
we're
gonna
go
out
and
tuck
them
validate.
B
Cool
I
think
it's
a
great
point
and
I
there's
another
component.
That's
just
we
have
to
think
about.
Oh,
if
we,
if
we
want
that
improved
experience,
it
comes
through
iteration
right,
and
so
we
have
to
make
sure
we're
thinking
through
what
are
the
individualized
next
steps
that
can
beat
us
there.
The
the
notion
of
like
rich
graphical
user
interface
feels
like
it's
the
kind
of
thing
that
you
would
normally
like,
go
work
in
a
silo
for
three
months
and
develop
and
then
like
spring
on
the
application,
but
that's
just
not
how
we
work
here.
C
Iii
wanted
to
add
to
that
last
point
that
I
think
that
audience
is
important
there.
So
a
lot
of
the
a
lot
of
the
features
that
we're
going
to
work
on
and
are
currently
working
on,
have
an
audience
that,
like
heavily
relies
in
version
control
to
manage
pretty
much
everything
from
pipelines
to
infrastructure,
to
rules
to
alerts.
All
of
that
is
generally
fishing.
Troll
I
think
that
yeah,
that
the
monitoring
aspect
has
big
reliance
on
dashboards
and
things
like
that.
C
But
I
don't
think
that
I
don't
think
that
rich
graphical
GUI
should
be
the
first
thing
in
many
of
the
features
that
that
were
going
to
work
on
that
being
said,
because
we
want
to
be
kind
of
the
solution
to
deploy
to
kubernetes
for
personal
users.
That's
going
to
be
important,
but
I
think
that
the
overall
experience
to
people
that
are
in
that
role
or
in
that
business
today
doing
operations
is
going
to
be
more
important.
B
So
thanks
Daniel
all
right.
If
no
other
questions
I,
you
can
feel
free
to
ask
additional
questions
in
the
issue
or
there's
an
OP
section.
Slack
channel
feel
free
to
jump
in
there.
I
think
what
I
would
also
love
to
see
is.
This
document
is
not
like
something
that
product
management
like
plops
down
and
is
the
gospel
like
please
contribute,
mrs
updates.
B
Have
we
can
have
a
discussion
there's
a
couple
of
points
from
today's
conversation
that
I'm
gonna
use
to
update
the
document,
but
it's
meant
to
be
our
method
of
communicating,
especially
within
the
ops
section
kind
of
like
what
our
current
plans
and
strategy
are,
that
every
team
member
can
refer
to
and
if
we
can
hash
out
questions
or
debates
or
discussions
in
mrs
to
that
document.
So
please
consider
it
a
living
and
breathing
thing
jewel.
If
nothing
else
I
appreciated
the
discussion.
This
was
awesome
and
it
will
see
you
all
soon.