►
From YouTube: Monolith to Microservices with Bite-Sized Kubernetes
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everybody
thanks
for
joining
this
webinar
on
monoliths
and
microservices
with
bite
size
kubernetes.
My
name
is
Tama
nakahar
I'm,
a
VP
of
the
developer
experience
at
a
company
called
weaveworks
where
we
created
gitups.
We
are
really
excited
to
bring
together
two
fantastic
speakers
on
this
topic.
We
think
it's
really
important
that
so
many
people
that
we
talk
to
in
the
kubernetes
community
and
especially
with
the
flux
project
that
we
created
and
maintained.
A
So
many
of
you
still
struggle
to
bring
your
monolith
to
microservices,
and
some
of
that
has
brought
you
to
the
kubernetes
space
which
people
like
Chris
and
Leo
agree
is
really
kind
of
a
no-brainer
for
this
challenge.
However,
that
doesn't
mean
that
it's
easy,
so
we're
really
excited
to
bring
these
two
speakers
together
to
first
of
all
talk
about
what
microservices
exactly
means
for
you
and
that
Journey
can
be
hopefully
a
little
less
daunting.
Chris
Richardson
is
the
create
of
microservices.io,
has
been
working
in
this
space
for
over
10
years.
A
B
Welcome
to
my
talk
on
the
microservice
architecture
in
this
talk,
I'm
going
to
answer
the
following
questions:
what
is
the
microservice
architecture?
Why
should
you
use
it?
When
should
you
use
it
and
how
do
you
adopt
it?
But
first
let
me
introduce
myself.
I've
done
a
number
of
things.
Over
the
past
40
years,
for
example,
I
developed
lisp
systems
in
the
late
80s
early
90s
I
also
created
the
original
cloud
Foundry
back
in
2008
and
since
2012
I've
been
focused
on
what
eventually
became
known
as
the
microservice
architecture.
B
I
help
organizations
around
the
world
use
microservices.
Here's
the
agenda
for
my
talk
first
I'm
going
to
describe
why
we
need
to
deliver
software
rapidly,
frequently
and
reliably
after
that
I'm
going
to
describe
the
monolithic
and
microservice
architectures
next
I'll
describe
how
to
refactor
an
existing
monolithic
application
to
microservices.
B
Finally,
I'll
talk
about
how
the
microservices
pattern
language
can
be
your
guide
when
designing
an
architecture.
These
days
the
world
is
crazy.
All
more
specifically,
it's
volatile.
It's
uncertain,
it's
complex
and
ambiguous.
Not
only
do
businesses
have
to
deal
with
unexpected
new
competitors,
they
also
need
to
deal
with
pandemics,
Wars
and
so
on.
In
order
to
thrive,
businesses
need
to
be
nimble,
agile
and
innovate.
Faster.
Modern
businesses
are
powered
by
software.
This
means
that
if
you're
responsible
for
a
business,
critical
application,
then
you're
under
immense
pressure
to
deliver
software
rapidly,
frequently
and
reliably.
B
Specifically,
your
organization
needs
to
be
high,
performing
as
defined
by
the
Dora
metrics.
There
are
four
Dora
metrics.
The
first
is
deployment
frequency,
which
is
the
rate
at
which
changes
are
deployed
or
released
into
production.
This
needs
to
be
high.
The
second
metric
is
lead
time,
which
is
the
time
from
commit
to
deploy.
It
must
be
low.
The
third
metric
is
time
to
restore
a
service.
You
need
to
be
able
to
quickly
recover
from
production
outages.
The
fourth
metric
is
change
failure
rate,
which
is
how
often
a
change
to
production
causes
an
outage.
B
This
obviously
needs
to
be
low.
In
other
words,
you
need
to
move
fast
and
not
break
things,
but
unfortunately
your
reality
is
probably
very
different.
Deployments
are
in
frequent,
painful
and
often
result
in
production
outages.
What's
more,
your
monolithic
technology
stack
is
out
of
date
to
deliver
software
rapidly,
frequently
and
reliably.
You
need
what
I
call
the
success
triangle.
First,
you
need
the
right
development
process,
specifically
devops,
as
defined
by
the
devops
handbook,
for
example,
developers
commit
changes
frequently
and
an
automated
deployment
pipeline
builds
and
tests
each
change
and
deploys
it
into
production.
B
Second,
you
need
the
right
organizational
structure.
That's
a
Loosely,
coupled
network
of
cross-functional
autonomous
teams
by
Loosely
coupled
I
mean
that
a
team
can
get
their
work
done
without
constantly
having
to
coordinate
with
other
teams.
The
book
teams-
apologies
is
a
must
read
on
this
topic
and,
finally,
you
need
an
architecture
that
supports
devops
and
Loosely.
Coupled
teams,
you
might
consider
asking
Twitter
about
whether
to
use
the
monolithic
architecture
or
the
microservice
architecture,
as
you
might
expect,
on
Twitter,
there
are
lots
of
opinions.
Some
are
more
helpful
than
others
in
reality.
B
The
answer
to
this
question
is
that
it
depends,
but
on
what?
What
are
the
criteria
that
you
should
consider?
When,
selecting
an
architectural
style
to
answer
that
question?
I
now
want
to
talk
about
architecture
patterns
for
modern
software.
The
software
development
Community
is
divided
by
what
Neil
Ford
calls
the
suck
Rock
dichotomy.
Your
favorite
technology
sucks
mine,
rocks.
Much
of
the
microservices
versus
monolithic
architecture.
Debate
is
driven
by
this
mindset,
a
powerful
antidote
to
the
suck
Rock
dike
economy
of
patterns.
They
provide
a
valuable
framework
for
making
architectural
decisions.
B
A
pattern
is
a
reusable
solution
to
a
problem
occurring
in
a
context,
along
with
its
consequences.
It's
a
relatively
ancient
idea,
first
described
in
the
70s
by
the
real
world,
architect,
Christopher
Excel
Alexander.
They
were
then
popularized
in
the
software
Community
by
the
gang
of
four
book
in
the
mid
90s.
What
makes
patterns
especially
valuable
is
their
structure.
B
In
particular,
a
pattern
has
consequences.
The
pattern
forces
you
to
consider
both
the
benefits
and
the
drawbacks
of
a
particular
approach.
It
also
requires
you
to
consider
the
patterns
issues
which
are
the
sub
problems
that
are
created
by
applying
this
pattern.
A
pattern
typically
references,
the
success,
the
patterns
that
solve
those
sub-problems
and
then.
B
Finally,
a
pattern
must
also
reference
alternative
patterns
which
are
different
ways
of
solving
the
same
problem
later
on
I'll
describe
some
specific
patterns,
sometimes
the
patterns
that
are
related
through
the
predecessor,
successor
relationship
and
the
alternative
relationship
form
of
pattern,
language,
a
pattern.
Language
is
a
collection
of
patterns
that
solve
problems
in
a
particular
domain.
Nine
years
ago,
I
created
the
microservices
pattern,
language,
with
a
goal
of
helping
Architects
use,
microservices
more
appropriately
and
effectively
on
the
left,
are
the
monolithic
architecture
and
microservice
architecture
patterns.
They
are
alternative,
architectures
for
your
application.
B
All
of
the
other
patterns
are
direct
or
indirect
successive
patterns
of
the
microservice
architecture
pattern.
They
solve
the
problems
that
you
create
for
yourself
by
using
microservices
the
pattern.
Language
can
be
your
guide
when
defining
an
architecture.
The
way
you
use
it
to
solve
a
problem
in
a
given
context
is
as
follows.
First,
you
find
the
applicable
patterns.
Next,
you
assess
the
trade-offs
of
each
pattern.
You
then
select
a
pattern
and
apply
it.
This
pattern
updates
the
context
and
creates
one
or
more
sub
problems.
B
You
then
repeat
this
process
recursively
until
you
have
designed
an
architecture.
I
now
want
to
describe
the
first
tattoo
patterns,
monolithic
architecture
and
microservice
architecture.
These
two
patterns
are
alternative
solutions
to
the
same
problem:
the
monolithic
architecture
structures,
the
application
as
a
single
Deployable
or
executable
component.
The
microservice
architecture
consists
of
multiple
components
or
Services.
These
two
patterns
share
the
same
context
and
forces.
Let's
look
at
the
context.
B
The
context
is
the
environment
within
which
you
are
developing
modern
applications.
It's
as
I
described
earlier,
the
need
for
Loosely
coupled
devops
teams
to
deliver
software
rapidly,
frequently
and
reliably
as
measured
by
the
Dora
metrics.
Let's
now
talk
about
the
problem
that
these
two
patterns
solves.
B
Roughly
speaking,
the
problem
is
to
design
an
application
architecture,
but,
more
specifically,
we
can
frame
the
problem
as
how
to
group
the
application
subdomains
to
form
executable
or
Deployable
components,
which
are
also
known
as
Services
a
subdomain
models
and
implements
a
slice
of
business
functionality,
which
is
sometimes
known
as
a
business
capability.
Each
subdomain
is
owned
by
a
small
team,
that's
responsible
for
its
development.
The
subdomains
must
be
grouped
to
form
executable
or
Deployable
components.
A
monolithic
architecture
consists
of
a
single
component.
A
microservice
architecture
consists
of
multiple
components
or
Services.
B
B
For
example,
the
authors
of
the
accelerate
book
describe
how
testability,
deployability
and
loose
coupling
are
essential.
In
addition,
if
you're
building
a
long-lived
application,
you
need
an
architecture
that
lets
you
easily
upgrade
its
technology
stack
I've
generalized
these
architectural
requirements
into
what
I
call
the
dark,
energy
and
dark
matter.
Forces
dark
energy
and
dark
matter
are
concepts
for
astrophysics,
but
they
are
good
metaphors
for
the
conflicting
forces
or
concerns
that
you
must
resolve
when
designing
an
architecture.
B
These
forces
include
team
autonomy,
fast
deployment
pipeline,
the
need
to
support
multiple
technology
stacks
and
so
on.
Another
dark
energy
force
is
the
need
to
segregate
subdomains
by
their
characteristics,
such
as
resource
requirements,
business
criticality
or
regulatory
requirements.
Dark
matter
is
an
invisible
matter
that
has
a
gravitational
effect
on
stars
and
galaxies.
It's
a
metaphor
for
the
attractive
forces
that
encourage
you
to
put
sub-domains
in
the
same
service.
They
are
primarily
generated
by
the
operations
that
span
subdomains.
B
These
forces
include
simple,
efficient
interactions
between
Services
minimizing
design,
time
and
runtime
coupling
between
services
and
preferring
asset
transactions,
to
eventual
consistency.
Let's
now
look
at
each
pattern
solution
in
a
little
more
detail.
The
monolithic
architecture
is
an
architectural
style
that
structures
the
application
as
a
single
executable
component.
A
monolithic
application
typically
consists
of
a
single
code
repository
multiple
teams,
work
on
different
modules
of
the
same
application,
there's
a
deployment
pipeline
that
builds
and
tests
the
application
and
deploys
it
into
production.
B
This
architecture
has
numerous
benefits
and
drawbacks
because
the
monolithic
architecture
consists
of
a
single
component.
It
resolves
the
Dark,
Matter,
attractive
forces.
All
interactions
between
the
applications
modules
are
local
and
so
they're
simple
and
efficient.
There's
no
runtime
coupling.
Moreover,
the
application
can
Implement
operations
using
acid
transactions,
which
are
simple
and
familiar,
but
whether
the
architecture
resolves
the
first
three
dark
energy
forces
depends
upon
the
size
of
the
application
and
the
number
of
teams
that
are
developing
it.
B
As
the
monolith
grows,
it
becomes
more
complex,
it
takes
longer
to
build
and
test,
so
the
single
deployment
pipeline
just
gets
slower
and
slower.
Even
the
application.
Startup
time
can
impact
the
deployment
pipeline,
also,
as
the
number
of
teams
increases
their
autonomy
declines,
since
they
are
all
contributing
to
the
same
code
base
in
the
single
repository,
for
example,
even
something
as
simple
as
pushing
changes
to
the
code
repository
can
be
challenging
due
to
contention.
B
Some
of
these
issues
can
be
mitigated
through
design
techniques
such
as
modularization
and
using
sophisticated
build
Technologies
such
as
an
automated
merge
queue
and
clustered
builds.
However,
ultimately,
it's
likely
that
the
monolithic
architecture
will
become
an
obstacle
to
Rapid
frequent
and
reliable
deployment.
Furthermore,
the
monolithic
architecture
cannot
resolve
the
last
two
dark
energy
forces.
It
can
only
use
the
single
technology
stack
back.
You
need
to
upgrade
the
code
base
in
one
go,
which
can
be
a
significant
undertaking
and
since
there's
only
a
single
component,
there's
no
possibility
of
segregating
subdomains
by
their
characteristics.
B
The
monolith
is
inherently
a
mixture
of
subdomains
with
different
scalability
requirements,
security
requirements
and
business
criticality.
The
microservice
architecture
is
an
architectural
style
that
structures
the
application
as
a
set
of
components
or
in
other
words
Services.
Each
service
is
Loosely
coupled
independently
Deployable
implements
one
or
more
business
capabilities
and
is
often
owned
by
a
small
team.
A
service
has
an
API
that
consists
of
operations
and
events.
B
An
operation
is
a
behavior
that
can
be
invoked
by
a
client
either
synchronously
using
a
protocol
like
rest
or
Ace
synchronously
using
messaging
events
are
published
by
a
service
when
something
notable
occurs,
such
as
the
creation
or
updating
of
a
business
entity.
A
service
can
collaborate
with
other
services.
It
can
invoke
their
operations
and
consume
their
events.
A
service
consists
of
code
in
a
source
code
repository,
there's,
two
types
of
code,
application
code
and
infrastructure
code.
Application
codes
such
as
Java
or
golang,
is
the
services
implementation.
B
The
infrastructure
code,
such
as
kubernetes
yaml
or
terraform
configures
the
infrastructure
needed
to
run
the
service
a
service
has
a
deployment
pipeline
which
builds
tests
and
deploys
the
service
at
runtime.
The
service
consists
of
one
or
more
service
instances,
typically
containers,
and
it
also
consists
of
infrastructure
such
as
databases
and
message
queues.
An
essential
characteristic
of
the
microservice
architecture
is
that
each
service
is
independently
Deployable.
This
doesn't
just
mean
that
a
service
is
packaged
as
a
container
image
it's.
Instead,
it
means
that
a
service
can
and
should
be
tested
in
isolation.
B
Using
test
doubles
for
its
dependencies.
It's
then
deployed
into
production
without
any
slow
and
brittle
end-to-end
tests.
A
service
is
Loosely
coupled
there
are
two
types
of
coupling
design
time
coupling
which
I'll
talk
about
later
and
runtime.
Coupling
runtime
coupling
between
Service,
A
and
B
is
the
degree
to
which
the
availability
of
service
a
is
affected
by
the
availability
of
service
B.
B
For
example,
the
order
service
is
tightly
coupled
to
the
customer
service
if
it
cannot
respond
to
a
create
order
request
until
the
customer
service
responds
to
it.
This
reduces
the
availability
of
the
create
order
operation.
Ideally,
the
order
service
should
be
able
to
respond
to
an
HTTP
post
without
waiting
for
a
response
from
the
customer
service.
B
This
is
known
as
the
self-contained
service
pattern,
and
it
typically
requires
a
service
to
use
asynchronous
collaboration
patterns
such
as
Saga
design,
time
coupling
is
the
degree
to
which
service
a
is
forced
to
change
in
lockstep
with
service
B.
Two
services
are
tightly
designed
time,
coupled
when
they
regularly
change
in
lockstep.
For
the
same
reason,
tight
design
time
coupling
reduces
productivity
because
it
requires
time-consuming,
API
changes
and
coordination
between
teams.
B
One
way
to
minimize
design
time
coupling
is
to
design
services
so
that
they
look
like
icebergs
an
iceberg
service
has
a
small,
stable
API
that
encapsulates
its
much
larger
implementation.
This
enables
the
services
team
to
make
changes
without
regularly
impacting
the
services
clients
loose
design
time.
Coupling
also
means
that
your
services
should
not
share
database
tables.
For
example,
the
order
service
should
not
access
the
customer
table
directly.
Instead,
it
should
use
the
customer
services
API.
B
B
Services
should
rarely
Implement
a
technical
function,
for
example,
it's
a
red
flag
and
for
services
simply
a
wrapper
around
a
database.
The
relationship
between
teams
and
services
is
an
interesting
topic,
since
one
of
the
goals
of
the
microservice
architecture
is
team
autonomy,
it's
common
for
each
service
to
be
owned
by
a
single
team.
This
is
the
service
per
team
pattern.
However,
sometimes
the
service
might
be
owned
by
two
or
more
teams,
especially
when
it
resolves
dark
matter.
Forces
such
as
efficient
interactions.
B
It's
important
to
remember
that
if
a
service
is
owned
by
a
small
number
of
teams,
it
does
not
necessarily
reduce
team
autonomy.
Moreover,
it
can
help
you
avoid
having
an
excessively
fine-grained
architecture,
which
is
known
as
the
more
the
merrier
anti-pattern.
In
fact,
a
team
should
only
own
more
than
one
service
if
and
only
if
it
solves
a
tangible
problem.
For
example,
the
fraud
team
might
need
to
have
an
additional
python
service
in
order
to
run
a
python
based
machine
learning
model.
B
The
microservice
architecture
has
various
benefits
and
drawbacks
when
compared
with
the
monolithic
architecture,
the
benefits
and
drawbacks
are
flipped.
The
microservice
architecture
pattern
can
resolve
the
dark
energy
repulsive
forces,
but
potentially
not
resolve
the
Dark
Matter
forces.
You
need
to
carefully
design
the
microservice
architecture,
in
other
words
the
grouping
of
subdomains
to
form
services
and
the
design
of
the
operations
that
span
multiple
services.
In
order
to
resolve
these
forces,
you
should
consider
using
the
microservice
architecture
when
one
or
more
of
the
following
is
true.
Your
application
is
large.
B
A
large
number
of
developers
are
working
on
the
application.
You
need
to
use
multiple
technology
Stacks,
it's
beneficial
to
segregate
subdomains
by
their
characteristics,
for
example,
segregating
subdomains
by
their
resource
requirements,
might
improve
scalability
or
segregating
them
by
their
business.
Criticality
can
improve
availability.
So,
let's
imagine
that
one
or
more
of
these
are
criteria
applied
to
your
monolithic
application.
How
exactly
do
you
adopt
the
microservice
architecture?
There
are
numerous
principles
for
migrating.
A
monolith
to
microservices
I
want
to
talk
about
these
six
principles.
B
The
first
principle
is
make
the
most
of
your
monolith.
Remember
it's
not
an
anti-pattern.
If,
if
software
development
is
slow,
then
improve
your
process,
you
will
need
to
do
that
anyway,
when
adopting
microservices
adopt.
Devops
is
defined
by
the
devops
handbook,
automate
your
deployment,
Pipeline
re-team
topologies
and
improve
your
organization.
Similarly,
if
your
application
technology
stack
is
out
of
date,
don't
automatically
assume
that
you
should
modernize
it
to
microservices.
B
B
B
The
third
principle
for
refactoring
to
microservices
is
that
you
should
Define
a
draft
Target
architecture
up
front
assemblage
is
the
name
of
the
architecture,
design
process
that
I
like
to
use.
It
takes
your
applications
requirements
as
input
and
defines
a
service
architecture
that
consists
of
one
or
more
components.
It's
important
to
remember,
however,
that
this
target
architecture
is
not
set
in
stone.
When
you
do
the
migration
you'll
learn
more
about
both
your
application
and
the
microservice
architecture.
As
a
result,
you
should
expect
to
evolve
the
target
texture.
B
The
fourth
principle
for
refactoring
to
microservices
is
that
it
should
be
done
incrementally
using
the
Strangler
application
pattern.
The
evolution
of
your
architecture
looks
something
like
this
at
the
beginning,
you
just
have
the
monolith
over
time.
More
and
more
functionality
is
migrated
out
of
the
monolith
into
services.
B
You
can
also
Implement
new
features
directly
as
Services
the
monolith
gradually
shrinks
and
my
ultimately
disappear.
The
fifth
principle
is
that
you
should
focus
on
migrating
functionality
that
gives
you
the
highest
return
on
investment
migrating.
A
module
out
of
the
monolith
into
a
service
is
time
consuming.
B
For
example,
you
need
to
untangle
dependencies
as
a
result,
you
should
only
want
to
migrate
a
module
if
there's
a
benefit
to
doing
so.
In
other
words,
if
it
resolves
one
or
more
of
the
dark
energy
forces
such
as
improved
team
autonomy
or
faster
deployment
pipeline,
a
good
way
to
visualize
priorities
is
to
place
the
applications
modules
on
a
cost
benefit.
Matrix.
You
want
to
focus
on
those
modules
in
the
top
right
quadrant.
The
sixth
principle
for
refactoring
to
microservices
is
that
you
should
measure
success
using
the
right
metrics.
B
Success
is
not
measured
by
counting
the
number
of
services,
there's
not
inherent
value
in
having
Services
what
matters
are
the
benefits
of
of
using
Services.
There
are
two
types
of
metrics
that
measure
success.
The
first
are
improvements
to
the
Dora
metrics.
You
want
to
see
a
reduction
in
lead
time,
which
is
the
time
from
commit
to
deploy.
You
want
to
see
an
increase
in
deployment
frequency,
while
at
the
same
time
you
want
to
see
deployments
become
much
more
reliable.
The
second
way
to
measure
success
are
improvements
to
the
other
illites
such
as
scalability.
B
In
the
final
part
of
my
talk,
I
want
to
explain
how
the
microservices
pattern
language
can
be
your
guide
when
designing
an
architecture
deciding
to
use
the
microservice
architecture
is
just
the
beginning
of
the
architecture
definition
process.
The
pattern
language
consists
of
solutions
to
the
numerous
problems
that
you
create
for
yourself
by
deciding
to
use
microservices.
B
There
are
three
categories
of
patterns.
The
first
category
are
application
focused
patterns.
These
include
patterns
for
Designing
operations
that
span
multiple
services,
such
as
the
Saga
pattern
and
the
cqrs
pattern.
The
third
category
are
patterns
that
are
infrastructure
focused.
These
include
include
the
deployment
patterns,
except
for
serverless.
Actually
in
between
is
the
second
category
which
are
patterns
that
are
a
combination
of
application
code
and
infrastructure.
B
For
example,
developers
write
application
code
that
uses
infrastructure
Services
most
observability
patterns
fall
into
this
category.
The
serverless
deployment
pattern
is
also
in
this
category,
since
it's
a
combination
of
a
programming
model
and
infrastructure.
Let's
now
look
at
a
few
of
these
patterns.
There
are
two
database
architecture
patterns.
The
first
is
the
shared
database
pattern.
B
B
This
pattern
reduces
design
time
coupling
between
Services
one
drawback,
however,
is
the
transaction
management
is
more
complicated,
an
operation
that
spans
multiple
Services
cannot
be
implemented
as
an
asset
transaction.
Instead,
you
must
use
eventual
consistency.
There
are
four
patterns
for
implementing
operations
that
span
Services
a
command,
which
is
an
operation
that
updates
data
can
be
implemented
using
either
The
Saga
pattern
and
or
the
command
side
replica
pattern,
a
query
which
is
an
operation
that
retrieves
data
can
be
implemented
using
either
the
API
composition
pattern
or
the
cqrs
pattern.
B
One
drawback
of
these
four
patterns
is
that
they
are
eventually
consistent
as
a
result,
using
them
is
more
complex
than
using
acid
transactions.
The
pattern
language
contains
numerous
patterns
related
to
inter-service
communication.
The
communication
style
patterns
are
remote
procedure,
invocation
and
messaging
remote
procedure
and
vacation
style.
Communication
such
as
rest
is
simple,
familiar
and
easy
to
use.
One
drawback,
however,
is
that
it
can
create
excessive
runtime
coupling
which
reduces
availability.
As
a
result,
it's
a
pattern
that
you
should
use
very
carefully.
The
other
communication
style
pattern
is
asynchronous
message.
B
There
are
various
flavors
of
asynchronous
messaging,
including
events.
The
application
typically
uses
a
message
broker
such
as
Apache,
Kafka
or
rabbitmq.
Alternatively,
it
might
use
a
brokerless
messaging
mechanism
such
as
web
hooks
asynchronous
messaging
is
more
complex.
However,
a
key
benefit
is
that
it
reduces
runtime
coupling
between
Services
the
pattern.
Language
includes
several
deployment
patterns,
including
service
per
VM
service
per
container
and
serverless
deployment.
B
B
So
that's
my
part
of
this
presentation.
In
summary,
the
best
architecture
for
your
application
depends
upon
the
details
of
your
application
and
your
organization.
The
microservices
pattern.
Language
is
your
guide
when
designing
an
application
architecture.
The
dark,
energy
and
dark
matter
forces
are
a
very
useful
set
of
criteria
for
helping
you
decide
between
the
monolithic
and
microservice
architecture.
If
you
decide
to
migrate
your
monolithic
application
to
microservices
it's
important
to
follow
the
refactoring
principles
in
particular,
it's
essential
that
you
incrementally
migrate
to
a
microservice
architecture.
C
All
right,
thank
you
so
much
Chris.
This
was
very
insightful.
I
hope
you
all
really
appreciated
all
the
really
really
cool
knowledge
that
you
that
Chris
just
shared
right,
like
microservices
monoliths,
went
to
pick
one
over
the
other
and
the
differences
around
these
architectural
patterns.
That
was
really
awesome.
Thank
you,
Chris.
So
I
want
to
take
all
that.
Chris,
just
shared
with
you
and
breaking
down
to
the
world
of
kubernetes.
C
Okay
I
want
us
to
talk
as
to
how
we
can
actually
and
likely
will
have
to
run
and
operate
and
build
and
maintain
workloads
that
are
following
both
architectural
patterns
and
that
we
can
do
that
on
top
of
kubernetes,
using
all
the
capabilities
that
kubernetes
can
offer.
Okay
before
I.
Get
to
that,
though,
I'd
like
to
introduce
myself.
My
name
is
Leonardo
morillo
I
am
principal
Solutions
architect
at
weaveworks,
and
we
are
the
github's
company.
C
C
This
webinar
is
sponsored
by
the
CNC
app
the
cloud
native
Computing
foundation,
and
we
have
actually
donated
a
few
of
our
projects,
flux
which
is
a
get
Ops
toolkit
Flagger
for
Progressive
deployment
to
the
cncf,
and
we
build
other
products
such
as
we've,
get
UPS
open
source
and
with
github's
Enterprise,
to
enhance
and
extend
the
capabilities
of
our
open
source
solutions
for
github's
deployment
policies,
code,
cluster
lifecycle
management
and
many
many
other
things.
So
look
us
up
we're
doing
a
lot
of
cool
things
that
likely
will
help
your
Enterprise
as
well.
C
So
now
that
I
mentioned
Enterprise,
let's
talk
a
little
bit
as
to
what
the
reality
of
the
Enterprise
is.
Okay,
it's
very
likely
that,
for
most
of
you
that
are
listening
to
me
now,
Greenfield
is
far
from
our
reality.
Right
most
of
the
people
that
I
work
with
most
of
our
clients
are
actually
Enterprise
level
organizations
that
have
a
lot
of
Legacy
code
bases.
They
have
huge
monoliths
that
are
mission,
critical
they're,
basically
not
going
anywhere
anytime
soon.
C
So
it
is
very
important
to
realize
that
as
much
as
there
are
as
there
are
all
these
different
architectural
patterns
that
we
can
leverage
today,
monoliths
are
mission.
Critical
and
they're
gonna
stick
around
for
a
while,
okay
and
it's
because
it
takes
effort
and
time
to
strangle
them
or
to
build
new
capabilities
using
a
different
architecture
pattern
to
replace
them
over
time.
These
are
applications
that
have
been
long-standing,
as
I
mentioned,
they're,
Mission,
critical
and
the
risk
and
effort
Associated
to
modernizing
them
is
non-trivial.
C
So
it's
important
for
everybody,
both
those
that
are
building
this
application
developers,
as
well
as
the
people
that
are
managing
those
operations
and
devops
teams
and
infrastructure
teams,
and
all
the
people
that
have
to
deal
with
this
applications
to
realize,
and
we
probably
already
have
that
it
will
take
time
for
us
to
go
from
having
monoliths
in
our
infrastructure
and
in
our
solutions
to
just
being
microservices.
Okay.
C
But
the
idea
here
is
that
we
want
to
choose
a
platform
that
will
simplify
the
process
of
us
moving
from
one
to
the
other
and
into
the
future
right,
because
we're
talking
about
models
and
microservices
today,
Chris
briefly
mentioned
functions
and
service
or
serverless,
as
it's
all
also
known,
there
likely
will
be
other
patterns
that
we'll
have
to
adapt
for
that
will
have
to
operate.
We
have
to
build
so.
C
The
whole
idea
here
is
what
we
can
do
to
abstract
complexity
from
this
heterogeneous:
complex
environments,
it's
better
for
everybody,
it's
better
for
the
developers
that
are
building
those
services
that
are
that
are
operating
those
Solutions
and
it's
it's
indispensable
to
reduce
the
friction
so
that
all
these
different
generations
of
Technology
can
coexist
and
that's
where
I
think
kubernetes
provides
us
with
a
unique
Advantage.
Okay.
So
let's
look
at
to
our
agenda.
C
This
is
exactly
what
we're
going
to
be
looking
at
today,
one
we're
going
to
talk
about
the
different
Solutions
out
there
and
capabilities
that
allows
us
to
use
kubernetes
as
our
holistic
workload
scheduler
okay.
So
this
is
whether
you're
running
VMS
or
whether
you're
running
containers
or
functions
serverless.
You
can
basically
run
anything
and
everything
on
the
same
platform,
and
this
has
a
host
of
benefits
that
we'll
look
into
okay,
we're
gonna,
there's
a
lot
already
being
said
about
running
microservices
and
kubernetes,
it's
after
all,
kind
of
like
it's
most
a
friendly
environment.
Right.
C
We're
also
going
to
look
at
specifics
as
to
how
you
can
actually
run
your
monoliths
on
kubernetes
as
well
and
realize
that
containers
are
not
just
for
microservices.
You
can
actually
containerize
monoliths
and
there's
a
whole
SKU
of
benefits
that
you'll
get.
If
you
run
your
monoliths
containerized
in
a
common
platform,
together
with
the
rest
of
your
code
basis
or
your
services,
and
what
this
enables
you
to
do
is
to
reduce
the
complexity,
as
you
start
modernizing,
as
you
start
moving
forward.
C
C
There's
basically
Solutions
and
capabilities
out
there,
so
that
kubernetes
can
become
the
single
API
to
operate
any
type
of
resource
that
you
need
to
operate.
Okay,
here's
just
a
few
of
those
options
that
I
think
are
very
relevant
and
valuable.
We're
actually
going
to
go
in
depth
into
any
one
of
these,
but
I
think
it's
important
for
you
to
be
aware,
if
you're
not
already
of
the
different
tools
that
are
out
there,
that
allow
you
to
use
kubernetes
as
the
API
for
everything
there's
other
Talks
by
the
CNC,
if
they're
very
valuable
here
as
well.
C
So
look
them
up.
Whoever
is
allows
you
to
manage
virtual
machines
VMS,
just
as
you
would
any
other
workload
in
kubernetes
Cube
vert
is
a
project
also
donated
to
the
cncf
that
allows
you
to
declare
virtual
machines
as
kubernetes
objects,
okay.
So
this
is
one
path
where
you
can
start
integrating
workloads
that
are
running
on
VMS
with
containerized
workloads
and
manage
the
life
cycle
and
their
discoverability
and
how
to
reach
them
using
a
common
pattern
which
is
basically
driven
by
kubernetes,
declarative
configuration
services
and
all
these
other
capabilities.
All
these
other
Primitives.
C
That
kubernetes
enables
cross
plane.
Another
project
by
the
cncf
is
for
VMS
and
anything
else.
This
is
a
project
that
you
can
use
to
declare
any
Cloud
resource
any
manage
Cloud
resource
across
pretty
much
any
public
Cloud
that
is
out
there
using
the
same
patterns,
open
functions
as
a
service
if
you
need
to
run
functions
or
Services
as
a
service
within
your
cluster,
of
course,
containers.
C
Okay,
which
containers
are
kind
of
underlying
component
to
all
those
different
types
of
workloads,
and
now
we
have
the
open
container
initiative
right,
oci,
which
is
kind
of
this
new
standard
for
container
images.
So
point
being
kubernetes
is
a
growing
ecosystem
where
you
can
effectively
run
any
type
of
workload
in
the
platform
following
a
common
operating
model
using
declarative
configuration,
basically
reducing
the
complexity
and
friction
between
all
the
different
teams
that
are
managing
different
aspects.
Different
areas
of
your
architecture.
C
Now,
let's
talk
about
models
and
microservices
and
how
they
can
coexist,
and
just
as
I
mentioned,
as
well
as
any
other
Cloud
resource
that
you
have
serverless
functions
or
anything
else.
Okay,
now
the
way
for
mono
is
to
coexists.
This
is
after
going
from
just
VM
like
if
you're
already
running
a
monolith
on
a
virtual
machine,
you
can
use
cubert,
Let's,
Take,
It,
Forward,
okay,
let's
think
about
containers.
C
Okay,
your
microservices
are
already
containerized
they're,
already
server
stateless
they're
already,
hopefully
following
12
factors
in
their
Cloud
native,
but
it
is
possible
to
containerize
your
monolith
as
well
with
caveats
kind
of
knowing
where
to
look
and
how
to
approach
it.
Okay-
and
this
is
one
key
step
to
having
your
monolith
and
your
microservices
living
together
as
containers
in
the
common
platform.
Okay,
let's
start
with,
let's
just
first
look
at
kind
of
the
four
different
areas
where
you're
gonna
have
to
look
into
and
we'll
we'll
double
click
on
them
going
forward.
C
Okay,
stickiness
and
statefulness
is
one
of
the
most
monoliths
were
built
in
a
world
where
you're
not
really
looking
for
statelessness
right,
they
actually
hold
state
and
because
the
whole
state
you
need
to
have
session
Affinity
right.
If
I
make
a
request.
C
So
you
need
to
look
at
how
to
do
how
to
handle
this
stickiness
and
statefulness
when
you
containerized
a
modeler
in
into
a
container
of
course,
because
of
this
because
of
kind
of
like
the
way
that
states
managed
and
sessions
are
managed,
you
cannot
always
use
the
same
patterns
that
you
use
for
scaling
microservices
if
you're
running,
containerized,
monoliths,
okay,
so
Cloud
native
patterns
don't
always
apply,
and
when
I,
what
I
mean
by
that
is
you
usually
can't
always
do
horizontal
Auto
scaling?
C
So
you're
gonna
have
to
look
at
how
to
scale
your
monolith
in
in
this
new
environment
and
also
how
to
build
the
artifact,
because
most
monoliths
depend
and
expect
assume
a
lot
of
characteristics
are
met
by
the
underlying
nodes
that
are
running
the
workload
and
usually
not
immutable,
which
means
they're
not
replaced
with
new
versions
rather
they're
reconfigured,
to
run
the
new
version
when
a
new
release
happens.
Okay,
so
we're
gonna
have
to
look
as
to
how
how
to
go
from
mutable
to
immutable
and
how
to
handle
configuration.
C
Okay
and,
of
course,
build
size
and
time.
Okay
models
are
usually
larger
than
microservices.
Well,
they're,
larger
code
bases
they'll
do
a
whole
bunch
of
different
things.
So
we
want
to
make
sure
that
we
are
optimizing,
there's
new
artifacts
that
we're
building
not
just
for
their
build
size
and
well.
That
is
important
and
we'll
look
at
soon.
Why?
But
also
because
of
the
of
the
of
the
time
that
it
takes
to
build
right,
which
has
an
impact.
C
Chris
talked
about
Dora
metrics
right
how
quickly
you
can
get
a
new
version
built
and
how
quickly
you
can
actually
enable
your
developers
to
iterate
and
release
small
changes
will
be
critical
to
the
adoption
of
this
new
pattern
of
this
new
platform.
As
you
start
to
unify
your
microservices
and
your
monoliths
in
a
single
platform:
okay,
let's
let's
double
click
on
each
one
of
these
okay,
stickiness
and
statefulness.
C
C
That
needs
that
is
kept
and
known
by
that
instance,
and
my
next
request
is
gonna
have
to
hit
something
that
knows
that
same
thing:
okay,
there's
a
couple
of
areas
where
you
can
enable
session
stickiness
in
your
deployment
of
your
monolith
in
kubernetes,
and
this
is
dependent
on
where
you
need
it
and
usually
you
might
need
to
know
both
places.
It
can
be
done
at
the
service
level
or
at
the
Ingress
level.
C
Okay,
we're
going
to
look
a
little
bit
later
on
this
talk
as
to
what
those
different
components
are
just
remember,
you
can
do
it
in
both
places
and
it's
as
with
most
things
kubernetes,
either
just
a
a
change
in
the
configuration
of
the
object
that
you're,
deploying
or
just
an
annotation
annotations
are,
of
course,
dependent
on
the
Ingress
that
you're
using
so
here's
just
a
quick
example
of
how
you
use
it,
how
you
do
it
with
the
nginx
Ingress
controller,
you
can
do
it
with
service
measures
as
well.
C
You
can
do
it
with
SEO
and
you
can
do
it
with
other
increase
controllers.
They
all
have
kind
of
a
different
way
to
do
it.
I
guess
the
bottom
line
is,
and
it's
very
important
once
you're
going
into
this
world
of
containerizing
your
monolith,
and
you
want
to
run
it
together
with
your
with
your
microservices,
you
need
to
make
sure
that
your
underlying
infrastructure,
what
you're
doing
for
Ingress,
will
support
this
type
of
capability.
C
Now,
as
I
mentioned
session,
stickiness
is
mostly
related
to
statefulness.
There
is
a
an
object,
a
kind
that
allows
you
to
to
manage
deployments
of
stateful
workloads
in
kubernetes
and
they're
called
stateful
sets.
Okay
with
stateful
sets.
You
get
unique,
Network
identifiers
storage
that
is
attached
to
your
workload
will
remain
even
on
on
a
restart,
and
it's
always
ordered
okay.
So
using
these
two
well,
this
kind
of
three
different
configuration
areas
you
can
manage
statefulness
and
stickiness
of
your
monolith
when
containerized
Within
kubernetes.
C
Now
we
talked
about
scaling
your
monolith
in
kubernetes,
okay,
meaning
enabling
it
to
handle
moral
load.
Okay
with
microservices,
you
usually
rely
on
horizontal
portal.
Scalars,
okay,
horizontal
plural
scalars
will
create
multiple
instances
of
your
will,
increase
the
replicas.
It
will
increase
the
number
of
parts
that
are
serving
your
workload.
C
That's
not
always
possible
with
monoliths
because
of
what
we
just
talked
about
right,
State
and
stickiness
and
whatnot,
and
this
is
where
the
vertical
plot
autoscaler
comes
into
play:
okay,
the
vertical
part
of
the
scalar.
What
it
does
is
it
increases
and
it
it
gives
the
instance
of
your
workload,
more
resources.
It
doesn't
spin,
more
copies
of
it.
It
just
makes
them
handle,
have
more
memory
or
have
more
CPU
okay.
So
the
vertical
part
of
the
scalar
is
what
you
usually
want
to
use
for.
Monolithic
deployments
for
stickiness
and
stakeholders
are
relevant.
C
You
might
get
to
a
point
where
you're
requesting
more
capacity
than
a
given
node
is
able
to
provide
it
that
anyone
know
it
is
able
to
provide
which
would
make
your
workload
unable
to
be
scheduled
anywhere.
So
this
is
something
to
really
be
mindful
of
when
you
configure
the
the
patterns,
the
the
configuration
of
your
vertical
part
of
the
scaler,
and
when
you
define
your
node
capacity,
okay,
we'll
we'll
talk
about
how
to
also
isolate
monoliths
from
microservices
in
terms
of
node
going
forward.
C
Another
very
important
thing
is
you
don't
want
to
use
horizontal
protocol
scalar
and
the
vertical
part
Auto
scalar
together?
Okay,
that's
just
a
recipe
for
disaster
now
dependencies
and
configuration
okay,
we
mentioned
how
monoliths
are
usually
built
in
a
way
where
they
actually
expect
a
lot
from
the
underlying
Hardware
from
down
the
line.
Machine,
VM
or
whatever
is
it's
running
that
workload,
okay
and
and
what
I
mean
by
that?
Is
they
expect
packages
to
be
installed?
C
They
expect
files
to
be
in
some
path
and
they're,
usually
not
immutable,
and
what
I
mean
by
that
is
the
VM
and
its
configuration
is
managed
through
change.
Okay,
so
whenever
a
new
package
needs
to
be
installed,
it's
installed
on
top
of
the
VM
all
right
whenever
a
new
version
of
the
artifact
that
it
represents.
Your
monolith
is
built
it's
copied
over
and
replaces
the
previous
version
on
the
VM.
That's
running
it,
so
this
is
called
mutability
right,
you're
actually
mutating
the
VM
container
image
are
immutable.
C
Okay,
once
and
there's
a
whole
bunch
of
value
to
immutability
that
I
encourage
you
all
to
dig
deeper
into
We're,
not
gonna
talk
us
the
benefits
of
immutability,
but
container
images
are
immutable
and
by
being
immutable,
that
means
that
you're
packaging
everything
that
your
application
needs
to
run
on
a
single
artifact,
which
is
a
container
image.
Okay.
C
Now
that
means
that
there's
gonna
be
some
effort
to
go
over
when
you're
looking
to
identify
how
to
build
the
docker
files,
which
are
basically
the
configuration
files
that
Define
how
to
build
your
container
image
for
anybody.
That's
not
familiar
with
that.
You
build
the
image
of
your
monolith.
Okay,
you're
gonna
have
to
identify
what
packages
it
relies
on.
You're
gonna
need
to
identify
what
operating
system
it
expects
to
have
on
the
VM,
that's
currently
running,
so
that
you
can
use
it.
C
The
similar
container
base
image,
okay
and
there's
some
ways
for
you
to
accelerate
that
process.
If
there's
already
a
configuration
management
well,
managing
these
configuration
is
a
ansible
puppet
or
any
one
of
those
that
Services
have
as
a
great
Foundation
as
a
great
basis
for
you
to
identify
what
to
put
in
the
docker
file
for
the
container
image
to
be
built
so
that
it
satisfies
the
expectations
of
the
monolith.
Artifact
binary
that
you're
copying
into
that
container
image.
C
Okay,
now
there's
a
there's,
a
critical
aspect
here
to
consider-
and
that
is
that
a
lot
of
model
is
required
to
do
things
at
the
node
level.
Okay
and
and
I
know
that's
ambiguous,
but
this
is
where
security
contacts
come
into
place
play
a
a
container
running
within
kubernetes
is
usually
or
should
like,
should
be
very
much
isolated
from
the
underlying
node
right.
It
should
have
no
rights
to
see,
perform
or
otherwise
do
anything
at
the
node
level.
That's
not
always
possible
with
monoliths
okay.
C
So,
if
you're
going
to
run
both
monoliths
as
well
as
microservices
in
a
common
infrastructure
in
the
common
kubernetes
cluster,
it
is
important
to
have
them
isolated,
ideally
to
individual
nodes
that
are
only
running
this
type
of
workload.
This
is
also
beneficial
for
capacity
right.
They,
you
will
need
a
different
balance
of
capacity
for
your
microservices
to
your
monoliths
and
you'll
need
different
security
constraints.
Okay,
so
running
your
microservices
and
your
model
is
in
separate
environment
in
separate
groups
of
nodes.
C
It's
super
important,
particularly
when
your
model
is
or
any
one
of
your
workloads
require
privileged
security
context.
Okay,
there's
Primitives
in
kubernetes
that
allow
you
to
do
that.
You
can
use
stains,
you
need
affinity
and
you
can
use
security
policies
to
both
specify,
specifically
in
which
nodes
your
workload,
your
monolith,
your
containerized
monolith,
can
run
as
well
as
to
deny
any
sort
of
traffic
that
originates
from
those
nodes
or
the
namespace.
C
That's
running
your
monolith
to
any
other
node
group
or
namespace,
where
you're
running
non-privileged,
workloads,
okay,
and
we
also
talked
about
build
size
and
build
time.
Okay,
monoliths
are
usually
much
larger
than
microservices
because
of
what
they're
doing
they're
doing
a
whole
bunch
of
more
stuff
than
just
one
service,
which
means
the
build
time
is
usually
slower
and
the
container
images
are
usually
going
to
be
larger.
Okay,
this
is
going
to
have
an
impact
in
your
storage.
C
Okay,
container
images
are,
if
you're,
using
proper
practices
when
you're
building
those
Docker
files
they're
going
to
be
building
a
way
that
is
very
efficient.
Okay,
that
it
basically,
it
can
reuse
different
layers
that
you've
built
in
the
past
so
that
you
don't
consume
all
that
capacity
when
you're,
storing
them.
Okay,
the
only
store
kind
of
every
new
version
is
just
the
Delta,
the
difference
between
the
like
any
other
previous
layer
that
was
used
and
what
hasn't
what's
new?
C
Okay,
but
as
as
you
probably
know
it's
every
time,
a
new
container
image
is
downloaded
on
one
of
your
notes.
It's
stored
in
that
node.
So,
since
we're
doing
immutability,
which
we
weren't
before
we
have
a
large
binary
that
changes
all
the
time
might
not
be
changing
the
underlying
dependencies
and
if
you're,
using
Docker
files
right,
you
built
that
in
a
way
that
those
are
cached
and
not
reused
all
the
time.
C
But
if
you're
binary
the
one
that
you're
building
for
your
model
is
pretty
large
and
you're
doing
multiple
deployments
each
with
a
new
version
of
the
container
image.
For
your
for
your
release,
right
for
your
application
for
your
monolith,
that
means
that
your
node
is
going
to
have
multiple
versions
of
your
application
at
any
given
time
and
if
they're
large,
they
couldn't
consume
a
lot
of
artists.
C
Okay,
so
you
need
to
be
mindful
of
understanding
the
size
of
your
build,
making
sure
that
you're
using
proper
Docker
file
practices
to
reduce
it
to
the
kind
of
smallest
possible
size
and
then
make
sure
that
you
have
a
printing
mechanism
in
your
nodes.
So
you
can
get
rid
of
old
images
that
you're
no
longer
using
okay.
C
Now,
it's
very
important
for
your
initiative
to
get
buy-in
from
your
development
teams.
Okay,
your
development
teams
are
motivated
by
fast
delivery,
they're
gonna
appreciate
being
able
to
run
their
monoliths
locally
easily
they're
gonna
appreciate
how
container
images
will
enable
this
devops
benefits
right
of
of
you
have
the
same
code
base
and
you
run
it
anywhere
and
it's
it
operates
in
the
same
way
right
it's
fully
automated,
but
you
need
to
make
sure
that
you
are
quantifying
the
build
and
release
time.
C
Okay,
because
if
there's
one
thing
that
I
know
developers
hate
is
to
have
to
wait
for,
builds
and
deployments,
okay,
so
the
faster
that
you
can
actually
get
the
cycle,
the
better
for
you
to
gain
traction
within
your
organization,
the
better
for
you
to
actually
and
and
for
any
developer.
That
is
listening.
Guarantee.
You're
gonna
approve
this.
C
That
I'm
saying
right,
the
the
better
it
is
for
the
developers
that
are
now
using
this
new
platform
to
deploy
their
workloads
to
buy
in
so
make
sure
that
you
are
deploying
as
quickly
as
you
can
that
your
build
pipeline
happens
as
quickly
as
you
can
and
we'll
see.
How
get
Ops
can
help
with
that,
and
this
basically
gives
us
what
a
heterogeneous
architecture
will
look
like
right.
C
You
have
a
common
API
you're
using
ingresses
and
services
to
Route
requests
to
different
types
of
workloads,
those
that
are
horizontally,
Auto
scaling
that
our
microservices
that
are
running
in
their
own
namespace
and
those
that
are
vertically
Auto
scaling
and
using
staple
sets
and
other
capabilities
to
scale
which
are
your
container
rights,
monoliths
and
all
those
are
running
on
different
nodes
and
there's
policy
between
them.
So
what
does
this
look
there
right?
C
The
whole
idea
here
is
that
the
service,
basically
abstracts
whatever,
is
running
behind
it.
Okay,
so
it
could
be
a
containerized
monolith.
It
could
be
a
set
of
microservices,
but
it
doesn't
matter
because
you're
using
a
service
in
front
and
the
service
is
what's
handling,
whether
you're
session
Affinity
or
whatever.
It
is
that
your
monolith
needs.
The
service
is,
what's
abstracting,
access
to
it
and
what
any
other
service
or
any
outside
consumer
through
an
Ingress
will
need
to
no
no.
C
The
configuration
for
that
monolith
is
actually
a
file
in
the
file
system,
so
we're
gonna
use
more
kubernetes
capabilities
to
run
this
with
very
little
change
in
this
new
containerized
environment.
So
we're
going
to
mount
a
config
map
which
a
config
map
is
an
object
in
kubernetes
that
holds
basically
content
in
this
case.
Let's
imagine
a
Json
file
and
we're
going
to
mount
it
in
the
file
system.
Okay,
so
that's
very
little
change
to
the
containerized
modeler.
Okay,
the
service
is
using
session
Affinity,
the
Pod
is
vertical,
Auto
scaling,
so
state
is
managed.
C
The
stickiness
is
managed
and
we
didn't
even
have
to
change
how
the
monolith
loaded
its
configuration,
because
we're
loading
it
from
the
file
system
using
a
config
map
as
it's
the
origin
of
that
configuration.
Now.
Let's
imagine
we
scratched
the
user's
capability,
because
we
now
have
a
user's
microservice,
okay,
so
this
is
that
path
right
of
strangling
this
application.
C
We
had
all
these
sets
of
capabilities
in
a
single
monolith,
we're
taking
bounded
context
out
of
it
and
creating
small
services
from
them,
and
this
new
services
are
actually
Cloud
native
and
they
are
actually
using
following
the
12
factors.
So
how
would
that
look?
In
the
previous
slide?
We
saw
one
Ingress
sending
all
traffic
to
one
service,
and
then
the
model
is
just
doing
its
thing.
Okay,
here
we're
saying
now
we're
going
to
split
something
out.
Users
is
no
longer
going
to
be
in
this
monolith,
so
we
use
the
Ingress.
For
that.
C
We
add
on
the
rule
that
says
anything
that
is
slash.
Users
is
now
going
to
hit
the
user's
microservice,
which
has
different
rules.
It's
not
using
session
affinity
and
the
same
config
map
that
we
had
mounted
or
that
we
have
mounted
as
a
file
in
the
file
system
of
the
containerized
monolith
is
now
injected
in
the
environment
of
this
new
workload
of
this
new
microservice,
and
we
can
actually
do
horizontal
scaling
with
it.
C
So
this
is
the
pattern
that
we
can
use
to
over
time
start
eliminating
components
out
of
the
containerized
monolith
and
pushing
them
to
other
services,
and
we
can
actually
share
the
same
configuration
and
inject
it
differently
into
different
types
of
services
as
we
proceed
as
we
as
we
go
through
this
process
of
modernization.
Okay
and
of
course,
we
need
to
talk
about
get
UPS
because
really
get
UPS
companies.
So
let's
talk
about
GitHub
physical
and
deployment
pattern.
Okay
for
us
to
accomplish
this,
we
need
configuration
and
that's
the
beauty
of
githubs.
C
Okay,
the
configuration
of
your
monolith,
whether
it's
VMS,
whether
it's
a
containerized
monolith
with
vertical
part
on
a
scalar
and
session
stickiness
such
an
affinity
or
a
microservice
that
is
fully
Cloud
native,
no
matter
what
the
type
of
workload
it
is.
C
Think
that's
one
of
the
key
risks
to
modernizing
Legacy
application
to
straggling
monoliths
right,
there's
a
lot
of
fear
of
breaking
stuff
and
it's
high
risk
right.
Looking
at
Legacy
code
bases
extracting
the
components
of
that
into
its
own
new
service.
It's
non-trivial.
It
takes
a
lot
of
effort
and
it
takes
a
lot
of
planning
and
strategy
right.
So
we
want
to
be
able
to
do
that
without
breaking
anything
and
by
using
declarative
configuration.
C
We
can
do
very
soon
and
they're,
using
kubernetes
and
containers
as
a
common
platform
for
runtime
makes
it
even
easier
and
with
tools
such
as
with
gitups,
you
can
actually
automate
where
you
feel
comfortable.
You
can
have
manual
Gates
by
using
pull
requests
and
stuff
like
that,
to
basically
provide
a
means
for
humans
to
interface,
in
your
delivery
process,
in
your
employment
process
and
integrate
with
any
number
of
audits
alerts
and
any
other
mechanism
that
you
need
to
make
sure
that
you
understand
and
that
your
developers
understand
what's
going
on
okay.
C
But,
aside
from
that
operating
all
those
different
architectures
on
top
of
a
common
platform
which
is
kubernetes,
really
reduces
complexity,
and
it
streams
lines
the
path
right.
It
makes
it
easier
for
you
to
migrate
and
refactor
over
time
because
of
all
the
negative
capabilities
that
it
offers.
Kubernetes
is
ideal
for
this,
and
the
containers
are
not
just
for
microservices.
C
You
can
actually
use
them
for
monoliths
as
well,
and
if
you
choose
to
use
models
to
to
run
your
model
as
ask
containers
in
kubernetes,
you
need
to
be
mindful
of
not
isolation,
capacity,
Planning,
Network
policies,
so
that
when
the
running
privileged
workloads
and
less
than
ideal
scaling
mechanisms,
they're
basically
running
in
a
protected
environment
where
they
can't
negatively
impact
other
workloads
that
are
following
different
architectural
patterns.
So
thank
you
very
much.
I
hope
this
was
insightful
and
please
look
us
up.
C
A
I
hope
that
was
really
useful.
It
was
quite
information,
packed
and
again
we're
here
to
help
you
both
on
your
monolith
to
microservices
Journey,
as
well
as
how
kubernetes
fits
into
that.
If
you
have
any
follow-up
questions,
we
have
the
contact
information
here
for
Chris
Leo
and
I'm
Tamo
nakahara.
If
you
have
any
questions
for
me,
I'm
happy
to
help
and
we'll
leave
you
with
one
of
our
recent
blogs
that
hopefully
will
be
useful
you
for
you.