(2017) From Monoliths to Services: Gradually Paying your Technical Debt

(2017) From Monoliths to Services: Gradually Paying your Technical Debt

58f5652bb5e072d755d62ae229965472?s=128

David Litvak Bruno

June 07, 2017
Tweet

Transcript

  1. From Monoliths to Services Gradually paying your Technical Debt BY

    DAVID LITVAK (@dlitvakb)
  2. 2 TECHNICAL DEBT

  3. “You want to make a “quick change” to your software

    […], and it isn’t quick. Whatever made that happen, that’s tech debt.” Dave Diehl http://jimplush.com/talk/2015/02/ Senior Developer at Fusion Alliance
  4. None
  5. Metaphor explaining difficulties of shipping software

  6. Like financial debt, technical debt comes with interests. Failing to

    pay your debt, interests will come back at you. Why is it called Debt?
  7. None
  8. THE SOFTWARE COST TRIAD Move one corner and the others

    will adjust accordingly If you want to increase Quality, you will have to spend more Money and Time Money Time Quality SOFTWARE COST Technical Debt comes when Quality is not taken into account, prioritising spending less or working faster
  9. Debt itself is not a bad thing! Invest and pay

    back early! Don’t leave debt hanging! But Hey! It’s not always bad!
  10. None
  11. What are the causes? • Cutting Corners “I know it

    looks complicated, but I don’t have time to refactor it.” https://www.codementor.io/ruby-on-rails/tutorial/staying-on-top-of-your-technical-debt
  12. None
  13. What are the causes? • Lack of Testing “We can

    write tests for it later.” https://www.codementor.io/ruby-on-rails/tutorial/staying-on-top-of-your-technical-debt
  14. None
  15. What are the causes? • Assuming “False Positives” are Positives

    “The build fails sometimes, but it passes most of the time. Let’s just move on.” https://www.codementor.io/ruby-on-rails/tutorial/staying-on-top-of-your-technical-debt
  16. None
  17. How to avoid? • Work Small Make incremental progress

  18. None
  19. How to avoid? • Work Clean Seek for refactoring opportunities

  20. None
  21. How to avoid? • Work Green Have a Test Suite

    - Use Continuous Integration Tools
  22. None
  23. Some useful techniques • Pair-Programming • Test-first development (TDD &

    BDD) • Continuous Integration & Continuous Delivery
  24. Categorizing Technical Debt

  25. Grades of Debt - James Higgs • Grade One: Accumulation

    due to extrinsic changes Keep up to date with your dependencies and technologies https://madebymany.com/blog/the-four-grades-of-technical-debt
  26. None
  27. Grades of Debt - James Higgs • Grade Two: Developer

    Comfort Code for readability - your future self and co-workers will much appreciate it https://madebymany.com/blog/the-four-grades-of-technical-debt
  28. None
  29. Grades of Debt - James Higgs • Grade Three: Cost

    of Pragmatism Use debt wisely and prototype - throw away if not successful https://madebymany.com/blog/the-four-grades-of-technical-debt
  30. None
  31. Grades of Debt - James Higgs • Grade Four: The

    One with the Bite - Impossibility to Move Forward Point of no return! If you’re here, it may be wise to think about restarting! https://madebymany.com/blog/the-four-grades-of-technical-debt
  32. None
  33. 33 MICROSERVICES

  34. Architectural Styles • Monoliths Single Application - Multiple Responsibilities •

    Microservices Multiple Applications - Single Responsibilities
  35. “The microservice architectural style is an approach to developing a

    single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.” Martin Fowler Chief Scientist at ThoughtWorks http://martinfowler.com/articles/microservices.html
  36. It's an architectural style that enables us to separate each

    of our product’s responsibilities into very small and separate applications This gives us flexibility
  37. KISS / UNIX Modern development adopted a similar style Where

    does it come from? https://en.wikipedia.org/wiki/KISS_principle
  38. None
  39. Why is it useful? • Service Independence Independent from one

    another - they have “contracts”
  40. Why is it useful? • Deployability Have a bug in

    a component - fix and deploy
  41. Why is it useful? • Team Independence Each can be

    owned by a different team
  42. What are the downsides? • Piping You have to take

    into account the inter-connections • Deployability Orchestration and Versioning • Infrastructure Much more complex setup
  43. There are no silver bullets

  44. Where does this approach not fit? • On small or

    single-concern applications • When teams have a hard time collaborating • With unexperienced DevOps teams
  45. 45 STATE OF THE CLOUD

  46. “If someone asks me what cloud computing is, I try

    not to get bogged down with definitions. I tell them that, simply put, cloud computing is a better way to run your business.” Marc Benioff CEO of salesforce.com http://www.mercurynews.com/2009/10/23/2009-qa-marc-benioff-ceo-of-salesforce-com/
  47. 2017

  48. None
  49. “Cloud computing is really a no-brainer for any start-up because

    it allows you to test your business plan very quickly for little money. Every start-up, or even a division within a company that has an idea for something new, should be figuring out how to use cloud computing in its plan.” Brad Jefferson CEO & Co-Founder of Animoto http://www.cio.com/article/2428093/infrastructure/cloud-computing--pros-and-cons.html
  50. What does it provide us? - Infrastructure • Cheap Even

    with pay-on-demand pricing models
  51. What does it provide us? - Infrastructure • Replaceable Changed

    the service? Drop the server and create a new one
  52. What does it provide us? - Infrastructure • Scalable When

    demand raises, automatically spin up new copies to cope with demand
  53. What does it provide us? - Software • CDNs Global

    content caching - Blazing fast websites
  54. None
  55. What does it provide us? - Software • Content and

    Databases Storage servers with multiple architectures
  56. None
  57. What does it provide us? - Software • And EVERYTHING

    Else Even sending “Thank You” notes as a Service
  58. None
  59. Current Options - Infrastructure • Amazon Web Services • Microsoft

    Azure • Rackspace • Google Cloud Engine
  60. Current Options - CDNs • CloudFront • Akamai • MaxCDN

    • Fastly
  61. Current Options - Services • Contentful Content Management as a

    Service
  62. None
  63. Current Options - Services • Snipcart Shopping Cart as a

    Service
  64. None
  65. Current Options - Services • Auth0 Authentication as a Service

  66. None
  67. 67 GOING SERVERLESS

  68. “Serverless architectures refer to applications that significantly depend on third-party

    services (knows as Backend as a Service or "BaaS") or on custom code that's run in ephemeral containers (Function as a Service or “FaaS”). […] By using these ideas, and by moving much behaviour to the front end, such architectures remove the need for the traditional 'always on' server system sitting behind an application” Mike Roberts CEO & Co-Founder of Fried Gold Software http://www.martinfowler.com/articles/serverless.html
  69. TRADITIONAL APPLICATION Unintelligent Client Server does most of the hard

    work Source: https://www.martinfowler.com
  70. SERVERLESS APPLICATION Rich client - Many Frontends Independent services and

    infrastructure Source: https://www.martinfowler.com
  71. “If your PaaS can efficiently start instances in 20ms that

    run for half a second, then call it serverless.” Adrian Cockcroft Technology Fellow at Battery Ventures https://twitter.com/adrianco/status/736553530689998848
  72. 72 GOODBYE MONOLITH

  73. “Microservices architecture potentially offers an easier way to pay down

    technical debt. Refactoring a big monolithic application can be the equivalent of a balloon payment. […] you can pay your technical debt incrementally by refactoring services one by one.” Eric Knorr Editor in Chief at CNET http://www.infoworld.com/article/2878659/application-development/reducing-technical-debt-with-microservices.html
  74. Now that we’ve introduced the concepts Let’s dive into how

    to apply them in practice
  75. Starting from your Rails App • Identify Models usually travel

    in families - identify these families
  76. None
  77. Starting from your Rails App • Categorize Understand the functionality

    and responsibility of each component family
  78. None
  79. Starting from your Rails App • Split Create separate API

    apps exposing them
  80. None
  81. Starting from your Rails App • Communicate Integrate different parts

    of the application through HTTP or Message Queues
  82. None
  83. Moving away from Rails • Move Static and Read-first content

    to a CMS Marketing, Blogs, Product and non-user generated content moved
  84. None
  85. Moving away from Rails • Decouple your Front-End from your

    business logic Your HTML or Native app shouldn’t be tied to your server code
  86. None
  87. Moving away from Rails • Profit from 3rd party Services

    Use cloud based authentication, messaging, mailing, payments to remove burden from your code
  88. None
  89. Moving away from Rails • Leverage Static Sites and Static

    Assets Using Static Site Generated websites + CDNs to deliver fast and increase conversion
  90. “It’s much easier mentally to tackle $10,000 of debt across

    4 credit cards at $2500 each than 1 card at the full $10,000.” Jim Plush Sr Director of Engineering at CrowdStrike http://jimplush.com/talk/2015/02/28/microservices-allow-for-localized-tech-debt/
  91. Keep Security in Check • Validate Validate on your Client

    side code - specially on payment transactions
  92. None
  93. Keep Security in Check • Validate Validate on your Middleware

    - specially on payment transactions
  94. None
  95. Keep Security in Check • Validate Make sure not to

    expose your internals
  96. None
  97. Keep Security in Check • Validate Make sure you have

    retry and fallback mechanisms
  98. None
  99. Rounding up • Prototype and test ideas • Create single

    responsibility applications • Test your code • Keep it safe
  100. Demo Time

  101. None
  102. We’re Hiring! Twitter: @dlitvakb Email: david.litvak@contentful.com Thanks!