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

Talk about how to improve the architecture and reduce the technical debt of your applications. By gradually separating away responsibilities from your monolithic apps into single responsibility services.

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
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?
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!
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
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
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
17. How to avoid? • Work Small Make incremental progress
19. How to avoid? • Work Clean Seek for refactoring opportunities
21. How to avoid? • Work Green Have a Test Suite - Use Continuous Integration Tools
23. 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
25. 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
27. 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
29. 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
31. 31 MICROSERVICES
32. Architectural Styles • Monoliths Single Application - Multiple Responsibilities • Microservices Multiple Applications - Single Responsibilities
33. “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
34. 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
35. KISS / UNIX Modern development adopted a similar style Where does it come from? https://en.wikipedia.org/wiki/KISS_principle
37. Why is it useful? • Service Independence Independent from one another - they have “contracts”
38. Why is it useful? • Deployability Have a bug in a component - fix and deploy
39. Why is it useful? • Team Independence Each can be owned by a different team
40. What are the downsides? • Piping You have to take into account the inter-connections • Deployability Orchestration and Versioning • Infrastructure Much more complex setup
41. 41 STATE OF THE CLOUD
42. “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/
45. “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
46. What does it provide us? - Infrastructure • Cheap Even with pay-on-demand pricing models
47. What does it provide us? - Infrastructure • Replaceable Changed the service? Drop the server and create a new one
48. What does it provide us? - Infrastructure • Scalable When demand raises, automatically spin up new copies to cope with demand
49. What does it provide us? - Software • CDNs Global content caching - Blazing fast websites
51. What does it provide us? - Software • Content and Databases Storage servers with multiple architectures
53. What does it provide us? - Software • And EVERYTHING Else Even sending “Thank You” notes as a Service
55. Current Options - Infrastructure • Amazon Web Services • Microsoft Azure • Rackspace • Google Cloud Engine
56. Current Options - CDNs • CloudFront • Akamai • MaxCDN • Fastly
57. Current Options - Services • Contentful Content Management as a Service
59. Current Options - Services • Snipcart Shopping Cart as a Service
61. Current Options - Services • Auth0 Authentication as a Service
63. 63 GOING SERVERLESS
64. “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
65. TRADITIONAL APPLICATION Unintelligent Client Server does most of the hard work Source: https://www.martinfowler.com
66. SERVERLESS APPLICATION Rich client - Many Frontends Independent services and infrastructure Source: https://www.martinfowler.com
67. “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
68. 68 GOODBYE MONOLITH
69. “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
70. Now that we’ve introduced the concepts Let’s dive into how to apply them in practice
71. Starting from your Rails App • Identify Models usually travel in families - identify these families
73. Starting from your Rails App • Categorize Understand the functionality and responsibility of each component family
75. Starting from your Rails App • Split Create separate API apps exposing them
77. Starting from your Rails App • Communicate Integrate different parts of the application through it’s HTTP Interfaces
79. Moving away from Rails • Move Static and Read-first content to a CMS Marketing, Blogs, Product and non-user generated content moved
81. 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
83. Moving away from Rails • Profit from 3rd party Services Use cloud based authentication, messaging, mailing, payments to remove burden from your code
85. Moving away from Rails • Leverage Static Sites and Static Assets Using Static Site Generated websites + CDNs to deliver fast and increase conversion
86. “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/
87. Keep Security in Check • Validate Validate on your Client side code - specially on payment transactions
89. Keep Security in Check • Validate Validate on your Middleware - specially on payment transactions
91. Keep Security in Check • Validate Make sure not to expose your internals
93. Keep Security in Check • Validate Make sure you have retry and fallback mechanisms
95. Rounding up • Prototype and test ideas • Create single responsibility applications • Test your code • Keep it safe
96. Demo Time
98. We’re Hiring! Twitter: @dlitvakb Email: david.litvak@contentful.com Thanks!