FaaS or not to FaaS. Visible and invisible benefits of the Serverless paradigm at DevOpsCon Berlin 2020
- 1. FaaS or not to FaaS Visible and invisible benefits of the Serverless paradigm by Christian Bannes and Vadym Kazulkin, ip.labs GmbH, 13.10.2020
- 2. Contact Vadym Kazulkin ip.labs GmbH v.kazulkin@iplabs.de @VKazulkin @ServerlessBonn (Meetup) Christian Bannes ip.labs GmbH c.bannes@iplabs.de xing.com/profile/Christian_Bannes https://www.linkedin.com/in/vadymkazulkin/ https://www.iplabs.de/
- 4. The Value Proposition of Serverless But let’s talk about of Total Cost of Ownership of the Serverless paradigm
- 5. TCO Full Picture No Infrastructure Operation and Maintenance Forrest Brazeal „The Business Case For Serverless” https://www.trek10.com/blog/business-case-for-serverless
- 6. No Infrastructure Maintenance Is infrastructure maintenance and operation your core competency ?
- 7. TCO Full Picture No Infrastructure Operation and Maintenance Auto Scaling and Fault Tolerance Built in Forrest Brazeal „The Business Case For Serverless” https://www.trek10.com/blog/business-case-for-serverless
- 8. Auto Scaling And Faul Tolerance Built In • Can you get capacity planning and auto scaling right? • Do you want to solve the hard problem of fault tolerance by yourself?
- 9. TCO Full Picture No Infrastructure Operation and Maintenance Auto Scaling and Fault Tolerance Built in Do more with less Forrest Brazeal „The Business Case For Serverless” https://www.trek10.com/blog/business-case-for-serverless
- 10. Do more with less By heavily relying on the managed Serverless services you • Need fewer engineers to start implementing your new product idea • Can do more with the same amount of people
- 11. TCO Full Picture No Infrastructure Operation and Maintenance Auto Scaling and Fault Tolerance Built in Do more with less Lower technical debt Forrest Brazeal „The Business Case For Serverless” https://www.trek10.com/blog/business-case-for-serverless
- 12. Lower technical debt • Whatever code you write today is always tomorrow’s technical debt © Paul Johnston • Less code means lower technical debt • Time and effort required for maintaining the solution over its whole lifecycle is by far much more than for developing it Jeff Atwood „The Best Code is No Code At All” https://blog.codinghorror.com/the-best-code-is-no-code-at-all/ Paul Johnston “Cloud 2.0: Code is no longer King — Serverless has dethroned it” https://medium.com/@PaulDJohnston/cloud-2-0-code-is-no-longer-king-serverless-has-dethroned-it-c6dc955db9d5
- 13. TCO Full Picture No Infrastructure Operation and Maintenance Auto Scaling and Fault Tolerance Built in Do more with less Lower technical debt Focus on Business Value and Innovation Forrest Brazeal „The Business Case For Serverless” https://www.trek10.com/blog/business-case-for-serverless
- 14. Focus On Business Value and Innovation Every organization wants exactly this!
- 15. TCO Full Picture No Infrastructure Operation and Maintenance Auto Scaling and Fault Tolerance Built in Do more with less Lower technical debt Faster Time to Market Forrest Brazeal „The Business Case For Serverless” https://www.trek10.com/blog/business-case-for-serverless Focus on Business Value and Innovation
- 16. Faster Time To Market • Time To Market is the key differentiator in today’s business! • Ask yourself: what is core for your business and what you can get as Commodity +(Utility) as a Service?
- 17. FaaS... …or not to FaaS ?
- 19. 1. Application lifecycle 2. Workloads 3. Programming Model 4. Platform limitations 5. Cost at scale 6. Organizational environment 7. Platform and tooling maturity Decision Checklist : understand your… Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 20. Understand Application lifecycle Christian Posta „Be as serverless as you can, but not more than that” https://blog.christianposta.com/serverless/its-not-about-microservices-vs-serverless/
- 21. Explore phase • Quickly validate hypotheses • Rapidly experiment • Run experiments as cheaply as possible Serverless is a perfect fit Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 22. Exploit phase • Built something that does provide customer value • Build it on scale • Build a profitable product around it partly serverless and partly not serverless architecture Image: Robert Scoble via Flickr Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 23. Application lifecycle • How much of my stack should I own to be able to deliver business value? • Outsource SLA, regulatory compliance, price, and roadmap to my service provider? Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 24. Existing applications • You can’t magically move that all off to service providers • You can try to modernize parts of them Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 25. Strangler Pattern • Add a proxy (API Gateway or Application Loadbalancer), which sits between the legacy application and the user • Add new services and link it to the proxy Marin Fowler „StrangerFigApplication” https://martinfowler.com/bliki/StranglerFigApplication.html Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 26. FinDev Concept Activity-based costing on a digital operation-by-operation basis • Figure out features which deliver business value comparing to their cost Aleksander Simovic & Mark Schwarz „FinDev and Serverless Microeconomics: Part 1” https://aws.amazon.com/de/blogs/enterprise-strategy/findev-and-serverless-microeconomics-part-1/ Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 27. 1. Application lifecycle 2. Workloads 3. Programming Model 4. Platform limitations 5. Cost at scale 6. Organizational environment 7. Platform and tooling maturity Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 28. Understand your workloads • Event-driven • API-driven • Batch Job • Internal Tool • ML/AI • Big Data Image: flickr.com/photos/everywhereatonce/294789504 Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 29. Lambda Layers & Lambda Runtime API Door opener for use cases like: • Big Data • ML/AI Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 30. A Shared File System for Your Lambda Functions Door opener for use case like: • ML/AI Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 31. Understand your workloads • Do we need to access specialized hardware ? • GPU access required? • Another RAM/CPU ratio? • Do we need constantly high performance? • Response time below 100 ms (e.g. bidding or gaming platforms) “A Berkeley View on Serverless Computing” https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.html
- 32. Understand your workloads • Do we need high throughput ? • Lambda‘s network bandwidth is limited (an order of magnitude lower than a single modern SSD) shared between all functions packed on the same VM “A Berkeley View on Serverless Computing” https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.html
- 33. Understand your workloads • Do functions need to communicate with each other? • functions are not directly network accessible, they must communicate via an intermediary service “A Berkeley View on Serverless Computing” https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.html
- 34. 1. Application lifecycle 2. Workloads 3. Programming Model 4. Platform limitations 5. Cost at scale 6. Organizational environment 7. Platform and tooling maturity Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 35. Understand FaaS programming model • Every function may fail and have to be retried • At-least-once (event) delivery Joe Hellerstein “The State of The serverless Art” https://medium.com/riselab/the-state-of-the-serverless-art-78a4f02951eb Requires code idempotency • Difficult to be guaranteed • Shifts the complexity to the developers
- 36. 1. Application lifecycle 2. Workloads 3. Programming Model 4. Platform limitations 5. Cost at scale 6. Organizational environment 7. Platform and tooling maturity Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 37. Understand platform limitations • Cold start • Lambda with and without VPC for each runtime Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 38. Provisioned Concurrency for Lambda Functions Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 39. Further cold starts reduction options • For Java language with high startup time and high memory footprint • Use Ahead-Of-Time-Compiler (AOT) (part of GraalVM) • Use frameworks like Micronaut, Quarkus or Spring Boot which offer support for GraalVM “A Berkeley View on Serverless Computing” https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.html
- 40. Jeremy Daly: “Mixing VPC and Non-VPC Lambda Functions for Higher Performing Microservices” https://www.jeremydaly.com/mixing-vpc-and-non-vpc-lambda-functions-for-higher-performing-microservices/ Vadym Kazulkin @VKazulkin , ip.labs GmbH Lambda behind the Virtual Private Cloud (VPC)
- 41. Lambda in VPC: • The network interface creation happens when Lambda function is created or its VPC settings are updated. • Because the network interfaces are shared across execution environments, only a handful of network interfaces are required per function • Reduced the cold start from approx. 10 seconds to below 1 second Chris Munns: "Announcing improved VPC networking for AWS Lambda functions” https://aws.amazon.com/de/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/
- 42. Amazon Aurora Serverless Data API as beta for MySql and Postgres available https://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/data-api.html Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 43. Don‘t be scared of cold starts To avoid cold starts them completely, you have to : • Overpay • Overprovision Cold starts don’t really matter if the you make the call asynchronously Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 44. Understand platform limitations • Cold start • Lambda with and without VPC for each runtime • Invocation duration/timeouts • Lambda 15min • API Gateway integration 29sec • Max Memory • Lambda 3GB Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 45. Understand platform limitations • Max concurrent invocations • Soft limit of 500-3000 parallel executions for all Lambdas in each AWS account • Max connection limit for RDS • Use RDS-Proxy (supports RDS for MySQL and Aurora with MySQL compatibility) • Use Data API for Aurora Serverless • Use NoSQL database Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 46. 1. Application lifecycle 2. Workloads 3. Programming Model 4. Platform limitations 5. Cost at scale 6. Organizational environment 7. Platform and tooling maturity Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 47. The reality is… Lambda is often just a small percentage of your total cost Vadym Kazulkin, @VKazulkin
- 48. $ 3.50 Per million API calls API Gateway Vadym Kazulkin, @VKazulkin
- 49. HTTP APIs in Beta 70% cheaper as API Gateway • Fewer configuration options • Well-suited for most use-cases
- 50. DynamoDB On-Demand Image: https://aws.amazon.com/blogs/aws/amazon-dynamodb-on-demand-no-capacity-planning-and-pay-per-request-pricing/ Vadym Kazulkin, @VKazulkin
- 51. Provisioned vs On-Demand • Use On-Demand for spiky workloads • Use Provisioned for constantly high workload Vadym Kazulkin, @VKazulkin
- 52. Understand your cost at scale • Lambda • API Gateway • Dynamo DB capacity choices • Logging costs • Monitoring costs Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 53. Understand your cost at scale • Data transfer costs • X-Ray • Step functions • Caching costs (API Gateway, AppSync, DAX for Dynamo DB) • Remote API calls • 3rd party services price models Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 54. 1. Application lifecycle 2. Workloads 3. Programming Model 4. Platform limitations 5. Cost at scale 6. Organizational environment 7. Platform and tooling maturity Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 55. Understand organizational environment (structure, reponsibilities, knowledge, culture) • Do you already embrace DevOps best practices? Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 56. Tom McLaughlin Talk: What do we do when the server goes away? • Monitoring & Alerting • Chaos Engineering & Game Days • Infrastructure as Code & Testing • Help understand constraints of AWS services & choose the right one Tom McLaughlin „What do we do when the server goes away” https://speakerdeck.com/tmclaugh/serverless-devops-what-do-we-do-when-the-server-goes-away Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 57. Help understand constraints of AWS services & choose the right one. Example Event Sources: Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 58. Event Sources • SQS and SNS are charged for requests • Kinesis charges for shard hours & PUT requests Image: https://blog.binaris.com/lambda-pricing-pitfalls/ Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 59. Event Sources • Cost for Kinesis grows with slower rate • Attractive at to operate at scale Image: https://blog.binaris.com/lambda-pricing-pitfalls/ Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 61. Co-evolution of practices with Serverless 1/2 • True DevOps (even DevSecOps) • FinDev responsibilities in the teams • Complete infrastructure automation • Chaos Engineering Sheen Brisals “Why the ‘WHY’ matters more than the ‘WHAT’ in Serverless!” https://medium.com/lego-engineering/why-the-why-matters-more-than-the-what-in-serverless-2ef56c397962 DevOps Topologies: https://web.devopstopologies.com/
- 62. Co-evolution of practices with Serverless 2/2 • Each developer can get its own (AWS test) account • No local testing environment or only for quick functional tests • Testing in production Michael Bryzek “What do you know about testing in production?” https://www.youtube.com/watch?v=z-ATZTUgaAo
- 63. 1. Application lifecycle 2. Workloads 3. Programming Model 4. Platform limitations 5. Cost at scale 6. Organizational environment 7. Platform and tooling maturity Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 64. Serverless platform and tooling maturity • Infrastructure-as-a-Code solutions maturity (e.g. Cloud Formation, CDK, Terraform) • Development environment & framework maturity (e.g. AWS SAM, AWS Amplify, Serverless Framework) Image: http://tea.solgenomics.net/anatomy_viewer/microscopy/slm82_fruit Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 65. Serverless platform and tooling maturity • CI/CD • Observability (Logging, Monitoring, Tracing) • Alerting • Security • Integration with 3rd party SaaS Image: http://tea.solgenomics.net/anatomy_viewer/microscopy/slm82_fruit Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 66. Recent CloudWatch Improvements • Search over multiple Log Groups became possible • CloudWatch Logs Insights • enables you to interactively search and analyze your log data in Amazon CloudWatch Logs • Embedded Metric Format • JSON specification used to instruct CloudWatch Logs to automatically extract metric values embedded in structured log events.
- 67. • Application lifecycle • Workloads • Programming Model • Platform limitations • Cost at scale • Organizational environment • Platform and tooling maturity FaaS or not to FaaS Christian Bannes and Vadym Kazulkin @VKazulkin , ip.labs GmbH
- 68. Contact Vadym Kazulkin ip.labs GmbH v.kazulkin@iplabs.de xing.com/profile/Vadym_Kazulkin @VKazulkin @ServerlessBonn (Meetup) Christian Bannes ip.labs GmbH c.bannes@iplabs.de xing.com/profile/Christian_Bannes
- 70. Thank You!