►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
The Monolith is Dead. Long Live the Monolith! - Mitch Connors & Jason Wang, Google
Monoliths! Who talks about Monoliths anymore? Didn't we move on to SOA and microservices a decade ago? Despite the domination of distributed architectures for cloud software, 60% of enterprise IT budgets still go to the datacenter, where the Monolith is King. While these legacy applications have historically been perceived as liabilities, new developments in service mesh enable enterprises to benefit from their monolithic assets while taking advantage of Cloud Native technologies. In this talk, you will learn about how you could embrace your monolith by enabling it with: * Zero Touch security with Envoy and Spiffe * Zero Touch observability with Prometheus * Zero Touch uptime improvements with Circuit Breakers * Zero Risk test in production with fault injection and canary deployment * Zero Risk traffic migration in Hybrid cloud environments (VM and multi-cluster)
https://sched.co/cp8K
A
C
B
So
we're
here
today
to
talk
to
you
about
monoliths,
which
might
strike
you
as
a
little
bit
odd
right.
This
is
kubecon
kubernetes
con
the
cloud
native
compute
foundation's
annual
conference,
where
we're
supposed
to
talk
about
containers
and
micro
services,
not
about
monoliths,
well
we're
not
in
the
wrong
place,
and
I
want
to
make
sure
that
you
know
neither
are
you
you
see.
Microservices
are
a
brand
new
technology.
B
Looking
at
the
curve,
it
says
about
80,
I
might
even
say
more
than
that
of
users
still
are
going
to
own
one
or
more
monolithic
applications,
and
so
we
want
to
have
a
story
for
them
about
cloud
native
technologies
that
doesn't
simply
involve
abandoning
all
the
work
that
they've
invested
in
their
monolith
and
carving
it
up
into
microservices.
You
shouldn't
have
to
refactor
your
entire
code
base
to
take
advantage
of
cloud
native
compute.
B
Additionally,
we're
talking
about
monoliths,
because
at
istio
we
actually
migrated
our
architecture
to
monolith.
We
had
microservices
up
until
our
first
release
in
2020
about
march.
We
went
ahead
and
migrated
those
three
microservices
into
one
comprehensive
monolith,
and
you
know
what
we
found.
It
was
actually
a
lot
easier
for
our
users
to
deploy
and
manage,
and
it
was
a
lot
easier
for
us
to
troubleshoot.
B
So,
let's
start
by
defining
monolith,
oxford
english
dictionary
tells
us
it's
a
large
single,
upright
block
of
stone.
That
definition
works,
maybe
as
a
metaphor,
but
I
think
wikipedia
gets
it
a
little
bit
closer
to
what
you
and
I
are
talking
about.
A
monolithic
application
is
self-contained
and
independent
from
other
computing
applications
comes
from
the
greek
single
rock,
and
I
got
the
usage
chart
here,
which
I
thought
was
interesting.
Nobody
seems
too
surprised,
I
think,
about
this
early
2000s
crest
of
talking
about
monoliths.
B
Everyone
was
talking
about
moving
to
service,
oriented
architecture
and
microservices.
This
this
bump
was
a
little
bit
more
interesting.
I'm
curious
to
know
why
everyone
was
talking
about
monoliths
in
the
1870s.
I
don't
think
it
was
about
the
babbage
machine,
but
if
anybody
knows
please
hit
me
up
on
twitter
I'd
love
to
hear
the
answer
to
that.
Well,
so
when
we
take
into
consideration
that
definition
independent
from
other
computing
applications,
I
think
you'll
find
that
true
monolithic
applications
are
rare
right.
All
of
our
applications
have
dependencies
on
other
applications
at
the
very
least.
B
Even
if
you've
got
a
combined,
frontend
backend
server,
you've
probably
got
a
database
for
persisting
data
you're,
probably
not
doing
that
yourself
in
process,
even
if
it
sits
on
the
same
computer,
still
not
quite
a
monolith.
You've
got
some
networking
traffic
there
that
might
have
latency
you're
interested
in
might
need
security.
B
Additionally,
you
don't
tend
to
get
your
users
sitting
at
the
same
computer.
Your
monolith
is
running
on
right.
You
tend
to
have
users
who
are
on
the
internet
and
those
users
are
coming
to
you
via
a
load,
balancer
or
a
gateway
or
a
firewall.
So
true,
monoliths
are
pretty
rare.
Most
of
the
time.
What
we're
talking
about
is
really
a
macro
service.
It's
one
process
that
just
has
lots
of
functionality
packed
into
it.
You've
got
business
logic,
you've
got
front
end
logic.
B
You've
got
logic
that
maybe
nobody
really
knows
what
it
does
anymore,
but
it's
still
there
and
everyone's
afraid
to
take
it
away.
We
want
to
talk
about
for
people
like
that.
How
do
you
own
a
monolith,
bringing
it
towards
cloud
native
compute
technologies
without
going
through
all
the
pain
of
a
refactor?
So
I
want
to
introduce
you
to
our
pet
monolith.
We're
going
to
be
talking
about
a
company
called
the
hipster
shop.
Hipster
shop
is
an
online
boutique.
B
Page
to
the
raid
ratings
page
are
happening
over
tcp,
and
that
is
actually
a
change
that
we
would
advocate
for
making
inside
of
a
monolith.
It's
not
a
complete
refactor,
but
it
does
involve
some
elbow
grease,
but
the
cool
thing
is
with
just
that.
Little
bit
of
elbow
grease.
I
think
we'll
be
able
to
show
that
there
are
a
lot
of
advantages
that
you'll
be
able
to
find
with
cloud
native
technologies,
and
your
monolith
feel
free
to
follow
along
with
us
since
we're
all
sitting
at
our
laptops
anyways.
B
B
We
had
to
sort
of
abbreviate
them,
so
they
fit
on
the
screen,
and
we
really
don't
expect
you
to
write
them
down
from
the
screen,
so
go
ahead
and
check
out
github,
where
we'll
have
detailed
examples
for
you
to
follow
through
follow
along
with
all
right.
So,
let's
see
what's
what
the
first
challenge
we
want
to
do
with
our
monolith.
Is
the
ceo
of
hipster
shop
comes
to
his
dev
team
and
says
guys?
The
website
is
just
way
too
slow.
I've
been
waiting
for
it
to
load
forever.
B
I'm
worried
that
customers
are
going
to
give
up
and
we're
going
to
lose
money.
I
need
you
to
speed
things
up.
Why
is
it
running
slow
and
what
changed
it
was
growing
great
last
week.
Well
as
a
dev
team,
we
know
that
the
hipster
telemetry
system
is
is
not
really
a
system,
it's
more
like
seven
systems.
B
There's
a
log
scraper
and
the
part
that
the
intern
rewrote
last
summer
did
use
a
telemetry
system
that
was
hooked
up
to
a
dashboard.
But
nobody
really
knows
how
that
part
works.
Identifying
exactly
where
this
latency
comes
from
might
be
difficult.
We
could
run
it
in
debug
mode
and
get
trace
dumps
of
absolutely
everything
on
the
application,
but
that's
going
to
slow
it
down
even
further.
B
C
Sure
yeah
before
we
actually
look
at
example
and
integrate
with
a
service
mesh.
Let's
look
at
e-still
e-still
is
a
service
mesh
which
is
developed
by
google
and
ibm
and
a
few
other
organizations
in
the
easter
match.
You
can
see
in
the
diagram
east
od
lives
inside
the
control
plane
and
the
control
plane
is
where
we
actually
do.
The
configurations
for
most
of
our
isto
apis,
so
esto
d
is
responsible
for
reading
and
pushing
configurations
discovering
proxies
in
a
mesh
and
configuring
certificates
for
the
proxies
on
the
data
plane.
C
The
proxy
that
we're
talking
about
are
basically
invoice
proxies,
which
are
very
popular
these
these
years
and
a
lot
of
organizations
are
stopping
start
starting
to
adopt
avoid
proxies.
So
the
proxies
are
interacted
alongside
with
each
workload,
and
they
are
the
main
entry
points
for
the
traffic
in
and
out
of
the
workloads.
C
C
So
in
this
example,
we
are
integrating
our
via
our
hipster
shop,
which
is
running
on
vm
and
and
leveraging
a
kubernetes
cluster
in
a
kubernetes
cluster.
It
is
created
to
just
host
each
of
the
prometheus
and
kiali
ecod,
as
we
mentioned,
is
installed
to
push
configurations
to
the
easter
proxies
or
easter
proxy
on
the
via
and
prometheus
and
kia
install
to
script,
metrics
and
display
service
telemetry
graph
for
us.
So
as
before,
external
traffic
is
directed
to
the
vm.
C
And
so,
with
that
being
configured,
we
can
easily
get
some
initial
graphs
and
telemetry
using
chiadi
and
prometheus,
and
you
can
see
that
we
have
some
request.
Count
request
size,
telemetry
being
ingested
by
just
integrating
east
o
into
our
application,
and
we
can
already
the
traffic
flow
from
the
external
to
inside
of
our
our
hipster
shop
application
without
extra
configuration
and
also.
In
addition,
we
can
configure
jaeger
to
provide
tracing
data
for
us
within
the
mesh.
B
All
right,
so
we've
been
able
to
get
telemetry
data
for
our
monolith.
We've
been
able
to
identify
where
the
cause
of
our
latency
was
and
go
and
patch
that
to
keep
our
ceo
happy
without
touching
a
single
line
of
code,
but,
as
is
true
in
business,
change,
is
constant,
especially
in
this
industry.
So
the
next
day
the
ceo
is
back
with
the
dev
team.
To
tell
us
awesome
news
about
this
acquisition
of
the
company
called
review
lee
now.
B
Well,
the
dev
team
we're
a
little
bit
less
excited
about
this.
We
know
that
review
lee
runs
on
kubernetes
they're,
already
containerized
and
because
they're
already
containerized
they've
been
able
to
take
advantage
of
a
weekly
release,
cadence
just
constantly
shipping,
with
continuous
integration,
continuous
delivery
products,
on
the
other
hand,
with
our
vm
based
monolith.
B
So
we've
got
two
options:
we
can
refactor
the
monolith
finding
everywhere
that
we've
used
the
reviews
api
and
replace
it
with
the
review
lee
api-
that's
probably
not
too
difficult,
it's
probably
maintaining
a
config
file.
We
can.
We
can
get
over
that,
but
we
also
are
going
to
need
to
ask
reviewly
all
of
these
new
developers
who
are
excited
about
their
acquisition,
we're
going
to
have
to
give
them
the
bad
news
that
they
need
to
move
to
waterfall
right.
B
C
Sure
that's
that
we
beauty
to
our
service
mesh.
Now,
let's
see
given
our
already
configured
digital
service.
Mesh
already
have
the
vm,
which
is
running
the
hipster
shop
and
it's
already
in
our
mesh
and
now
we're
adding
review
es
another
service
in
the
service
mesh.
Note
that
we
are
putting
only
one
kubernetes
cluster
in
this
example,
but
we
can
also
configure
another
kubernetes
cluster,
which
may
already
be
running
beauty
and
put
it
also
integrated
in
our
current
service
mesh.
B
C
Yeah
exactly,
I
think,
a
lot
of
people
have
been
trying
this
kind
of
practice
before
by
doing
canary
deployment
where
in
canary
deployment,
you
can
try
to
migrate
your
traffic
from
one
or
the
other
and
test
out.
If,
if
one
one
version
is
working
or
not
versus
the
other
one.
So
in
this
example,
we
we
have.
C
All
right
so
now
we
have
two
services
and
two
versions
of
the
search
service.
Now
we
wanted
to
bring
it
to
production
and
before
we
do
bring
to
production,
we
definitely
want
to
do
some
additional
testing,
and
you
may
hear
the
term
chaos
engineering
in
the
past
and
one
of
the
practices
in
chaos.
Engineering
is
to
actually
do
a
phone
injection.
B
All
right,
so
we've
survived
two
crises
with
our
ceo.
We've
made
no
changes
to
our
monolithic
code
base,
but
now
we've
got
observability
for
both
reviewly
and
for
our
legacy,
application
we've
integrated
it
and
we've
made
sure
that
there
was
no
downtime.
Even
when
there
were
bugs
in
our
integration
with
review
lee,
we
were
able
to
detect
them
early
roll
back
quickly
and
get
them
patched
as
well
as
some
really
interesting
testing
in
staging
now.
B
B
Unless
it's
explicitly
been
authorized
in
some
sort
of
a
whitelist
system
and
we
don't
have
a
whitelist
system,
we
also
know
that
we're
going
to
have
to
authenticate
not
just
the
server
as
in
normal
https,
but
also
the
client
side
of
the
request.
This
is
all
done
for
a
really
good
reason.
It
means
that
there's
no
security
perimeter,
whether
an
attacker
is
coming
from
outside
of
the
data
center
or
from
within
your
firewall,
there's
no
way
for
them
to
compromise
many
services
in
a
zero
trust
environment
simultaneously.
B
So
it's
a
great
plan
or
a
great
idea,
but
man.
How
are
we
going
to
implement
a
plan
like
this?
Well,
we've
got
two
options.
We
can
refactor
our
monolith
and
refactor
reviewly
to
use
mtls
auth
for
every
single
network.
Call
our
our
monolith,
I
think
we
said
was
in
python
and
so
the
request
module
probably
supports
mutual
auth
somewhere.
B
If
we
figure
out
the
configuration
parameters,
review
was
written
in
javascript,
so
we
might
need
to
find
a
javascript
library
that
supports
mtls,
and
then
we've
got
to
make
sure
that
we
configure
them
to
be
compatible
with
one
another,
which
might
be
a
little
bit
tricky.
We
might
be
looking
at
several
months.
We
might
need
to
push
back
on
our
csos
timeline
or
we
could
use
a
service
mesh
with
spiffy
jason.
Tell
us
how
that's
going
to
work.
C
Yeah
exactly,
I
think,
when
talking
about
security,
normally
we're
talking
about
two
aspects:
one
is
authentication
which
is
talking
about
who
is
making
the
call
or
kind
of
identity
of
the
caller
or
the
colleague
you
know
as
well
as
what
can
the
caller
do,
which
is
authorization
in
that
sense?
So,
let's
look
at
authentication
for
the
first
case
where
we
can
enable
mtis,
as
mitch
mentioned,
for
the
service
mesh.
C
So
mtis
is
a
two-way
communication,
a
two-way
authentication
that
both
the
client
server
authenticate
each
other
at
a
request.
So
this
helps
that
no
unknown
services
are
able
to
communicate
with
the
services
in
our
mesh.
He
still
can
enforce
that
entire
service
mesh
to
be
mtrs
compatible
by
using
pr
peer
authentication
api.
C
For
me
still
and
and
in
that
and
and
in
this
configuration
you
can
see
that
we're
making
mti's
in
mode
strict
so
that
all
the
services
in
our
service
mesh
are
compliant
with
mtis
and
are
able
to
are
being
encrypted
and
in
addition
about
who
can
make
the
call
and
to
further
enforce
this
security.
We
can
also
add
policies
not
only
allow
certain
workflows
to
perform
certain
operations
on
the
service.
C
So
when
we
are
doing
this,
we
are
giving
each
service
a
specific
identity
that
is
unique
within
the
mesh
and
in
this
example,
we
are
only
allowing
the
hipster
shop
identified
by
this
identity.
Cluster.Local
sites
namespace
slash
default
service,
account
hipster
shop
to
perform
a
get
operation
on
the
review
service.
B
B
We
also
looked
at
observability
with
prometheus
and
now,
if
you
want
to,
and
if
you
have
a
business
need
to
you're
ready
to
start
using
the
strangler
pattern
to
carve
off
sections
of
your
monolith
and
migrate
them
into
kubernetes
as
needed,
and
we've
done
all
of
this
without
touching
a
line
of
code.
So
I
hope
that
you
can
see
from
these
examples
how
you
can
take
the
things
that
we've
shown
today
and
apply
them
to
your
monolith
and
bring
some
of
the
cloud-nating
compute
native
compute
magic
back
to
your
monolithic
code
base.
A
B
So
I
see
a
question
about
bootstrapping
config.
It
asks
if
we're
in
transition
to
istio,
and
we
are
already
generating
some
envoy
configuration.
Can
we
use
that
in
that
configuration
moving
forward
alongside
istio,
and
the
answer
is
that
this
is
not
a
supported
operation.
Istio
would
not
help
you
troubleshoot.
This,
however
istio
does
expose
bootstrap
config
to
envoy,
and
that
is
configurable.
B
C
B
B
B
Sure
the
question
is
how
we
see
the
future
of
service
mesh
interface
and
will
istio
fully
meet
the
requirements
of
smi,
so
service
mesh
interface
is
a
project.
That's
come
about
as
a
collaboration
from
our
friends
at
solo.I.
Oh,
I
think
they're,
probably
presenting
a
few
talks
at
this
conference
as
well
they're,
usually
around,
and
what
they
sought
to
do
is
abstract
away
service
mesh
implementations
like
istio,
linker,
d,
etc,
so
that
you
could
write
one
config
and
have
it
apply
to
all
of
them.
B
B
As
far
as
I
am
aware,
istio's
functionality
is
a
superset
of
what
smi
exposes,
so
some
of
istio
functionality
can
be
driven
through
smi,
and
some
of
it
cannot
and
that's
because
smi
can
only
expose
functionality
that
is
available
in
all
service
meshes.
So
in
areas
where
istio
distinguishes
itself
is
unique,
smi
struggles
to
at
least
in
my
understanding
and
again
I
am
no
expert
on
that.
You
should
talk
to
christian
posta
or
levine.
If
they're
around
about
the
details
there
and
I'm
sure,
they'd
be
able
to
give
a
much
different
perspective
on.
B
A
B
Can
tackle
the
first
question
here
about
the
difference
between
istio's
provided
onboard
version
and
the
official
docker
image
for
envoy
if
we
were
to
use
the
official
docker
images
in
istio,
what
would
happen
is
we're
on
a
quarterly
release.
Cadence,
and
I
believe
envoy,
is
also
on
something
like
a
quarterly
release
cadence.
B
So
that
would
mean
that
when
envoy
is
working
on
a
feature
and
ships
it,
it
would
likely
be
another
quarter
beyond
that
before
istio
is
able
to
take
advantage
of
it,
and
we
at
istio
are
very
interested
in
exposing
the
bleeding
edge
of
envoy
functionality
and
performance
to
our
users.
So
what
we
tend
to
do
is
around
the
time
we're
cutting
a
release.
We
will
take
the
previous
release
of
envoy
and
cherry
pick,
all
of
the
best
features
from
the
upcoming
version
that
are
still
stable
into
it,
and
that
is
what
we
release.
C
C
B
We
do,
and
actually
with,
regards
to
redis,
in
particular
the
hipster
shop
that
you
just
saw
the
demo
built
on
top
of
uses
redis,
and
it
was
built
particularly
as
an
istio
demo
in
the
in
the
microservices,
and
then
we
we
packaged
into
a
monolith
for
this,
but
it's
still
using
redis
within
the
monolith.
So
you
were
able
to
see
traffic
flowing
to
and
from
redis
with
telemetry
security
and
all
of
that-
and
it
worked
fairly
well
if
you've
run
into
problems
about
a
year
ago,
accessing
databases
with
the
istio
sidecar.
B
There
were
some
difficulties
with
protocol
detection
and
protocol
sniffing.
There
have
been
a
lot
of
improvements
over
the
last
12
months
in
that
area.
So
if
you
had
a
little
bit
of
trouble
a
year
ago,
give
it
another
shot,
kick
the
tires
and
if
you're
still
running
into
trouble,
we
are
always
hanging
out
at
slack.istio.io
or
discuss.istio.org,
and
I
would
definitely
be
hearing
interested
in
hearing
about
any
problems
that
you're.