►
From YouTube: Kubernetes Is Not For Developers and Other Things the Hype... - Taylor Thomas & Jordan Olshevski
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Kubernetes Is Not For Developers and Other Things the Hype Never Told You - Taylor Thomas & Jordan Olshevski, Microsoft
As a new or experienced user of Kubernetes, you’ve likely heard someone say something similar to “Kubernetes will make things so much better for your developers!” In this talk, we will examine why Kubernetes is not a developer tool and cut through other common misconceptions. Along the way, we’ll learn how Kubernetes provides powerful abstractions for running and operating applications. Luckily for us, there are many options for leveraging the abstractions Kubernetes provides to create a better developer experience. Drawing on real-life experience with Kubernetes at three large corporations, we will work through practical examples of using Helm, Draft, custom controllers, and other Kubernetes tools to build example platforms for empowering developers.
To Learn More: https://sched.co/GrRa
A
I've
spent
most
of
my
career
in
developer,
tooling,
and
infrastructure
management
in
one
form
or
another
I
started
out
working
in
data
centers
shelepin
around
servers
and
it
was
sort
of
dreadful,
ended
up
automating
myself
into
the
office
just
so
that
I
could
be
with
humans
instead
of
machines
that
was
nice
and
sort
of
just
kept
kept
doing
that
kept
at
it.
So
I've
been
yeah
working
on
I
worked
out
at
puppet,
worked
on
puppet
and
now
working
on
on
kubernetes
at
Microsoft.
This
is
Taylor.
B
You
know
I'm
Taylor
I
have
a
kind
of
similar
backstory
to
Jordan.
I
was
once
upon
a
time
doing
stuff
in
a
data
center.
Have
that
memory
of
pulling
out
a
live
drive
from
a
server
and
having
it
rent
your
arm
and
so
I've
also
kind
of
went
from
there
to
being
more
towards
a
developer.
I
started
more
towards
Intel
and
then
was
at
Nike
with
Jordan
and,
like
he
said
now,
we're
both
working
on
IKS
at
Microsoft
and
so
just
a
little
bit.
So
you
know
like
well
why
listen
to
us
about
these
ideas?
B
We're
gonna,
we're
gonna,
give
we've
collectively
built
various
application
platforms
for
different
kinds
of
enterprises
with
kubernetes
over
the
past
few
years.
So
this
talk
is
just
a
combination
of
what
we've
learned
along
the
way
and
sharing
some
ideas
and
conversations
that
we've
had
around
some
misconceptions
about
what
kubernetes
is
for
and
what
you
can
do
to
really
leverage
kubernetes.
A
So
Mead
the
app
developer
he's
a
good,
app
dev,
a
good
responsible,
confident,
app
developer
rights,
memory,
leak,
free
C++,
so
generally
probably
an
app
developer
cares
a
fair
amount
about
the
business,
at
least
what
the
software
does.
Hopefully,
what
the
software
does,
and
not
only
how
the
software
itself
is
constructed,
it's
sort
of
a
blend
right.
They
probably
have
a
background
in
the
business
that
the
organization
works
in,
in
addition
to
some
kind
of
computer
science
or
tech
background.
A
But
it's
it's
cross-functional,
and
this
is
a
really
good
thing
like
we
should
have
more
people
that
work
cross-functionally
that
understand
humans
and
are
able
to
translate
that
into
machine
talk.
And
ultimately
this
is
why
we're
all
here
right.
We
do
things
that
help
humans.
We
don't
just
help
machine
sort
of
satisfy
themselves
in
an
infinite
recursion,
so
they're
they're.
What
make
us
all
all
money?
It's
a
really
good
thing:
there's
sort
of
the
lifeblood
of
the
tech
organization.
A
A
There's
a
fish
on
the
deck
somehow
tentacles
in
capsule,
aiding
the
boat.
It's
a
real
mess
for
all
of
you
that
raised
your
hands
as
app
devs
I
suspect.
Maybe
you
have
felt
this
at
one
point
with
kubernetes
one
way
or
another:
oh
I'm,
seeing
some
nods
yeah
yeah,
we've
all
been
there,
and
so
ultimately,
we
would
attribute
this
to
the
idea
that
kubernetes
doesn't
hide
very
much
from
you.
A
It
exposes
the
the
computational
primitives
underneath
these
systems
that
we
deal
with
and
if
you
don't
have
a
solid
understanding
of
those
primitives,
then
cuber
Nettie's
doesn't
do
you
a
lot
of
good?
It
puts
a
lot
of
control
in
one
place
and
it
makes
those
primitives
very
obvious,
very
messy.
It's
a
very
sharp
knife,
so
primitives,
let's
define
that
as
let's
say,
processes,
files
kind
of
these,
these
system
e
things
that
maybe
app
developers
in
previous
years
didn't
stumble
on
everyday
simple
questions
become
difficult
to
answer
like.
A
Why
are
my
pods
evicted
sometimes,
should
I
worry
about
that,
taking
down
my
app,
how
do
I
just
get
all
the
logs
they're,
not
just
done
viral
aughh
on
one
server
anymore,
like
how
do
I
get
all
the
logs
from
my
app?
Is
it
normal
that
my
app
is
running
as
root
like
should
I
be
worried
about
that,
and
then
how
do
I
kind
of
roll
out
a
change
that
only
affects
certain
users
right
now
that
we
have
all
of
this
newfound
power?
A
So
why
bother?
Why
bother
sometimes
I,
don't
know,
I,
don't
know,
I!
Think.
Our
argument
is
that
cuber
Neddy's
justifies
its
own
weight.
It's
big
it's
complex,
but
it
models
something
that's
even
bigger
and
more
complex
and
by
kind
of
centralizing
control
of
these
computational
primitives.
We
gain
a
great
deal
of
efficiency.
We're
able
to
in
kind
of
practical
terms,
start
and
stop
many
processes
at
one
time
right
at
sort
of
a
primitive
level.
A
So
ultimately,
it's
those
higher-order
constructs
that
that
really
bring
the
value,
but
they
also
bring
additional
complexity,
and
so
there's
this
kind
of
dance
between
the
complexity
of
the
the
primitives
themselves
and
then
the
added
complexity
of
the
higher
order,
primitives
and
ultimately,
the
the
benefit
that
we
get
from
those
higher
order.
Primitives
is
a
sense
of
Industry
standardization
right,
even
if
you
individually
aren't
feeling
the
benefit
of
a
deployment
resource.
We
all
kind
of
agree
on
what
a
deployment
is
and-
and
that's
a
big
deal
for
like
for
us
as
an
industry.
A
So
the
takeaway
here
in
plain
terms,
is
the
cube
root.
Nettie's
is
really
hard.
It's
worth.
It
is
hard
because
the
systems
that
lie
underneath
are
hard,
so
it
often
makes
sense
to
specialize
so
meet
the
platform.
Dev
ie,
DevOps,
engineer,
sre,
infrastructure,
engineer,
new
school
sis
admin.
What
have
you
they're
pretty
hip
like
they
run
Linux
on
their
laptop?
A
They
write
go
generally
they're
there
they're
into
technology
in
a
way
right,
they're,
probably
not
as
interested
in
in
the
business
as
an
app
developer,
would
be,
and
for
a
reason,
they're
specialists
in
infrastructure
software,
usually
within
an
organization
they're
responsible
for
providing
a
platform
to
app
developers,
one
way
or
another,
the
boundaries
of
that
relationship
can
be
organic
or
can
be
somewhat
siloed
or
harsh.
It
sort
of
depends
on
the
situation,
but
you
know
you
see
a
lot
of
both
sometimes
they're,
even
embedded
in
app
development
teams.
A
It's
not
a
bad
idea,
so
this
is
all
things
considered.
We've
sort
of
seen
this
come
in
various
waves
in
the
industry,
right,
the
opposite,
dev
divide
and
then
that
breaking
down
and
sort
of
starting
to
kind
of
embrace
some
of
the
splitting
again,
but
we're
we're
making
a
positive
argument
for
this.
Of
course,
there's
lots
of
caveats
but
specialization
in
infrastructure
tech
specifically
around
kubernetes.
It's
not
a
bad
thing,
it's
a
very
good
thing,
because
ultimately,
it
frees
up
the
app
dev
to
do
the
human
machine
translation
that
makes
us
all.
A
You
know
our
cell.
At
the
end
of
the
day,
it's
very
good
thing,
so
here
I'm,
just
gonna
read
this
one
for
Batum
responsible,
kubernetes
users
limit
their
own
options
by
abstracting
away
what
is
constant
within
their
organization.
If
you
take
nothing
else
away.
Take
this.
This
is
the
job
of
a
specialist.
A
So
building
an
opinionated
platform
means
that,
at
the
end
of
the
day,
the
platform
engineer,
the
infrastructure
engineer,
what-have-you
is
limiting
the
options
of
app
developers.
That
maybe
don't
know
better
and
maybe
don't
need
to
know
better
Heroku
being
a
terrific
example
right
greatly
limited
options,
but
there's
a
freedom
that
comes
with
that
important
caveat
is
that
the
complexity
doesn't
go
away
just
because
it's
hidden
I
falls
on
another
person,
so
someone
still
has
to
manage
that
fleet
of
nodes
that
has
a
tendency
of
going
away
or
I'm
gonna
work
in
a
donut
here.
A
We're
gonna
work
it
in
okay,
so
let's
say
I
have
a
donut
and
it's
on
the
table
way
back
there
and
it
looks
like
a
perfectly
fine.
Donut
from
here
looks
delicious,
but
my
my
human
perceptive
mechanism
is
filling
in
a
lot
of
gaps.
I,
probably
can't
really
see
the
detail
of
the
donut
I,
just
kind
of
think.
Oh,
that's!
A
donut
and
I
take
the
donut
for
granted
right,
that's
a
good,
app
developer
thing.
A
The
donut
should
be
taken
for
granted,
but
what,
if
I
walked
closer
and
the
thing
was
actually
covered
in
in
bugs
like,
let's
say
ants,
it
wouldn't
be
wow.
This
is
an
overwrought
analogy,
I'm
making
it
work
the
infant's
infrastructure
engineers
job
would
be
to
stand
at
that
doughnut
and
to
pick
the
ants
off
of
it
and
then
I
would
pick
up
the
doughnut
and
eat
it.
A
So
the
perils
of
this
relationship
are
many,
and
ultimately,
if
you're,
in
a
a
position
of
either
the
app
developer
or
the
the
platform
developer.
In
this
situation,
you
should
sit
down
and
talk
and
actually
work
things
out
in
an
organic
way.
There's
probably
a
lot
of
pain
on
both
sides
of
this
relationship,
so
having
kind
of
a
human
element
getting
together
and
you
know
determine
the
bounds
of
that
specialization
determine
how
you
can
best
work
together.
This
is
a
very
deeply
human
pursuit.
It's
really
hard.
A
B
That
brings
us
to
the
nitty
gritty
details,
so
we've
been
talking
kind
of
a
little
bit
more
abstractly
about
the
different
things
that
you
should
consider,
but
if
you're
a
platform
developer
going
to
listen
to
an
application
developer,
what
are
the
actual
things
you
should
listen
for.
First
off,
you
really
need
to
understand
their
current
ops
practices.
How
do
they?
How
do
they
release
their
app?
Where
are
they
developing?
Are
they
developing
on
local
machines?
Are
they
sharing
a
server
somewhere?
B
There's
multiple
different
ways:
people
are
developing
their
apps
and
how
do
they
test
those
apps?
Is
there
unit
tests
and
then
do
they
have
a
specific
fleet
of
servers
that
they
run
tests
on?
There's
many
different
details
that
you
need
to
understand
about
how
they
run
their
ops
currently
with
an
application,
even
if
they're,
not
the
ones
doing
the
ops.
The
next
thing
is
learning
about
their
apps.
You
have
to
ask
questions
like
do
you
care
about
high
low
latency
or
high
throughput?
B
Do
you
need
high
availability?
I
mean
that
sounds
kind
of
like
a
dumb
question.
Everybody
wants
high
availability.
The
answer
actually
is.
No
most
people
don't
care
for
some
of
these,
especially
like
internal
apps.
If
it
goes
off
at
10
o'clock
at
night.
Most
of
this
isn't
on.
Nobody
cares
speaking
from
experience,
and
the
other
question
you
asked
is:
where
are
they
storing
their
state?
Are
they
storing
in
some
remote
data
store?
Are
they
storing
things
locally
or
with
some
sort
of
attache
disk
and
then
ask
what
technologies
do
they
use?
B
What
are
the
languages
they
use?
What
are
the
frameworks
they
use?
Those
are
critical
to
identify
for
some
of
these
abstractions
that
we'll
go
into
later
some
different
things
that
you
can
try.
You
have
to
understand
what
technologies
are
in
use
by
the
application
developers
and
then
another
one.
That's
really
interesting
is
identifying
their
business
requirements
and
some
people
go
wait,
but
we
have
our
own
business
requirements
and
they
have
their
own,
but
you
have
to
know
what
what
do
their
bosses
expect
and
how
are
they
measured?
Why
does
that
matter?
B
A
good
example
of
this
is
compliance
that
wonderful
word.
If
you
work
at
a
large
company,
you
probably
have
some
sort
of
security,
checklist
or
checklist
of
things.
You
have
to
get
done
or
approved
before
an
app
can
release
or
certain
changes
can
be
made.
Those
are
the
kind
of
things
that,
if
you
understand
what
their
processes
you
can
abstract
that
away
from
them
entirely
and
it
actually,
it
makes
both
sides
happy.
B
It
makes
those
wanting
the
compliance
to
have
just
something
automated,
so
it
always
happens
and
it
gets
rid
of
that
from
off
the
Optive
shoulders
now
last
and
most
importantly,
is
really
combination
of
the
previous
three
and
a
few
more
points
is
you
have
to
understand
how
they
think
about
their
systems.
One
of
the
best
exercises
you
can
do
if
you're
a
platform
developer
is
sit
down
with
the
app
developers.
B
You're
supporting
an
app
developers
be
willing
to
do
this
and
you
go
in
and
you
sit
down
with
together
and
you
map
out
what
what
does
the
system
look
like?
Everybody
has
a
slightly
different
mental
model
and
getting
that
out
helps
you
understand
what
you
can
make
easier
and
what
you
can
abstract
out.
You
can
also
start
understanding
what
legacy
things.
B
Could
you
make
easier
for
them
many
times
when
people
are
starting
to
move
their
apps
in
to
kubernetes
it's
something
from
something
more
legacy,
and
then
you
have
to
start
considering
how
they're
doing
things
within
their
systems
like
monitoring
and
tracing
and
logging,
what
kind
of
view
do
they
need
into
their
apps
and
what
kind
of
information
do
they
need
to
gather?
Because
some
of
it
is
something
that
maybe
only
you're
going
to
use
as
a
platform
developer
but
other
times
it
might
be
something
that
they
want
to
see.
B
So,
let's
get
even
a
little
bit
deeper
I'm,
sorry
for
the
terrible
Java
joke
for
the
title
of
this,
but
the
what?
What
are
the
things
you
need
to
consider
when
you're
implementing
something
that
an
app
developer
needs
so
I'm
going
to
be
going
into
some
examples
that
we've
seen
of
how
you
can
abstract
away
and
make
a
platform
built
on
kubernetes
that
developers
can
actually
use.
B
But
this
is
something
that
applies
to
all
of
them,
like
with
most
things
that
Devils
in
the
details
and
so
understanding
the
implications
of
these
details
is
a
platform
developer's
job.
So
you
have
things
like
a
service
and
an
ingress
you
have
to
decide,
are
using
a
service,
or
are
you
using
an
ingress
if
you
are
using
an
ingress
which
ingress
controller?
Are
you
using
what
kind
of
classes
of
ingress
do
you
want
to
set
up
and
why?
How
are
you
going
to
route
them?
How
you
gonna
provide
the
high
availability
for
them?
B
Those
are
all
things
you
have
to
consider
if
you're
doing
it
with
you're
doing
a
platform,
and
you
have
to
figure
that
out
for
networking,
then
you
also
have
things
like
our
back-end
policies.
You
have
pod
and
network
security
policies.
You
have
our
back
rules.
How
much
access
are
you
granting
to
an
application
developer
or
to
other
types
of
people
who
need
to
view
things
in
the
cluster?
Then
how
do
you
handle
things
like
deployment
scaling?
So
if
you
have
a
deployment,
what
is
your
update
strategy?
B
What
are
the
ways
you're
gonna
run
your
your
containers,
all
those
settings
that
you
see
on
a
pod
spec.
You
have
to
figure
out
each
of
those
details,
and
then
you
have
to
do
things
like
limit
rangers
like.
If
you
have
multiple
shared
resources,
you
have
to
find
a
way
to
make
sure
that
you
don't
end
up
with
the
noisy
neighbor
problem.
All
these
things
are
the
kinds
of
details
that
app
developers
generally
don't
want
to
handle,
and
that's
why?
Yes,
it
was
a
superlative
title,
but
we
actually
believe
that
kubernetes
is
not
for
developers.
B
These
are
the
kinds
of
things
that
they
shouldn't
have
to
worry
about
when
you're
developing
an
app
when
the
this
lifeblood
of
an
organization
is
developing
it.
So
let's
give
some
examples:
what
do
you
do
as
a
specialist
if
your
platform
dev
one
thing
to
understand
before
I
dive
into
this,
is
that
kubernetes
is
fundamentally
a
resource
oriented
system,
so
any
interaction
involves
one
or
more
API
resources.
You
have
to
work
with
the
way
to
protect
a
developer
from
kubernetes
is
to
template
or
generate
the
API
resource
just
for
them.
B
When
you
boil
down
all
the
options
we're
going
to
talk
about,
that's
eventually
what
it
comes
down
to
and
if
you're
a
platformer
dev
you
generally
think
okay,
how
can
we
do
this
with
software?
So
we're
not
just
like
running
these
things
manually,
so
I'm
gonna
walk
through
some
practical
examples.
Now
each
of
these
examples
could
really
be
their
own
talk,
so
we're
gonna
kind
of
brace
the
room,
but
these
are
based
on
real
things
we
have
done
and
seen
in
the
different
places
we've
worked
so
first
off.
This
is
kind
of
we're.
B
Gonna
start
with,
like
the
lowest
level
of
abstraction
to
the
highest
level
of
abstraction
and,
first
off
you
have
scripting
and
let's
face
it.
Just
at
the
beginning,
here
you'll
likely
use
some
sort
of
scripting,
no
matter
what
option
you
choose
like.
We
all
have
we've
all
written
bash.
We
all
have
to
write
bash
and
generally
a
make
target
that
all
happens.
B
That
will
still
be
there,
but
this
is
more
of
the
using
scripting
as
your
main
thing
for
deploying
to
kubernetes
now
I'm
curious,
how
many
of
you
have
used
scripting
for
your
kubernetes
said
it
before
either
currently
or
before?
Okay,
so
I
decent
amount.
That's!
This
is
how
I
actually
started
with
kubernetes.
B
But
as
you
can
see
here
on
this
slide,
we
have
how
the
app
dev
would
interact
with
this
method
and
the
platform
dev
and
an
app
dev
would
just
be
invoking
a
script
either
locally
or
with
the
script.
Runner
Jenkins
circle,
CI,
concourse
name
it.
You
can
I
mean
I,
guess,
I
work
for
Microsoft,
Azure,
DevOps
and
so
the
like,
and
any
of
your
script
runners
you
have
to.
B
They
have
some
way
to
invoke
it
and
then,
as
a
platform
developer,
you
define
those
scripts
and
the
arguments
that
it
takes
and
you
get
to
choose
the
platform
that
it
runs
on.
So
that's
what
you
would
do
from
a
scripting
sign
now.
I've
done
this
before
a
little
bit
with
with
ansible
and
bash,
and
it
turns
out
okay,
but
eventually
you
kind
of
run
into
things
where
you
want
to
move
to
something
more
evolved
and
that's
where
you
get
to
helm.
B
Has
that
and
you
can
install
some
amazingly
complex
systems
with
just
a
simple
command.
You
can
do
something
like
helm,
install
elasticsearch
and
instead
of
having
to
spin
all
that
up
yourself.
It
has
everything
already
predefined
and
some
knobs
you
can
configure
with
something
called
a
values
file.
It
also
provides
some
basic
life
cycle
management
called
hooks.
You
have
pre-installed
hooks
post,
install
hooks,
pre
update
hooks.
B
All
these
things
can
run
to
help
do
specific
things
for
the
life
cycle
of
the
application,
but
it's
limited
in
some
senses,
but
and
the
values
file
can
also
become
a
bit
constraining
because
eventually,
you
end
up
just
exposing
all
the
same
command
line
flags
that
your
application
needs
to
start
up
as
a
helm.
Value
now
helm
is
a
really
good
option.
If
there
are
many
common
pieces
of
software
that
all
your
teams
use.
This
is
things
like
security
tools
that
need
to
be
installed.
Logging,
specific
database
implementations.
B
All
of
those
things
are
really
good
for
for
sharing.
You
only
have
to
write
it
once
and
then
everybody
can
use
it.
You
also
have
to
recognize
that
there's
still
a
lot
of
knobs
here
and
cout
and
people
are
still
interacting
directly
with
kubernetes.
Your
developers
will
still
work
directly
using
coop
control
to
check
on
the
status
of
things.
This
is
okay.
If
your
developers
want
that,
but
really
it's
it's.
B
If
you're
trying
to
abstract
away
kubernetes,
it's
better
to
try
to
hide
away
as
much
of
that
as
possible
as
something
with
helm
is
that
it
gets
people
excited.
It
really.
Does
help
people
understand
kubernetes,
because
I
mean
the
first
time
I
used
it.
It
was
like
when
I
could
do
helm,
install
elasticsearch
or
helm
install
like
Maria
DB.
B
It
was
like
mind
blown,
and
so
it
really
is
a
good
opportunity
to
get
people
into
kubernetes
and
it
made
that
reuse
really
easily
easy,
but
you'll
find
helm,
wasn't
meant
to
be
a
life
life
cycle
management
tool
of
your
application.
That's
not
it's
its
primary
case,
and
so
sometimes
you
start
running
into
where
that
become
feels
a
little
bit
too
simplistic
for
you
as
you're
trying
to
do
something
more
complex
and
eventually
you
might
end
up
forking
all
your
charts
and
defining
every
variable.
B
But
the
thing
is:
is
it
is
still
a
great
model
for
the
app
dev
as
you
can
see,
they
can
manage
the
releases
and
they
can
get
the
state
of
their
app
and
then
the
platform
dev
just
has
to
maintain
that
chart.
So
next
one
is
a
CR
D
in
controller,
so
does
everyone
know
at
a
CR
D
as
a
customer
resource
definition,
yeah,
ok,
I'm,
making
sure
how
many
of
you
have
done
something
with
a
CR
D
and
a
controller
model
before
ok.
B
What
this
does
for
a
developer?
Is
they
manage
the
application
now
by
instantiating
and
modifying
a
version
of
that
resource?
So,
instead
of
having
to
deal
with
deployments
and
services
and
HBAs
and
in
ingress
and
yada
yada
yada
yada?
Now
it's
just
one
or
two
custom
resource
definitions
that
they
have
to
know.
So
it
greatly
reduces
the
space
of
what
you
have
to
use
in
kubernetes,
at
least
from
the
nap
dev
side
and
then
a
good
example.
I
guess
of
this
is
the
sed
operator,
which
is
one
of
the
longer
existing
operators.
B
This
is
a
great
thing
for
for
app
developers,
because
it
just
reduces
it
to
something
so
much
smaller
and
especially
if
you
have
some
common
things
that
happen
for
every
single
one
of
your
applications,
it's
easier
just
to
wrap
it
and
take
that
for
your
four
year
developers
so
last,
but
probably
the
most
highest
em
track.
This
one
is
a
little
bit
crazy.
This
is
a
custom
API,
so
I'm
just
curious.
Has
anyone
made
a
custom
API
on
top
of
kubernetes
that
they've
used
their
business?
B
B
I
should
say,
as
you
can
see,
the
idea
behind
the
custom
API
is
that
the
application
developer
would
just
have
to
call
the
API,
that's
wrapped
around
it
to
create
the
application,
and
then
they
give
some
sort
of
artifact
that
they
have
to
deploy,
whether
that's
a
container
or
a
binary
or
whatever
it
might
be
to
to
deploy
their
application.
Then,
from
the
platform
dev
side,
they
have
a
lot
of
other
work
because
they
have
to
create
define
the
API
and
they
write
the
controllers
and
the
business
logic
around
running
the
application.
B
It's
gonna
provide
a
very
opinionated
interface
and
the
users
don't
even
have
to
worry
about
kubernetes
at
all.
You
could
switch
this
out
entirely
underneath
for
something
like
Nomad.
If
you
wanted
to
oh
my
gosh,
you
mentioned
Nomad
and
a
kubernetes
talk,
but
like
the
it
doesn't
matter,
you
can
swap
it
out
underneath
for
anything
that
you
you
want
to
it.
B
Just
always
has
that
same
point
of
abstraction
for
your
users,
the
big
disclaimer
on
this
is
that
you
should
not
do
this
unless
you
are
probably
a
big
company
with
a
very
specific
need
when,
when
we've
done
this
before
this
is
something
where
we
could
identify
that
that
many
of
the
users
had
a
common
language
or
common
two
languages
and
frameworks
that
they
could
all
use.
The
example
that
we've
had
before
is
that
we
wanted
to
completely
hide
kubernetes
from
our
developers,
because,
as
we
sat
there
and
talked
about
ok,
what
do
our
developers
want?
B
They
just
wanted
the
place
to
run
their
apps.
They
didn't
care.
Containers
was
relatively
new
at
this
time
for
for
the
organization
we
were
in,
and
so
the
idea
we
thought
was
if,
for
example,
Java
if
everyone's
doing
Java,
then
why
not
just
upload
a
jar?
People
don't
even
have
to
worry
about
containers,
and
that
would
give
them
a
highly
highly
available.
B
Auto
scaled
app
with
a
TLS
certain
a
domain
name
with
with
a
way
to
view
some
basic
logs
and
system
metrics
and
then
also
conform
to
all
the
API
standards
that
already
exist
for
the
existed
for
the
organization.
So
I
said
this
in
is
very,
very
specific.
It's
probably
overkill
for
for
some
instances,
but
if
you
have
a
very
homogenous
use
case
where
it's
one
or
two
languages
and
a
few
frameworks,
this
can
actually
be
a
real
benefit
for
your
developers
and,
ultimately,
that's
what
all
these
are.
These
are
examples.
B
You
can
implement
these
kind
of
things
in
any
way,
but
you
have
to
know
that
your
developers
are
not
gonna
want
to
have
to
interact
with
kubernetes
all
the
time.
There's
some
that
do
and
if
you
do
that's
great,
have
fun
with
kubernetes.
It's
really
fun
to
do
that.
That's
how
I
started
with
it,
but
what
I?
What
I
have
seen?
I
know
that
Jordan
is
seen.
We
talked
about
this
as
we
as
we
wrote.
This
talk
is
that
most
the
people
we
see
they
don't
want
to
have
to
interact
with
kubernetes
a
lot.
B
B
I'll,
try
to
repeat
it
if
you
yell
it,
so
anyone
can
hear
it,
but
I
love
these
moments.
It's
like
we
either
board
you
all
to
death
or
explain
it
really.
Well,
okay,
awesome!
So
just
one
limb
things,
just
a
big
thanks
to
Emily
Jordan's
wife,
who
drew
all
these
things.
So
if
you're
interested
in
having
some
more
drawings,
you
can
always
reach
out
to
her
so
I
think
that's
it.
If
there's
no
other
questions
and
thank
you
very
much
there,
you
go.