4 Key takeaways from running Serverless on production for 4 years

Serverless is everywhere nowadays. Many companies already adopted Serverless for simple automation tasks but many more are looking to go even further. At Atlassian’s Opsgenie, we use Serverless, specifically AWS Lambda, for various use-cases since its first release. We even had a spin-out product out of it – called Thundra.io! In this talk, I share 4 key takeaways out of this 4 years journey and give some real-life examples

Transcript

1. 4 Key takeaways from running Serverless on production for 4 years SERHAT CAN | @SRHTCN TECHNICAL EVANGELIST | ATLASSIAN | AWS COMMUNITY HERO
2. @SRHTCN
3. @SRHTCN
4. @SRHTCN WHY > WHAT
5. @SRHTCN There is great inefficiency in how we operate software today. WHY SERVERLESS?
6. @SRHTCN WHY SERVERLESS? Idle computing resources Developer productivity There is great inefficiency in how we operate software today.
7. @SRHTCN Opsgenie’s Journey
8. @SRHTCN
9. @SRHTCN We adopt AWS fully managed services as much as possible
 Your time is priceless, don’t spend on anything that is not going to help you win!
 You cannot have experts in every area in team You don’t have time to become on expert on everything. DynamoDB, SQS, Lambda, RDS Aurora, EC2, ELB, ALB, Route53, Kinesis, SNS and a lot more…
10. @SRHTCN 2015 Writing small scale custom integrations At this point, we started leveraging AWS Lambda to help our customer run custom code Opsgenie’s Serverless journey
11. @SRHTCN 2015 Writing small scale custom integrations At this point, we started leveraging AWS Lambda to help our customer run custom code Opsgenie’s Serverless journey First production usage Started using AWS Lambda for leveraging async / not business critical jobs such as DynamoDB autoscale 2016
12. @SRHTCN 2015 Writing small scale custom integrations At this point, we started leveraging AWS Lambda to help our customer run custom code Opsgenie’s Serverless journey First production usage Started using AWS Lambda for leveraging async / not business critical jobs such as DynamoDB autoscale 2016 Service and Incident Management A new customer facing feature running on AWS Lambda integrated with the rest of the code base. 2017
13. @SRHTCN 2015 Writing small scale custom integrations At this point, we started leveraging AWS Lambda to help our customer run custom code Opsgenie’s Serverless journey First production usage Started using AWS Lambda for leveraging async / not business critical jobs such as DynamoDB autoscale 2016 Service and Incident Management A new customer facing feature running on AWS Lambda integrated with the rest of the code base. 2017 A Spin Off: Thundra Observability for AWS Lambda 2018
14. @SRHTCN Key Takeaways
15. @srhtcn Takeaway 1: Serverless doesn’t remove the need for great engineers.
16. @srhtcn https://theburningmonk.com/2016/12/yubls-road-to-serverless-architecture-part-1/
17. @srhtcn There is a learning curve for going fully Serverless img source: http://jeremykao.com/embrace-the-learning-curve/
18. @SRHTCN
19. @srhtcn • Event driven everything! • Inter-function communication is complex • Functions should be idempotent • Stateless with a twist • Even milliseconds matter Serverless doesn’t remove the need for great engineers
20. @srhtcn Takeaway 2: Serverless is LessOps, not NoOps.
21. @srhtcn $40.000 incident
22. @srhtcn Lessons learned: $40.000 incident • Avoid infinite retries • Monitor and alert for pricing 
 (no pricing metric for AWS Lambda)
 • Think of Cloudwatch cost and sample logs & metrics
23. @srhtcn Serverless is LessOps, not NoOps • Build delivery pipeline and deployment strategy • Cold starts (VPC affect is about to be history!) • Infinite scale but not really! • Monitoring has to be a first-class citizen
24. @srhtcn Fixing “it is slow” is harder in AWS Lambda • Too many moving pieces • No way to attach an agent • Even how to send the monitoring data is a discussion point
25. @srhtcn Takeaway 3: Serverless is “usually” cheaper.
26. @srhtcn Dynamo cross-region replication
27. @srhtcn Serverless is usually cheaper, event at scale • Free tier and 100ms based pricing • Finding good engineers is hard, keeping them is harder • Total cost of ownership • No initial investment (just code, less ops) • Less maintenance cost • Engineering workforce cost • You are probably not Spotify or Netflix, even they…
28. @srhtcn Takeaway 4: Serverless isn’t just for 
 a couple of use-cases.
29. @srhtcn Create alerts from Slack messages
30. @srhtcn Dynamo auto-scale and table migration
31. @srhtcn Service and incident management
32. @srhtcn Serverless computing isn’t just for a couple of use-cases • FaaS is great for connecting stuff on the cloud • If it is event-driven, it can be done with FaaS / Serverless • There is support for bring your own language • API Gateway has websocket support though! • Remember: The goal is not to use Serverless. Use a more specific service if exists. Focus on creating customer value faster. • Commonly used for data and stream processing, ETL jobs, building APIs…
33. @srhtcn Plus: Vendor lock-in is often a myth.
34. @srhtcn
35. @srhtcn Takeways 1. Still need great engineers 2. LessOps, not NoOps 3. Cheaper, even at scale 4. Can do many use-cases
 + Vendor lock-in is often a myth
36. @srhtcn Customers don’t care if you run on bare metal, VMs, containers, functions or whatever… They care if your solution helps them. They care if your service is always-on, fast and user-friendly. They care if you deliver what they want fast.
37. @srhtcn Serverless computing will become the default computing paradigm of the Cloud Era. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf
38. Thank you! SERHAT CAN | @SRHTCN TECHNICAL EVANGELIST | ATLASSIAN | AWS COMMUNITY HERO