How to disassemble a monolithic app in microservices

Talk presented at Rubyday 2015 in Turin.

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, ruby, deploy, devops, sacrificial architecture.

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

Transcript

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 SEARCH TREND
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 X P S2 S1
38. CHOOSE WISELY • Reliability • Routing algorithms • Highly Availability • Supported protocols
39. MESSAGE BUS X P1 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 IN THE MAKING OF THIS 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