Exploring the drivers behind the Microservices hype, and defining the prerequisites in architecture and infrastructure needed before contemplating this path.
Presented at the first Sydney Microservices Meetup - Small Talk.
Architecture • Defining
the
boundaries
between
components
(modularisaHon)
to
• minimise
dependencies
between
components
(coupling)
and
• maximise
cohesiveness
within
components
! • Equips
us
to
deal
with
CHANGE High Cohesion Low Coupling High Cohesion
System • A
unit
of
deployment
and/or
development
and/or
(most
likely)
purchase
or
commissioning
• Independent
of
other
systems
• UI
and
persistence
• Development
and
evoluHon
• OperaHons
• Frameworks
and
languages
• Underlying
runHme
‘process’
• Limited
interacHon
with
other
systems Independent Limited Independent
System Early
ObjecHves • This
is
the
natural
way
to
start
building
systems
• Easy
to
develop
• Homogenous
• Small
number
of
concerns,
so
highly
cohesive
• ‘Simple’ UI Logic Data
System Over
Time • New
funcHonal
concepts
and
concerns
are
added
• Has
no
concept
of
the
‘funcHonal
separaHon’
of
concerns
• Only
decouples
technical
concerns
• But
technical
concerns
change
the
least
o^en!
• How
does
this
architecture
evolve
as
a
‘system’
grows
over
Hme? UI Logic Data
System Please
Don’t
Ever
Change • You
know
you
have
a
monolith
if
change
is
slow
and
terrifying
• It’s
slow
and
terrifying
because:
• Each
layer
has
very
low
cohesion
(covers
many
concerns)
• Each
layer
depends
on
the
layer
below
it
(albeit
abstracted)
very
significantly
• The
‘unit
of
change’
requires
too
big
of
a
‘unit
of
understanding’
(doesn’t
fit
in
your
head) UI Logic Data
Other
Concerns • Long
term
commitment
to
technology
stack
• Difficult
to
onboard
new
developers
• Slow
and
overloaded
development
environment
• Slow
applicaHon
startup
• Difficult
to
conHnuously
test
and
deploy
• Very
difficult
to
scale
applicaHon
horizontally
• Difficult
to
scale
development
• Difficult
to
idenHfy
boelenecks
and
issues
• Very
difficult
to
cleanly
integrate
with
other
systems
System The
First
Step • Admit
that
this
horizontal
layering
is
insufficient
past
a
certain
scale
(mulHple
funcHonal
concerns
in
a
fast-‐changing
environment)
• The
layers
must
create
boundaries
that
meet
the
principles
of
architecture
(modules
with
high
cohesion
and
low
coupling) UI Logic Data
VerHcal
(Domain)
Slices • This
is
MUCH
beeer
• A
change
is
much
more
likely
to
affect
a
single
slice
• This
can
be
VERY
difficult
to
do
correctly Customer Product Billing System
System Billing The
Trap Customer Product UI Data Yes!
Great
benefit
to
having
a
single,
cohesive
user
interface OK,
let’s
trust
everyone
to
respect
these
boundaries ReferenHal
integrity
and
transacHons
reintroduce
coupling
Once
reliance
on
a
shared
database
between
components
is
removed,
the
system
boundary
becomes
arbitrary
! i.e.,
you
can
choose
the
most
appropriate
system
boundary
Conway’s
Law OrganizaHons
which
design
systems
…
are
constrained
to
produce
designs
which
are
copies
of
the
communicaHon
structures
of
these
organizaHons
—
M
Conway Boundary Boundary Monolith Monolith
No
Man’s
Land Domain System Organisation Note: Organisational boundaries tend to be far more complex (domains align with business, systems align with IT, organisations cut across both)
My
Opinion hep://www.sixtree.com.au/arHcles/2014/microservices-‐characterised/ Services
with
uniform
interfaces Small
with
a
single
responsibility Containerless Organised
“verHcally”
along
business
capabiliHes Loose
coupling,
favouring
choreography
over
orchestraHon Decentralised
governance
where
only
the
interfaces
are
agreed Decentralised
data
management Infrastructure
is
automated Design
for
failure 100
to
1000
lines
to
code EssenHal Why? Why??!???!?
I
guess
it
is
easier
to
use
a
new
name
(Microservices)
rather
than
say
that
this
is
what
SOA
actually
meant
–
re
hep://t.co/ gvhxDfDWLG
—
Arnon
Rotem-‐Gal-‐Oz
(@arnonrgo)
March
16,
2014
yamen
chalasr
mitchan
dicoding
terukinakano
suzuki
hiro_y
ryamakuchi
a4lg
alexandresalome
koluku
10xinc
kishida
orderedlist
keavy
pauljervisheath
vanstee
holman
lara
garrettdimon
lauravandoore
destraynor
philhawksworth
samanthasiow