1. The document discusses using a serverless architecture to build a reservation itinerary application for a hospitality group managing 7500 properties worldwide. 2. Key parts of the serverless solution include using AWS Lambda, Kinesis, DynamoDB, API Gateway and other services to process reservation data from multiple sources and expose APIs for mobile and web clients. 3. Challenges in the serverless implementation included unpredictable logging in CloudWatch, performance issues with Java SDK and DOM parsers, and ensuring data consistency when storing logs in DynamoDB. These were addressed through alternative approaches.

1. Learning
Serverless Use Cases
Best Practices

2. Why
Are We
Here?

3. Architecture
Computing
Framework
Serverless

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.