How to disassemble a monolith into microservices (#daje version)

There's a huge interest around microservices and microservice architecture... almost every IT conference has a session about it.
A clear idea of the benefits/pitfalls that this approach brings is crucial for a successful adoption in a project.

In this presentation I share some of the experiences made during the dismantling a monolithic application into microservices.
I analyze some of the reasons justifying the adoption of this type of architecture, talk about the most important issues to consider and reveal some approaches that have been successful in our experience.

Topics (among others): microservices, monolith, communication, async messaging, rabbitmq, circuit breaker, conway law, devops, sacrificial architecture.

Talk presented at Codemotion 2016 in Rome.

Note: This is a adapted version of the presentation, without effects and animations.

Transcript

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 MICROSERVICE IC
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 X P S2 S1
53. MESSAGE BUS X P1 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 IN THE MAKING OF THIS 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