►
From YouTube: Abstracting Heavy Lifting: How K8s Speeds Up Multi-Cloud Solution Delivery - Rob Zuber, CircleCI
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
Abstracting Heavy Lifting: How K8s Speeds Up Multi-Cloud Solution Delivery - Rob Zuber, CircleCI
At CircleCI, we build a complex, distributed system for CI/CD used by thousands of sophisticated teams. While we started as a single-cloud, SaaS product, we’ve grown to serve huge customers, across clouds and behind customers’ firewalls. With scale came issues in our ability to build, distribute, and manage our product. CircleCI CTO Rob Zuber will discuss how we hit the limits of distribution via an unsophisticated orchestration engine, and how consolidating on K8s helps us control networking, security, and availability while minimizing one-off work. K8s also allows us to live a value: only building what is a core differentiator to our business. Even if your team isn’t selling a distributed system, you can apply what we’ve learned. Abstracting your heavy lifting makes it possible to escape the whims of AWS, GCP, or Azure, reduce maintenance, and ultimately, helps drive velocity.
To learn more: https://sched.co/GrRv
A
I
am
Rob
Sumer
CTO
of
circle
CI,
thanks
for
for
joining
and
I
want
to
talk
to
you
today
about
abstracting,
heavy
lifting
so
at
circle,
CI
we're
very
focused
on
developer
productivity,
helping
engineering
teams
do
the
job
that
they're
they
should
be
focused
on
doing
and
taking
away
a
lot
of
what
we
call
undifferentiated
heavy
lifting
and
a
lot
of
the
work
that
really
you
know
you
can
leave
to
someone
else,
and
so
we
think
about
that.
A
lot
in
terms
of
the
product
that
we
deliver.
But
we
also
think
about
that.
A
A
So,
as
a
company,
we
do
continuous
integration,
continuous
delivery
or
continuous
deployment.
We
offer
that
in
the
cloud
where
we
manage
all
of
your
compute
for
you
and
execute
your
jobs
on
your
behalf,
and
we
also
have
a
server
offering
where
you
can
take
our
product
and
and
manage
it
and
run
it
yourself.
A
We
in
in
our
cloud
environment,
we
support
about
300,000
developers
across
well
over
12
million
builds
a
month
at
this
point
and
a
little
over
25,000
organizations,
but
it
wasn't
always
this
way.
So
if
we
go
back
a
little
bit,
Circle
CI
was
founded
in
2011
and
launched
the
product
in
the
beginning
of
2012
and
I
always
like
to
start
with
architecture
diagrams.
That
look
a
little
bit
like
this,
because
this
is
basically
what
we
had
built
right.
A
It's
a
start-up
we're
not
really
sure
what
it
is
we're
trying
to
achieve
and
if
you're
a
new
company
or
launching
a
new
product.
This
is
usually
what
your
product
looks
like
right.
It's
it's
very
simple.
It's
easy
to
reason
about,
and
it's
easy
to
manage
in
in
your
production
environment,
and
we
only
had
one
offering.
A
We
were
offering
this
service
in
the
cloud
again
running
your
compute
on
your
behalf,
executing
jobs
on
your
behalf,
so
that
you
could
focus
on
on
building
your
business
fast
forward
to
about
2015
and
we
decided
to
also
offer
a
server
product
and
so
the
difference
there
is.
You
would
take
our
application
and
run
it
on
your
own
premise
or
under
your
own
premises,
behind
your
firewall
and
basically
running
the
thing
that
we
are
running
in
the
cloud
and
again
that
the
architecture
was
pretty
straightforward
right.
A
A
A
A
So
the
coordination
of
some
some
jobs
within
our
environment,
along
with
license
management,
upgrades
some
phone
home
around
who
our
customers
were
and
how
they
were
using
the
product,
etc,
and
so
that
was
that
was
great
and
got
us
into
the
market
and
allowed
us
to
to
deliver
this
on-premise
solution
fast
forward.
Another
year
and
suddenly
our
product
looks
like
this
right.
Our
engineering
team
is
scaling,
our
service
is
scaling
and
instead
of
just
having
a
simple
model,
if
now
we
have
a
large
collection
of
services,
all
of
which
talk
to
each
other.
A
I,
obviously
didn't
draw
the
network
interactions
between
them
here,
but
it's
a
very
different
view
of
a
product
and
five
monoliths
across
the
bottom.
Because
not
only
do
we
have
all
these
services,
we
still
have
a
monolith
and
we've
taken
the
monolith
and
configured
it
in
a
bunch
of
different
ways.
A
This
leads
to
some
challenges,
in
fact,
because
we
have
a
distributed
system.
We
really
have
more
like
N
squared
problems,
so
every
single
thing
that
we
do
inside
of
our
product
inside
of
our
environment,
we
have
to
solve
in
two
different
ways
how
we
manage
communication,
how
we
manage
configuration
and
it's
starting
to
lead
to
a
set
of
challenges
for
us
in
terms
of
delivery,
which
is
you
know,
our
our
teams
are
deploying
things
into
the
cloud
where
it's
where
CIN
CD
companies,
so
we
do
continuous
deployment.
A
We
are
using
configurations
sort
of
tailored
for
kubernetes,
as
we
push
things
out
into
the
cloud
environment,
and
then
we
go
to
package
up
a
release
of
our
server
product
and
it
turns
out
that's
something:
we've
done
in
terms
of
our
product
to
get
into
cloud,
doesn't
work
properly
in
the
server
environment
because
we're
using
a
completely
different
scheduler,
with
different
configuration
mechanisms,
etc,
etc.
So
now
we
need
to
find
a
way
to
to
get
out
of
this
this
situation.
A
You've
got
developers
who
are
working
specifically
in
their
dev
environments
and
you've
got
operators
who
are
sort
of
holding
the
keys
to
the
kingdom
in
production
and
in
between
what
I
often
refer
to
as
the
chasm
of
despair,
like
the
notion
that
you
were
actually
gonna
get
something
from
development
into
production
was
everybody's
nightmare
developers
didn't
want
to
have
to
deal
with
it,
operators
didn't
want
developers
changing
their
environment,
I
mean
we
all
remember
what
that
looked
like
right.
So
we
started
to
have
a
shift
in
culture
and
that
shift
started
with
automation
right.
A
If
we
have
some
good
tooling
that
allows
developers
to
move
things
from
their
development
environment
into
production,
then
maybe
we
can
solve
some
of
the
challenges
we're
facing
right.
So
we
get
to
smaller
increments.
We
deliver
those
with
lower
risk
profile
and
everyone's
a
little
bit
happier
about
the
kinds
of
changes
that
we're
making
in
production
and
confident
that
we
can
undo
those
changes
or
fix
them
quickly
as
we
run
into
them.
A
And
so
this
is
I
think
been
really
good
for
all
of
us,
because
it's
an
opportunity
to
to
really
refine
and
and
learn
from
each
other.
So
this
photo
is
a
it's
a
piece
of
Japanese
humor
that
I
love,
so
rgm
of
Japan
was
in
town
and
brought
these
t-shirts.
This
is
myself
and
our
CEO
and
his
t-shirt
says:
I
actually
can
I
can't
even
read
it.
So
you
probably
can't
I
completely
understand
Circle,
C,
I
and
my
t-shirt
says:
I
can
do
Circle
C
I
a
little
and
with
a
great
sense
of
irony.
A
So
here
are
some
things
that
we've
learned
and
how
they
apply
to
this,
this
pathway
of
getting
us
into
a
better
place
from
an
overall
operational
perspective.
First,
you
want
to
understand
your
customer
I
mean
ultimately,
at
the
end
of
the
day,
you're
building
for
a
customer
and
if
you're
very
clear
about
who
your
customer
is
and
what
they
need,
then
you
can
make
sure
that
you're
building
the
right
things
and
building
the
right
thing
saves
a
lot
of
time.
A
Focus
on
your
core
competencies
right,
don't
build
the
things
that
are
not
really
differentiating
you
as
a
business
use,
abstractions
to
isolate
change
and
use
abstractions
to
reduce
complexity,
so
starting
with
the
first
one
understanding
your
customer.
So
this
is
this
is
Maya
Jenny,
Dante
and
Diego,
and
therefore
personas
that
we
use
internally
at
circle
CI-
and
this
is
really
helpful
for
us.
They
represent
not
just
the
developer,
who
is
using
our
product
to
do
CIN
CD.
A
They
represent
the
operator
within
a
company,
that's
managing
our
platform,
business
decision-makers
and
engineering
management,
everybody
who
would
participate
in
the
use
of
our
platform
so
that,
as
we
think
about
what
we're
trying
to
deliver
we're
very
clear
about
the
person
for
whom
we're
trying
to
deliver
it
and
what
their
needs
are
as
a
customer-
and
this
is
great,
but
your
personas
are
only
as
good
as
they
are
correct.
So
if
you
miss
read
your
customer,
then
you're
gonna
be
building
to
the
wrong
set
of
needs.
A
So,
as
we
looked
at
this
challenge
of,
we
have
you
know
one
way
of
deploying
for
server
another
way
of
deploying
for
cloud.
We
had
to
sit
down
and
reflect
on
who
our
circle
CI
server.
Customer
really
is,
and
this
is
the
the
operator
of
the
product.
So,
first
of
all,
if
you
are
taking
our
cloud
offering
and
running
it
yourself,
you're,
probably
a
very
sophisticated
development
shop.
A
If
you
don't
think
that
you
can
make
use
of
our
operating
this
thing
for
you,
then
you
probably
have
a
team
of
some
significant
size
with
the
ability
to
manage
a
reasonably
sophisticated
product,
and
so
the
notion
that
a
sort
of
one-click,
install
or
simplicity
is
going
to
be
the
most
important
thing
for
you.
It's
maybe
not
correct.
A
Second
you're,
probably
experienced
with
kubernetes
I
mean
at
this
point
in
2018,
were
at
coop
con
with
8,000
other
attendees
like
kubernetes,
is
out
there
right.
There
is
a
lot
of
understanding,
there's
a
lot
of
resources
in
order
to
be
able
to
manage
something
like
this
and
so
giving
someone
something
that's
completely
prepackaged
and
different
may
or
may
not
be
the
right
outcome
for
us,
probably
not
at
this
point.
Live
upgrades
are
more
valuable
than
one-click
upgrades.
So
what
that
means
is
a
company
that's
running
our
our
server
install
is
again
a
sophisticated
shop.
A
And
finally,
they
generally
operate
like
a
multi-tenant
cloud,
so
Circle
CI
was
designed
and
built
so
that
we
could
operate
the
service
and
many
many
different
companies
and
different
customers
could
use
the
service
to
get
their
work
done,
and
this
is
actually
what
very
large
software
organizations
look
like.
There
is
a
team
that
is
central,
creating
leverage
and
creating
efficiency
for
their
engineers
and
the
engineers
need
control
of
their
own
ability
to
work
so
that
central
team
can't
be
managing
changes
to
configuration
updates
to
the
server
etc.
A
Just
for
the
needs
of
one
specific
development
team.
So
they
really
operate
in
the
exact
same
way
that
we
operate,
which
is
again
like
a
like
a
multi-tenant
cloud
and
so
providing
them
a
system
that
looks
and
operates
like
more,
like
our
actual
cloud
system
is
the
best
fit.
So
now
we
have
a
much
clearer
picture
of
our
customer
next,
we
want
to
make
sure
that
we're
focusing
on
our
core
competencies
and
the
things
that
really
drive
us
as
a
business.
So
we
spent
a
lot
of
time
this
year.
A
Thinking
about
domain
driven
design,
I,
don't
know
if
anybody
here
is,
has
read
this
book
or
books
liked
it
or
thought
about
domain
driven
design.
I
would
highly
recommend
it
it's
really
about-
and
this
is
the
original
book
by
by
Eric
Evans,
who
sort
of
drove
this
thinking,
but
there's
a
number
of
other
authors
who
have
who
have
written
similar
books
and
it's
really
about
understanding
your
domain
overall
and
recognizing
that
large
software
systems
are
complex.
A
It's
difficult
to
reason
about
the
entire
thing
at
once,
and
therefore
you
need
to
break
it
down
into
subdomains,
and
one
of
the
most
important
pieces
of
that
exercise
is
understand
which
of
those
subdomains
are
really
critical
to
you
and
our
core
to
what
you're
offering
as
a
business
and
which
are
are
not
there
supporting
or
generic.
So
this
is
a
bit
of
a
map
of
what
that
looks
like
for
us
at
circle.
Ci
I
described
already.
We
do
continuous
integration,
continuous
deployment
and
that
really
breaks
down
for
us
into
two
core
domains.
A
One
is
workflow
coordination,
which
is
an
overall
graph
of
the
jobs
that
you
want
to
run
and
how
they
are
interrelated.
What
the
dependencies
are
such
that
when
one
completes
successfully
another
should
run
or
if
one
fails,
what
the
outcome
should
be
overall
for
the
workflow
and
then
the
other
is
job
execution
which
is
really
finding
capacity
in
the
system.
Configuring
it
correctly
and
executing
the
actual
steps
of
work
that
you
want
us
to
execute
in
order
to
validate
and
build
your
software
or
to
deploy
it
into
your
production
environment.
A
And
then
all
these
things
around
the
edges,
like
plans
and
payments
I
think,
is
a
great
example,
our
generic,
in
the
sense
that
no
one
comes
to
circle
CI,
because
they're
super
excited
about
how
we
charge
their
credit
card.
They
might
be
annoyed
if
the
form
doesn't
work
properly
or
something
like
that,
but
we're
not
changing
the
world
of
CI
and
CD
with
better
payment
forms,
or
you
know
a
different
way
of
doing
discounting
or
something
like
that.
These
are
generic
systems
and
they're
solved
problems.
A
There
are
people
out
there
who
have
built
fantastic
billing
and
payment
systems
and
plan
systems,
and
we
should
just
leverage
those-
and
this
is
actually
a
very
liberating
process
to
go
through
by
the
way,
because
recognizing
that
you
should
just
take
something
off,
the
shelf
is
a
really
great
place
to
be
so
what's
interesting
about.
This
is
that
you
can
actually
go
another
level
down,
so
we've
called
out
generic
domains
and
core
domains
for
us,
but
within
those
you'll
see
similar
patterns
so
within
job
execution,
which
I
just
said
is
absolutely
core
to
our
business.
A
You'll
find
that
there
are
things
that
we
do,
that
are
very
specific
to
us,
like
the
construction
of
the
environment
and
signalling
the
inputs
and
outputs
and
the
things
that
are.
We
basically
provide
a
DSL
over
compute
to
allow
you
to
do
CI
and
C
D,
where,
as
resource
availability,
making
sure
there's
enough
capacity
online
to
meet
demand
at
any
given
time
of
the
day
is
a
solved
problem
right.
Auto
scaling,
group
and
task
scheduling
I
mean
we're
at
coop
con.
A
There
are
people
that
have
figured
out
how
to
do
task
scheduling
very
effectively,
and
it's
not
something
that
we
should
be
doing
and
if
we
did
it
for
a
while,
and
it
was
a
disaster,
so
there
are,
there
are
tools
out
there
that
we
can
use.
If
you
go
to
the
other
end,
take
something
that
I
had
called
out
as
pretty
generic
previously,
which
is
the
operation
of
our
environment
itself.
A
We
have
some
generic
pieces
of
that
which
is
container
orchestration,
again
kubernetes
a
great
tool
for
that
observability
like
I'm,
not
gonna,
rewrite
stats,
D
or
Prometheus,
or
whatever,
to
get
metrics
out
of
the
system.
There's
a
lot
of
great
tools
out
there
for
logging.
These
are
not
things
that
I
should
be
building
they're,
just
things
that
I
need
to
have
available,
so
someone
can
operate
the
system
effectively,
but
the
upgrade
management
and
how
that
works
is
very
core
to
how
people
use
our
system
and
how
they
perceive
it.
A
A
Okay,
so
another
key
thing
that
we've
learned
as
software
developers
or
hopefully
learned
continue
to
learn,
but
I
think
we
need
to
apply
to
how
we
think
about
systems
is
isolating
change
through
abstractions
and
I.
Think
that
what
happens
when
we
go
and
evaluate
technology,
and
one
of
the
reasons
that
we're
always
so
stressed
out
when
we're
evaluating
technology
and
trying
to
decide
what
to
do
is
we
go
all-in
like
once,
we've
decided
that
we
are
going
to
use
a
specific
tool.
We
bake
the
assumption
of
that
tool
into
our
entire
platform
right.
A
And
the
key
point
on
here
is
that
you
have
domain
logic
and
that
domain
logic
should
have
no
understanding
of
the
inputs
and
outputs
to
your
domain.
And
specifically,
if
you
look
at
the
driving
adapters
on
the
left
or
the
driven
adapters,
you
know
you
have
an
HTTP
API,
let's
say,
and
maybe
today
you're
using
rest
and
tomorrow
you
might
decide
to
use
graph
QL.
The
the
business
logic
of
your
domain
should
not
change
as
a
result
of
that
it
should
be
completely
isolated
from
it.
A
And
if
you
look
to
the
right
I
think
what's
really
interesting
is
we
thought
we
were
doing
the
right
thing,
around
isolating
databases,
for
example,
but
ODBC
and
JDBC
are
not
abstractions.
There
are
libraries
that
give
you
a
simpler
access,
but
there
you're
still
tied
in
to
the
notion
that
you're
using
a
relational
database,
even
an
ORM.
At
that
point,
it's
not
an
abstraction.
A
The
abstraction
is
the
notion
that
I
have
something
to
store
and
I,
don't
care
how
it
gets
stored
and
when
I
do
that,
when
Cassandra
becomes
the
right
solution,
I
don't
have
to
go
change.
My
assumptions
all
the
way
through
my
codebase.
So
what
does
this
look
like
when
I'm
trying
to
insulate
myself
from
the
cloud?
A
First
of
all,
when
I'm
moving
across
multiple
cloud
providers,
I
can
use
well-known
established
interfaces
right.
It
doesn't
matter
to
me
if
I'm,
using
Postgres
in
RDS
or
I'm,
deploying
it
myself
or
I'm,
using
a
Postgres
interface
provided
to
me
in
GCP.
It's
still
Postgres
and
kubernetes
is
the
same
thing.
So
for
us
you,
we
run
kubernetes
ourselves
with
our
own,
install
we're
actually
looking
at
moving
that
to
one
of
the
cloud
provider
installs.
So
we
can
do
less
management,
but
the
interface
for
us
is
the
same.
A
So
that's
that's
one
option,
but
there's
not
not.
Everything
works
like
that.
The
blobstore
is,
for
example,
in
different
cloud
environments,
look
different,
but
there
are
tons
of
libraries
out
there.
I
can
go
pull
J
clouds
off
the
shelf
or
go
cloud
or
whatever
library
is
is
available
to
me
in
the
language
that
I'm
developing
in
so
that
I
can
be
completely
insulated
from
that.
A
A
But
that's
good,
that's
how
you
we
should
consume
our
books,
but
the
emphasis
on
complexity
throughout
his
writing
is
extremely
valuable
because,
as
we
look
at
the
software
that
we
build,
you
know
his
point
is
the
greatest
limitation
that
we
have
is
our
ability
to
understand
our
own
systems,
so
we
in
software
I
mean,
if
you
think
about
any
other
engineering
discipline
we
are
about
as
limitless
as
it
gets
right.
I
have
an
editor
and
I
have
some
ideas
and
I
can
just
build
and
build
and
build
right.
A
I
mean
this
is
how
we
end
up
building
everything
ourselves
honestly,
because
we
feel
unconstrained
if
I'm
trying
to
build
a
bridge.
I
have
a
lot
of
constraints,
but
if
I'm
writing
software,
the
only
thing
that's
really
holding
me
back
is
my
ability
to
keep
managing
the
complexity
of
that
software
and
so
going
back
to
our
design
problem.
A
That
manages
a
lot
of
our
orchestration
stuff
and
we've
made
that
part
of
our
system,
because,
if
ice,
if
I
give
you
a
package
and
that
package
starts
with
replicated-
and
you
don't
know
anything
about
that-
then
I
am
now
supporting
this
third-party
tool,
plus
everything
that
I've
built
right,
and
so
the
interface
feels
very
simple
again
going
back
to
who
our
customer
is.
We
thought
that
the
best
possible
interface
to
give
you
was
one
that
was
very
light.
Had
this
sort
of
one-click
installer,
one
click
upgrade
model
and
for
you.
B
A
A
So,
to
recap:
four
key
things
that
I
think
you
want
to
take
away
as
an
operator
or
infrastructure
developer
that
are
key
components
of
how
we've
been
thinking
about
software
development
for
a
long
time.
Number
one
make
sure
that
you
understand
your
customer
really
understand
what
their
needs
are,
so
that
you
can
focus
on
building
the
things
they
need,
as
opposed
to
every
possible
combination
of
what
you
think.
Someone
might
need
number
two
focus
on
your
core
competencies.
A
We
all
have
a
thing
that
is
driving
us
as
a
business
and
brings
in
either
the
the
revenue
or
the
customers
or
whatever
it
is
that
you're
measuring
by
and
everything
that
every
time
you
spend
energy
on
something.
That
is
not
that
you
are
using
valuable
time
and
not
creating
value
for
your
organization
you're.
A
A
A
A
I,
guess,
there's
there's
probably
two
things
one
in
our
cloud
environment
we
don't
deploy
our
our
primary
data
stores
inside
of
kubernetes,
mostly
because
they've
been
there
for
a
really
long
time,
like
predating
all
of
our
service
infrastructure,
but
that's
not
necessarily
how
we
how
we
deploy
the
server
product
either.
So
there's
that
like
data
stores,
but
that's
a
configuration
thing,
basically,
you
can
say:
ok,
I
need
access
to
these
data
stores
and
they're
here.
So
that's
one.
The
other
thing
that
is
really
key
for
us,
but
I
think
is
an
unusual
case.
A
Don't
run,
as
you
know,
as
containers
inside
of
kubernetes,
we
have
to,
in
some
cases
their
raw
VMs,
in
some
cases,
their
physical
machines
and,
in
some
cases
where
you
know
we're
composing
together
a
set
of
docker
containers
that
represent
the
work
that
you
want
to
do
and
in
all
of
those
cases
we
do
that
outside
of
kubernetes,
but
I
think
that
that
again,
I
think
that's
very
specific
to
what
we
do,
because
most
systems
that
I
think
about
aren't
doing
arbitrary
compute
for
other
people.
That's
a
very
sort
of
CIN
CD
specific
problem.
A
B
A
A
The
compute
for
the
purposes
of
builds
that
I
was
just
talking
about,
is,
is
not
as
constrained,
but
that
exists
outside
of
kubernetes
as
I
was
just
describing.
So
it's
always
been
a
Linux
only
operating
environment.
The
thing
that
I
think
we
get
actually
as
a
result
of
this
change,
going
back
to
the
abstraction.
Is
we
care
a
lot
less
about
what
may
be
flavor
of
Linux
or
distribution
or
how
you've
configured
your
environment
around
that
those?
A
Because
actually,
that
was
another
learning
that
we
had
with
respect
to
these
customers
is,
they
might
have
a
very
specific
like
we
run
everything
on
Red,
Hat
Enterprise,
let's
say,
and
we
have
an
image
that
is
locked
down
and
we've
stripped
out
everything
that
we
don't
want
in
there.
You
know
it's
been
hardened
by
our
security
team
and
that's
how
we
want
to
run
so
we
can
go,
deploy
kubernetes
on
top
of
that
and
then
Orson
up
not.we,
that
customer
can
deploy
kubernetes
and
that's
our
interface,
whereas
previously
we
had
to
validate.
A
A
Yeah
right
so
I
mean
to
be
clear,
we're
in
the
process
of
this
transition
right
now,
but
we've
always
had
to
tell
them
they
have
to
use
something
right.
No
one
has
ever
been
able
to
just
take
our
software
and
sort
of
run
it
as
a
as
a
binary
or
whatever,
and
that
stems
from
the
fact
that
it's
actually
it's
a
complex
piece
of
software
right
and
so
the
difference.
A
A
We
can
help
you
get
that
installed
and
run
it
ourselves,
but
you
can
get
a
lot
of
help
in
terms
of
sort
of
using
that
overall,
it's
actually
been
more
of
a
pull
the
other
way,
though,
if
I'm
totally
honest
where
people
have
said,
we
have
kubernetes,
we've
built
the
kubernetes
base
of
knowledge
inside
our
company,
we're
investing
in
that
we're
training,
people
we're
hiring
people.
Please
allow
us
to
use
that
because
that's
where
our
expertise
is
now
right,
so
I
think
the
again
as
the
I
would
say.
A
2017
was
a
year
where
everything
kind
of
went
in
the
kubernetes
direction
right
most
of
the
other
orchestration
engines,
kind
of
just
became
wrappers
around
kubernetes,
and
so
the
the
community
and
the
knowledge
base
is
big
enough.
Now
that
that's
actually
a
real
advantage
in
a
product
offering
that
make
sense,
yeah.
A
So
the
question
is:
do
I
think
that
kubernetes
is
the
right
abstraction
to
hide
complexity
and
I?
Think
you
can
take
both
views
of
this
right
so
where
I
show
the
change
in
what
is
actually
our
product?
I
mean
kubernetes.
If
you
are
a
shop
running
your
own
cloud
and
you
are
deploying
a
simple
application
on
top
of
an
ami
or
whatever.
A
Saying,
oh
well,
now
we
need
kubernetes,
because
that's
what
everybody
is
doing
is
adding
a
lot
of
complexity
right
that
you
may
not
need,
and
so
the
question
is:
where
is
the
trade-off
for
you
and
your
use
case
in
your
application?
In
our
case,
we
we
got
at
least
a
consistent
like
I'm,
just
looking
at
our
cloud
environment
as
a
starting
point.
We
got
a
consistent
way
to
deploy
and
manage
containers.
We
were
already
building
things
effectively
in
containers.
A
You
know
in
a
way
that
allowed
us
to
easily
define
these
are.
These
are
the
communication
paths
we
need,
but
these
you
know
we
don't
care
about
how
that
exactly
happens
inside
of
the
system,
so
we
traded
off
some
things,
but
we
took
on
the
burden
of
management
of
kubernetes
itself
and
I.
Think
if
you
bring
all
of
that
in
and
consider
that
to
be
part
of
your
work,
then
your
trade-off.
A
The
point
at
which
you
trade-off
and
get
a
net
reduction
in
complexity
is
probably
high,
but
when
you
realize
that
you
can
actually
hand
that
off
to
someone
else
right,
if
you
go
with
an
e,
KS
or
gke
or
whatever,
then
you
have
taken
a
lot
of
the
complexity,
which
was
the
underlying
systems
and
moved
it
away.
Basically
from
what's
on
your
plate,
and
so
your
net
reduction
in
complexity
is,
is
in
a
much
better
state,
and
so
the
trade-off
is
or
the
trade-off
point
would
be
much
lower
something
cents.
B
A
Want
to
answer
your
question,
but
I
want
Drivetime
to
answer
this
question:
are
we
okay?
Okay?
So
the
question
was
basically:
is
his
kubernetes,
the
right
sort
of
level
of
abstraction,
or
should
we
go
one
level
up
right?
So
you
can
imagine
a
world,
and
we
did
have
this
conversation
where
we
would
say.
Well,
we
have
two
different
deployment
models,
so
let's
build
a
definition
that
allows
us
to
basically
spit
out.
A
You
know
if
we
were
a
bigger
team
or
we
had
reasons
to
deploy
in
other
ways.
We
would
probably
consider
that
we
actually
thought
about.
You
know
some
other
models
that
we
had
that
conversation,
but
really
the
ultimate
trade-off
was.
Is
this
an
investment
that
we
would
make
right
now
and
I?
Guess
that's
a
really
important
thing
to
think
about
in
abstractions
overall,
and
one
thing
we
always
discuss
like
abstractions
are
great
because
they
protect
you
from
these
issues
of
change
and
complexity,
but
they're
also
often
expensive
in
and
of
themselves
right.
A
So
this
goes
back
to
understanding
your
domain
and
understanding
your
customer.
All
of
these
things,
you
should
create
abstractions
first
in
the
places
that
have
the
highest
rate
of
change,
and
if
we
can
sort
of
commit
to
something
for
a
while
with
kubernetes,
then
we
don't
have
to
worry
about
that
abstraction.
Does
that
answer
your
question?
Okay,
all
right!
Thanks
again,
everybody
enjoy
the
rest
of
your
day.