A Jedi's guide to Migrating to Serverless

Use the force, Luke!
Serverless has made its stand. It attracts us with its simplicity, cost-effectiveness, removal of server responsibilities and scaling issues. But the path is slippery and you can easily fall to the dark side and bring back all the monoliths and make it even worse!
In this talk, we will briefly explain serverless and it’s migration problems and challenges. Comparing to the Luke Skywalker’s path from the episodes IV, V and VI, we will discover what mistakes can you make when going serverless, how easy is it to fall into the trap and how to avoid them in the first place.

Transcript

1. A Jedi’s Guide to Migrating to Serverless Serverless Meetup Milano Milano, Italy
2. 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
3. What we’ll be covering • Stepping stones to serverless • Serverless monoliths • Rethinking application processes • “Divide et impera” • Structural Analysis • Challenges
4. STAR WARS NERD ALERT
5. Serverless means… • No longer need to manage or configure servers • Pay only for used time • Automatically scaled per usage • Auto-failover and automated high scalability You know it, it’s a serverless meetup
6. How does one go serverless?
7. New developers usually start rushing to the tools… They are important, but don’t focus on them first
8. “We’ll just build applications on serverless instead of cloud” To many going serverless seems like…
9. To the business it looks the same… Attribution: Simon Wardley serverless
10. “We just go serverless now.” “I have a light saber, therefore I am a Jedi.”
11. ANTI PATTERN ALERT Welcome to Serverless Monoliths!
12. Very naively, gone to the Dark Side • Kept all drawbacks from your previous state • Slower starting time • Hard to maintain and test • Higher cost
13. Looks like…
14. It also means… every time you wanted to use your car, 
 you would have to assemble it first.
15. Migrating to serverless requires us to change how we think about application development …not just jump to serverless.
16. So, how should we migrate?
17. Learn from Luke’s mistakes
18. Function-by-function approach “Divide et impera” 1. Pick your already isolated services first
 “the low hanging fruit”
19. 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.
20. Function-by-function approach “Divide et impera” 3. Divide your business processes into functions
21. Reinventing the wheel?
22. 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)
23. Structural Analysis overview
24. 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 flow cannot go directly back to the same process it leaves • Many more
25. 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?
26. Hiring people to write code to sell is not the same as hiring people to design and build durable, usable, dependable software. - Larry Constantine
27. For some unknown reason resembles a bit Obi Wan Kenobi
28. “But can we use this approach everywhere?”
29. Example: Migrating User authentication
30. Challenges 1. Architecture & Communication 2. Costs 3. Testing our applications 4. Security
31. 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
32. 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)
33. 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
34. 3. Testing serverless apps • Divide the functionality -> primitive Lambdas • Separate the main business logic • Apply Hexagonal architecture • Derisk your code
35. 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
36. 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*
37. 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:
38. Case Study: • Low hanging fruits 
 = preprocessors • Migrated all preprocessors into serverless functions • Separated their business process into functions • > 200,000 requests / h
39. Case Study: • Converters were eating too much resources • Too expensive Heroku dynos • Less isolation, could collide over resources • Hard to experiment Problems: MINDMUP
40. Case Study: • Low hanging fruits 
 = converters • Migrated all converters into functions • Separated business processes for payments, notifications, file storage • Half a million active users each month • Grew 30% in the migration period, 
 while reduced costs by 30% MINDMUP
41. Summary • Don’t just rush migrating serverless. Rethink. • If possible, apply Structural Analysis of business requirements first • Remember your context. Reuse. • Pick the low hanging “fruits” (services) first. • “Divide et impera” existing services.
42. Learn more? Use code claudia40
43. Thank you! Questions? @simalexan