What went wrong for my clients in the past 6 years trying to implement Microservice Architectures? This is a retrospective, a list of things we must to avoid to gainable with this kind of software architecture.

1. Gabriele Lana
gabriele.lana@GMAIL.COM !
gabrielelana "
gabrielelana #

2. Microservice
architectures

3. what can I
tell you in
less than
an hour?
⥁

4. Something that
you will not
find directly
on books

5. something based
on knowledge
but learned
on the field

6. (mandatory definition)
"Microservices are
small, autonomous
services that work
togheter"

7. (mandatory question)
"how small are
the
microservices?"

8. (mandatory pros/cons)
•diversity ++
(languages, frameworks, architectures)
•resilience +++
(partial failure is allowed)
•scaling ++
(different services scales differently)
•INDependence +
(deploy independently with lower risk)
•organizational
alignment +
(Conway's law)
•composability ++
(one service many clients, UNIX way)
•replaceability ++
(easier to experiment with)
•complexity ----
(distributed systems are no joke)
•testing --
(will they work together?)
•infrastructure -
(need strong automation culture: devops)
•consistency -
(forget transactional consistency)
•speed -(-*)
(network communication can be slow)

9. We will look at
3of the worst
problems
⥁

10. for every problem
We will look at
• How it feels like
• what GOT wrong
• How to prevent it
• How to fix it

11. wrong responsibility1
symptoms:
• changes becomes harder and harder
• A single change touches many places
• Most of the changes touch *THAT* PLACE

12. wrong responsibility1
symptoms:
• changes becomes harder and harder
• A single change touches many places
• Most of the changes touch *THAT* PLACE

13. wrong responsibility1
symptoms:
• changes becomes harder and harder
• A single change touches many places
• Most of the changes touch *THAT* PLACE

14. wrong responsibility1

15. wrong responsibility1
symptoms:
• changes becomes harder and harder
• A single change touches many places
• Most of the changes touch *THAT* PLACE

16. wrong responsibility1
symptoms:
• changes becomes harder and harder
• A single change touches many places
• Most of the changes touch *THAT* PLACE

17. wrong responsibility1
CAUSES:
• wrong design and distribution of responsibilities
• low cohesion
• high coupling

18. wrong responsibility1
CAUSES:
• wrong design and distribution of responsibilities
• low cohesion
• high coupling
SERVICE A SERVICE B

19. wrong responsibility1
CAUSES:
• wrong design and distribution of responsibilities
• low cohesion
• high coupling
CLASS A CLASS B

20. wrong responsibility1
PREVENTion:
• DDD
• Event storming
• software design

21. wrong responsibility1
TREATMENT:
• architectural refactoring

22. wrong responsibility1
TREATMENT:
• architectural refactoring

23. wrong responsibility1
TREATMENT:
• architectural refactoring

24. wrong responsibility1
TREATMENT:
• architectural refactoring

25. wrong responsibility1
TREATMENT:
• architectural refactoring

26. wrong responsibility1
TREATMENT:
• architectural refactoring

27. wrong responsibility1
TREATMENT:
• architectural refactoring

28. wrong responsibility1
TREATMENT:
• architectural refactoring

29. wrong responsibility1
TREATMENT:
• architectural refactoring

30. wrong responsibility1
TREATMENT:
• architectural refactoring

31. shared database2
symptoms:
• changes becomes harder and harder
• uncontrollable complexity
• Shared code between services

32. shared database2
CAUSES:
• database used for software customization
(combinatorial number of feature)
• Database normalization
• database owns business logic
• false need of strong consistency

33. shared database2
prevention:
• one (more?) database(s?) per microservice
• denormalize your data model
("Do not try and bend the spoon, that's impossible.
Instead, only try to realize the truth... there is no
spoon")

34. shared database2
TREATMENT:
• partition database

35. shared database2
TREATMENT:
• partition database
expose
network
endpoints
one step at a time
(do not remove
until safe)
NEtwork

36. shared database2
TREATMENT:
• partition database
they can be
two logical
database on a
physical one
they can even
be the same
locical
database but
every service
has its own
tables

37. shared database2
TREATMENT:
• events + projections (create read models)
EVENTS
READ
MODELS

38. shared database2
TREATMENT:
• events + projections (create read models)
read models can be used to "replicate" data
owned by a service "A" so that they can be
*READ* from a service "B"
EVENTSREAD
MODELS

39. distributed monolith3
symptoms:
• cannot deploy independetly
• one failure brings everything down

40. distributed monolith3
CAUSES:
• synchronous communication
• lack of service independence
• still false need of strong consistency ;-)

41. distributed monolith3
PREVENTion:
• postel's law
• Asynchronous communication
• circuit breakers, bulkheads, ...
"Be conservative in
what you send, be
liberal in what you
accepT"

42. distributed monolith3
treatment:
• architectural refactoring
• protocol refactoring
• ui refactoring

43. distributed monolith3
treatment:
• architectural refactoring
• protocol refactoring
• ui refactoring
you
can
do
it!

44. questions?