►
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
Monolith to Microservice: Pitchforks Not Included - Jason Plum, GitLab
Learn how GitLab turned it’s omnibus into cloud native Helm charts by way of containerization and orchestration. This talk aims to help practitioners already running large scale, successful products make decisions on how to move to microservices while maintaining product development cadence and serving customers on legacy software everyday. It’s like driving a race car and fixing it as you are competing in a race, without pit stops. We will cover: - How we made the application stack capable of scaling via containerization, through many changes to stateful behaviors. - Why we made the changes from an architectural view. - How on earth we accrued the technical debts we had to fix in the first place. - Most importantly, we’ll demonstrate why the monolith concept was the right place to start, but Kubernetes is our future.
To learn more: https://sched.co/GrSP
A
A
A
Coming
out,
it's
as
the
person
standing
here,
it's
impressive
to
see
the
number
of
people
that
want
to
learn
the
things
that
we've
learned
over
the
last
year
doing
the
work
that
we
have
to
convert
our
massive
omnibus
monolith
into
a
cloud
native
chart
and
the
changes
that
were
actually
required
to
make
that
migration.
Now
I
mentioned
pitchforks
here
and
I'll.
Explain
this
pun
has
anybody
ever
went?
We
have
a
great
application.
It
works
great.
We
have
hundreds
of
thousands
of
users.
Now
we
got
to
do
the
new
tech
and
then
go.
A
A
A
But
now
that
we're
kind
of
tailed
in,
let
me
cover
Who
I
am
my
name-
is
Jason
I'm,
a
senior
distribution
engineer.
I
have
spent
the
last
year
doing
our
cloud
native
helm,
charts
and
breaking
out
this
gigantic
pile
of
code
that
may
very
complex,
very
coordinated
application.
Sweet
work,
I
have
a
history
working
with
containers
and
commits
into
docker.
Has
anybody
here
ever
heard
of
the
bridge
IP
flags?
A
No,
none
of
my
networking
guys
here,
yeah
I
did
that
because
I
couldn't
deal
with
the
Cisco
VPN
anymore,
but
you
know
what
you're
welcome
flannel
but
yeah.
So
last
September
at
the
beginning,
my
boss
comes
to
me
and
goes
okay,
so
we've
got
this
and
we've
got
the
existing
omnibus
in
a
caperna
t's
chart.
But
now
we
need
to
do
it
the
right
way.
A
So
the
real
question
people
don't
realize
is
what
is
get
loud
now,
I'm
gonna
explain
to
you
from
a
couple
of
viewpoints,
the
first
of
which,
being
that
right.
This
is
the
marketing
pitch
and
I'll.
Just
put
this
up.
You
can
find
this
on
our
page,
but
gitlab
is
the
first
single
application
to
actually
have
the
entire
DevOps
lifecycle.
In
a
single
interface,
we
do
concurrent
DevOps,
unlocking
the
organization's
from
all
the
constraints
of
the
tool
chains,
providing
unmatched
visibility,
higher
levels
of
efficiency
of
efficiency
and
comprehensive
governance,
while
we're
at
it.
A
While
we
can
make
your
lifecycle
200%
faster
doing
that
is
highly
complex.
So,
let's
look
at
it
from
two
viewpoints
and
I'll:
explain
which
one
I'm
gonna
do
you
have
the
end
user?
This
is
what
you
see.
This
is
where
everything
you
need
is
the
end
users
view
the
interface
itself,
which
we
pride
ourselves
on
making
sure
that
you
can
do
everything
in
one
interface
without
having
to
jump
around
without
having
to
integrate
all
the
things
we
can.
If
you
want,
but
but
then
again,
let's
look
at
it
another
way
in
the
crowd.
A
A
That's
not
the
case.
These
days
now
we
are
still
Ruby
on
Rails
for
the
primary
application,
but
we've
got
sidekick
now
on
the
side,
we've
got
giddily
that
I'll
cover
in
a
little
bit.
That
is
a
complete
go
service.
We
actually
have
a
shim
proxy
in
front
called
workhorse.
That's
go
binary
that
takes
the
heavy
lifting
away
from
Ruby
so
that
we
can
make
sure
that
our
api's
are
responsive.
A
We
did
this
and
then
we
started
packaging.
This,
because
doing
everything
from
source
is
hard,
so
we
created
the
omnibus
package
and
that
slowly
became
the
gigantic
monolith,
but
it
was
sensical
because
when
we
started
we
had
a
clear
focus.
We
had
a
group
of
people
working
a
single
product
to
binding
that,
and
then
we
took
that
we
bundled
that
and
we
shipped
it
and
we
shipped
it
and
we
shipped
it
and
we
shipped
it
and
all
the
twenties
every
month
for
the
entire
lifespan
of
this
company.
We
have
done
that.
A
A
A
Ok,
it's
still
that
big,
it's
still
usable
still
has
all
the
features
and
all
the
configuration
you
download,
500
Meg's
as
an
installation
package
and
it
unpacks
to
over
a
gig
and
a
half,
and
that's
before
you
start
putting
data
in,
because
we
have
all
of
these
things,
because
that
package
contains
literally
everything
it
requires
to
run
our
SAS
every
component,
every
configuration
and
every
way
you
can
put
it
together,
it's
good
because
we're
able
to
use
it,
we
use
it.
Our
customers
use
it
the
exact
same
way.
A
Now
one
of
the
key
components
of
what
we've
done
over
the
years
is
get
the
trick
is
get
itself
is
the
reason
that
moving
to
cloud
native
was
hard,
but
let
me
show
you
why,
through
a
series
of
examples,
not
from
a
consumer
perspective
but
from
the
inner
workings
of
how
it
behaves
itself,
so
everybody
know
what
it
is
and
how
it
actually
works.
No
do
we
all
know
how
it
works
for
us
right.
You
run
a
couple
of
commands.
A
You
push
up
to
us
everybody's
happy,
UCI
kicks
off,
deploy
app,
did
you
do
right,
but
at
the
core
of
that
command
is
how
everything
is
handled,
how
everything
is
put
together?
It
works
with
snapshots
of
the
entire
file.
The
sheer
number
of
files
involved
is
every
file
you
have
and
every
version
you've
ever
had
and
all
the
indexes
and
references
and
everything
else.
A
A
You
check
out
that
tree.
Get
your
coffee
come
back
check
out
any
branch
I,
don't
care
what
it
is
and
then
dip
that
against
current
master,
how
many
files
just
got
read
on
the
file
system
right
all
the
files
that
are
marked
as
different
between
the
two
of
them
and
when
you
do
diff
that
dip
in
for
information
is
not
stored.
It's
not
greeting
it
and
cutting
it
out.
It's
running
diff
on
all
of
those
files.
A
A
How
about
10,000
people
a
second
right!
Do
you
see
where
this
is
going?
Suddenly
it's
harder?
But
why
is
this
the
problem,
traditional
methods,
these
types
of
requirements
are
the
absolute
heart
of
the
monoliths
that
we
have,
but
then
we
take
that
and
multiply
that,
not
by
10,000
by
a
hundred
thousand,
because
all
of
a
sudden
somebody
started
importing
hundreds
of
thousands
of
repositories
a
day.
A
First
off.
Let's
look
at
the
traditional
methods,
we'll
make
more
of
them
and
we'll
spread
it
out,
we'll
sharp
the
disc
figure
out
more
of
them.
Okay,
that's
not
working,
so
we'll
put
them
on
SSDs
cool,
okay!
Now
we're
gonna
raid
16
of
these
things
together,
because
they're
still
not
fast
enough.
Now
we
have
the
problem
of,
we
have
hundreds
of
things
in
the
fleet
accessing
tens
of
machines
that
are
massive
with
every
disk
we
can
throw
at
it
and
it's
still
not
keeping
up,
because
the
traditional
methods
are
a
problem.
A
You
pick
the
pitchfork
and
go
nope
the
beauty
of
NFS
is.
It
is
capable
it
is
proven,
but
it's
not
meant
for
this
scale.
Why?
Because
of
the
way
it
works,
we
now
have
a
mount
that
has
to
be
on
every
single
node,
because
our
API
code
and
our
web
code
and
several
other
processes
in
the
background
have
to
be
able
to
read
these
files
because
we're
using
Garrett
we're
using
Lib
get
we're
using
a
bunch
of
other
things.
It
has
to
read
them
on
the
file
system.
A
A
It
solved
the
problem,
but
it
created
another
one.
Now
we're
not
as
worried
about
how
much
this
we
can
get
to
or
that
all
of
them
can
get
to
it.
But
now
we've
got
disk
I/o
problems
because
we've
got
everybody
trying
to
read
this
disparate
set
of
files.
Now
we've
got
all
of
that
traffic
going
across
the
at
work
and
there's
only
so
much
you
can
fit
through
the
tube
and
then,
of
course,
the
whole
problem
with
NFS
system
ends,
and
if
s
falls
over
what
happens
so
does
everything
else?
A
Now
we
can
only
push
the
traditional
methods
of
up
and
out
so
far
before
we
realize
that
that's
just
not
going
to
work,
because
we
don't
have
big
enough
pipes,
end
of
line
so
now
we've
got
all
of
this
and
we've
just
got
more
of
them
and
more
of
them
and
more
of
them
and
all
of
a
sudden
we
need
to
add
15
nodes
to
the
fleet
and
another
15
nodes
to
the
fleet
and
another
15
nodes
to
the
fleet
to
keep
up
with
sudden
user
demand
with
every
single
time.
We
have
to
double
something.
A
A
We
centralize
everything
across,
and
this
gives
us
the
ability
to
actually
meet
throughput
because
that
pipe,
that's
not
getting
any
bigger,
suddenly
has
1/10
of
the
traffic
going
through
it.
Now
we
have
more
room
just
to
be
able
to
even
get
to
the
file
servers
plus
we
don't
have
NFS
mounts
on
everything.
So
if
one
node
goes
out,
we
don't
lose
half
the
fleet
in
an
instant,
but
we're
also
optimizing
for
the
very
specific
problem
of
how
do
I
get
to
get
in
the
most
performance
way.
A
A
A
Now
we
can
look
for
our
other
choke
points.
Traditional
files
are
still
there.
If
you
upload
something
file
system
now,
chain
NFS
hasn't
gone
away
completely.
Yet
there's
a
problem.
Do
we
really
need
to
have
an
offense,
because
somebody
uploaded
a
cat
picture
come
on
guys?
We
can
do
better
than
that
right.
A
So
our
next
solution
was
to
take
everything.
We've
got
as
a
traditional
file
that
does
not
get
and
move
it
into
object
stores
as
an
option.
Why
does
this
matter?
Because
now
I
don't
have
to
have
the
file
system
locally
now
I
can
take
all
of
these
files
hand
it
to
a
service
that
works
well,
and
we
already
have
proven
it
and
has
the
ability
to
run
on
Prem
in
a
cloud
and
any
number
of
men
and
service
providers.
A
Now
everybody
knows
this
writes
pets-
cattle-
you
should
have
all
heard
this
term
by
now,
popularized
by
CERN,
but
in
a
nutshell,
anything
that
you
can
replace
easily
is
cattle.
Anything
that
you
have
to
care
and
feed
for
on
a
regular
basis
is
a
pet.
Why
does
that
matter?
Because
that
pet
is
your
stateful
information,
our
database,
for
example?
A
A
Every
component
is
now
separated
and
because
it
can
be
individually
configured
with
only
the
thing
it
needs
and
I
don't
have
to
go,
turn
off
and
generate
files
for
umpteen
other
things.
Instead
of
being
two
minutes,
it
can
be
as
little
as
five
seconds
if
I
need
to
bring
up
more
web
workers,
because
all
of
a
sudden,
our
api's
are
getting
literally
slammed
because
somebody
decided
to
start
forking.
Unreal
Engine,
like
crazy
I,
can
do
that
now
in
less
than
a
minute
and
I've
got
30
of
them.
There's
a
big
difference
there.
A
A
But
if
they're
in
separate
containers
and
there's
no
shared
disk
and
I
can't
do
a
shared
disk,
because
if
we
do
shared
disk
through
rewrite
many,
what's
the
major
provider
that
will
do
that
for
us
on
every
platform.
Anybody
remember
another
three-letter
problem,
so
we
have
to
face
down
and
fix
those
things.
A
Then
we
have
an
interesting
problem
that
was
quite
fun
to
find
workhorse.
Remember
that
smart
proxy
I
told
you
about
it
apparently
likes
to
talk
to
UNIX
sockets,
not
TCP.
We
fixed
it
since
obviously,
but
it's
pretty
amazing
when
you
have
a
connection
come
in
and
then
the
moment
you
decide
I'm
gonna,
do
it
over
TCP.
Instead
of
Unix
everybody
becomes
localhost,
that's
gonna
make
it
walking
hard
great
I've
got
15
gigs
of
Splunk
and
everybody's
from
the
same
machine.
Oh
right.
A
Then
we
have
another
problem:
it's
deadly
simple
at
that
too
time
constraints,
which
is
what
you
have
to
worry
about
your
developers,
the
development
resources
milestones
roadmaps,
deliverables.
All
those
project
managers
on
your
back,
saying,
hey
the
business
still
has
to
function
while
we
rework
entire
pieces
of
this.
A
That
also
means
that
new
features
are
going
to
continue
coming
because
I'm
not
gonna,
be
able
to
stop
the
guy
who's,
doing
the
rails
app
and
the
go
binaries
from
actually
shipping
features
that
make
it
more
performant
better
ad
maven
packages
bring
us
all
of
the
epic
stories,
etc,
etc.
I
can't
stop
that
it
still
has
to
function.
I
still
have
a
product
to
ship.
My
customers
still
have
a
product
that
they
want
to
use
and
they
want
to
get
updates
and
security
pages.
I
can't
just
magically
stop
that.
A
A
Resources
are
dead,
simple
right,
everybody
knows
how
much
CPU
this
process
needs.
I
mean.
Yes,
ok.
We
know
that
Unicorn
is
memory
hungry,
we're
aware
right,
you've
been
telling
us
for
years.
We
use
too
much
RAM
we're
working
on
it,
but
do
we
actually
know
what
it
is?
Do
you
have
the
monitoring
for
your
applications?
Do
you
know
how
much
CPU
you
need
when
idle
versus
when
there's
10
people
versus
literally
some
guy
clicking
around
and
if
files,
because
he's
one
to
look
at
what
the
kernel
would
like
in
2,
6
2.
A
A
A
Load
balancing:
what
are
we
load
balance?
What
can
we
load
balance?
Can
we
use
a
layer?
Seven
anybody
think
SSH
is
layer,
seven
there's
a
hint
do,
then
we
have
to
deal
with
which
providers
now
for
us,
it's
simple.
We
know
where
we
are,
but
not.
Everybody
wants
to
use
the
same
load
balancers
that
we
want
to
use
or
the
services
that
we
use
and
since
I'm
making
this
for
me
but
I'm,
making
it
for
all
of
my
customers.
A
I
have
to
remember
that
I
have
to
make
the
entire
thing
capable
of
using
whatever
my
users
decide
to
choose,
which
means
I
have
to
support
all
the
load
balancers
from
all
the
major
cloud
providers
and
figure
out
how
to
do
it
on
metal.
It's
a
new
option.
Thankfully,
then,
how
do
I
deal
with
scaling?
I
mentioned
this
a
second
ago
right,
maybe
50
percent,
for
the
thing
that
needs
a
lot
of
memory
is
a
bad
idea.
A
It's
important
to
know
what
things
you
can
scale
horizontally
and
which
things
you
should
just
give
more
resources
to
in
the
first
place,
which
things
should
be
configurable
and
how
to
tweak
them
and
have
a
document
to
your
users
how
to
tweak
them,
because
their
use
case
may
not
be
exactly
yours,
so
you
should
document
exactly
how
you
test
it
so
that
they
can
test
it
in
their
load.
Then
the
question
comes
down
to
automatic
or
manual.
A
A
My
giddily
notes
out
right
if
I
inadvertently
make
too
many
databases,
I'm
gonna,
piss
things
off,
but
all
of
my
say
registry
nodes,
maybe
if,
for
some
reason
somebody
has
started
pulling
registry
images
every
hour
on
the
hour
from
100
machines
baby
every
once
in
a
while
I
should
just
let
that
go
ahead
and
spawn
up
and
down
to
fit
load
right,
and
you
have
resilience
what
actually
happens
to
your
application
when
a
node
a
whole
know
disappears
off
the
cluster.
Do
you
know?
Do
you
know
how
that
behaves?
A
Do
you
know
which
things
shouldn't
be
on
the
same
nodes
so
that
that
doesn't
happen?
How
does
that
recover?
You
should
know
these
things,
and
you
think
you
do
until
you
don't
know
where
your
applications
at,
because
you
don't
know
until
it
gets
yet
old,
traditional
problems,
new
ways
of
looking
at
them.
Yes,
but
you
also
need
new
ways
of
examining
them
at
the
same
time,
so
how
to
plan
that
out
can
actually
be
really
hard
and
I'm
not
going
to
cover
that,
because
that's
a
whole
other
talk.
A
Some
of
that
you
may
have
gone
to
Marvin's
talk
yesterday
and
if
you
didn't
I
suggest
you
catch
it
all
the
video
recordings
later
now,
I
kind
of
buzzed
through
that,
but
the
three
things
I
really
want
you
to
understand
are
right
here.
In
simple
terms:
in
the
beginning,
we
were
small
and
working
within
a
monolith
was
the
right
choice
and
I
believe
still
today,
that's
the
right
choice
for
many
people
doing
early
work.
A
A
A
The
question
was,
despite
as
careful
and
planning
as
we
were,
did
we
end
up
with
any
big
production
customer
oopsies?
The
answer
is
dole
because
we
tested
the
daylights
out
of
this.
First,
we
deploy
believe
it
on
all
of
these
charts
into
review
applications
into
a
very
large
CI
cluster.
So
we
actually
test
everything
about
the
charts
at
load
for
every
single
feature.
Addition
in
the
codebase
before
it
gets
merged
into
our
stable
branch
on
the
charts
and
before
it
gets
released
to
a
customer.