Serverless computing provides several key benefits including no need to provision or manage servers, automatic scaling with usage, only paying for resources used, and built-in high availability and fault tolerance. Some common use cases for serverless include backend services and apps, data processing, voice and chat bots, and web applications. When building serverless applications, developers should consider factors like repository structure, cold starts, package size and dependencies, timeouts and errors, performance optimization, and security practices.

1. Serverless Computing & key Consideration
Anand Gupta
(Senior Solution Architect at Capgemini)
Linked in: https://www.linkedin.com/in/anand-gupta-415570160/

2. 01
03
04
05
07
08
09
10
What Is Serverless ?
Use cases
Patterns.
Communication Patterns.
Key Benefits of Serverless.
How does Functions-as-a-service
work?
Key Considerations and best practices.
Introduction
Agenda
02 Brief of Cloud Computing
06 Serverless Application & AWS Lambda

3. 3
Traditional way to
provide the
infrastructure
Data
Center
Provides CLI or API to
manage
infrastructure(AWS
EC2)
IAAS
Provides infrastructure
bases on developed
application (AWS
Beanstalk)
PAAS
Provides infrastructure
on demand when the
FaaS provider receive
the request(AWS
Lambda)
Serverless
Brief History of Cloud computing.

4. 4
No Server provision or manage
Scale with Usage
Never Pay for Idle
High Availability and fault tolerance built in
What is Serverless ?
Serverless is new set of emerging practices that'll change the way we build the application, it
brings more agility, cuts cost and enables more efficient application development. This seems like
a real fundamental shift the way we are building out application.

5. How does Functions-as-a-service Works?
/users
/orders
/catalogue
Host Instance Application
FaaS Platform
/users
/orders
/catalogue
/users
Traditional Computing Serverless Computing
Request: Many To One Instance
Instance
Request: One To One

6. 6
01
02
03
04
05
06
New Feature
Product engineers can innovate rapidly as serverless architecture has alleviated the problems of system engineering.
Thus, you spend less time on operational issues and can release new feature faster.
Pay for Use
With serverless, you only pay for what you use, there are no hardware costs and no costs when your services are not in
use, and you get away not paying anything when the application is not in use.
Deployment Package
Simplifies deployment and packaging, which eliminates the complex build and deploy process.
Resilience and Flexibility
Because Serverless is stateless, it is highly resilient when under load and in sub-optimal execution conditions.
Developer productivity
Smaller code, agile development and enables the developers to concentrate on code and deliver quickly.
No Server to provision
Eliminates the need of estimating what type of, and how many, resources our application requires also the process of
acquiring machine instances and setting them up ready for deployment
Key Benefits of Serverless Computing

7. 7
Serverless Application
Event Source Function Service
Changes in
data state
Changes in
Resources
state
Request to
end points
Node.js
Python
Java
C#
Go
Ruby
Runtime
API
Database
External endpoint

8. 8
Anatomy of AWS Lambda Function
Handler Function Event Object Context Object
Function to be executed
upon invocation
Data sent during Lambda
function invocation
Method available to interact
with runtime
information(request ID, log
group, more)
exports.handler = (event, context, callback) => {
// TODO implement
console.log("context object details");
console.log(JSON.stringify(context));
callback(null, “test response');
};

9. 9
Serverless Communication Patterns
Synchronous
(Push)
API
Gateway
/master
Asynchronous
(Event)
Stream
(Poll Based)
SQS
S3
Lambda function Lambda function
Events
Kinesis
DynamoDB
changes
Lambda function

10. 10
Design Pattern : API implementation
{….} https Endpoint
CloudWatch
Cognito(IDM)
/booking
IDM
MDM
Booking
API Gateway Service Database

11. 11
Design Pattern : Microservice Integration
{….} https Endpoint
Lambda
API Gateway
Amazon MQ
RDS
/payment
/orders
/loyalty
{….}
https private
Endpoint
{….} third party
https Endpoint
API Layer
Source System Message Broker & Listener Target System

12. 12
Design Pattern : Batch Job
Cloud Watch
Alarm
(time based) Step Functions
S3
/sendMail
Sendgrid
Lambda invoked when
scheduled time occurs
Scheduled Processor Internal Service

13. 13
BACKENDS
• Apps & services.
• Mobile
• IoT
DATA PROCESSING
• Real Time
• Map Reduce
• Batch
VOICE ENABLED SERVICES
• Powering Voice Enabled
Apps.
• Alexa Skill Kit
IT AUTOMATIONS
• Policy Engines
• Extending AWS
Services.
• Infrastructure
Management
WEB APPLICATIONS
• Static Web sites.
• API development
• API Integration
CHAT BOTS
• Powering chat bots.
Use cases

14. 14
1. Mono Repo 2. Repo per function
3. Repo per Group
/users
/orders
1. Key Consideration : Repository Structure
One Group of repo
should not have more
then 25 to 30 function
No Repo per function and
pipeline
Group the application
in function close to
functionality.
No mono repo.
1
2
3
4

15. 15
Download code
and
dependency
Create, setup
and start
new container
Runtime
Bootstrapped
Code execution
2.a Key Consideration : Cold Start
The Request Life Cycle
AWS Provider Optimization Dev team Optimization
Cold Start Time
Warm Start Time
Request Execution time

16. 16
Memory size
If you increase the memory, you will also get
more CPU, this memory balancing approach
will help to faster the start up time.
Runtime
Scripting languages (Python, Java script) perform
a lot better in startup time in comparison to
compiled runtimes (Java, .NET, C#).
Code package size
The larger the size, the more time it takes to
spin up a new container, avoid unnecessary
third-party libraries
Application initialization
If application is performing any task at startup, it will
add to cold start, try to load the resources lazily.
2.b Key Consideration : Cold Start Improve Startup Latency

17. 17
• Minimize your package
size.
• There is a hard limit of
50MB for compressed
deployment package.
Application Package Size
• Put your dependency(e.g.
jar files) in a separate
directory.
• An uncompressed(Layer)
AWS Lambda hard limit of
250MB.
Lambda Layer
• Stop reaching for 3rd
party dependencies and
rather build your own
serverless library.
3rd party dependencies
3. Key Consideration : Application Package and Dependency management

18. 18
API Gateway should have
mapping of error code to avoid
CORS error.
API Gateway Error Mapping
Follow the proper HTTP error
code.
Http Error Code
AWS API Gateway has a 29
second hard limit of timeout. Use
short timeout limits. set them at
3-6 seconds for API calls
API Gateway Timeout
Use global exception handler in
your code and do not allow
exception to propagate outside
of Lambda handler.
Global Exception Handling
Request and response
(synchronous calls) body
payload size can be up
to 6 MB.
Pay Load Size
Lambda time out limit is 15
minute, so do not perform long
job.
Lambda Timeout
4. Key Consideration : Exception Handling and timeout

19. 19
S
START UP
TIME
• Minimize the complexity of your
dependencies.
• Choose interpreted languages like Node.js or
Python over languages like Java and C# if
cold start time is affecting user experience.
M
MEMORY
BALANCING
• Lambda costing depends on both memory
allocation and execution time. If we need to
reduce the Lambda execution time, one can
try increasing memory (and by extension,
CPU) to process it faster
C
CODE
OPTAMIZATION
• Store and reference external configurations
and dependencies locally after first
execution.
• Avoid memory intensive or iteration of
large data set.
R
RE-USE LAMBDA
CONTAINERS
• Cache reusable resources.
• Limit the re-initialization of variables/objects
on every invocation. Instead use static
initialization/constructor, global/static
variables and singletons.
5. Key Consideration : Performance

20. 20
• Do not store secrets in
application code, environment
variables or in a source code.
• For sensitive information,
utilize a secret storage that
enables both runtime access,
as well as easy and routine
key rotation.
Manage secrets in secure
storage
• Offloading authentication
concerns from your functions
core business logic
• DDOS protection, traffic
throttling and rate limiting.
API gateways as a
security buffer
• Avoid globally defined roles
and resource access
permissions for functions.
• Minimize access rights to
resources for functions using
fine-grained permissions for
each function
Adopt Least privilege
• Audit and monitor how and
what functions are accessing
to ensure no illegal
paths are taken, and monitor
security vulnerabilities in
functions.
• Implement central logging
system to gain better
observability.
Monitor and log functions
6. Key Consideration : Security

21. 21
Q/A