A Jedi's guide to Migrating to Serverless

Slide 1

Slide 1 text

A Jedi’s Guide to Migrating to Serverless Serverless Meetup Milano Milano, Italy

Slide 2

Slide 2 text

Who’s this Jedi idiot? Aleksandar Simovic Senior software engineer  ScienceExchange JS Belgrade co-organizer Author of “Serverless Applications with Node.js” Core team member of Claudia.js

Slide 3

Slide 3 text

What we’ll be covering • Stepping stones to serverless • Serverless monoliths • Rethinking application processes • “Divide et impera” • Structural Analysis • Challenges

Slide 4

Slide 4 text

STAR WARS NERD ALERT

Slide 5

Slide 5 text

Serverless means… • No longer need to manage or conﬁgure servers • Pay only for used time • Automatically scaled per usage • Auto-failover and automated high scalability You know it, it’s a serverless meetup

Slide 6

Slide 6 text

How does one go serverless?

Slide 7

Slide 7 text

New developers usually start rushing to the tools… They are important, but don’t focus on them ﬁrst

Slide 8

Slide 8 text

“We’ll just build applications on serverless instead of cloud” To many going serverless seems like…

Slide 9

Slide 9 text

To the business it looks the same… Attribution: Simon Wardley serverless

Slide 10

Slide 10 text

“We just go serverless now.” “I have a light saber, therefore I am a Jedi.”

Slide 11

Slide 11 text

ANTI PATTERN ALERT Welcome to Serverless Monoliths!

Slide 12

Slide 12 text

Very naively, gone to the Dark Side • Kept all drawbacks from your previous state • Slower starting time • Hard to maintain and test • Higher cost

Slide 13

Slide 13 text

Looks like…

Slide 14

Slide 14 text

It also means… every time you wanted to use your car,   you would have to assemble it ﬁrst.

Slide 15

Slide 15 text

Migrating to serverless requires us to change how we think about application development …not just jump to serverless.

Slide 16

Slide 16 text

So, how should we migrate?

Slide 17

Slide 17 text

Learn from Luke’s mistakes

Slide 18

Slide 18 text

Function-by-function approach “Divide et impera” 1. Pick your already isolated services ﬁrst  “the low hanging fruit”

Slide 19

Slide 19 text

Function-by-function approach “Divide et impera” 2. Rethink and separate services into functions Hint: you don’t pay for your function storage, just usage.

Slide 20

Slide 20 text

Function-by-function approach “Divide et impera” 3. Divide your business processes into functions

Slide 21

Slide 21 text

Reinventing the wheel?

Slide 22

Slide 22 text

Structural Analysis • Method for analyzing and writing business requirements • Part of a Structural Analysis and Structural Design method group • Based on Data Flow diagrams • Developed by Larry Constantine in 1970s (~ 50 years ago)

Slide 23

Slide 23 text

Structural Analysis overview

Slide 24

Slide 24 text

Structural Analysis Rules • Processes should not talk to one another • Data storages should not talk to one another • If you wanted a process to talk to another one, it needed to go via data storage • A data ﬂow cannot go directly back to the same process it leaves • Many more

Slide 25

Slide 25 text

Comparing with serverless recommendations? • Function should not talk to one another (Linear cost) • Data storages should not talk to one another (sometimes) • If you wanted a function to talk to another one, it should go via data storage, the same for storages. • Flow can’t go directly to the function it came from. (Forbidden) Are we reinventing the wheel all the time?

Slide 26

Slide 26 text

Hiring people to write code to sell is not the same as hiring people to design and build durable, usable, dependable software. - Larry Constantine

Slide 27

Slide 27 text

For some unknown reason resembles a bit Obi Wan Kenobi

Slide 28

Slide 28 text

“But can we use this approach everywhere?”

Slide 29

Slide 29 text

Example: Migrating User authentication

Slide 30

Slide 30 text

Challenges 1. Architecture & Communication 2. Costs 3. Testing our applications 4. Security

Slide 31

Slide 31 text

1. Architecture & Communication • Applications & microservices -> Primitive functions • Organizing a Swarm of Functions -> Zerg Rush issues • Problems with function reuse • Running arbitrary executables and function state

Slide 32

Slide 32 text

2. Costs • Reserved -> Pay-per-use -> possible change of your business model • Freemium model -> Can help/kill your company • Denial-of-service -> Denial-of-wallet • Undercover fees (API GW more expensive than Lambda)

Slide 33

Slide 33 text

3. Testing serverless apps • No control over resources and infrastructure • Harder to write tests (*bundled Lambdas) • Not many SLAs (DynamoDB announced a few days ago) • End to end tests are more expensive, slow and brittle, as they are running on a multitude of services

Slide 34

Slide 34 text

3. Testing serverless apps • Divide the functionality -> primitive Lambdas • Separate the main business logic • Apply Hexagonal architecture • Derisk your code

Slide 35

Slide 35 text

4. Security • Increased security implementation • Less risk (who’s harder to hack, you or AWS/Microsoft/Google?) • Compliance & Standardization • Out-of-the-box encryption (available on most of the provider services you are using) • Bonus: Leaving your AWS keys in GH repo -> get instant Bitcoin miners

Slide 36

Slide 36 text

What are the future challenges? • Serverless composable components • Business driven development (articles - “made an app in a minute”) • “Maxing out” your serverless resources • 1-1 business-to-app copy • Frontend*

Slide 37

Slide 37 text

Case Study: • Can’t predict the popularity of their pens • Have lots of unexpected peaks • Being able to serve is the key business goal • Spending lots on provisioning servers • Keeping lots of servers idle Problems:

Slide 38

Slide 38 text

Case Study: • Low hanging fruits   = preprocessors • Migrated all preprocessors into serverless functions • Separated their business process into functions • > 200,000 requests / h

Slide 39

Slide 39 text

Case Study: • Converters were eating too much resources • Too expensive Heroku dynos • Less isolation, could collide over resources • Hard to experiment Problems: MINDMUP

Slide 40

Slide 40 text

Case Study: • Low hanging fruits   = converters • Migrated all converters into functions • Separated business processes for payments, notiﬁcations, ﬁle storage • Half a million active users each month • Grew 30% in the migration period,   while reduced costs by 30% MINDMUP

Slide 41

Slide 41 text

Summary • Don’t just rush migrating serverless. Rethink. • If possible, apply Structural Analysis of business requirements ﬁrst • Remember your context. Reuse. • Pick the low hanging “fruits” (services) ﬁrst. • “Divide et impera” existing services.