Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Jedi's guide to Migrating to Serverless

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.

Aleksandar Simovic

June 21, 2018
Tweet

More Decks by Aleksandar Simovic

Other Decks in Technology

Transcript

  1. 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
  2. What we’ll be covering • Stepping stones to serverless •

    Serverless monoliths • Rethinking application processes • “Divide et impera” • Structural Analysis • Challenges
  3. 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
  4. New developers usually start rushing to the tools… They are

    important, but don’t focus on them first
  5. Very naively, gone to the Dark Side • Kept all

    drawbacks from your previous state • Slower starting time • Hard to maintain and test • Higher cost
  6. It also means… every time you wanted to use your

    car, 
 you would have to assemble it first.
  7. Migrating to serverless requires us to change how we think

    about application development …not just jump to serverless.
  8. 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.
  9. 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)
  10. 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
  11. 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?
  12. Hiring people to write code to sell is not the

    same as hiring people to design and build durable, usable, dependable software. - Larry Constantine
  13. 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
  14. 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)
  15. 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
  16. 3. Testing serverless apps • Divide the functionality -> primitive

    Lambdas • Separate the main business logic • Apply Hexagonal architecture • Derisk your code
  17. 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
  18. 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*
  19. 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:
  20. Case Study: • Low hanging fruits 
 = preprocessors •

    Migrated all preprocessors into serverless functions • Separated their business process into functions • > 200,000 requests / h
  21. Case Study: • Converters were eating too much resources •

    Too expensive Heroku dynos • Less isolation, could collide over resources • Hard to experiment Problems: MINDMUP
  22. 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
  23. 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.