This document discusses microservices and the motivations for adopting a microservices architecture. It begins by describing some of the issues that arise with traditional monolithic architectures over time, as new features and concerns are added. These include low cohesion between layers, high coupling between components, and changes requiring understanding too many parts of the system. The document then introduces the concept of microservices as an architecture where services are defined around business capabilities and organized vertically rather than horizontally. It discusses some of the challenges of developing and managing microservices at both the domain and infrastructure levels. Overall, the document provides an introduction to microservices and why decomposing monolithic applications into independently deployable microservices can help address many of the issues that arise for systems

1. Microservices
101
The
Big
Why?

2. Yamen
Sader
Sixtree
Co-­‐Founder
Principal
Consultant
Hacker
!
@yaamehn
#microservices

3. We
Are
Here

4. System
Why
Are
We
Here?
• TradiHonal
3-­‐Her
‘architecture’
to
build
‘systems’
• But
what
is
an
architecture?
• And
what
is
a
system?
UI
Logic
Data

5. 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

6. 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

7. Woah
Independent
Limited
Independent
High Cohesion
Low Coupling
High Cohesion

8. Horizontal
layering
(alone)
is
evil

9. 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

10. 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

11. UI
Logic
Data
MUD
UI
Logic
Data

12. CONGRATULATIONS!
You
have
a
Monolith

13. 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

14. 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

15. 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

16. 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

17. System
Billing
The
Trap
Customer
ProductUI
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

18. System
Billing
The
Prerequisite
Customer
ProductUI
Can
you
design
your
system
without
sharing
the
database?
(This
is
the
hardest
part)

19. And
now,
for
my
next
trick…

20. Billing
Customer
Product
UI

21. 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

22. UI
DistribuHon
&
Scale
Becomes
Possible
But not necessarily desirable…
Customer
Product
Billing

23. 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

24. 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)

25. Microservices
Defined
The
confluence
of
boundaries
between
the
Domain
Architecture,
the
System
and
OrganisaHonal
Structure
This is the only new thing

26. Microservices
Land
Domain System Organisation
This is the basis of alignment between Microservices
and DevOps maturity

27. Drawing
the
rest
of
the
owl

28. Let’s
Take
a
Ride

29. First
Law
of
DistribuHon
Don’t

30. Domain
Architecture
Customer Product Billing
Draw
the
boxes
Low
rate
of
change

31. Micro
Architecture
AngularJS
MongoDB
JEE
Oracle
NodeJS
Ninjas
Build
the
boxes
High
rate
of
change

32. Macro
Architecture
Monitoring
Data
ReplicaHon
Protocols
Messaging
UI
IntegraHon
?
Service
Discovery
Deployment
ReporHng
Distributed
Tracing
&
ExcepHon
Handling

33. The
Hard
Bits
• UI
IntegraHon
&
SSO
• Data
IntegraHon
&
DuplicaHon
• Monitoring
• Deployment
&
Management
• Service
RegistraHon
&
Discovery
• Developer
Tooling
• Distributed
ParHHoning
• (No)
TransacHons
• ReporHng
• Data
MigraHon
• Protocols
&
Standards
• Distributed
Tracing
&
Error
Handling
• Resiliency
And
many
more!

34. The
(micro)
elephant
in
the
room

36. 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??!???!?

37. This is not a microservice

38. 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

39. Further
Reading
• Master
Reading
List:
hep://www.maesHne.com/microservices
• The
Big
MoHvaHon:
hep://www.infoq.com/presentaHons/Breaking-­‐the-­‐Monolith
• Asking
Why:
hep://genehughson.wordpress.com/2012/07/15/most_important_quesHon/
• On
Architecture:
hep://genehughson.wordpress.com/2012/04/04/architecture-­‐versus-­‐design/
• Great
Series:
hep://www.Hgerteam.dk/category/soa/microservices/
• Life
Beyond
Distributed
TransacHons:
hep://www.ics.uci.edu/~cs223/papers/cidr07p15.pdf
• Distributed
Big
Balls
of
Mud:
hep://www.codingthearchitecture.com/2014/07/06/
distributed_big_balls_of_mud.html
• Reality:
heps://rclayton.silvrback.com/failing-­‐at-­‐microservices
• Our
Thoughts:
hep://www.sixtree.com.au/arHcles/tag/microservices.html