from monoliths to services: grafually paying your technical debt

From Monoliths to Services Gradually paying your Technical Debt

BY DAVID LITVAK (@dlitvakb)

2

TECHNICAL DEBT

“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

Metaphor explaining difficulties of shipping software

Like financial debt, technical debt comes with interests.

Failing to pay your debt, interests will come back at you.

Why is it called Debt?

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

Debt itself is not a bad thing!

Invest and pay back early!

Don’t leave debt hanging!

But Hey! It’s not always bad!

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


• Lack of Testing

“We can write tests for it later.”



• Assuming “False Positives” are Positives

“The build fails sometimes, but it passes most of the time. Let’s just move on.”


How to avoid?

• Work Small

Make incremental progress

How to avoid?

• Work Clean

Seek for refactoring opportunities

How to avoid?

• Work Green

Have a Test Suite - Use Continuous Integration Tools

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



• Grade Two: Developer Comfort

Code for readability - your future self and co-workers will much appreciate it




• Grade Three: Cost of Pragmatism

Use debt wisely and prototype - throw away if not successful




• 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!



31

MICROSERVICES

Architectural Styles

• Monoliths

Single Application - Multiple Responsibilities

• Microservices

Multiple Applications - Single Responsibilities

“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

http://martinfowler.com/articles/microservices.html

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

KISS / UNIX

Modern development adopted a similar style

Where does it come from?

https://en.wikipedia.org/wiki/KISS_principle

https://en.wikipedia.org/wiki/KISS_principle

Why is it useful?

• Service Independence

Independent from one another - they have “contracts”

Why is it useful?

• Deployability

Have a bug in a component - fix and deploy

Why is it useful?

• Team Independence

Each can be owned by a different team

What are the downsides?• Piping

You have to take into account the inter-connections

• Deployability

Orchestration and Versioning

• Infrastructure

Much more complex setup

41

STATE OF THE CLOUD

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

http://salesforce.com

http://www.mercurynews.com/2009/10/23/2009-qa-marc-benioff-ceo-of-salesforce-com/

“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

http://www.cio.com/article/2428093/infrastructure/cloud-computing--pros-and-cons.html

What does it provide us? - Infrastructure

• Cheap

Even with pay-on-demand pricing models


• Replaceable

Changed the service? Drop the server and create a new one


• Scalable

When demand raises, automatically spin up new copies to cope with demand

What does it provide us? - Software

• CDNs

Global content caching - Blazing fast websites


• Content and Databases

Storage servers with multiple architectures


• And EVERYTHING Else

Even sending “Thank You” notes as a Service

Current Options - Infrastructure

• Amazon Web Services

• Microsoft Azure

• Rackspace

• Google Cloud Engine

Current Options - CDNs

• CloudFront

• Akamai

• MaxCDN

• Fastly

Current Options - Services

• Contentful

Content Management as a Service


• Snipcart

Shopping Cart as a Service


• Auth0

Authentication as a Service

63

GOING SERVERLESS

“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

http://www.martinfowler.com/articles/serverless.html

TRADITIONAL APPLICATION

Unintelligent Client

Server does most of the hard work

Source: https://www.martinfowler.com

https://www.martinfowler.com

SERVERLESS APPLICATION

Rich client - Many Frontends

Independent services and infrastructure

Source: https://www.martinfowler.com

https://www.martinfowler.com

“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

https://twitter.com/adrianco/status/736553530689998848

68

GOODBYE MONOLITH

“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

http://www.infoworld.com/article/2878659/application-development/reducing-technical-debt-with-microservices.html

Now that we’ve introduced the concepts

Let’s dive into how to apply them in practice

Starting from your Rails App

• Identify

Models usually travel in families - identify these families


• Categorize

Understand the functionality and responsibility of each component family


• Split

Create separate API apps exposing them


• Communicate

Integrate different parts of the application through it’s HTTP Interfaces

Moving away from Rails

• Move Static and Read-first content to a CMS

Marketing, Blogs, Product and non-user generated content moved


• Decouple your Front-End from your business logic

Your HTML or Native app shouldn’t be tied to your server code


• Profit from 3rd party Services

Use cloud based authentication, messaging, mailing, payments to remove burden from your code


• Leverage Static Sites and Static Assets

Using Static Site Generated websites + CDNs to deliver fast and increase conversion

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

Keep Security in Check

• Validate

Validate on your Client side code - specially on payment transactions


• Validate

Validate on your Middleware - specially on payment transactions


• Validate

Make sure not to expose your internals


• Validate

Make sure you have retry and fallback mechanisms

Rounding up

• Prototype and test ideas

• Create single responsibility applications

• Test your code

• Keep it safe

Demo Time

We’re Hiring!

Twitter: @dlitvakbEmail: [email protected]

Thanks!