Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices, a bittersweet symphony

Microservices, a bittersweet symphony

A story of how we got from initial architectural patterns to the microservice architecture.

How we did it wrong and how to not repeat those mistakes again.

Presented at: RubyConf Brazil 2015

92d08794b535e41a4082c57ea547546e?s=128

Sebastian Sogamoso

September 19, 2015
Tweet

Transcript

  1. MICROSERVICES A BITTER SWEET SYMPHONY

  2. @sebasoga

  3. None
  4. HOW AN ARCHITECTURE TREND CREATED A DISASTER

  5. HOW DID THIS HAPPEN?

  6. THE STORY STARTS 30 years ago

  7. BUILT APPLICATIONS THAT RUN ON A MAINFRAME IN THE BEGINNING

  8. THREE TIER ARCHITECTURE YOUNG ARCHITECTURE

  9. Three tier architecture YOUNG ARCHITECTURE

  10. WE BUILT DISTRIBUTED SYSTEMS AND WEREN’T AWARE ABOUT IT YOUNG

    ARCHITECTURE
  11. THE MOORE LAW STILL STAND AT THE TIME HARDWARE IMPROVEMENT

  12. THE SCALING PROCESS WAS STILL EXTREMELY SLOW AND EXPENSIVE HARDWARE

    IMPROVEMENT
  13. EVERYONE WAS GOING ONLINE THE INTERNET

  14. DISTRIBUTED DATA STORAGE AND PROCESSING THE INTERNET

  15. COMMODITY HARDWARE WAS A REALITY THE INTERNET

  16. MONOLITHIC APPLICATIONS BECAME POPULAR THE MONORAIL

  17. None
  18. None
  19. BREAKING DOWN THEIR BIG APPLICATIONS INTO SERVICES MOVING TO SERVICES

  20. None
  21. MICROSERVICES AND THE START OF THE END MOVING TO MICROSERVICES

  22. None
  23. Microservices…

  24. None
  25. MICROSERVICES SOA

  26. Services independently deployed

  27. None
  28. Infrastructure automation

  29. None
  30. Evolutionary design

  31. None
  32. THIS IS WHERE A LOT OF APPLICATIONS TURN INTO HELL

    THE DISASTER
  33. None
  34. None
  35. THE DISASTER MICROSERVICES ARE ABOUT GOOD OBJECT ORIENTED DESIGN AT

    AN APPLICATION LEVEL
  36. TRUE

  37. YOU WILL BENEFIT FROM A MICROSERVICE ARCHITECTURE IF YOU HAVE

    CLEAR BOUNDARIES WITHIN YOUR APPLICATION
  38. FALSE

  39. None
  40. None
  41. None
  42. None
  43. None
  44. None
  45. TL;DR

  46. WE TEND TO GET EXCITED ABOUT IMPLEMENTING NEW IDEAS

  47. WE DON’T REALISE THAT DOING IT THE “OLD WAY” MIGHT

    BE GOOD ENOUGH
  48. WHY ARE WE TALKING ABOUT MICROSERVICES IF THEY ARE SO

    TERRIBLE?
  49. THEY’RE NOT

  50. THE RIGHT CASE WHEN YOU NEED TO SCALE A SPECIFIC

    PART OF YOUR APPLICATION
  51. THE RIGHT CASE When your team is ready

  52. THE RIGHT CASE WHEN YOU NEED TO DEPLOY A PART

    OF YOUR APP MORE OFTEN
  53. THE RIGHT CASE WHEN YOU NEED TECHNOLOGY HETEROGENEITY

  54. THE RIGHT CASE MICROSERVICES =

  55. LESSON LEARNED?

  56. WE SOLVE PROBLEMS AND ADD VALUE TO THE COMPANIES/CLIENTS WE

    WORK FOR
  57. MICROSERVICES ARE USEFUL ONLY WHEN THEY ALLOW US TO ADD

    VALUE FASTER
  58. WRITE SERVICES SPECIFICATION AS EXECUTABLE CONTRACTS THAT CAN BE USED

    FOR TESTING INTEGRATIONS RECOMMENDATIONS
  59. GO WITH ASYNCHRONOUS OVER SYNCHRONOUS CALLS AS THEN MAKE IT

    EASIER TO DEAL WITH FAILURES RECOMMENDATIONS
  60. USE SCHEMA BASED DATA FORMATS OVER SCHEMA-LESS ONES RECOMMENDATIONS

  61. Code Climate’s blog

  62. rails new my_great_microservice —api

  63. None
  64. @sebasoga OBRIGADO