Mariusz Richtscheid: Architektura typu serverless wraz z terminem "Function as a Service" zyskują coraz większą popularność. To całkiem odmienne podejście do tworzenia aplikacji oraz ich wdrażania ma wiele zalet, ale musimy być też świadomi problemów, jakie się z nim wiążą. W trakcie prezentacji pokażę, w jaki sposób można zmodyfikować istniejącą aplikację Node.js tak, by wykorzystać zalety tej architektury.

1. Serverless Node.js
Mariusz Richtscheid
Uszanowanko Programowanko
Gliwice, 11.04.2018

2. About me
• Full-Stack Developer in The Software House
• richtscheid@gmail.com
• linkedin.com/in/richtscheid
• github.com/barograf
Mariusz Richtscheid
2

3. Agenda
• What does serverless mean?
• AWS Lambda
• Quick start
• Migrating translations service to serverless architecture
• Serverless framework
• Pros and cons
3

4. Another buzzword?
• Big data - data
• Blockchain - database
• Cloud - there is still someone else’s computer
• IoT - malware-ready device
• Serverless - ?
4

6. Why serverless?
• Servers management and provisioning outsourced to
vendor
• Dynamic scaling of machine resources, no need for
capacity planning
• Pay only for what you use
• Your only concern is code
• Can be achieved with Platform as a Service (PaaS) or
Functions as a Service (FaaS)
6

7. No DevOps?
• A lot of is outsourced but…
• You still need to monitor your application
• And have strategy for deployments
• Also consider security, networking, debugging, whole
system scaling, etc.
7

8. Should I bother?
• Postlight Readability API before serverless
• $10,000 monthly cost
• 39 million requests per month (around 15 per second)
• After serverless
• New service name is Mercury Web Parser
• $370 monthly cost (API Gateway + Lambda)
8

9. Cloud computing service models
Source: https://medium.com/@sdorzak/why-serverless-is-the-new-black-e4ff9e9947e0
• Amazon EC2
• Google
Compute
Engine
• AWS Elastic
Beanstalk
• Heroku
• Google App
Engine
• AWS Lambda
• Google Cloud
Functions
FaaS

10. PaaS vs FaaS
10
• System runs server
process which handles
requests
• No long-running processes,
each request handled by
function execution
• Scaling means adding
more processes
• Scaling means executing
more functions
concurrently
• Charge per running time • Charge per execution

11. Serverless providers
11

12. AWS Lambda runtimes
• Python, Java, .NET Core, Go
• Node.js
• v4.3.2
• v6.10.3
• v8.10
• announced 02.04.2018
• added async handler support
12
FaaS

13. AWS Lambda pricing
• 1M requests free
• $0.20 per 1M requests thereafter
• 400,000 GB-seconds free
• $0.00001667 GB-second thereafter
• Every code optimisation reduces costs
13

14. AWS Lambda limits
• Memory - 3008MB
• Ephemeral disk capacity - 512MB
• Execution duration - 300s
• Concurrent executions - 1000 (can be increased)
14

15. Quick start (1/2)
15
serverless.yml
index.js

16. Quick start (2/2)
16

17. How it works
17
FunctionInvocation Result
Container
Invocation Function
Cold start
Container
Result

18. Things to remember
• No long-running processes
• Function is stateless
• Gets executed and returns a value
• Once uploaded it is ready to be executed all the time
• You pay only when functions are executed
18

19. Use cases (1/3)
19 Source: https://aws.amazon.com/lambda/

20. Use cases (2/3)
20 Source: https://aws.amazon.com/lambda/

21. Use cases (3/3)
21 Source: https://aws.amazon.com/lambda/

22. Translations service (1/3)
Google Spreadsheet
JSON XLF
iOSAndroid
22
>_https://

23. Translations service (2/3)
Producer
with scheduler API
Google Spreadsheet
Cache storage
23
API call
GET /translations

24. Translations service (3/3)
Producer
API call
GET /translations
API
Google Spreadsheet
DynamoDB
as cache storage
CloudWatch
scheduler
API Gateway
24

25. Migration steps
• Get rid of state, use some storage or execution context
• Get rid of long running processes
• Use environment variables to provide config
• Make storage abstraction, inject proper storage
implementation to IoC container
• Write functions handlers
• Prepare stack provisioning
25

26. Storage abstraction (1/2)
For local
development
For serverless
26

27. Storage abstraction (2/2)
For serverless
27

28. Producer function handler (1/2)
Before serverless
28
• Extract file
• Transform it
• Load into storage

29. Producer function handler (2/2)
• event
• input data from other
sources
• context
• remaining time
• request id
• function name
• log group name
• etc.
After serverless
29

30. API function handler
Serverless
Express.js
30

31. Stack provisioning
• AWS Console
• AWS CLI
• AWS Serverless Application Model
• Serverless Framework
31

32. serverless framework
• Translates configuration file into infrastructure
• Common concepts like functions, events, resources etc.
• Pluggable
• For AWS it uses CloudFormation provisioning
32

33. serverless.yml (1/3)
33

34. serverless.yml (2/3)
• Events from:
• S3
• DynamoDB
• Kinesis Data Streams
• Simple Notification Service
• Simple Email Service
• Cognito
• CloudFormation
• Alexa
• Others
34

35. serverless.yml (3/3)
35

36. Stack creation (1/3)
36

37. Stack creation (2/3)
37

38. Stack creation (3/3)
38

39. Stack update
39

40. Invoking function
40

41. Logs and stats (1/2)
41

42. Logs and stats (2/2)
42

43. Entire stack rollback
43

44. Stack removal
Just in case when startup has failed
44

45. Testing
• Serverless framework allows local functions invocation,
but it is just emulation
• AWS Serverless Application Model has Docker image
which fakes AWS infrastructure more accurately
• Test your app using InMemory implementations for
abstractions like storage (not always possible)
45

46. Optimisation steps
• Http cache on API Gateway (reduce time, cost)
• Lower memory limit
• Use execution context for local cache
• Use fast storage solution, e.g. Redis
• Divide app into multiple functions and package them
separately
• https://serverless.com/blog/serverless-architecture-code-
patterns/
46

47. Pros
• Reduced operational cost (occasional requests)
• Optimisation equals not only speed, but also cost savings
• Effortless scaling (spikes in traffic)
• Time to market and experimentation
• Reduced deployment complexity
• Reduced system administration
47

48. Cons
• Vendor control and lock-in
• Needs to be stateless
• No long-running processes
• Hard to optimise, test and debug
• Limits on execution time, memory
48

49. Thanks!
Any questions?
49