►
Description
We discussed why we want to be Kubernetes First
B
Yeah
and
I
wanted
to
have
it
posted
to
the
channel,
so
it's
really
easy
cool.
I
I
have
item
number
one
which
is
a
decide
on
the
importance
of
kubernetes,
particularly
for
chris
and
lana.
I
want
to
kind
of
point
out:
what's
happened
here
and
get
you
to
think
about
something
specifically
that
victor
and
I
talked
about
yesterday.
B
So
when
we
deprecated
the
certificate-based
cluster
integration,
you
may
have
noticed
that
a
whole
slew
of
feature
also
was
forced
to
be
deprecated,
and
this
is
actually
for.
This
is
a
result
of
us
actually
doing.
In
my
opinion,
something
really
well
in
the
past,
so
get
lab
was
pretty
early
in
terms
of
kind
of
recognizing
the
importance
of
kubernetes,
and
we
built
a
lot
of
really
powerful
features.
B
But
of
course
we
realized
that
the
way
we
are
integrating
is
not
how
people
want
to
practice
for
a
bunch
of
different
reasons,
primarily
around
security,
and
therefore
we
created
the
agent
and
now
we're
kind
of
back
to
square
one
for
a
lot
of
our
capabilities,
for
example,
to
do
advanced
deployment
in
chris's
world
without
kubernetes,
it's
extremely
difficult.
You
might
need
to
connect
to
or
have
access
somehow
to
a
low
balance
in
order
to
do
things
like
blue
green
deploys
to
to
do
that.
B
That's
a
lot
of
work,
but
in
the
kubernetes
world,
it's
relatively
straightforward,
because
you
have
this
thing
with
an
api
that
controls.
What
happens?
It's
largely
it's,
maybe
not
largely
all
declarative,
makes
things
really
easy
to
build
things
quickly.
So
the
topic
of
conversation
that
victor
and
I
had
yesterday
was.
B
We
we
see
in
our
opportunity
reviews
when
people
are
choosing
gitlab
oftentimes.
This
is
during
the
time
of
re-platforming.
Moving
to
the
cloud
taking
advantage
of
kubernetes
so
to
have
a
robust
set
of
features
around
kubernetes
is
really
really
important.
It
presents
natural
opportunities
for
us
to
upsell
our
capability
to
get
really
sticky
with
the
customer
when
we
have
features
that
they're
looking
for
as
they
move
to
kubernetes.
B
The
fundamental
point
I
just
want
to
make
is,
when
you
think
about
iterating,
when
you
think
about
introducing
new
features,
it
is
really
really
good
to
start
kubernetes,
both
from
a
market
perspective
and
both
and
from
an
effort
perspective.
They
they
line
there.
So
it's
and
it's
okay
to
not
offer
the
entire
future
set
to
every
single
customer.
That's
that's
an
hour.
Our
aim
is
to
meet
customers
where
they're
at
and
deliver
something
quickly.
C
C
A
A
Actually,
I
would
say
that
that
whole
topic
around
aligning
our
our
the
user
flow
and
picking
specific
parts
about
that
is
the
answer
to
your
question.
Okay,
I
can
tell
you
where
we
are
right
now,
which
is
that
the
agent
is
looked
after
by
many
many
users
early
adopters,
even
have
it
in
production
and
even
more
serious
users,
like
gitlab.com
itself,
wants
to
adopt
the
agent
and
actually
I'm
not
advocating
for
it.
So
that's
important.
A
We
discuss
that
with
dog
footing,
I'm
not
the
type
who
goes
out
and
markets
that
I
want
them
to
to
see
the
value
in
it,
and
so
they
are
really
now
even
users
like
gitlab.com
are
looking
at
the
agent
to
be
used,
and
the
agent
today
works
really
well
for
a
particular
use
case
that
is
deployment
of
pure
kubernetes
yaml,
manifest
that
that
it
does
brilliantly,
but
it
has
with
respect
to
your
area.
It
has
no
integration
at
all
to
anything
related
to
monitoring
that
we
have
previously
pod
logs
with
metrics.
A
It
has
no
integrations
with
alerts
how
we
could
surface
layers
that
are
raised
from
parameters
within
the
cluster
to
be
shown
inside
of
git
lab
nothing
like
that
for
increase.
It
has
no
integration
with
environment
boards.
We
are
just
removing
that
from
the
product
and
even
worse,
not
just
that
integration
was
pretty
poor
and
actually
for
the
environment
board
integration.
Our
users
said
that
they
rather
not
use
that,
except
for
any
initial
explanations,
but
they
are
looking
for
a
similar
kind
of
integration.
A
A
So
we
have
that
knowledge,
and-
and
these
are
the
things
that,
if
you
leave
it
on
me,
it
will
be
only
kubernetes
if
we
do
it
separately,
it
might
be
everything,
but
it
will
be
super
slow.
On
the
other
hand,
if
we
do
it
together,
we
we
set
our
road
maps
in
a
synchronized
fashion.
They
know
what
each
others
are
working
on.
Reviews
might
be
much
faster,
because
we
know
that
we
are
working
on
similar
areas
and
so
on
and
so
forth,
and
and
that's
the
the
whole
idea
here-
and
I
think
that's
this
most.
C
D
E
C
B
B
B
Be
able
to
deliver
at
nbc
within
a
milestone,
whereas,
if
you
were
to
say
hey,
I
really
wanted
the
environment
to
represent
all
the
servers
and
hosts
and
whatever
like.
How
are
we
even
going
to
build
that?
We
have
no
idea
at
the
moment,
so
there's
going
to
be
lots
of
these
types
of
opportunities
or
we
can.
B
C
So
I
think
the
example
victor
that
you
mentioned
for
the
response
stage,
is
being
able
to
surface
and
integrate
alerts
that
are
coming
from
the
agent,
so
that
sounds,
that
sounds
great.
Does
this
sim?
Where
does
this
information
is
this?
Is
it
sounds
like
this
information
doesn't
necessarily
exist
within
the
agent
today,
but
it's
something
that
may
be
okay,.
A
A
A
Because
there's
one
one
project
where
the
agent
is
configured,
but
it's
very
likely,
especially
in
the
future,
that
there
will
be
another
project
that
actually,
where
the
applications
reside
even
both
source
code
and
the
manifest
for
that
application,
and
we
have
to
come
up
with
all
these
ideas.
Okay,
then,
where
should
it
go,
whether
it's
configurable
or
better,
whether
you
know
what
our
users
want,
and
this
we
have
to
figure
out?
But
after
that
the
code
base?
There
is
some
previous
knowledge
already.
D
I
think
I
had
the
next
one
if
we're
ready
to
move
on.
I
just
was
asking
the
question
because
yeah,
I
think
I
think
I
think
I'm
understanding
sort
of
the
like
the
point
of
view,
which
is
yeah
markets
using
kubernetes.
We
wouldn't
have
have
a
and
camping
you're
answering
this,
but
like
just
high
high
adoption
of
that
in
general,
in
the
industry.
D
We
have
a
good
sense
that
anything
building,
capabilities
related
to
kubernetes
will
already
make
a
sticky
and,
as
even
from
a
like,
a
value
to
effort
perspective
like
going
with
kubernetes
related,
like
kind
of
the
kubernetes
version
of
the
feature
sets
we're
building
is
like
a
really
like
we're
really
like
that.
We
have
like
high
confidence
in
that
direction.
Right,
like
that's
sort
of
like,
I
think
what
you
guys
are
saying
and
so
yeah
my
my
question
here
was
just
like.
Do
we
have
like?
What's
our
like
from
your
perspective?
B
A
I
I
have
some
more
markets
site
data
I
as
quickly.
I
couldn't
come
up
with
the
link,
but
I
remember
very
well
that
more
than
90
percent
of
containers
monitored
by
datadog
run
inside
kubernetes,
and
of
course
this
is
a
tricky
thing
because,
like
this
is
a
container
organization
just
so
likely
bigger
users
who
run
even
the
same
container,
multiple
scaled
up
to
multiple
pods
are
running.
That's
a
dog
but
like
if
you
just
count
the
number
of
containers
more
than
90
percent
of
them
run
within
kubernetes.
A
A
Is
what
I
linked
below
this
dashboard?
I
don't
know
if
you
have
seen
it
with
anna.
I
have
seen
it
already.
We
started
to
collect.
We
asked
a
question
now
when,
when
a
user
creates
a
new
project
like
what
is
their
deployment
target
and
I
managed
to
to
break
it
down
by
tier
and
there
we
see
that
around
19
percent
in
the
past
two
days
is
targeting
kubernetes,
so
it's
among
the
paying
tiers
not
for
free,
because
yeah
so
pretty.
C
C
A
A
A
A
A
This
is
especially
apparent
with
autodevops,
which
is
a
huge
set
of
ci
templates
that
probably
not
many
users
can
use
as
they
are,
so
everybody
has
to
customize,
and
then
the
question
is
whether
our
customizations
are
good
enough
and
so
on.
Very
often
what
I
hear
on
user
interviews
is
that
they
just
want
to
write
their
own
ci,
so
we
should
rather
have
that.
So
this
is
that
we
were
very
open.
United
is
the
other
thing.
The
third
was
that
we
took
on
responsibilities
that
we
shouldn't
have
like
what
we
call
the
gitlab
managed.
A
B
A
primary
example
of
that
is
for
fun
running
by
itself
is
easy,
but
that's
actually
not
useful
for
most
organizations.
You
know
to
monitor
your
production
app
to
have
a
single
instance
of
sorry
microfinance
prometheus
having
a
single
instance
of
prometheus,
that's
essentially
useless
to
to
any
organization
with
any
sort
of
traffic,
and
if
you
were
to
install
that
via
gitlab,
that's.
C
A
Yeah
there
is
actually
we
are
struggling
with
that
we
have
a
huge
maintenance
burden,
because
we
we
inherited
gitlab
many
steps.
Now
we
are
trying
to
move
away
from
that,
so
we
give
more
and
more
responsibility
to
our
users
in
terms
of
that,
so
they
can
maintain
it
instead
and
they
own
those
projects.
A
C
A
A
So
now
we
have
the
cluster
management
project,
template
that
actually
allows
you
to
install
all
the
applications
that
integrate
with
gitlab
like
it
allows
you
as
well
to
install
promoters.
But
now
that's
a
project
template.
So
you
will.
What
you
will
receive
is
a
project
and
you
can
upgrade
it.
We
don't
upgrade
it
for
you.
You
are
on
your
own
once
it's
deployed
and
I
would
still
not
recommend
it
for
many.
Many
users.
A
Have
a
cluster
created
within
aws
or
gcp?
Have
all
these
apps
installed
with
single
clack
click?
Add
the
auto
devops
template
as
a
template
include,
and
you
got
review
apps
you
get
a
staging
deployment,
you
get
a
production
deployment,
it
runs
for
15
minutes.
You
might
have
to
disable
many
of
those
jobs
because
they
just
fail
in
your
setup.
A
A
Yes,
but
to
getting
for
getting
started
experience
that
was
amazing
for
new
users
like
nobody
knew
kubernetes.
It
was
just
this
big
thing
where
people
wanted
to
move
without
really
understanding
it.
That
was
a
really
good
value
offer.
Actually,
and
probably
we
need
that
kind,
that
level
of
of
ease
as
well,
but
we
should
build
it
on
very
strong
foundations.
So
that's
why
what
we
did
with
in
the
configure
team
when
we
restarted
the
kubernetes
management
direction?
A
The
first
thing
that
that
we
decided
is
that
previously
direction
page
said
that
we
are.
We
want
to
serve
every
kubernetes
users
and
want
to
have
a
very
beginner
friendly
setup.
I
think
that
was
on
our
direction
page
and
we
changed
it.
We
want
primarily
to
serve
experienced
juventus
users,
because
we
believe
that
if
we
can
set
them,
we
can
build
higher
level
abstractions
to
serve
beginner
users.
A
A
D
Yeah
I
just
trying
to
internalize
this
these
concepts
that
we're
talking
about
and
thinking
about
it
in
terms
of
outcomes
too
and
so
yeah.
I
think
these
are
kind
of
obvious,
but
like
it
helps
me
frame
how
this
fits
into,
what
I'm
doing,
and
probably
what
we're
the
rest
of
us
like
are
doing
beyond
what
we're
just
talking
about
today.
D
So
yeah,
just,
I
think
some
of
you
added
to
this,
but
like
in
my
mind,
like
for
for
my
like
category
like
environment
management,
increasing
adoption
engagement
because
it
becomes
more
useful
if
we're
in
the
example,
kevin
and
victor
were
talking
about
right.
Environments
are
connected
to
the
actual
targets
that
were
that
users
are
using.
It
makes
it
more
useful,
yeah
kevin
that
looks
like
you,
wrote,
cross-stage
adoption.
D
A
A
A
So,
basically,
what
we
miss
a
lot
is
something
like
a
kubernetes
dashboard.
I
don't
know
if
you
have
ever
seen
a
kubernetes
dashboard
or
not.
The
idea
is
that
kubernetes
is
really
composed
of
resources.
Like
you
have
a
deployment
resource
that
spins
up
replica
sets
resource
that
creates
your
pods.
Then
you
have
a
separate
ingress
resource.
A
You
have
a
service
resource
and
all
this
together
create
a
web
service
that
shows
up
on
a
domain
and
it's
extremely
natural
to
when,
when
you
run
the
deployment
to
see
how
these
pods
are
terminated,
the
old
versions,
the
new
versions
are
spin
up.
You
see
the
status
there
and
you
have
links
to
get
out
to
block
tailing
or
or
log
history,
or
something
like
that,
and
today
we
miss
this.
A
B
Most
organizations
will
have
some
sort
of
dashboard
whether
it's
stockholder,
whether
it's
one
of
the
many
things
this
is.
This
is
right
in
gilap's
sweet
spot
in
that
you
have
one
app
that
actually
does
all
of
this,
and
then
it's
it's
only
one
single
space
because
for
the
this
is
right
now
always
going
to
be
a
separate
thing,
separate
step,
separate
everything,
but
it
actually
doesn't
need
to
be,
especially
if
you're
already
using
gitlab
for
everything
else
to
manage
your
application.
Development
deployment.
B
A
E
A
C
E
D
B
D
Is
very
helpful
to
hear
your
sort
of
strong
perspective
on
this,
and
so
I
think
now
yeah,
I
think
any
now
when
we're
thinking
about
new
feature
sets
like
this
will
yeah
this.
I
think
the
the
goal
is
like
to
have
this
top
of
mind
and
yeah
make
sure
we.
I
also
think
this
is
like
this
feels
like
a
really
actionable
way
for
us
to
coordinate
together
too
on
our
road
maps
and
directions,
and
so
yeah.
Even
from
that,
like
practical
perspective,
it's
like
okay.
D
A
Actually,
one
thing,
especially
for
you,
chris,
that
I
would
highlight,
which
is
that
I'm
I
I
think
that
we
should
be
kubernetes
first
and
very
much
focused
on
it
but
like
when
we
discussed
this
yesterday
with
kevin.
Then
it
came
up
that,
like
seriously
having
the
environment
board
built
out
in
a
more
insightful
way
for
gitlab
pages,
that
that's
that's
natural
fit
because
gitlab
manages
those
pages,
so
we
should
be
able
to
provide
more
more
things.
There
yeah.
D
A
So,
let's
not
not
forget
the
the
other
easy
beans,
because
the
other
thing
that
I
think
we
learned
from
autodevops
is
that
if
we
focus
on
a
single
solution,
we
will
very
likely
rule
out
every
other
possibility
and
we
need
to
rewrite
if
we
ever
have
to
do
so.
We
have
to
be
very
mindful
about
how
we
build
up
these
integrations
and
it's
more
that
from
a
diplomat
management
point
of
view.
A
I
don't
know
whether
so
I
would
say
that
with
environments,
it
might
work
something
similar
because
there's
the
environment
syntax
within
ci,
but
I
have
no
idea
what's
on
the
monitor
side.
So
what
what
gates?
We
have
to
keep
open
and
and
have
to
think
about
as
we
build
out
these
things
at
the
same
time,
why
we
go
very
much
into
kubernetes.
B
B
B
B
B
A
No,
I
it
was
really
for
your
information.
Just
I
know
that
alana
is
aware
of
it.
I
wanted
to
share
it
with
chris
as
well,
so
feel
free
to
look
at
it
if
it
inspires
you
in
any
way,
take
that
inspiration
with
you
and
use
it
on
your
own
benefit.
So
that's
it
nothing!
Nothing
else.
One
question
about
vanities.
A
A
Seen
good
ones
about
it
that
that
would
with
that
focus.
So
I
I
just
added
the
next
topic,
my
my
ideas.
What
I
would
speak
about
and
and
it's
not
so
what
you
have
is
as
resources
are
not
that
describe
the
benefits
of
kubernetes
but
they're,
always
like
okay,
how
to
get
started
with
it.
But
we
don't
care
about
getting
started.
D
Yeah
sure
victor
I
mean
yeah
say
I
had
the
same.
Like
you
know,
I
wouldn't
want
you
to
kind
of
spend
your
time
on
that
if
there
are
already
existing
resources,
but
I
mean
if,
if
you
have
like
a
if
you
know,
like
the
you,
probably
have
the
awareness
of
like
what's
the
right
information
for
us
to
to
know
right,
that
would
be
the
most
useful
for
us
right,
which
yeah.
D
Yeah
I
wrote
that
it
varies.
I
I've
actually
sort
of.
As
an
aside,
I've
been
digging
into
feature
flags
at
a
customer
call
yesterday
and
like
some
of
what
at
least
the
vision
is
for
future
flags
as
like
a
concept
is
that
software
developers
for
sure
could
do
it,
but
even
so
sasha,
but
even
beyond
that,
like
kind
of
the
idea
is
that
non-technical
people,
like
like
product
managers
like
as
a
release
manager,
sort
of
type
of
role,
can
kind
of
flip
the
switch
right.
D
A
A
B
D
A
D
D
C
A
A
C
C
A
A
A
C
B
I
I
the
way
I
understand
in
layman's
terms
is:
this
doesn't
necessarily
have
to
be
a
specialized
role,
but
imagine
a
team
that
practices
devops
you're,
paying
it
you're
literally
responsible
for
the
operations
of
your
service.
So
it's
not
just
about
writing
code.
It's
also
about
being
on
call
being
writing
your
gamble
files
for
your
pipeline,
etc,
etc.
E
C
A
A
Thankfully,
where,
if
there's
an
issue
with
the
kubernetes
agent
server,
that's
owned
by
the
configure
group,
then
we
are
immediately
brought
into
into
those
discussions,
and-
and
this
is
this
is
the
alison
approach
who,
when
when
we
are
both
immediately
into
setup
rights
where
we
have
to
be
there,
even
though
it's
not
about
software
development,
it's
more
about.
We
own
that
component.
C
B
B
E
C
A
B
A
A
B
B
D
B
B
A
D
And
victor,
I
think
what
you're
getting
at
with
like.
What's
the
signal
is,
like,
maybe
part
of,
like
maybe
similar,
to
what
we're
doing
with
the
options?
It's
like
there's
some
sort
of
like
check
and
the
incident
is
worked
on
some
fix
and
then
another
like
look
at
a
dashboard
or
check.
Things
are
okay,
post
deployment
right.
B
Which,
which
is
frankly
like,
can
be
really
complicated
because
it's
not
often
it's
not
just
about
the
service
itself.
It's
the
environment,
yeah.
So,
like
all
the
affected
neighbors
for
a
service
that
was
having
issues
you
want
to
look
at
your
entire
pod,
the
other
things
that's
around
that
depends
on
where,
upstream
or
downstream,
from
the
service
that's
affected.
D
D
I
was
yeah
I
was
just
saying.
I
was
just
saying
like
to
kevin's
point
like
that,
this,
this
sort
of
remediation
and
like
post
so
like
remediation
deployments,
checking
the
deployment
worked,
is
like
very
complex.
That's
what
sort
of
what
kevin
was
saying-
and
I
was
just
saying
that
like
well.
That's
that's,
probably
a
good
opportunity
for
us,
because
it's
so
complex,
it's
probably
like
an
area
where
we
should
collaborate
on
like.
A
Yeah,
I
I
might
have
said
the
same
so
please
catch
me
if
I,
if
what
I'm
saying
is
not
the
same,
but
I
was
thinking
okay,
how
can
you
move
forward
from
here-
and
my
idea
would
be
that
where
incident
comes
in
earlier
in
this
process,
because
environments
and
our
deployments
are
are
all
around
at
the
beginning
as
well,
is
how
do
you?
How
do
you
know
what
what
environment
you
are?
How
do
you
observe
the
given
environment
so
that
you
have
to
specify
those
things
somewhere
that
this
is
how
you
manage
the
environment?