Serverless: Less is more

Answering what, why, why not of Serverless and explaining basics of AWS Lambda by showing some use-cases at the end.

Transcript

1. @srhtcn Serverless: Less is more Serhat Can @srhtcn Technical Evangelist at @OpsGenie
2. @srhtcn Who am I? Remote worker in Istanbul after 7 years in Ankara Software Engineer to Technical Evangelist @OpsGenie Writes, talks, and speaks about DevOps and Serverless - So far: London (x5), Amsterdam (x3), Barcelona (x2), Kiev (x2), Warsaw, Zurich - Soon: Boston, NYC, Berlin, Paris, Nuremberg, Las Vegas Organizer - Serverless Turkey meetup - DevOps Turkey meetup - DevOpsDays Istanbul
3. @srhtcn 3000+ customers from all around the world 10M$ from Battery Ventures in mid 2016 From 15 people in 2016 to 90 Ankara, 87 Boston, 7 Washington DC. within 2.5 years Learn more (Turkish - otherwise visit opsgenie.com): https://medium.com/@serhatcan/opsgenie-nedir-ne-yapar-b688eaf724f1
4. @srhtcn • Always-on • Don’t react, RESPOND! • Reliable and flexible alerting • Reporting and analytics • 200+ integration
5. @srhtcn You want to run code on cloud. Your options: Bare metal IaaS (VM) CaaS (container) PaaS (app) Serverless (function) More control, more code Less control, less code
6. @srhtcn Making thoughtful decisions about tools and architecture can help; well-considered constraints can free us from the decisions that aren't bringing us distinguishable benefit. Bridget Kromhout https://queue.acm.org/detail.cfm?id=3185224
7. @srhtcn What is wrong with lower level abstractions? aka. VMs, Containers, Apps
8. @srhtcn Nothing Use where and when it makes sense Just be aware that hidden costs are bigger than service costs
9. @srhtcn What is Serverless?
10. @srhtcn Defining Serverless Serverless is an event driven, utility based, stateless, code execution environment. Simon Wardley @swardley
11. @srhtcn Defining Serverless Event driven: Code is initiated and run after an event like HTTP request or storage of a file triggers.
12. @srhtcn Defining Serverless Event driven: Code is initiated and run after an event like HTTP request or storage of a file triggers. Utility based: No payment for idle time or hosting. You pay for the resources you use when your code is triggered.
13. @srhtcn Defining Serverless Event driven: Code is initiated and run after an event like HTTP request or storage of a file triggers. Utility based: No payment for idle time or hosting. You pay for the resources you use when your code is triggered. Stateless: Code execution environment is deconstructed after sometime. No information is guaranteed to stay in the environment after function execution is completed.
14. @srhtcn Defining Serverless Event driven: Code is initiated and run after an event like HTTP request or storage of a file triggers. Utility based: No payment for idle time or hosting. You pay for the resources you use when your code is triggered. Stateless: Code execution environment is deconstructed after sometime. No information is guaranteed to stay in the environment after function execution is completed. Code execution: Just code, not servers / VMs / containers etc.
15. @srhtcn Why should I go Serverless? Two main reasons
16. @srhtcn Less is more Less code to maintain, less ops, less toil (work tied to running a production service that tends to be manual, repetitive) - Scaling - Provisioning - OS or Language updates - Resource utilization - Network monitoring - Fault tolerance - Shipping logs https://landing.google.com/sre/book/chapters/eliminating-toil.html
17. @srhtcn
18. @srhtcn Economics - No payment for idle time or hosting - Easy to get started - Faster time to market
19. @srhtcn What is NOT Serverless? S3, DynamoDB, OpenShift, Fargate NoOps Silver bullet
20. @srhtcn Which services are Serverless? AWS Lambda Azure Functions IBM Cloud Functions Google Cloud Functions
21. @srhtcn Serverless vs. Easy to use Inexpensive Low maintenance Event driven apps working best with other cloud services Containers More suitable for complex apps with enterprise roots More control over the environment Long running apps More mature tooling
22. @srhtcn AWS Lambda
23. @srhtcn
24. @srhtcn How it works?
25. @srhtcn How it works internally? https://engineering.opsgenie.com/what-is-different-in-the-serverless-world-b9e0f68de191
26. @srhtcn Language support Node.js (JavaScript) Python, Java (Java 8 compatible), C# (.NET Core) Golang
27. @srhtcn Pricing You choose memory size % of CPU core and network capacity increases proportionally with memory More memory doesn’t always mean you pay more
28. @srhtcn https://www.slideshare.net/ChrisMunns/aws-startup-day-boston-2018-the-best-practices-and-hard-lessons-learned-of-serverless-applications
29. @srhtcn Pricing
30. @srhtcn Pricing
31. @srhtcn Supported event sources 20 different services can trigger AWS Lambda functions including. Event sources that aren't stream-based: Synchronous invocation: AWS SDK, Cognito, Alexa, API Gateway Asynchronous invocation: S3, SNS, CloudWatch logs, CloudWatch events Poll-based (or pull model) event sources that are stream-based: Kinesis, DynamoDB Streams, Poll-based event sources that are not stream-based: SQS
32. @srhtcn Scaling Most of the time, no need to deal with scalability There are two limits you need to be aware of: - Concurrent execution limit - Function level execution limit Set proper timeouts to your functions
33. @srhtcn Deployment Zip and upload Use tools like SAM, Serverless.js Blue-green or canary releases are easy
34. @srhtcn Logging Easy to write logs to CloudWatch just write console log Log group per function and log stream per container under log group Consider CloudWatch cost Stream logs to other services such as Elasticsearch for more advanced capabilities
35. @srhtcn Monitoring Metrics like invocations, errors, throttles, ConcurrentExecutions etc. Cloudwatch logs for custom monitoring data X-Ray for distributed tracing Thundra!!!
36. @srhtcn Determine the latency in different levels Automatic instrumentation GC, Thread counts & durations, CPU usage details Get the stack trace in case of an error and drill down See logs, traces, and metrics in one view What we needed was
37. @srhtcn Config Management Environment variables are easy to use For secrets encrypt with KMS Centralized config management with SSM Parameter Store
38. @srhtcn Testing Write unit tests as always More focus on integration tests Test locally with SAM CLI (Public Beta)
39. @srhtcn Security Functions are in isolated environment, with its own resources and file system view Code is in Amazon S3 and encrypted at rest Leverage full power of IAM roles Not recommended but you put your functions in a VPC
40. @srhtcn Handling errors Depends on the trigger type. Sync: handle on client side Async: Non-stream: retry a few times with delays. If doesn’t work, put data in DLQ Stream: retry until succeeded or data expires
41. @srhtcn Limitations
42. @srhtcn
43. @srhtcn
44. @srhtcn Toolkit around AWS Lambda Orchestration: Step Functions Deployment: SAM, Serverless.js, CloudFormation, Apex, Terraform Monitoring: X-Ray, Thundra Marketplace: AWS Serverless Application Repository
45. @srhtcn AWS Lambda at OpsGenie AWS Lambda with Java 8 DynamoDB SQS SNS VPC Serverless.js
46. @srhtcn Alert Enrichment
47. @srhtcn DynamoDB Cross Region Replication
48. @srhtcn DynamoDB Auto Scale
49. @srhtcn Service and Incident Management
50. @srhtcn Demo: Create Alerts from Slack Messages Source: https://github.com/opsgenie/slack-to-opsgenie-alert-creator
51. @srhtcn Follow these awesome folks and blogs engineering.opsgenie.com opsgenie.com/resources @swardley @chrismunns @theburningmonk
52. @srhtcn Thank you for listening! twitter.com/srhtcn linkedin.com/in/serhatcan medium.com/@serhatcan engineering.opsgenie.com