Download to read offline
![“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](https://image.slidesharecdn.com/bw1-litvak-170714162750/75/From-Monoliths-to-Services-Paying-Your-Technical-Debt-5-2048.jpg)
![“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](https://image.slidesharecdn.com/bw1-litvak-170714162750/75/From-Monoliths-to-Services-Paying-Your-Technical-Debt-66-2048.jpg)
![“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](https://image.slidesharecdn.com/bw1-litvak-170714162750/75/From-Monoliths-to-Services-Paying-Your-Technical-Debt-71-2048.jpg)
More Related Content
Similar to From Monoliths to Services: Paying Your Technical Debt
From Monoliths to Services: Paying Your Technical Debt
- 1. BW1 Projects & Teams 6/7/201711:30:00 AM BW1 From Monoliths to Services: Paying Your Technical Debt Presented by: David Litvak Brought to you by: 350 Corporate Way, Suite 400, Orange Park, FL 32073 888-‐268-‐8770 ·∙ 904-‐278-‐0524 - info@techwell.com - https://www.techwell.com/
- 2. David Litvak David Litvakis a Ruby and Python evangelist, agile devotee, frustrated sports legend, and developer evangelist at Contentful. He spends most of his days coding and slaying orcs and beasts in his favorite role playing games. For the past eight years, David has worked as a professional developer using Python, Ruby, PHP, Java, and .Net in very different areas such as GIS, social media analytics, and software as a service companies, as both a consultant and full-time employee. At National Technological University in Buenos Aires for seven years, David has been teaching Team Conduction Methodologies and Advanced Programming Techniques.
- 3. From Monoliths toServices Gradually paying your Technical Debt BY DAVID LITVAK (@dlitvakb)
- 4.
- 5. “You want tomake 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
- 7. Metaphor explaining difficultiesof shipping software
- 8. Like financial debt,technical debt comes with interests. Failing to pay your debt, interests will come back at you. Why is it called Debt?
- 10. THE SOFTWARE COSTTRIAD 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
- 11. Debt itself isnot a bad thing! Invest and pay back early! Don’t leave debt hanging! But Hey! It’s not always bad!
- 13. What are thecauses? • 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
- 15. What are thecauses? • 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
- 17. What are thecauses? • 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
- 19. How to avoid? •Work Small Make incremental progress
- 21. How to avoid? •Work Clean Seek for refactoring opportunities
- 23. How to avoid? •Work Green Have a Test Suite - Use Continuous Integration Tools
- 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
- 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
- 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
- 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
- 33.
- 34. Architectural Styles • Monoliths SingleApplication - Multiple Responsibilities • Microservices Multiple Applications - Single Responsibilities
- 35. “The microservice architecturalstyle 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 architecturalstyle that enables us to separate each of our product’s responsibilities into very small and separate applications This gives us flexibility
- 37. KISS / UNIX Moderndevelopment adopted a similar style Where does it come from? https://en.wikipedia.org/wiki/KISS_principle
- 39. Why is ituseful? • Service Independence Independent from one another - they have “contracts”
- 40. Why is ituseful? • Deployability Have a bug in a component - fix and deploy
- 41. Why is ituseful? • Team Independence Each can be owned by a different team
- 42. What are thedownsides? • Piping You have to take into account the inter-connections • Deployability Orchestration and Versioning • Infrastructure Much more complex setup
- 43. 41 STATE OF THECLOUD
- 44. “If someone asksme 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.
- 47. “Cloud computing isreally 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
- 48. What does itprovide us? - Infrastructure • Cheap Even with pay-on-demand pricing models
- 49. What does itprovide us? - Infrastructure • Replaceable Changed the service? Drop the server and create a new one
- 50. What does itprovide us? - Infrastructure • Scalable When demand raises, automatically spin up new copies to cope with demand
- 51. What does itprovide us? - Software • CDNs Global content caching - Blazing fast websites
- 53. What does itprovide us? - Software • Content and Databases Storage servers with multiple architectures
- 55. What does itprovide us? - Software • And EVERYTHING Else Even sending “Thank You” notes as a Service
- 57. Current Options -Infrastructure • Amazon Web Services • Microsoft Azure • Rackspace • Google Cloud Engine
- 58. Current Options -CDNs • CloudFront • Akamai • MaxCDN • Fastly
- 59. Current Options -Services • Contentful Content Management as a Service
- 61. Current Options -Services • Snipcart Shopping Cart as a Service
- 63. Current Options -Services • Auth0 Authentication as a Service
- 65.
- 66. “Serverless architectures referto 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
- 67. TRADITIONAL APPLICATION Unintelligent Client Serverdoes most of the hard work Source: https://www.martinfowler.com
- 68. SERVERLESS APPLICATION Rich client- Many Frontends Independent services and infrastructure Source: https://www.martinfowler.com
- 69. “If your PaaScan 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
- 70.
- 71. “Microservices architecture potentiallyoffers 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
- 72. Now that we’veintroduced the concepts Let’s dive into how to apply them in practice
- 73. Starting from yourRails App • Identify Models usually travel in families - identify these families
- 75. Starting from yourRails App • Categorize Understand the functionality and responsibility of each component family
- 77. Starting from yourRails App • Split Create separate API apps exposing them
- 79. Starting from yourRails App • Communicate Integrate different parts of the application through it’s HTTP Interfaces
- 81. Moving away fromRails • Move Static and Read-first content to a CMS Marketing, Blogs, Product and non-user generated content moved
- 83. Moving away fromRails • Decouple your Front-End from your business logic Your HTML or Native app shouldn’t be tied to your server code
- 85. Moving away fromRails • Profit from 3rd party Services Use cloud based authentication, messaging, mailing, payments to remove burden from your code
- 87. Moving away fromRails • Leverage Static Sites and Static Assets Using Static Site Generated websites + CDNs to deliver fast and increase conversion
- 88. “It’s much easiermentally 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/
- 89. Keep Security inCheck • Validate Validate on your Client side code - specially on payment transactions
- 91. Keep Security inCheck • Validate Validate on your Middleware - specially on payment transactions
- 93. Keep Security inCheck • Validate Make sure not to expose your internals
- 95. Keep Security inCheck • Validate Make sure you have retry and fallback mechanisms
- 97. Rounding up • Prototypeand test ideas • Create single responsibility applications • Test your code • Keep it safe
- 98.
- 100. We’re Hiring! Twitter: @dlitvakb Email:david.litvak@contentful.com Thanks!