C'è un enorme interesse intorno alle architetture a microservice ... quasi ogni conferenza IT ha una sessione che ne parla. Una chiara idea dei benefici / insidie che questo approccio porta con sé è cruciale per adottarlo con successo in un progetto. In questa presentazione condivido alcune delle esperienze fatte durante lo smantellamento di un'applicazione monolitica in microservices. Vengono analizzati alcuni dei motivi che giustificano l'adozione di questo tipo di architettura, analizzate alcune delle questioni più importanti da considerare e rivelo alcuni approcci che hanno avuto successo nella nostra esperienza. Presentazione tenuta al Codemotion 2016 a Roma. Nota: Questa è una versione adattata della presentazione, senza effetti e animazioni.

1. HOW TO DISASSEMBLE
A MONOLITHIC APPS IN
(NOT-SO) MICRO-SERVICES
ROME 18 - 19 MARCH 2016

2. MICHELE
FRANZIN
@REALFUZZY

3. INTEREST IN
#MICROSERVICES

5. PARTNERS

6. 12.000
TRANSACTIONS/MONTH
in just an hour

7. DISCLAIMER
my personal opinion
people have different experiences
ideas, comment, etc contact me @realfuzzy
subject is wide, so I’d love to hear your thoughts :-)
It’s not a code talk (but you can see some sources)

8. AGENDA:THERE’S NO
AGENDA
I’ve got a tale instead

12. BUAHAHAHAHA!
I AM THE
MONOLITH!
COME TO THE
WORLD TO BRING
IMMOBILISM AND
COMPLEXITY!

13. THE
MONOLITH

14. easy to develop

15. IDEs & development
tools support

16. easy to test

17. simple to deploy

18. works well for
relatively small apps

19. AFTER A WHILE…
http://www.qcodemag.it/wp-content/uploads/2014/09/favela.jpg

20. growth overloads
everything

21. difficult to adopt new
technologies

22. often stuck with the
starting choices

23. doesn’t scale to
long-lived application

24. MONOLITH
ARCHITECTURE ARCHITECTURE
MICROSERVICEIC

25. ARCHITECTURE
is the keyword

26. WHY MICROSERVICES
• suite of small services
• running in its own process
• communicating with lightweight mechanisms
• built around business capabilities
• independently automated deployable
• technology agnostic

28. EXPECTATIONS
http://www.wallpaperawesome.com/wallpapers-awesome/

29. relatively small

30. easier to understand

31. easier to scale
development

32. improve fault isolation

33. develop & deploy
independently

34. no vendor lock

35. improves
tuning & scaling

36. - additional complexity of a distributed system
- tools/IDEs are monolithic applications oriented
- testing is more difficult
- must implement the inter-service communication
- increase memory consumption

37. AGENDA*
✓ what’s a microservice?
✓ why have I to jump in ?
• where I can start from ?
• how I should be aware of ?
* I know, I know, I lied about the agenda

38. – Martin Fowler, Chief Scientist -ThoughtWorks
“…don’t even consider microservices
unless you have a system that's too
complex to manage as a monolith”

39. YAGNI
do monolith first
monolith
microservice
complexity
productivity
http://martinfowler.com/bliki/MicroservicePremium.html

40. – Sam Newman, author of Building Microservices
“I remain convinced that it is much easier
to partition an existing […] system than
to do so up front…
You have more to work with.”

41. HOPE vs REALITY
http://martinfowler.com/articles/dont-start-monolith.html

43. THE NEW
BEGINNING
https://upload.wikimedia.org/wikipedia/commons/6/67/Change_In_Hand.jpg

44. Q0: HOW TO DECOMPOSE A
MONOLITH?
1. Identify business boundaries
2. start decomposing each into own microservice
3. follow the Single Responsibility Principle
4. goto :2

46. Sir. Tools
A warrior that can
use every kind of
tool as a weapon
Strateky Sensei
Master renowned
for its strategic and
tactical ability
Workodoo Master
The work-force is
strong with this one

49. HAHAHAHA!
YOUR EFFORTS
ARE NOT
ENOUGH TO
DEFEAT ME!

50. Your efforts have little effect!
an orthogonal approach might
help you ...

51. …MANY
SERVICES THAT
COMMUNICATE ?
http://www.raptorsrepublic.com/

52. MESSAGING
XP
S2
S1

53. MESSAGE BUS
XP1
S2
S1
P2
S3

54. CHOOSE WISELY
• Reliability
• Routing algorithms
• Highly Availability
• Supported protocols

55. OUR CHOICE ☛ RABBITMQ
• AMPQ message broker
• Erlang
• Fast, reliable, secure
• Many clients
• Commercial support

56. HERE!

57. SPECIFICATION IS A MUST
(no matter what)

58. JSON-LD
JSON-API HAL
DIY

59. DESIGN FOR FAILURE
aka: communicate when communication is hard

60. CIRCUIT BREAKER
https://www.flickr.com/photos/leafbug/409950515/

61. http://martinfowler.com/bliki/CircuitBreaker.html

62. STOPLIGHT
https://github.com/orgsync/stoplight

63. HOW IT LOOKS LIKE

64. 9XL

68. – Melvin Conway, 1968
“organizations which design systems …
are constrained to produce designs
which are copies of the communication
structures of these organizations”

69. THE INVERSE
CONWAY MANEUVER

70. – Martin Fowler, Chief Scientist -ThoughtWorks
“For many people throwing away a code
base is a sign of failure, perhaps
understandable …, but still failure.”

71. SACRIFICIAL
ARCHITECTURE
http://www.cardhub.com/edu/credit-cards-expiration-date

72. POLYGLOT IS NICE
but mother tongue is fair enough

73. DEVOPS!
no devops?!? no party.
https://www.flickr.com/photos/91657289@N02/10218392744

74. CONTINUOUS DEPLOYMENT
FOR RUBY GEMS

75. The Smith
Master craftsman
expert in forging
anything
The Sculptor
An artist able to
give shape to
magnificent works
The Painter
Colors and shapes
come to life on her
canvas!

82. NO MONOLITHS WERE
HARMED INTHE MAKING
OFTHIS PRESENTATION

83. andreabrigu@gmail.com
@BriguGraphic
Illustrated by:

84. TAKEAWAYS
go monolith first
communication (all-around) is strategic assets
start simple, then don’t fear the change
take decisions, I-REALLY-MEAN-THAT

85. …WHAT’S NEXT ?
• testing
• CQRS + ES
• log analisys & monitoring
• metrics
• …

86. Thank you.
@realfuzzy
Michele Franzin