Going Serverless on AWS
0 likes261 views
This document discusses the threats and opportunities of going serverless on AWS. It covers limitations on deployment package sizes for Lambda functions, how Firecracker is used to power Lambda, and that serverless may be cheaper but not necessarily simpler due to underlying complexity. It also discusses development patterns like microservices and monolithic approaches. Frameworks like AWS SAM and the Serverless Framework are presented. Considerations around infrastructure setup, local development environments, security, logging/tracing, and loss of control are also covered. Opportunities of serverless like automated infrastructure management and cost/time savings are highlighted.
Going Serverless on AWS
- 1. Going serverless on AWS The Threats and Opportunities of Going Serverless Valentyn Nastenko [email protected]
- 2. Figleaf The choice to be private is all yours. https://figleafapp.com
- 4. Development environments: Limitations > aws lambda update-function-code --function-name limits-test --region us-east-1 --zip-file fileb://./50MB.zip An error occurred (RequestEntityTooLargeException) when calling the UpdateFunctionCode operation: Request must be smaller than 69905067 bytes for the UpdateFunctionCode operation >aws lambda update-function-code --function-name limits-test --region us-east-1 --s3-bucket limits-test-foobar-bucket --s3-key 250MB.zip An error occurred (InvalidParameterValueException) when calling the UpdateFunctionCode operation: Unzipped size must be smaller than 262144000 bytes In practical terms, this means that the size of your deployment package’s zip file would be around 100 MB—assuming a deflation of 40%.
- 5. MicroVM: Firecracker Remember that it’s Lambda’s prerogative to create a new container. You shouldn’t expect your function to run on a warm container; you should just be happy when it does. .@awscloud uses #Firecracker to power #Lambda, where it replaced EC2 to host #serverless compute jobs. With a boot time of .125 microseconds, this runtime can fire up 150 Micro-VMs/sec -- Holly Mesrobian
- 6. Serverless is cheaper, not simpler Take the canonical HelloRetail serverless project code and inspect how much complexity is left-out. The “project”, the services’ dependencies on PaaS and each other, the deployment order, event types and schemas and many more are not covered by the framework. They are partially scripted, partially documented, but mainly residing in the heads of the “uber-architects” or as tribal knowledge (which, in software, is also known as “trouble knowledge”).
- 7. Development environments: Patterns 1. Microservices Pattern Benefits of Microservices Pattern: ● Total separation of concerns. Each job/operation is in a separate unit of deployment (i.e., a separate Lambda function), allowing you to modify your application’s components individually, without affecting the system as a whole. This is a very agile and safe pattern, especially in production. ● Each Lambda function handles a single event making your functions easy to debug, since there is usually only one expected outcome. ● This separation of concerns is also great for autonomous teams. They can push functionality into production independently. Drawbacks of Microservices Pattern: ● You will end up with a lot of functions, which is harder to manage and can result in a lot of cognitive overhead. Lambda functions tend to be more granular than traditional microservices, so be ready for a lot of them! ● Performance could be slower. When functions handle a single job, they are called less, resulting in more cold starts. ● Deployments will be slower, since multiple functions have to be provisioned. ● You could reach the CloudFormation template file size limit quickly, especially if you’re using custom resources.
- 8. Development environments: Patterns 2. Services Pattern Benefits of Services Pattern: ● This will result in less Lambda functions that you need to manage. ● Some separation of concerns still exists. ● Teams can still work autonomously. ● Faster deployments. ● Theoretically better performance. When multiple jobs are within a Lambda function, there is a higher likelihood that Lambda function will be called more regularly, which means the Lambda will stay warm and users will run into less cold-starts. Drawbacks of Services Pattern: ● Debugging gets slightly more complicated, since the Lambda function is handling multiple jobs, and has different outcomes. ● Requires creating a router to call the right logic based on the request method or endpoint. ● Bigger function sizes due to putting multiple operations within the same Lambda function.
- 9. Development environments: Patterns 3. Monolithic Pattern Benefits of the Monolithic Pattern: ● A single Lambda function is much easier to comprehend and manage. It’s more of a traditional set-up. ● Fast deployments, depending on the total code size. ● Theoretically faster performance. Your single Lambda function will be called frequently and it is less likely that your users will run into cold-starts. Drawbacks of the Monolithic Pattern: ● Requires building a more complex router within your Lambda function and ensuring it always directs calls the appropriate logic. ● It’s harder to understand performance. The Lambda function will run for a variety of durations. ● You can easily hit the Lambda size limit in real world practical applications due to the larger function size.
- 11. Development environments ● Open Source Framework ● No CloudFormation ● Supports other platforms as well ● Takes care of nasty deployment things ● Support offline mode ● Extend the Serverless Framework with community driven plugins ● Huge community
- 13. Developers will need to devop
- 14. Development environments: Local Development
- 15. Security 1. Event-data injection, leading to OS command injection 2. Improper exception handling and verbose error messages, leading to sensitive information disclosure 3. Insecure Serverless Deployment Configuration, leading to sensitive data exposure 4. Over-privileged function permissions & roles, leading to DB data leakage and S3 bucket data tampering 5. Inadequate function monitoring and logging- the application doesn't properly log application layer attacks and errors 6. Insecure 3rd Party Dependencies 7. Application layer Denial of Service 8. An undisclosed *critical* issue, as a bonus! https://github.com/OWASP/Serverless-Goat
- 16. Security: FunctionShield “All serverless developers should use FunctionShield as part of every new function they develop” (Yan Cui, Principal Developer, DAZN)
- 18. Logging, error management and tracing Lightweight, agentless error monitoring for front-end, back-end, and mobile
- 19. Logging and tracing: X-Ray
- 20. Loss of control
- 21. Loss of control AWS's S3 outage was so bad Amazon couldn't get into its own dashboard to warn the world For S3, we believe we understand root cause and are working hard at repairing. Future updates across all services will be on dashboard. — Amazon Web Services (@awscloud) February 28, 2017 I can't change my mouse sensitivity because @razer @razersynapse servers are down 🙄 cc @internetofshit — Callum Mellor-Reed (@callummr) February 28, 2017 Joys of the @internetofshit - AWS goes down. So does my TV remote, my light controller, even my front gate. Yay for 2017. — Brian (@Hamster_Brian) February 28, 2017
- 22. Loss of control
- 23. Loss of control
- 24. Opportunities: ● Automated Infrastructure Management: An entire chain of manual infrastructure management processes is eliminated as users no longer need to coordinate and manage resource for increasingly distributed software components that constitute modern apps. ● Cost and Time Saving: The operational costs and time is reduced as no system administration processes are required to package and deploy the apps. ● High Scalability and Optimized Resource Utilization: The cost barrier to scale apps is also reduced as serverless IT workloads don’t require dedicated resources. Every application request is met with continuous and independent scalability requirements, yet the users are charged only during the period that requests are served. ● Truly Agile Business Processes: Since the application deployment process is (apparently) decoupled from the underlying infrastructure, Agile and DevOps-driven organizations are can maintain flexible IT operations and business processes. The constraints due to hardware complexity and infrastructure configuration limitations have less impact and role in dictating IT- driven business operations or app functionality. Agile teams can aim for faster development sprints and deploy iterative improvements or changing app functionality with fewer constraints. ● Reliability and Performance: Services like AWS are inherently resilient and can guarantee performance SLAs most of the times. Serverless architecture offers the convenience of reducing the opportunities of hardware misconfigurations that potentially lead to performance degradation with traditional app deployment practices.
- 25. Thank you for your attention Valentyn Nastenko [email protected]://goo.gl/T3SqRy