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

Slide 1

Slide 1 text

From Monoliths to Services Gradually paying your Technical Debt BY DAVID LITVAK (@dlitvakb)

Slide 2

Slide 2 text

2 TECHNICAL DEBT

Slide 3

Slide 3 text

“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

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

Metaphor explaining difﬁculties of shipping software

Slide 6

Slide 6 text

Like ﬁnancial debt, technical debt comes with interests. Failing to pay your debt, interests will come back at you. Why is it called Debt?

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

How to avoid? • Work Small Make incremental progress

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

How to avoid? • Work Clean Seek for refactoring opportunities

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

How to avoid? • Work Green Have a Test Suite - Use Continuous Integration Tools

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Some useful techniques • Pair-Programming • Test-ﬁrst development (TDD & BDD) • Continuous Integration & Continuous Delivery

Slide 24

Slide 24 text

Categorizing Technical Debt

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

33 MICROSERVICES

Slide 34

Slide 34 text

Architectural Styles • Monoliths Single Application - Multiple Responsibilities • Microservices Multiple Applications - Single Responsibilities

Slide 35

Slide 35 text

“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

Slide 36

Slide 36 text

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 ﬂexibility

Slide 37

Slide 37 text

KISS / UNIX Modern development adopted a similar style Where does it come from? https://en.wikipedia.org/wiki/KISS_principle

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

Why is it useful? • Service Independence Independent from one another - they have “contracts”

Slide 40

Slide 40 text

Why is it useful? • Deployability Have a bug in a component - ﬁx and deploy

Slide 41

Slide 41 text

Why is it useful? • Team Independence Each can be owned by a different team

Slide 42

Slide 42 text

What are the downsides? • Piping You have to take into account the inter-connections • Deployability Orchestration and Versioning • Infrastructure Much more complex setup

Slide 43

Slide 43 text

There are no silver bullets

Slide 44

Slide 44 text

Where does this approach not ﬁt? • On small or single-concern applications • When teams have a hard time collaborating • With unexperienced DevOps teams

Slide 45

Slide 45 text

45 STATE OF THE CLOUD

Slide 46

Slide 46 text

“If someone asks me what cloud computing is, I try not to get bogged down with deﬁnitions. 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/

Slide 47

Slide 47 text

2017

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

“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 ﬁguring 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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

What does it provide us? - Software • And EVERYTHING Else Even sending “Thank You” notes as a Service

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

Current Options - Infrastructure • Amazon Web Services • Microsoft Azure • Rackspace • Google Cloud Engine

Slide 60

Slide 60 text

Current Options - CDNs • CloudFront • Akamai • MaxCDN • Fastly

Slide 61

Slide 61 text

Current Options - Services • Contentful Content Management as a Service

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

Current Options - Services • Snipcart Shopping Cart as a Service

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

Current Options - Services • Auth0 Authentication as a Service

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

67 GOING SERVERLESS

Slide 68

Slide 68 text

“Serverless architectures refer to applications that signiﬁcantly 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

Slide 69

Slide 69 text

TRADITIONAL APPLICATION Unintelligent Client Server does most of the hard work Source: https://www.martinfowler.com

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

“If your PaaS can efﬁciently 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

Slide 72

Slide 72 text

72 GOODBYE MONOLITH

Slide 73

Slide 73 text

“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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

Starting from your Rails App • Communicate Integrate different parts of the application through HTTP or Message Queues

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

No content

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

Moving away from Rails • Proﬁt from 3rd party Services Use cloud based authentication, messaging, mailing, payments to remove burden from your code

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

No content

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

No content

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

Demo Time

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

We’re Hiring! Twitter: @dlitvakb Email: [email protected] Thanks!