Presentazione tenuta al Rubyday 2015 a Torino. C'è un enorme interesse intorno alle architetture 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 adottarla con successo in un progetto. In questa presentazione condivido alcune delle esperienze fatte durante lo smantellamento di un'applicazione monolitica in microservices. Analizzo alcuni dei motivi che giustificano l'adozione di questo tipo di architettura, parlo delle questioni più importanti da considerare e rivelo alcuni approcci che hanno avuto successo nella nostra esperienza. Nota: Questa è una versione adattata della presentazione, senza effetti e animazioni.

1. HOW TO DISASSEMBLE
A MONOLITHIC APP IN
(NOT-SO)MICRO-SERVICES
Turin - 17 november 2015

2. MICHELE
FRANZIN
@REALFUZZY

4. PARTNERS

5. 8000
TRANSACTIONS/MONTH
in just an hour

6. 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 I’ll show you some code)

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

14. MONOLITHIC MICROSERVICE
architecture is the keyword
ARCHITECTURE ARCHITECTURE

15. THE
MONOLITH

16. THE (SOMETIMES EVIL) MONOLITH
http://www.infoq.com/articles/microservices-intro

17. ✓simple to develop
✓IDEs & development tools support
✓easy to test
✓simple to deploy
✓works well for relatively small apps

18. - growth overloads everything
- difficult to adopt new technologies
- often stuck with the starting choices
- doesn’t scale to long-lived-application

19. #MICROSERVICE
SEARCHTREND

20. WHAT’S A MICROSERVICE
• suite of small services
• running in its own process
• communicating with lightweight mechanisms
• built around business capabilities
• independently automated deployable
• minimum of centralized management
• technology agnostic

21. http://blog.arungupta.me/monolithic-microservices-refactoring-javaee-applications/

22. ✓each microservice is relatively small
✓easier for a developer to understand
✓easier to scale development
✓improve fault isolation
✓develop and deploy independently
✓no long-term commitment to a tech-stack
✓allow a fine-grained performance tuning or scaling

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

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

25. GOALS
‣ time
‣ budget
‣ shit (can) happens
‣ ship

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

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

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

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

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

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

37. ASYNC MESSAGING
XP
S2
S1

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

39. MESSAGE BUS
XP1
S2
S1
P2
S3

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

41. SPECIFICATION
IS A MUST HAVE
(no matter what)

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

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

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

45. SLIM FIT
circuit_breaker https://github.com/
wsargent/circuit_breaker
breaker_box https://github.com/
sittercity/breaker_box
CB2 https://github.com/pedro/cb2
S
M
L

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

47. –Giovanni Mela
“Inserisci qui una citazione”.
9XL

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

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

50. CONTINUOUS DEPLOYMENT
FOR RUBY GEMS

54. –Giovanni Mela
“Inserisci qui una citazione”.

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

59. THE INVERSE
CONWAY MANEUVER

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

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

62. POLYGLOT IS NICE
but mother tongue is fair enough

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

64. 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!

72. NO MONOLITHS WERE
HARMED INTHE MAKING
OFTHIS PRESENTATION

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

74. TAKEAWAYS
• go monolith first
• communication (all-around) is strategic assets
• start simple, don’t fear the change
• take decisions. I-really-mean-that.

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

76. Thank you.
@realfuzzy
Michele Franzin