Serverless design considerations for Cloud Native workloads
Download as PPTX, PDF0 likes99 views
We have built a news website with more than a billion views per month and we are sharing the learnings from that experience covering Serverless architectures, Design considerations, and Gotchas.
More Related Content
What's hot (12)
Similar to Serverless design considerations for Cloud Native workloads (15)
Recently uploaded (20)
Serverless design considerations for Cloud Native workloads
- 1. Cloud Security Automation| | Advanced ServerlessApplicationArchitectureand Design Considerations DILIPKUMARKOLA,Co-founderandCTO, Tensult | 24th April2019
- 2. What is Serverless? • Serverless is, running the workloads on the Cloud without thinking about servers. • Examples: • Hosting an angular frontend website on AWS S3 bucket. • Implementing a backend API using AWS API Gateway, AWS Lambda and AWS DynamoDB. • Processing files when they get uploaded to AWS S3 bucket. • Send notifications to users using AWS SES when you sign up on the website. • And these are just a very few examples.
- 3. Why Serverless? Scalability AutomationFaster DeploymentsReduces Cost Low Maintenance
- 4. Large Scale multi-lingual news website 100% Serverless on AWS <12 months from concept to production CaseStudy News Website
- 5. 1 DevOps Engg >1 Bn Page Views per month 60 Mn Monthly Active Users 7 languages
- 6. CMS Architecture Authorization of backend users Cognito User Pool CMS Application API Gateway CMS API CloudFront Cognito Identity Pool S3 DynamoDB Lambda Elastic Search Populating to ES to enable search Lambda S3 Sitemaps and RSS feeders CMS User For storing photos and videos
- 7. News Website Architecture API Gateway Website API CloudFront DynamoDB Elastic Search S3 Web User Sitemaps and RSS feeders News Data Retrieval
- 8. NewsletterArchitecture CloudWatch Rule Fetch Newsletter Template S3 Cache Elastic Search Fetch List of Users Send Newsletter SES SNS Send Token to fetch next User List Newsletters Function Lambda
- 9. How Does AWSLambdaWork? • Function as a Service from AWS. • Upload function code written in • NodeJS, Java, Python, Go, Ruby, .Net etc. • Lambda creates a docker image and executes them • Automatically scales based on the requests. • Supports Pull and Push models. • In Pull model, the Lambda trigger reads the events from streams and processes them. • In Push model, we need to call Lambda function directly using API (API Gateway) • Billing is based on the memory allocated and duration of execution.
- 10. Key Aspects in Design
- 11. Lambda DesignConsiderations • Avoid loops in Data flows • Remember about Cold Starts • Avoid duplication of code • Add caching where possible • Tune the function configuration • Use versions and aliases • Treat global variables as constants • Know what you are logging
- 12. AWS Lambda scales very fast so if there is any loop in the data flow then it will keep on creating new containers to handle the new requests leading the bill to shoot up very fast so before deploying any serverless solution first fully understand the data flow and make sure there are no loops. • To detect loops keep monitoring • Invocation count • Billing Avoidloops inthe Data flows S3 Lambda Store thumbnails images Generate thumbnails
- 13. • AWS Lambda takes some time to start the first container and also the container will be removed when it idle some time. • Solution: • We can keep calling the AWS Lambda function every one minute using AWS CloudWatch event rules. • Refactor the function code to start faster by lazily loading the components. RememberaboutCold Starts CloudWatch Rule Lambda Pinger
- 14. Avoidduplication of code • It is a common danger in FaaS or microservice implementations as there are many decoupled components so developers tend to duplicate the same code at multiple places and this can become really unmanageable. • Define common code as libraries and reuse them in various functions and microservices. • Incase of NodeJS environment, we can refer common libraries as dependencies using local directory paths. • AWS Lambda service provides a feature called Layers in order to share the common code and libraries across multiple Lambda functions.
- 15. Addcaching where possible • AWS Lambda scales but there are limits and our limit is 2500 concurrent executions and we were hitting this limit and afterwards we added caching on top of the APIs. • When we send a push notification to our mobile users, we get more than 50K requests per second to our backend Lambda functions and AWS Lambda used to throttle us. • Then we restricted access to our API end points via CDN for mobile users as the requests are getting cached at CDN and only cache misses reaches to backend so considerably load is reduced on the backend Lambda functions. • So keep monitoring for throttles and errors.
- 16. Tune the function configuration • Memory determines both CPU and RAM allocated to function • Low memory doesn’t always means cost effective as it leads to low CPU, so requests might take more time leading to you paying even more. • Try different memory settings and analyze the request execution times then choose appropriate memory setting. • Don’t forget to tune this setting after every major update to the function.
- 17. Use versions andaliases • When updating the function make sure to create a new version. • This allows us to easily roll back the functions incase of failures. • We can also use aliases for A/B testing by pointing our APIs to a different alias. • Be aware of limits on storage and then decide the number of versions needed. Source
- 18. Treatglobal variablesas constants • AWS Lambda cache all the global variables and context across the requests so we can't change the global variables while requests are processing. If we do that then the data might get corrupted. • Solution: • Code review before deploying the functions to Lambda. • Do thorough testing in dev/staging environments before pushing functions to prod environment.
- 19. Know what you arelogging • Lambda integrates with CloudWatch for logs and CloudWatch provides good searching features but ingestion cost is high, so in the production only log warnings and errors. • Set retention for logs appropriately, by default logs in CloudWatch service are retained forever but that may not be necessary for business case. • In case you need to keep logs for a very long time for compliance reasons then move them to S3/Glacier services.
- 20. AboutUs • Founded in 2017, Tensult is a Technology Consulting Company for the cloud • Started by passionate, ex-AWS people who brings in-depth cloud knowledge and expertise • Automation First approach • 20+ Happy Customers
- 21. Thank You Sample our work Questions? Drop us a note at [email protected] https://github.com/tensult https://blogs.tensult.com Follow us https://linkedin.com/company/tensult https://twitter.com/tensultdotcom