This document discusses transitioning from monolithic applications to microservices and serverless architectures. It begins by defining technical debt and explaining how microservices can help pay it down incrementally. It then covers different architectural styles like monoliths and microservices. The rest of the document discusses moving to cloud infrastructure, breaking apart monolithic applications into independent services, communication between services, leveraging third-party services, and security considerations for microservices.

1. BW1
Projects & Teams
6/7/2017 11: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 Litvak is 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 to Services
Gradually paying your Technical Debt
BY DAVID LITVAK (@dlitvakb)

4. 2
TECHNICAL DEBT

5. “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

7. Metaphor explaining difficulties of 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 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

11. Debt itself is not a bad thing!
Invest and pay back early!
Don’t leave debt hanging!
But Hey! It’s not always bad!

13. 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

15. 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

17. 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

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. 31
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

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. 41
STATE OF THE CLOUD

44. “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. 2017

47. “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

48. What does it provide us? - Infrastructure
• Cheap
Even with pay-on-demand pricing models

49. What does it provide us? - Infrastructure
• Replaceable
Changed the service? Drop the server and create a new one

50. What does it provide us? - Infrastructure
• Scalable
When demand raises, automatically spin up new copies to cope with demand

51. What does it provide us? - Software
• CDNs
Global content caching - Blazing fast websites

53. What does it provide us? - Software
• Content and Databases
Storage servers with multiple architectures

55. What does it provide 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. 63
GOING SERVERLESS

66. “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

67. TRADITIONAL APPLICATION
Unintelligent Client
Server does 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 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

70. 68
GOODBYE MONOLITH

71. “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

72. Now that we’ve introduced the concepts
Let’s dive into how to apply them in practice

73. Starting from your Rails App
• Identify
Models usually travel in families - identify these families

75. Starting from your Rails App
• Categorize
Understand the functionality and responsibility of each component family

77. Starting from your Rails App
• Split
Create separate API apps exposing them

79. Starting from your Rails App
• Communicate
Integrate different parts of the application through it’s HTTP Interfaces

81. Moving away from Rails
• Move Static and Read-first content to a CMS
Marketing, Blogs, Product and non-user generated content moved

83. 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

85. Moving away from Rails
• Profit from 3rd party Services
Use cloud based authentication, messaging, mailing, payments to remove burden
from your code

87. Moving away from Rails
• Leverage Static Sites and Static Assets
Using Static Site Generated websites + CDNs to deliver fast and increase conversion

88. “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/

89. Keep Security in Check
• Validate
Validate on your Client side code - specially on payment transactions

91. Keep Security in Check
• Validate
Validate on your Middleware - specially on payment transactions

93. Keep Security in Check
• Validate
Make sure not to expose your internals

95. Keep Security in Check
• Validate
Make sure you have retry and fallback mechanisms

97. Rounding up
• Prototype and test ideas
• Create single responsibility applications
• Test your code
• Keep it safe

98. Demo Time

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