Going

Serverless
With AWS

Shubham Khetan, Deloitte LLP

 Need for a new Approach
 Although the cloud eliminates the need for companies to purchase and maintain their
own hardware, any server-based architecture still requires them to architect for
scalability and reliability.

 Companies need to own the challenges of patching and deploying to those server fleets
as their applications evolve.

 Companies also must scale their server fleets to account for peak load and then
attempt to scale them down when and where possible to lower costs—all while
protecting the experience of end users and the integrity of internal systems.

 Idle, underutilized servers prove to be costly and wasteful. Analysts estimate that as
many as 85 percent of servers in practice have underutilized capacity.

 Serverless applications are designed to address these challenges by offering companies

a different way of approaching application design, one with inherently lower costs and
faster time to market.
 What is Serverless
 Serverless applications are ones that don't require you to provision or manage any
servers.
 Serverless apps are architected such that developers can focus on their core
competency—writing the actual business logic.

Serverless model offers a number of advantages compared with conventional

server-based application design -
 There is no need to provision, deploy, update, monitor, or otherwise manage
servers. All of the actual hardware and server software is handled by the cloud
provider.
 The application scales automatically, triggered by its actual use. This is inherently
different from conventional applications, which require a receiver fleet and explicit
capacity management to scale to peak load.
 In addition to scaling, availability and fault tolerance are built in. No coding,
configuration, or management is required to gain the benefit of these capabilities.
 There are no charges for idle capacity. There is no need (and in fact, no ability) to
pre-provision or over-provision capacity. Instead, billing is pay-per-request and based
on the duration it takes for code to run.
 The AWS Serverless
Platform

 AWS has a broad collection of

fully managed services that
enable organizations to create
serverless apps that can
integrate seamlessly with other
AWS services and third-party
services.

 The cloud logic layer is

provided by AWS Lambda and
complemented by
Lambda@Edge and AWS
Greengrass.

 Lambda functions scale

precisely with the size of the
workload, down to the
individual request.
 Amazon API Gateway – HTTP endpoints for Lambda functions, including a full range of API
proxy and API management capabilities.
 Amazon S3 – Lambda functions can be used as automatic event triggers when an object is
created, copied, or deleted.
 Amazon DynamoDB – Lambda functions can be used to process any or all of the changes
made to a database table.
 Amazon SNS – Messages can be routed to Lambda functions for processing, adding the ability
to dynamically respond to published content.
 Amazon SQS – Messages in queues can be easily processed by Lambda functions.
 Amazon Kinesis Streams – In-order record processing of streaming data is provided by
Lambda functions, making it easy to build near real-time analytics engines.
 Amazon Kinesis Firehose – Lambda functions can be applied automatically to the records
ingested by a Firehose, making it easy to add transformation, filtering, and analysis capabilities
to a data stream.
 Amazon Athena –Lambda functions can be automatically triggered for each object in a query’s
result set.
 AWS Step Functions – Multiple Lambda functions can be orchestrated to create long-running
workflows for both human-centric and automated processes.
 Amazon CloudWatch Events – Lambda functions can be used to automatically respond to
events, including third-party events.
 Amazon Aurora – Database triggers can be written as Lambda functions.
 Introduction to AWS Lambda
 Lambda is a high-scale, provision-free serverless
compute offering based on functions which can be
triggered by a variety of events that occur on AWS or
on supporting third-party services.

 When there are multiple, simultaneous events to

respond to, Lambda simply runs more copies of the
function in parallel.

Invocation model for AWS Lambda

(request-response)
 Lambda Function Code
 Code can be written in any of the languages supported by Lambda (Node.js, Python,
Java, Ruby, C#, Go, Powershell)

 Libraries, artifacts, or compiled native binaries that can execute on top of the runtime
environment can be part of your function code package

 Code can also be written in other programming languages (PHP, SmallTalk etc.), as
long as you stage and invoke that code from within one of the support languages in
the AWS Lambda runtime environment.

 AWS provides a set of tools called AWS SAM Local to enable local testing of Lambda
functions.

 The maximum size of a function code package is 50 MB compressed and 250MB

extracted
Handler

When a Lambda function is invoked, code execution begins at what is called the
handler.

• MyOutput output handlerName(MyEvent event, Context

Java context) {
•
•
...
}

Node.js
• exports.handlerName = function(event, context, callback) {
• ... // callback parameter is optional
• }

Python
• def handler_name(event, context):
• ...
• return some_value

C#
• def handler_name(event, context):
• ...
• return some_value
The Event Object
 The contents of the event parameter include all of the data and metadata your Lambda
function needs to drive its logic.
 The event differs in structure and contents, depending on which event source created
it.

The Context Object

 The context object allows your function code to interact with the Lambda execution
environment.
 The contents and structure of the context object vary, based on the language runtime
your Lambda function is using, but at minimum it will contain:
o AWS RequestID
o Remaining Time
o Logging

Note : It’s important to understand the central tenant when writing code for Lambda:
your code cannot make assumptions about state.
Warm and Cold Function Containers
 Lambda Function Event Sources
You can associate your Lambda function with event sources occurring within AWS services that
will invoke your function as needed or use the Invoke API to directly Invoke the functions.

Invocation Patterns
 Push Model – Lambda function is invoked every time a particular event occurs within
another AWS service(Example : S3, API Gateway, SNS, CloudFormation, CloudWatch events
and logs, Alexa)
 Pull Model – Lambda polls a data source and invokes the function with any new records
that arrive at the data source, batching new records together in a single function invocation
(Example : DynamoDb, Kinesis Streams, SQS)

InvocationType Parameter
Lambda function can be executed synchronously or asynchronously. This parameter has three
possible values :
 RequestResponse – Execute synchronously
 Event – Execute asynchronously
 DryRun – Test that invocation is permitted for the caller, but don’t execute the function.
 Lambda Function Configuration
You have various configuration options to set that define how your code is executed
within Lambda –

Function Memory
 You can allocate 128 MB of RAM up to 1.5 GB of RAM to your Lambda function.
 The same dial will also influence the CPU and network resources available to your
function.

Versions and Aliases

 Lambda lets you version your AWS Lambda functions.
 You can address the most recent code that has been uploaded to your Lambda function
through the $LATEST version.
 A function alias allows you to invoke and point event sources to a specific Lambda
function version.

Timeout
 You can designate the maximum amount of time a single function execution is allowed
to complete before a timeout is returned.
 The maximum timeout for a Lambda function is 300 seconds.
IAM Role
 You can assign an IAM role (called an execution role) to each of your Lambda
functions.
Lambda Function Permissions
 With permissions, you declare a function policy that lists the AWS Resource Names
(ARNs) that are allowed to invoke a function.
Network Configuration
 A Lambda function has two broad options for outbound network connectivity:
o Default
o VPC
Environmental Variables
 Environment variables for Lambda functions enable you to dynamically pass data to
your function code and libraries without making changes to your code.
Dead Letter Queues
 If an exception occurs when trying to invoke your function in these models, the
invocation will be attempted two more times (with back-off between the retries). After
the third attempt, the event is either discarded or placed onto a dead letter queue, if
you configured one for the function.
Shared Responsibility Model - Lambda
 Lambda Runtime Environment
Storage and State

1) Each Lambda execution environment

also includes a writeable file system,
available at /tmp.
2) files written to /tmp remain for the
lifetime of the execution
environment.
3) The /tmp storage is implemented
with either Amazon Elastic Block
Store (Amazon EBS) or local storage
on the Lambda worker instance.
4) You can implement your own
memory encryption and wiping
process before function termination.
Fig : Isolation Model for AWS Lambda
 Monitoring and Auditing Lambda
Functions
Amazon CloudWatch
Through Amazon CloudWatch, it reports metrics such as the number of requests, the
execution duration per request, and the number of requests resulting in an error.
Amazon CloudTrail
CloudTrail enables you to log, continuously monitor, and retain account activity related to
actions across your AWS infrastructure, providing a complete event history of actions
taken through the AWS Management Console, AWS SDKs, command line tools, and other
AWS services.
AWS XRAY
X-Ray’s end-to-end view of requests as they travel through your application shows a map
of the application’s underlying components, so you can analyze applications during
development and in production.
AWS Config
With AWS Config, you can track configuration changes to the Lambda functions (including
deleted functions), runtime environments, tags, handler name, code size, memory
allocation, timeout settings, and concurrency settings, along with Lambda IAM execution
role, subnet, and security group associations.
 Is Serverless always appropriate?
 When the goal is explicitly to avoid making any changes to an application.
 When fine-grained control over the environment is required, such as specifying
particular operating system patches or accessing low-level networking operations, in
order for the code to run properly.
 When an on-premises application hasn’t been migrated to the public cloud.
 Serverless Application Use Cases
The serverless application model is generic, and applies to almost any type of application from a
startup’s web app to a Fortune 100 company’s stock trade analysis platform. Here are a few
examples:

Web apps Mobile IT

IoT Backends
and websites Backends Automation

Clickstream and other near real-time streaming

Chatbots
data processes

In addition to the highly adopted use cases, other domains in which companies are
using Serverless approach are -
 Bigdata, such as MapReduce problems, high speed video transcoding etc.
 Low Latency, custom processing for applications and assets delivered though CDNs
 Connected Devices enabling serverless capabilities to run inside IoT Infrastructures
 Custom logic and data handling in on-premise devices like Snowball Edge
 A Case Study – Bustle.com
About Bustle
Bustle.com is a news, entertainment, lifestyle, and fashion website catering to women.
Bustle also operates Romper.com, a website focused on motherhood. Bustle is based in
Brooklyn, NY and is read by 50 million people each month.

The Challenge
 Bustle was originally running on a third-party platform as a service (PaaS) but
migrated to using AWS OpsWorks to gain better scale and availability.
 The site was built as a monolith and had trouble scaling.
 There was also a fair amount of server management, automation, and monitoring
involved in order to keep the website running smoothly; this raised the barrier of entry
for new engineers to roll out new code changes.
 The engineering team wanted to focus on areas where they thought they brought the
customer the most value, which was building front-end features instead of dealing with
operations.
 The Solution

 Bustle started to use AWS Lambda to process high volumes

of site metric data from Amazon Kinesis Streams in real
time. This allows the team to get data more quickly so they
can understand how new site features affect usage. They can
also now measure user engagement, allowing better data-
driven decisions.

 The team also decided to explore using AWS Lambda and

Amazon API Gateway for running an entirely serverless
website. To test, Bustle built Romper.com using Ember.js and
Riot.js running on a serverless backend comprising AWS
Lambda, Amazon API Gateway, and a self-managed Redis
data store.

 Bustle also built their own AWS Lambda and Amazon API
Gateway software-delivery tool, allowing developers to easily
do integration tests and deployments when they are ready to
release their code into production.

 The serverless back end supports the Romper website and

iOS app as well as the Bustle iOS app. Bustle plans to migrate
all of Bustle.com to the serverless back end.
The Benefits
 With AWS Lambda, the engineering team now puts zero thought into scaling applications.
There is an extremely low cost for any engineer to deploy production-ready code that will
scale. No one has to deal with infrastructure management, so every engineer can focus on
building out new features and innovating.
 With no operational maintenance of servers, the team can remain small, with half the
people normally required to build and operate sites of Bustle’s scale.
 Bustle has also experienced approximately 84% cost savings by moving to a serverless
architecture.
 Conclusion
 Serverless approaches are designed to tackle two classic IT management problems:
idle servers that drain a company’s balance sheet without offering value, and the cost
of building and operating fleets of servers, and server software, that distract and
detract from the business of creating differentiated customer value.
 AWS Lambda and the other AWS serverless offerings solve these longstanding
problems by eliminating the servers, containers, disks, and other infrastructure-level
resources from the programming and billing model.
 As a result, developers can work with a clean application model that helps them deliver
faster and organizations only pay for useful work.
 The easiest and fastest way to architect reactive, event-based systems and to deliver
cloud-native microservices is through the use of serverless architectures.
 References
White papers –
1) Serverless Architectures with AWS Lambda (November 2017)
2) Optimizing Enterprise Economics with Serverless Architectures (October 2017)
3) Security Overview of AWS Lambda (March 2019)
4) Serverless Streaming Architectures and Best Practices (June 2018)
5) AWS Serverless Multi-Tier Architectures: Using Amazon API Gateway and AWS
Lambda (November 2015)
Links –
1) https://aws.amazon.com/solutions/case-studies/bustle/
2) https://docs.aws.amazon.com/lambda/latest/dg/welcome.html