More Related Content
Similar to Serverlessusecase workshop feb3_v2 (15)
Recently uploaded (20)
Serverlessusecase workshop feb3_v2
- 1. Learning Serverless Use Cases Best Practices
- 4. Why Serverless? It is a modern approach to develop web applications enabling the developers to concentrate on code and deliver quickly. It provides decreased time to market and faster software release. Welcoming and active community • Your are not alone! Reduced costs and Pay as you go • Let’s take a look at a real world cost comparison: • This is a production web application with 16000 requests a day (average response time is 200ms): • Two EC2 instances → $2.97 / day • Serverless architecture → $0.05 / day • Lower operational Costs. “There is no server better than no server” – Werner Vogels, CTO Amazon
- 5. No server administration • Just write your code and you’re good to go. • Simplifies packaging and deployment and requires no system administration. • No server upgrades or adding new servers. Monstrously scalable • Your web application scales according to the needs.
- 6. Enterprise Using Serverless and many more...
- 7. Serverless Architectures: Serverless Architecture refer to applications that significantly depend on third-party services (knows as Backend as a Service or "BaaS") or on custom code that's run in ephemeral containers (Function as a Service or "FaaS") Serverless Computing: Serverless Computing is a cloud computing execution model in which the cloud provider dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. It is a form of utility computing. Serverless Framework: Serverless Framework is your single toolkit for deploying serverless architectures Definition's
- 8. An application for which you provide only the application logic that is executed on an infrastructure you don’t manage 1. Serverless refers to Serverless applications. 2. Serverless applications are ones that don't require you to provision or manage any servers. Serverless
- 9. Evolution of Serverless Physical Hardware OS Run Time Code Hardware OS Run Time Code Hardware OS Run Time Code Hardware OS Run Time Code Virtual Container Serverless
- 10. Various Serverless Platform Apache Openwhisk Serverless Platform Google Cloud Functions AWS LambdaAzure Functions
- 11. WEB Applications • Static Websites • Complex Web apps • Packages for Express Backends • Apps and Services • Mobile • IoT Data Processing • Real time • MapReduce • Batch Chatbots • Powering Chatbot Logic Amazon Alexa • Powering Voice enabled apps • Alexa Skill Kit IT Automation • Policy Engines • Extending AWS services • Infrastructure management Common use cases
- 12. Use Case Reservation Itinerary Application For Hospitality group managing hotels and Resorts worldwide 1. Develop secure and scalable application to process reservation data for 7500 properties around the world. 2. Ingest 100,000 messages per day from third party system and should be scalable to 375,000 messages. 3. Application should be able to digest data from existing legacy application during the migration of properties. 4. Migrate the existing EDW to AWS ( 2year worth data around 90 Million unique reservations) 5. Security controls for PII compliance data. 6. Expose API to fetch reservation itinerary for 3rd party application and Mobile application. Timeline – 3 months. Development Team size – 3 Testing Team size - 2
- 13. Choosing the serverless platform.
- 14. XML Msgs APP 3 EW D On Premise System External Source Kinesis HTNG Msgs APP 1 Dynamo DB Cloud watch logs APP 4 APP 2 Aurora Cloud Formation Bit Bucket REST Server- 1 APP 1 Custom Auth Mobile client AWS IAM REST Server-2 APP 1 Web Client Amazon Glacier Dynamo DB Solution Architecture
- 15. External Source Kinesis APP 1 Dynamo DB Amazon Glacier HTNG 1. Archive and Extract details form the HTNG messages (reservation itinerary) received from 3rd party system. 2. Store the extracted details to the Aurora DB and DynamoDB for further processing. 3. Ensure adequate security measures for the stored and retrieved messages Third party integration Design pattern used –AWS: Stream Processing
- 16. Process messages (reservation itinerary) received from On-premise /Legacy system, based on the XML data mapping and extract the details. Move the extracted details to DynamoDB for further processing. Cloud Formation Cloud watch Msg 1 APP 1 Dynamo DB EWD On Premise System Bit Bucket Legacy / On premise integration Design pattern used –AWS Event-driven data processing.
- 17. Process to read lambda Cloud watch logs and update Audit DynamoDB using request ID and sequence number. Cloud Formation Cloud watch Dynamo DBLambda Bit Bucket Cloud watch Monitoring and Auditing Solution Design pattern used:-Event Driven Automation
- 18. Build API’s to fetch Reservation Itinerary details for the mobile application. Use custom authentication. Dynamo DB REST Server- 1 APP 1 Custom Auth Mobile client API for Legacy Mobile Application Design pattern -AWS: Web Applications
- 19. API’s to fetch Reservation Itinerary details for the third party web applications. Dynamo DB AWS IAM REST Server-2 APP 1 Web Client API for Web Application Design pattern -AWS: Web Applications
- 20. The estimated time to load all 90 million unique reservation to DynamoDB using AWS kinesis and lambda was 90 days. EMR was used to load the EDW data to AWS. The data load process was completed in 3 hours. Migrating Existing EDW to AWS EDW EMR JarHistory BucketLanding server and fire hose agent
- 21. • Lower cost due to the event based triggering of Lambda. • Server-less architecture and highly scalable and reliable. • The time taken to process the record is in milliseconds. • Async behaviour of Lambda function written in NODE JS, gives better performance and lower cost. • Logging, caching and throttling of the incoming API Request are taken care by API Gateway. • Dynamodb offers flexibility of increasing and decreasing throughputs based on the demands. • Un-authorized access of the AWS Resources are ensured using AWS IAM. Key Benefits
- 23. • Performance testing is the key for ensuring you pick the optimum memory size configuration. • Load test your Lambda function to determine an optimum timeout value. • Test with different batch and record sizes. • Test with different compute allocations. • Lambda functions exist in one of two states: cold or warm. Testing is the key to success
- 24. Package Size and Language Selection Lower startup time Package what is required and keep the deployment pack small. The underlying runtimes for both Python and NodeJS are faster than Java/C#.
- 25. Logging Lambda uses basic logging facilities (e.g. console. WriteLine), which end up in Cloudwatch. Leverage your logging library and lambda metrics & Dimensions to log app errors. (ERR ,ERROR ,Warning ,etc.) Note:- There is no SLA/guarantee when (or if) Lambda logs will appear in Cloud watch. Overall package size and start-up time appear to influence this. Latencies of up to 30 minutes have been observed.
- 26. Use AWS lambda metrics and cloud watch alarms. • At a minimum, monitoring and alerting thresholds should be setup for any business critical functionality: Throttling (exceeding concurrency) Failures Max execution duration. IteratorAge Alarms and Metrics
- 27. Note:- AWS Lambda currently does not log errors to CloudWatch Logs that are caused by insufficient ENIs or IP addresses. Concurrency and Accessing VPC Resources Lambda concurrent calls is limited by the number of free IPs in the subnets associated with that function or ENI’s. ENIs capacity = Projected peak concurrent executions * (Memory in GB / 3GB)
- 28. • Issue in processing the logs in Cloudwatch • Cloud watch JSON log order is not sequential and it is unpredictable. These cloud watch logs are processed, to store the lambda execution details in audit dynamo db. Due to the unpredictable behavior of cloudwatch logs, there is inconsistency in the data stored in audit table. Unable to save records based on the order of the incoming messages(i.e. Sequence number). Solution: • Each Cloudwatch log can be arranged based on request Id. So the details are stored in the dynamodb using the Request Id as primary key. Sequence number is made as GSI in Dynamodb for further processing. Challenges Faced
- 29. • Challenges in using Java SDK for lambda implementation. • Lambda function using AWS Java SDK has higher execution time, as the JVM load time is high. This impacts the performance of the function. Solution: • As Node JS takes very less time to load, it can be used to implement the lambda functions. Moreover the async characteristic of Node JS improves the performance. • Performance degradation while using DOM Parsers in the message processing. • DOM parsers are used in Lambda to extract the message details from the incoming messages in the kinesis stream. But this impacts the performance by increasing the execution time. Solution: • Xpath has been used for the extraction logic implementation in Lambda Node JS functions. This takes very less time to parse the HTNG messages. Issues in processing the logs in Cloudwatch Challenges Faced
- 30. Netflix & AWS Lambda Case Study Uses AWS Lambda to build rule-based self-managing infrastructure and replace inefficient processes to reduce the rate of errors and save valuable time. 1. Encoding Media Files – events fires to track, aggregate, Validate, tag and publish. 2. Backup for Disaster Recovery – Cross region replication, offsite-site backup and validation (raise alarm in case of failure). 3. Security and conformity – validate new resources for tags and security and raise alarm if not compliant. 4. Dashboard and monitoring – constantly validating the infrastructure against expected configuration.