Serverless without a fuss.

How to develop and debug Lambda functions without going crazy. Deck from my AWS User Group Kyiv talk.

Transcript

1. ©2020 AgileVision Sp. Z O.O. Agilevision.io Serverless without a fuss. How to develop and debug lambda functions without going crazy.
2. Agilevision.io 6. Application Structure 7. Deployment 8. Debugging & Tracing 9. Q&A 2 Plan 1. About me 2. What is Serverless? 3. Why Serverless? 4. “Ideal Application Profile” 5. Serverless in AWS Necessary theory Takeaways
3. AWS Certified Architect. Running an IT consulting company. Writing code. Love to share knowledge. About me 3
4. Agilevision.io 4 Serverless is a cloud-computing execution model in which the developer is not responsible for provisioning and maintaining server resources. A.K.A. Function-as-a-Service (FaaS). What is Serverless?
5. Agilevision.io Why Serverless? 5 • No maintenance • Flexible pricing • Seamless scaling
6. Agilevision.io 6 “Ideal Application Profile” • Faster time-to-market is required • You want to focus on a business logic rather than on the infrastructure • You need to be prepared for a high-load • Your goal is to be cost-effective Go Serverless If 6
7. Agilevision.io 7 “Ideal Application Profile” • Everyone in the team is trained properly • Application architecture is designed, discussed and validated by your team. • Everyone understands pricing, hard and soft limits of each AWS service that is going to be used • To do your homework, calculate costs projection based on theoretical growth of a user base Before using Serverless make sure 7
8. Agilevision.io 8 Serverless in AWS - Compute Function-as-a-Service Lambda Serverless containers Fargate Application Blueprints SAR
9. Agilevision.io 9 Serverless in AWS - DB Serverless SQL Aurora Serverless Managed NoSQL DynamoDB
10. Agilevision.io 10 Serverless in AWS - Other Serverless Presto Athena Real-time data streaming Kinesis Data Streams Object Storage S3 User Sign-Up, Sign-In, and Access Control AWS Cognito … and many other
11. Agilevision.io 11 Before we proceed • Further suggestions are based on a previous experience mixed with retrospective thinking • Do not overengineer Some notes 11
12. Agilevision.io / 12 Application Structure
13. Agilevision.io 13 Typical HTTP Handler Lambda Structure 13 API Endpoint Lambda Function Request Data Response Data HTTP Request HTTP Response /api/organization/1/devices
14. Agilevision.io 14 ...and on a scale with a bit of encapsulation 14 /api/organization/1/devices /api/organization/1/devices/0001A231 /api/organization/1/users ...
15. Agilevision.io 15 Simplified view on a scale 15 HTTP Request HTTP Request HTTP Request
16. Agilevision.io Possible issues 16 • Each Lambda has its own cold start penalty • Each API endpoint requires a ton of AWS resources
17. Agilevision.io 17 Short-term solution with long-term penalties 17 HTTP Request HTTP Request HTTP Request Request routing happens inside Lambda This is not the best approach in the long run. See next slide to understand why
18. Agilevision.io What’s wrong with a single Lambda for multiple APIs? 18 • Optimization opportunities are missed. • API Gateway routing and transformation capabilities are not used, thus you are wasting money (and time). • Code becomes more complicated(and it will result in more bugs) • Testing is more complicated
19. Agilevision.io About missed optimization opportunities... 19 Init Unpack Logic Cold start Invocation Execution time Shared init = shared cold start time OR conditional init = waste of money and time
20. Agilevision.io NodeJS vs Python vs Java HTTP Request Duration 20
21. Agilevision.io NodeJS Duration 21
22. Agilevision.io Python Duration 22
23. Agilevision.io NodeJS vs Python vs Java Invocation Time 23
24. Agilevision.io / 24 Duration
25. Agilevision.io 25
26. Agilevision.io / 26 Most expensive invocations
27. Agilevision.io 27
28. Agilevision.io So... 28 • Invocation duration != HTTP Request Processing Time • Some environment have longer cold start than others • Non-cold start request processing time is almost the same. But each environment has its own latency “base value”. This may matter for aggressive optimizations
29. Agilevision.io Valid cases to use single Lambda + internal routing 29 • Migration of an existing code • Incoming request routing is complicated and can’t be achieved using API Gateway • Quick and dirty proof of concept
30. Agilevision.io Deployment 30
31. Agilevision.io Lambda Deployment Approaches 31 Native External SAM CDK Serverless CloudFormation Terraform Semi-native
32. Agilevision.io Native Deployment 32 • CloudFormation under the hood • AWS Way • Rollback support • Very flexible • IDE Integration
33. Agilevision.io The Dark Side of Native Deployment 33 • Slow • Packaging is not included • Verbose
34. Agilevision.io Semi-Native Deployment 34 • CloudFormation under the hood • Rollback support • Eloquent • Stuff not supported by AWS is implemented via plugins • There are tons of plugins
35. Agilevision.io Horrors of Semi-Native Deployment 35 • Not supported by AWS • New resources support may appear with a delay • Freemium model
36. Agilevision.io External Deployment 36 • No CloudFormation under the hood • Faster • No rollback/limited rollback • Super flexible
37. Agilevision.io Pains of External Deployment 37 • No rollback • Super verbose • Constant release of incompatible tool versions • Latest resources may not be available • Not all resources may be available due to architecture/paradigm limitations
38. Agilevision.io How to decide? 38 Choose Serverless framework for fast development Choose other options for sophisticated infrastructures and additional features
39. Agilevision.io 39 Debugging and Tracing
40. Agilevision.io 40 Invocation options • End-to-end invocation initiated by a trigger (e.g. HTTP request to API Gateway) • Lambda invocation (API or Lambda Console) • Local invocation
41. Agilevision.io 41 Debugging options • Remote trial & error ( a.k.a. invoke and check logs until problem disappears) • Local trial & error • Local debugging with breakpoints (a.k.a. normal development process)
42. Agilevision.io 42 Trial & error debugging Trigger Lambda Check CloudWatch Update code
43. Agilevision.io 43 Checking logs
44. Agilevision.io 44 Trial & error pros • No configuration needed • Execution involves all services/resources and can be great for creating end-to-end tests
45. Agilevision.io 45 Trial & error cons • Code is deployed and only then tested • Takes a lot of time (deployment, invocation and waiting for logs to arrive) • Exhausting and inefficient
46. Agilevision.io 46 Local trial & error Trigger Lambda Check Output Update code
47. Agilevision.io 47 Local invocation and output
48. Agilevision.io 48 Local invocation pros • Speed • No need to deploy code before checking it works • Easy stubbing and mocking of external services
49. Agilevision.io 49 Local invocation cons • Local environment is completely different from the cloud • You have to mock inputs from triggers • Execution environment support depends on a tool
50. Agilevision.io 50 Local debugging Set breakpoints Invoke locally Analyze & fix
51. Agilevision.io 51 Local debugging
52. Agilevision.io 52 Local debugging pros • Predictable process • Fast • Smaller feedback loop • Debug context
53. Agilevision.io 53 Local invocation cons • Local environment differs from the production • Execution environment support can be limited depending on a tool • Additional configuration required
54. Agilevision.io 54 Pro Tip :) Lambda handler code should not have any business logic. Instead, it should extract input, pass it further and format response. Then you can easily replace the entry point and debug any function in any IDE.
55. Agilevision.io 55 Tracing • Simple setup • Useful insights • Flexible configuration, including custom sub-segments to reflect application mission-critical modules
56. Agilevision.io 56 Tracing example
57. Agilevision.io / 57 Questions?