►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Why Use Managed Kubernetes?: It's Dangerous to Go Alone! - Seth McCombs, Workday
Seth will cover common misconceptions and dispel myths around the usage of managed Kubernetes services. Without focus on specific services in particular, more of a push towards acceptance of managed services, especially if you're an engineer or leader that is considering Kubernetes but don't know how to get started. When discussing a managed Kubernetes service, responses have range from “why?” or “managed services aren’t as powerful” or the all too common reference to "vendor lock in" - often leaving those on the receiving end with a feeling of being lesser. Viewers will walk away from this session with more acceptance of managed services, and realize that using a managed service doesn't make one a bad engineer. There are many benefits to be had adoption of Kubernetes, and it's not a contest to prove how much you can build. If you have a small team and want to use Kubernetes, then a managed service can be the first step or only step towards Kubernetes usage.
A
Hi
everyone
thank
you
for
being
here.
My
name
is
seth
mccombs.
I
am
a
software
engineer,
focusing
on
cloud
orchestration
and
kubernetes
things
at
workday
and
in
the
upstream
kubernetes
project.
I've
also
spent
some
time
on
the
release
teams,
as
well
as
working
as
parts
of
sig,
docs
and
sig
release
in
the
past
today,
I'd
like
to
cover
a
topic.
Some
people
may
have
avoided
or
have
some
some
preconceptions
about.
A
So
you
know,
depending
on
where
you
may
find
your
infrastructure
running,
you
may
have
some
choices
there.
So
the
original
title
for
this
talk
was
a
little
more
aggressive
than
the
one
I
ended
up
going
with.
It
was
something
along
the
lines
of
using
a
managed
kubernetes
service
doesn't
make
you
a
bad
engineer,
and
while
I
still
believe
that
statement
wholeheartedly,
I
thought
it
was
best
to
lighten
up
a
little
bit
before
my
current
role
in
in
past
various
infor
related
roles.
A
I
found
that,
even
though
I
wanted
kubernetes
to
be
the
only
thing
I
was
working
on,
you
know
to
be
the
focus
of
my
day
today
that
wasn't
you
know
that
wasn't
the
case.
Kubernetes
was
the
platform
I
was
deploying
on
and
what
really
mattered
were
the
services
I
provided
to
my
end
users,
whether
they
were
the
developers,
the
actual
you
know,
consumers
of
the
product
or
service
the
company
made
the
executives
that
used
some
sort
of
service.
A
You
know
the
kubernetes
clusters
I
ran
were
just
a
means
to
an
end,
and
it
was
in
one
of
these
roles
that
I
came
to
terms
with
using
a
managed
kubernetes
service
and
it
was
a
service
provided
by
a
cloud
provider,
and
I
found
that
by
offloading
much
of
the
day-to-day
overhead
operational
stuff
I
needed
to
do
to
keep
clusters
running.
It
freed
me
up
to
work
on
some
other
cool
stuff
toil
less
and
it
was.
It
was
definitely
something
that
worked
for
me.
A
So
that's
it
right.
I
found
using
a
managed
kubernetes
service
worked
for
me.
The
story
has
a
happy
ending
and
we're
all
done.
Well,
I
found
sometimes
folks
at
cubecons
meetups
other
other
similar
events.
When
I
said
something
along
the
lines
of
you
know,
I'm
using
a
managed
kubernetes
service
from
my
cloud
provider.
I
often
received
one
response
more
than
others,
and
that
response
was
why.
A
A
Why
wouldn't
I
want
that,
so
I
learned
a
lot
talking
to
these
folks
and
you
know
some
some
whys
and
why
knots
for
their
decisions
to
not
use
these
services
a
lot
of
valid
points,
and
so
that's
what
I'm
going
to
talk
about
today,
I'm
going
to
try
to
dispel
some
myths
around
using
these
services.
With
some
experience
I've
had
in
the
past,
maybe
leave
you
with
some
answers
to
questions
you've
had
and
and
also
because
nothing's
perfect,
I'm
definitely
going
to
touch
on
on
some
negatives.
A
They
they
have
valid
reasons,
they've
built
their
own
tools
adapted
and
adopted
some
upstream
or
open
source
things,
and
that's
totally
fine
too.
I'm
not
telling
I'm
not
here
to
tell
you
you
need
to
use.
You
know
one
of
these.
These
managed
services,
these
kubernetes
as
a
service
kind
of
platforms.
I'm
only
here
to
say
that
it
is
totally
okay.
A
If
you
do
and
you
you
know,
don't
let
people
get
you
down
and
and
make
you
feel
like
you're,
any
less
deserving
of
space,
because
you
you
didn't
build
it
all
yourself
so
these
days,
kubernetes
is
the
go-to
buzzword,
we're
sitting
at
kubecon
right
now.
This
kubernetes
thing
is
big.
If
you're
not
using
it,
you
probably
want
to
use
it.
If
you
don't
use
it,
you
probably
have
a
valid
reason,
maybe
after
looking
into
it,
that
you
don't
want
to
use
it
these
days.
Kubernetes
clusters
aren't
something
you
take
to
the
bank.
A
If,
if
you've
moved
your
service
from
big
monoliths
to
containers
on
top
of
kubernetes,
that's
you
know
something
huge
to
brag
about
I've
done
it.
It's
a
there's,
a
lot
of
work
involved,
but
what
I
mean
is
it's
not
a
bullet
point
on
your
sales
pitch.
You
know
I'm
talking
about
if
you're
providing
like
a
sas
offering
here
when
someone
asks.
Why
should
I
use
your
product
or
service?
Your
two
points
for
your
sales
pitch
shouldn't,
be
we're
lower
cost
and
we
run
on
kubernetes.
A
What
really
matters
is
what
your
clusters
allow
you
to
do:
less
downtime,
faster
iterations.
On
the
you
know,
software
you're,
developing
and
deploying
if
you
can
deploy
your
micro
service
in
you
know
a
fraction
of
the
time
versus
your
monolith.
You
can
get
to
market
faster.
You
know
things
like
that.
I
believe
it
was
a
few
cube
cons
back
that
that
liz
rice
said
something
along
the
lines
of
kubernetes
is
boring.
It's
it's
what
you
do
with
it!
A
That's
interesting,
and
so
that's
how
I've
started
to
approach
my
use
of
kubernetes,
I'm
not
looking
in
my
day-to-day
to
run
the
most
customized
state-of-the-art.
You
know
amazing
clusters.
I
want
all
the
benefits
that
kubernetes
can
bring
me,
but
I
don't
need
the
bragging
rights
of
building
in
it
all
myself.
A
A
Some
providers
offer
you
a
managed
control
plane.
They
handle
the
api
servers,
the
controller
scheduler,
all
the
associated
bits
there.
They
give
you
an
api
endpoint
to
run
your
cube,
cuddle
commands
against
leaving
it
up
to
you
to
deploy
your
virtual
machines.
As
you
see
fit
some
sort
of
template
they
provide,
or
some
automation,
you've
built.
Others
have
automated
this
as
well.
It's
one
or
two
clicks
to
deploy
your
node
pools,
specify
size
count,
networking
all
that
stuff.
A
A
You
know
so
that
kind
of
moves
beyond
the
kubernetes
as
a
service
and
is
at
one
extreme
of
the
end
of
the
spectrum
there
and
then
you
know
I'll
also
call
out
some
of
the
companies
and
consultants
service
providers
that
can
help
you
configure
clusters
on
your
existing
cloud
platform.
You
know
or
one
of
these
managed
services.
You
know
they
help.
You
avoid
a
lot
of
pitfalls
for
setup.
A
A
So
what
do
you
get
when
you
pick
a
managed
service?
One
of
the
biggest
things
in
my
experience
that
I
always
think
of
was
the
peace
of
mind
around
somebody
else
running
my
fcd
cluster.
You
could
say
that
about
the
whole
control
plane.
You
know
I
will
that
is.
It
is
nice
to
not
have
to
worry
about
that,
but
I
first
thought
purely
about
fcd.
A
I
I
went
through
running
clusters.
Migrating
from
from
ncd
version
two
to
version
three
that
was
some
fun.
I
never,
I
hope
to
never
have
to
do
again.
I've
seen
what
happens
when
an
cd
cluster
gets
broken
and
split
brains
there.
You
know
you
start
getting
different
responses
back
every
other
time.
You
run
a
cube,
cuddle
command,
it's
just
it's
just
not
fun.
I've
been
using
kubernetes
for
a
few
years
now,
I'm
still
not
an
expert
in
running
a
control,
plane
or
or
an
entire
cluster.
A
So
when
I
can
offload
things
to
other
specialists,
it's
something
I'm
going
to
do,
and
so
that's
that's
one
of
the
biggest
points
I
I
start
out
when
I
start
talking
about
you
know
using
a
managed
service.
If
my
cloud
provider
has
a
team
of
experts
that
can
keep
this
running
and
and
that's
just
a
service
I
subscribe
to,
it
takes
some
some
overhead
off
my
plate.
That's
huge!
A
So
next
up,
you
have
more
time
to
do
the
other,
the
cool
stuff.
You
know
the
building,
the
deploying
of
things
actually
on
kubernetes.
You
know
I'm
not
going
to
mark
it
with
hey
here's
my
service
and
it
runs
on
kubernetes.
Unless
you
sell
an
application
that
runs
on
kubernetes,
normally
your
end
users,
don't
care
about
that.
A
They
want
your
service
to
be
up
working,
responsive,
scalable,
low
cost,
insert
buzzword
here
they
want
all
those
things
they
want
new
features
faster
and-
and
you
know
what
really
matters
is
what
you
build
on
top
of
your
cluster.
If
we
truly
talk
about
kubernetes
as
a
platform
that
you
know
democratizes
these
containers,
we
can
deploy
anywhere.
Why
wouldn't
I
let
someone
else
whose
sole
purpose
is
to
run
kubernetes
clusters.
Do
it
for
me,
you
know
I.
I
view
it
in
the
similar
vein
to
picking
frameworks
for
coding
and
things
like
that.
A
You
know
let
somebody
else
simplify
it
for
me
and
I
can
do
the
you
know
the
easy
parts
so
next
up,
you
know,
kubernetes
is
complex.
If
you
ask
an
engineer,
that's
been
using
kubernetes
for
a
few
years.
What's
one
thing
you
wish
you
could
change
a
lot
of
times?
It's
it's
some
form
of
make
it
less
complex,
oftentimes.
You
know
when
getting
started,
but
you
know
just
overall,
I'm
all
about
a
a
couple.
Click
process
to
deploy
a
new
cluster
scaling.
A
Some
people
don't
have
to
worry
about
their
api
servers,
handling
a
surge
of
requests
or
ensuring
they
have
sufficient
worker
nodes.
If
you
do
have
those
worries
you
know
using
these
managed
services
can
take
that
off
at
their
your
plate.
You
know
and
just
make
it
easier
for
you.
I
again
I
want
to
keep
working
on
what
I'm
building
there's
a
great
run
of
of
security
talks
at
kubecon,
and
you
know
current
and
in
the
past,
and
one
call
out
is
often
that
kubernetes
is,
is
rather
insecure
by
default.
A
You
know.
So
if
I
have
a
trusted
advisor
that
can
help
me
set
things
up,
configure
things
in
a
way
that
secures
my
workloads
gives
me
a
great
starting
point.
You
know
I'll,
take
it
and
and
why
I'm
calling
these
things
out
is
that
these
are
tasks
that
can
easily
take
days
of
work
from
one
or
more
engineers.
You
know,
and
those
story
points
start
to
add
up
and
all
of
a
sudden,
your
sprints
turn
into
crawls.
A
You
know,
basically,
you
don't
have
to
be
an
expert
in
all
these
things.
No
one
can
know
everything
and
that's
not
a
bad
thing.
By
and
large,
these
services
are
less
complex
than
doing
it.
Myself
have
you
ever
scrolled
through
the
readme
and
and
the
docs
for
one
of
the
services
you
would
use
to
deploy
a
cluster.
A
You
know
those
things
get
verbose
fast,
and
you
know
this
is
no
shade
to
teams
that
write
these
docs
and
these
readmes.
You
know
they're
doing
heroes,
work,
but
there's
only
so
much
you
can
do
to
make
a
you
know.
The
configuration
of
a
complex
service
read
is
less
complex
and
and
the
source
code
for
kubernetes
there's
a
lot
there.
You
know
so
again.
I
want
to
build
on
top
of
it
and
let
somebody
else
specialize
in
running
the
platform.
A
So
next
up
we've
talked
about
what
it
is.
We've
talked
about
some
some
pros.
Why
I
like
it?
You
know
why
you
may
like
it
using
these
services
and
just
want
to
call
out
a
couple
common
complaints
that
people
would
have
when
I
would
tell
people.
I
used
these
these
types
of
services
and-
and
I
know
we're
all
we're
all
thinking
this
one
because
we're
all
conscious
of
our
cloud
spends.
So
doesn't
it
cost
more?
A
A
If
I
just
look
at
the
bill
from
my
cloud
provider
or
my
service
provider,
I'm
going
to
see
you
know
whatever
the
managed
api
endpoints
for
my
clusters
cost
per
hour
and
and
that
may
drive
my
bill
up,
but
on
the
other
side
of
things
you
know,
there's
still
someone
who's
hands
on
keyboards,
automating
and
setting
up.
You
know
my
self-managed
clusters
and
and
things
like
that,
there's
still
people
at
those
keyboards
hacking
away
on
stuff.
So
you
may
have
a
team
of
one
person.
A
You
may
have
a
team
of
20.,
but
either
way
I'm
I'm.
You
know
almost
100
certain
that
that
person's
not
working
for
free
and
you
pay
them
to
do
what
they
do.
So
you
have
to
think
you
know:
what
are
you
saving
in
terms
of
of
spend?
Are
you
spending
less
on
your
bill,
but
paying
your
engineer
for
more
time.
A
You
need
to
figure
that
out
in,
in
my
past
experience
I
found
that
by
you
know
unblocking
myself
to
build
cool
stuff.
When
I
was
you
know
a
team
of
one
at
a
mobile
app
startup
by
making
somebody
else
have
to
worry
about
the
I
want
to
run
kubernetes
kind
of
thing
and
get
me
just
get
to
deploy
more
things
on
top
of
it.
A
Not
only
did
I
sleep
better
at
night,
but
I
was
able
to
get
more
stuff
done
and
to
me
that
was
worth
the
the
increase
in
our
cloud
bill
and
and
thus
an
argument
I
was
able
to
take
to
the
actual.
You
know,
people
that
paid
that
bill
and
say:
hey
here's,
why
we
need
this.
So
with
most
things
around
cost
and
money,
it's
multi-faceted,
you
know,
what's
the
cost
of
running
your
own
versus
managed
service?
What
is
the
time
your
engineers
spend
on
these
upgrading
recovering?
A
You
know
what
is
their
time
worth
and
and
how
do
you
break
that
down?
Could
they
be
automating,
something
else
you
know
deploying
a
new
service
scaling
to
a
new
region.
All
these
things
add
up,
and
I
think
it's
worth
looking
into
you
know.
So
one
call
out.
Don't
take
this
as
permission,
you
know
if
you
are
some
sort
of
executive
or
engineering
leader.
Don't
take
this
as
permission
to
fire,
your
engineering
team,
if
you
move
to
a
managed
kubernetes
service,
that's
not
what
I'm
saying.
A
I'm
saying
that
unless
you
need
the
customizations
of
managing
your
own
clusters,
choosing
a
managed
service
allows
your
engineers
to
focus
on
higher
level
higher
priority
projects.
You
should
not
be
removing
those
engineers
entirely;
they
should
be
building
the
stuff
that
matters
not
just
the
platform
so
another
another
thing
around
around
around
cost
that
that
is
a
little
abstract
is,
is
what
about
the
the
vendor
lock-in
that
that
people
think
of
you
know
that
was
the
other
thing
is.
A
I
don't
want
to
be
stuck
on
this
specific
provider's
platform,
and
that
may
be
your
case
and
I
empathize
with
that.
So
one
of
the
things
that
I
think
about
with
these
managed
services-
you
know
if
you're
on
a
cloud
you've
already
picked
your
cloud
you're
using
their
service
for
vms
or
or
manage
database
service,
you're,
letting
them
handle
networking
things
like
that,
you're
all
you're
pretty
invested.
So
where
do
you
draw
the
line
this?
This
may
be
it
this
may
be.
A
A
Maybe
this
is
maybe
the
line
is
somewhere
past
this
and
you
say
no,
no,
let's
use
their
service,
you
know
and
and
have
them
run
our
our
kubernetes
clusters.
You
know
this
is
the
trust
you've
made
with
your
provider
to
handle
the
physical
side
of
things
and
and
where
you
draw
the
line
with
what
you
deploy
on
top
is
is
something
you
need
to
figure
out.
You
know,
so
you
may
find
that
if
you
want
to
move
from
one
cloud
provider
to
another,
there
may
be
some
concessions
you
need
to
make.
A
But
you
know
I
I've
never
encountered
companies
that
really
change
cloud
providers
overnight.
It's
it's
definitely
not
a
decision
made
lightly
and
and
all
these
managed
services
are
all
kubernetes
objects.
At
the
end
of
the
day,
it's
deployments
and
pods
and
stateful
sets
and
volumes
all
the
way
down.
So
you
know
you
can
take
your
kubernetes
stuff
from
managed
service
a
and
deploy
it
on
managed
service
b,
it's
just
the
initial
setup
that
might
look
a
little
differently
now.
This
is
different
than
using
what
I
called
out
earlier.
A
You
know
one
of
those
fully
managed
services
where
you
basically
upload
your
containers
and
they
handle
all
the
other
things
that
pretty
much
abstracts
away,
kubernetes
and
and
that
that
may
be
your
serious
vendor
lock-in,
but
it
also
might
be
beneficial
depending
on
the
size
of
your
operations
teams.
You
know,
so
it
depends
on
what
you're.
Looking
for
you
know,
you're.
Writing
your
your
code,
you're,
building
your
container
images.
You
write
your
helm,
charts!
You
break
out
your
ruler
to
indent
your
yaml,
you
know,
but
it's
going
to
be
a
cluster.
A
A
So
next
up
you've
decided
to
look
into
your
managed
kubernetes
service.
You
know
what
are
you
looking
for?
What
do
you
want?
So
you
know
the
first
thing
to
call
out
is:
does
your
cloud
provider
have,
do
you
have
options?
Does
your
cloud
provider
have
different
methodologies
of
setting
this
up?
Do
you
only
have
one
option
and
then
it
kind
of
comes
down
to
maybe
a
binary
decision
to
you
know
self-manage
or
not,
you
know.
So
what
do
you
look
for?
A
One
of
the
things
I
was
looking
for,
or
was
intrigued
by
was
you
know
how
many
buttons
did
it
did?
I
have
to
click
to
get
set
up.
How
long
did
it
take
me
to
deploy
these
things?
You
know
there's
a
decent
chance
that
no
matter
how
many
buttons
you
have
to
click
to
get
set
up,
it's
probably
easier
than
writing
these
config
files
on
a
self-managed
cluster
yourself.
A
A
Is
there
historical
records
of
security
issues
in
the
past,
maybe
based
on
their
platform-specific
setup?
You
know
that's
something
to
think
about,
and
then
lastly,
you
know
what
do
they
expose
in
terms
of
metrics?
You
know
monitoring
and
keeping
an
eye
on
these.
These
things
that
you're
using
to
run
your
infrastructure.
A
You
know
most
cloud
providers
have
some
sort
of
inbuilt
visualization
tool.
They
let
you
see
some
logs
and
metrics.
You
know
access
logs
are
also
important
for
security.
So,
while
you
may
abstract
away
some
of
the
management
of
the
the
administrative
administrivia
of
your
cluster,
you
know
you
still
want
to
understand.
What's
going
on,
you
know
how
how
obscure
is
is
too
obscure
and
abstract
for
these
things
you
know
so,
like
any
solution,
you
know
there's
a
a
lot
of
these.
A
These
fun
fun,
sre
related
terms
up
times,
slos
slis
things
like
that.
What
what
do
they
guarantee
in
terms
of
availability?
How
many
nines
do
you
get
at
the
end
of
the
day?
If
that's
something
you
care
about
what
happens
if
the
service
goes
down,
you
know,
are
there
historical
records
of
long
outages
that
that
maybe
are
too
much
risk
for
you
to
take
on
you
know:
how
does
this
compare
to
your
existing
infrastructure?
Having
issues
you
know?
Is
it
more
or
less
risky?
A
You
know
this.
This
is
one
of
those
things
to
think
about
when
thinking
about
that
lock-in,
you
know
if
you're,
if
your
providers,
you
know
object,
storage
breaks,
is
it
any
more
or
less
damaging
than
if
their
kubernetes
clusters
go
walk
about?
You
know,
and
you
start
having
problems.
You
know
so
there's
definite
trade-offs
there,
and
it
also
depends
on
just
your
your
your
team
power.
How
many
hands
you
have
on
keyboards
to
to
keep
these
things
running,
so
we
want
to
make
sure
providers
keep
up
their
end
of
the
deal.
A
So
many
people
talk
about
their
cloud
providers
when
they
have
an
issue,
you
can
get
a
refund,
you
can
get
cloud
credits
and
credits
are
great.
That's
awesome.
That's
less
money
to
spend
on
the
bill,
but
I
bet
that
oftentimes,
the
credits
you
get
aren't
equal
in
value
to
lost
revenue
or
lost
productivity,
so
you
know,
weigh
the
options
and,
lastly,
how
do
they
handle
just
overall
upgrading
how
how
one
touch
or
how
how
white
glove
for
lack
of
a
better
term?
A
Is
it
how
you
know
how
smooth
do
these
things
go?
Does
it
does
it
offer
down?
Does
it
make
you
your
clusters,
take
some
downtime.
Is
it
a
single
click?
You
know
things
like
that:
how
do
they
patch
the
operating
systems
and
run
times?
Is
that
exposed
to
you?
Do
you
even
care?
You
know
these
are
some
kind
of
some
of
the
questions
to
add
to
your
kubernetes
shopping
list.
So
you
know,
there's
not
one
way
to
do
this.
There's
there's
a
couple
paths.
A
I've
seen
taken
in
the
past
on
how
to
deploy
these
services
or
how
to
at
least
begin
your
investigation.
I've
used
I've
used
both
of
them.
You
know
the
first
being
you
you're,
not
using
kubernetes.
You
want
to
use
it
you've
heard
about
this
thing.
You
want
to
check
it
out.
The
other
one
being
you're
already
building
and
deploying
your
own
clusters
using
some
sort
of
framework,
either
upstreamed
or
in-house.
A
You
know
for
the
first
one
you
want
to
see
what
it's
all
about.
Why
waste
your
time,
diving
into
the
weeds
configuring
all
these
these
bits
and
and
twiddling
all
these
these
knobs?
If
you
have
a
platform
available
from
your
cloud
provider,
they
probably
have
a
managed
kubernetes
service,
so
you
know:
try
it
out,
see
how
it
works.
What
are
the
options
available
and
and
think
about
later,
whether
or
not
you
need
all
the
customization?
A
You
might
not
know
what
you're
missing,
and
that
might
be
a
good
thing.
So
you
know
just
really.
This
is
good
enough
to
make
sure
kubernetes
is
right
for
you
because
there's
a
whole
other
talk.
I
could
give
about
whether
or
not
you
need
a
kubernetes
cluster,
but
that's
not
what
I'm
here
for,
if
you're
not
running
on
a
public
cloud
you're
in
a
colo
or
you,
you
know,
have
your
own
data
centers,
you
can
still
fire
up
a
cluster
on
a
public
cloud
service
check
it
out
and
see.
A
A
So
you
know
the
big
thing
that
I
liked,
as
I
called
out,
was
the
delay
on
a
lot
of
the
configuration
choices
I
needed
to
make
and
just
try
it
out
with
a
managed
service
and
say
hey.
I
like
this,
this
paradigm,
this
declarative,
syntax
and
then
decide
later.
If
you
need
more
customization,
there
are
thousands
of
blogs
videos
conference
talks
all
over
the
internet,
how
to
get
more
out
of
your
cluster.
A
So
if
you
decide
later
on
down
the
road
that
customization
is
what
you
need,
then
you
can
move
to
a
place
where
you
run
your
own.
So
you
know
the
other
side
of
that.
The
flip
side
of
the
coin
is
maybe
you're
already
doing
it
yourself.
You
hopped
on
the
bandwagon
early
or
late,
and
you
know
you've
got
your
clusters
running
you're
ready
to
go.
A
You
find
that
your
engineering
team
spend
a
lot
of
time,
keeping
these
things
up
to
date,
keeping
them
running,
and
you
want
to
find
an
easier
way.
Why
not
take
a
development
environment
and
stand
up
on
a
managed
cluster?
Is
it
easier?
Does
it
work
better?
Do
the
devs
even
notice
a
difference
depending
on
how
you
answer
these
questions?
If
it
looks
good
move
forward
and
lastly,
it
doesn't
have
to
be
all
or
nothing
as
well.
Maybe
you
have
some
sort
of
tooling
cluster
where
your
ci
cd
stack
runs.
A
You
know
sort
of
jenkins
lives
or
something
like
that.
You
don't
need
a
lot
of
customization
there,
but
it
does
need
to
be
rock
solid.
You
can
use
a
managed
service
for
that.
That's
a
valid
use
case.
Maybe
your
production
environments
need
to
be
hyper
customizable,
you
need
all
those
knobs
and
dials.
You
need
to
change
your
api
server
flags
and
all
that
fun
stuff,
but
for
the
dev
environments
or
these
admin
environments,
your
logging,
aggregation
or
monitoring
environments.
A
You
know
maybe
those
can
be
managed
clusters
because
they
they
either
change
too
often
or
not,
often
enough
that
it
really
matters.
You
know
it
can
help
to
offload
some
of
this
setting
up
and
configuring
in
these
environments
and
you
don't
have
to
move
your
entire
workload
to
a
managed
services.
Maybe
move
some
of
your
stack.
A
You
know,
so
it's
it's
different
on
a
case-by-case
basis.
Maybe
you
save
some
money,
you
probably
save
some
time.
You
know
you
unblock
your
ops
and
infra
teams
from
you
know,
working
on
everything
that
they
don't
want
to
toil
on
and
they
get
to
spend
some
time
actually
keeping
the
production
environments
producing-
and
you
know
maybe
their
devs
get
the
baseline
environment
with
a
few.
You
know
mouse
clicks
and
they
get
to
work.
A
So,
as
I
said
at
the
beginning,
maybe
it's
an
easy
choice
and
you
have
a
cloud
provider
and
they
offer
a
kubernetes
service.
Does
it
fit
your
needs?
Maybe
they
have
multiple
options
at
different
levels
of
managed
or
abstractions.
You
know
at
the
least,
but
no
matter
which
way
you
go
building
it
brick
by
brick
or
you
know,
allowing
a
provider
to
do
it
for
you
or
taking
it
all
in-house
and
doing
it
yourself.
My
whole
point
here
has
been
we're
all
here
to
build
some
cool
stuff.
A
It
doesn't
matter
how
you
get
there
from
scratch
with
the
head
start
of
a
managed
service-
and
I
don't
just
you
know,
push
on
this
from
a
kubernetes
specific
point:
build
your
cool
stuff
use
the
tools.
You
need
the
tools
you
like,
whatever
works
for
you,
the
bragging
rights
that
you
self-manage
your
clusters,
make
you
no
more
skilled
than
the
team
that
uses
cloud
provider.
X's
manage
kubernetes
services,
and
I
think
this
is
a
big
takeaway,
especially
around
these
conference
times
cube
cons
can
be
overwhelming
the
first
time,
the
third
time
every
single
time.