Trasformare un'applicazione monolitica in microservices (versione #daje)
1 like9,625 views
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.
![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.](https://image.slidesharecdn.com/monolithdisassemble-codemotion-160322092925/85/Trasformare-un-applicazione-monolitica-in-microservices-versione-daje-40-320.jpg)
Trasformare un'applicazione monolitica in microservices (versione #daje)
- 1. HOW TO DISASSEMBLE A MONOLITHIC APPS IN (NOT-SO) MICRO-SERVICES ROME 18 - 19 MARCH 2016
- 5. PARTNERS
- 7. DISCLAIMER my personal opinion people have different experiences ideas, comment, etc contact me @realfuzzy subject is wide, so Id love to hear your thoughts :-) Its not a code talk (but you can see some sources)
- 8. AGENDA:THERES NO AGENDA Ive 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
- 21. dif鍖cult to adopt new technologies
- 22. often stuck with the starting choices
- 23. doesnt scale to long-lived application
- 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
- 29. relatively small
- 34. no vendor lock
- 36. - additional complexity of a distributed system - tools/IDEs are monolithic applications oriented - testing is more dif鍖cult - must implement the inter-service communication - increase memory consumption
- 37. AGENDA* whats 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 dont even consider microservices unless you have a system that's too complex to manage as a monolith
- 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.
- 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 ...
- 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)
- 59. DESIGN FOR FAILURE aka: communicate when communication is hard
- 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
- 70. Martin Fowler, Chief Scientist -ThoughtWorks For many people throwing away a code base is a sign of failure, perhaps understandable , but still failure.
- 72. POLYGLOT IS NICE but mother tongue is fair enough
- 73. DEVOPS! no devops?!? no party. https://www.鍖ickr.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 magni鍖cent works The Painter Colors and shapes come to life on her canvas!
- 82. NO MONOLITHS WERE HARMED INTHE MAKING OFTHIS PRESENTATION
- 84. TAKEAWAYS go monolith 鍖rst communication (all-around) is strategic assets start simple, then dont fear the change take decisions, I-REALLY-MEAN-THAT
- 85. WHATS NEXT ? testing CQRS + ES log analisys & monitoring metrics