Cloud Application

Development

Book website: www.hands-on-books-series.com © 2019 Arshdeep Bahga & Vijay Madisetti

Outline

• Design Considerations for Cloud Applications

• Cloud Application Design Methodologies
• Reference Architectures for Cloud Applications
• Python Web Application Framework - Django
• Designing a RESTful Web API

© 2019 Arshdeep Bahga & Vijay Madisetti

Design Considerations for Cloud Applications

• Scalability
• Scalability is an important factor that drives the application designers to move to cloud computing environments. Building applications
that can serve millions of users without taking a hit on their performance has always been challenging. With the growth of cloud
computing application designers can provision adequate resources to meet their workload levels.
• Reliability & Availability
• Reliability of a system is defined as the probability that a system will perform the intended functions under stated conditions for a
specified amount of time. Availability is the probability that a system will perform a specified function under given conditions at a
prescribed time.
• Security
• Security is an important design consideration for cloud applications given the outsourced nature of cloud computing environments.
• Maintenance & Upgradation
• To achieve a rapid time-to-market, businesses typically launch their applications with a core set of features ready and then
incrementally add new features as and when they are complete. In such scenarios, it is important to design applications with low
maintenance and upgradation costs.
• Performance
• Applications should be designed while keeping the performance requirements in mind.

© 2019 Arshdeep Bahga & Vijay Madisetti

Reference Architectures –
e-Commerce, Business-to-Business, Banking and Financial apps

• Load Balancing Tier

• Load balancing tier consists of one or more load balancers.
• Application Tier
• For this tier, it is recommended to configure auto scaling.
• Auto scaling can be triggered when the recorded values for
any of the specified metrics such as CPU usage, memory
usage, etc. goes above defined thresholds.
• Database Tier
• The database tier includes a master database instance and
multiple slave instances.
• The master node serves all the write requests and the read
requests are served from the slave nodes.
• This improves the throughput for the database tier since most
applications have a higher number of read requests than write
requests.

© 2019 Arshdeep Bahga & Vijay Madisetti

Reference Architectures –
Content delivery apps

• Figure shows a typical deployment architecture for content

delivery applications such as online photo albums, video
webcasting, etc.
• Both relational and non-relational data stores are shown in
this deployment.
• A content delivery network (CDN) which consists of a global
network of edge locations is used for media delivery.
• CDN is used to speed up the delivery of static content such
as images and videos.

© 2019 Arshdeep Bahga & Vijay Madisetti

Reference Architectures –
Analytics apps

• Figure shows a typical deployment architecture for compute

intensive applications such as Data Analytics, Media
Transcoding, etc.
• Comprises of web, application, storage, computing/analytics
and database tiers.
• The analytics tier consists of cloud-based distributed batch
processing frameworks such as Hadoop which are suitable
for analyzing big data.
• Data analysis jobs (such as MapReduce) jobs are submitted
to the analytics tier from the application servers.
• The jobs are queued for execution and upon completion the
analyzed data is presented from the application servers.

© 2019 Arshdeep Bahga & Vijay Madisetti

 Service Oriented Architecture

• Service Oriented Architecture (SOA) is a well established architectural

approach for designing and developing applications in the form services that
can be shared and reused.
• SOA is a collection of discrete software modules or services that form a part
of an application and collectively provide the functionality of an application.
• SOA services are developed as loosely coupled modules with no hard-wired
calls embedded in the services.
• The services communicate with each other by passing messages.
• Services are described using the Web Services Description Language (WSDL).
• WSDL is an XML-based web services description language that is used to
create service descriptions containing information on the functions
performed by a service and the inputs and outputs of the service.

© 2019 Arshdeep Bahga & Vijay Madisetti

SOA Layers
• Business Systems
• This layer consists of custom built applications and legacy systems such as
Enterprise Resource Planning (ERP), Customer Relationship Management
(CRM), Supply Chain Management (SCM), etc.
• Service Components
• The service components allow the layers above to interact with the business
systems. The service components are responsible for realizing the
functionality of the services exposed.
• Composite Services
• These are coarse-grained services which are composed of two or more
service components. Composite services can be used to create enterprise
scale components or business-unit specific components.
• Orchestrated Business Processes
• Composite services can be orchestrated to create higher level business
processes. In this layers the compositions and orchestrations of the
composite services are defined to create business processes.
• Presentation Services
• This is the topmost layer that includes user interfaces that exposes the
services and the orchestrated business processes to the users.
• Enterprise Service Bus
• This layer integrates the services through adapters, routing, transformation
and messaging mechanisms.
© 2019 Arshdeep Bahga & Vijay Madisetti
 Cloud Component Model

• Cloud Component Model is an application design methodology that provides a flexible way
of creating cloud applications in a rapid, convenient and platform independent manner.
• CCM is an architectural approach for cloud applications that is not tied to any specific
programming language or cloud platform.
• Cloud applications designed with CCM approach can have innovative hybrid deployments
in which different components of an application can be deployed on cloud infrastructure
and platforms of different cloud vendors.
• Applications designed using CCM have better portability and interoperability.
• CCM based applications have better scalability by decoupling application components and
providing asynchronous communication mechanisms.

© 2019 Arshdeep Bahga & Vijay Madisetti

CCM Application Design Methodology

• CCM approach for application

design involves:
• Component Design
• Architecture Design
• Deployment Design

© 2019 Arshdeep Bahga & Vijay Madisetti

CCM Component Design

• Cloud Component Model is created for the application based

on comprehensive analysis of the application’s functions and
building blocks.
• Cloud component model allows identifying the building
blocks of a cloud application which are classified based on the
functions performed and type of cloud resources required.
• Each building block performs a set of actions to produce the
desired outputs for other components.
• Each component takes specific inputs, performs a pre-defined CCM map for an e-Commerce application
set of actions and produces the desired outputs.
• Components offer their functions as services through a
functional interface which can be used by other components.
• Components report their performance to a performance
database through a performance interface.

© 2019 Arshdeep Bahga & Vijay Madisetti

CCM Architecture Design

• In Architecture Design step, interactions between the

application components are defined.

• CCM components have the following characteristics:

• Loose Coupling
• Components in the Cloud Component Model are loosely coupled.
• Asynchronous Communication
• By allowing asynchronous communication between components, it
is possible to add capacity by adding additional servers when the
application load increases. Asynchronous communication is made
possible by using messaging queues.
• Stateless Design
• Components in the Cloud Component Model are stateless. By
storing session state outside of the component (e.g. in a database), Architecture design of an e-Commerce application.
stateless component design enables distribution and horizontal
scaling.

© 2019 Arshdeep Bahga & Vijay Madisetti

CCM Deployment Design

• In Deployment Design step, application components

are mapped to specific cloud resources such as web
servers, application servers, database servers, etc.
• Since the application components are designed to be
loosely coupled and stateless with asynchronous
communication, components can be deployed
independently of each other.
• This approach makes it easy to migrate application
components from one cloud to the other.
• With this fiexibility in application design and
deployment, the application developers can ensure
that the applications meet the performance and cost
requirements with changing contexts.
Deployment design of an e-Commerce application

© 2019 Arshdeep Bahga & Vijay Madisetti

SOA vs CCM

Similarities
SOA CCM
Standardization & SOA advocates principles of CCM is based on reusable
Re-use reuse and well defined components which can be used
relationship between service by multiple cloud applications.
provider and service consumer.

Loose coupling SOA is based on loosely CCM is based on loosely

coupled services that minimize coupled components that
dependencies. communicate asynchronously
Statelessness SOA services minimize resource CCM components are stateless.
consumption by deferring the State is stored outside of the
management of state components.
information.

© 2019 Arshdeep Bahga & Vijay Madisetti

SOA vs CCM
Differences

SOA CCM
End points SOA services have small and well-defined set CCM components have very large number of
of endpoints through which many types of endpoints. There is an endpoint for each resource
data can pass. in a component, identified by a URI.
Messaging SOA uses a messaging layer above HTTP by CCM components use HTTP and REST for
using SOAP which provide prohibitive messaging.
constraints to developers.
Security Uses WS-Security , SAML and other CCM components use HTTPS for security.
standards for security
Interfacing SOA uses XML for interfacing. CCM allows resources in components represent
different formats for interfacing (HTML, XML,
JSON, etc.).
Consumption Consuming traditional SOA services in a CCM components and the underlying component
browser is cumbersome. resources are exposed as XML, JSON (and other
formats) over HTTP or REST, thus easy to consume
in the browser.

© 2019 Arshdeep Bahga & Vijay Madisetti

Model View Controller

• Model View Controller (MVC) is a popular software design pattern for web applications.
• Model
• Model manages the data and the behavior of the applications. Model processes events sent by the controller. Model has no information about the views and controllers.
Model responds to the requests for information about its state (from the view) and responds to the instructions to change state (from controller).

• View
• View prepares the interface which is shown to the user. Users interact with the application through views. Views present the information that the model or controller tell
the view to present to the user and also handle user requests and sends them to the controller.

• Controller
• Controller glues the model to the view. Controller processes user requests and updates the model when the user manipulates the view. Controller also updates the view
when the model changes.

© 2019 Arshdeep Bahga & Vijay Madisetti

RESTful Web Services

• Representational State Transfer (REST) is a set of architectural principles by which you can design
web services and web APIs that focus on a system’s resources and how resource states are
addressed and transferred.
• The REST architectural constraints apply to the components, connectors, and data elements, within
a distributed hypermedia system.
• A RESTful web service is a web API implemented using HTTP and REST principles.
• The REST architectural constraints are as follows:
• Client-Server
• Stateless
• Cacheable
• Layered System
• Uniform Interface
• Code on demand

© 2019 Arshdeep Bahga & Vijay Madisetti

 Python Web Application Framework - Django

• Django is an open source web application framework for developing web applications in Python.
• A web application framework in general is a collection of solutions, packages and best practices
that allows development of web applications and dynamic websites.
• Django is based on the Model-Template-View architecture and provides a separation of the data
model from the business rules and the user interface.
• Django provides a unified API to a database backend.
• Thus web applications built with Django can work with different databases without requiring any
code changes.
• With this fiexibility in web application design combined with the powerful capabilities of the Python
language and the Python ecosystem, Django is best suited for cloud applications.
• Django consists of an object-relational mapper, a web templating system and a regular-expression-
based URL dispatcher.

© 2019 Arshdeep Bahga & Vijay Madisetti

Django Architecture

• Django is Model-Template-View (MTV) framework.

• Model
• The model acts as a definition of some stored data and handles the interactions with the database. In a web
application, the data can be stored in a relational database, non-relational database, an XML file, etc. A Django model is
a Python class that outlines the variables and methods for a particular type of data.
• Template
• In a typical Django web application, the template is simply an HTML page with a few extra placeholders. Django’s
template language can be used to create various forms of text files (XML, email, CSS, Javascript, CSV, etc.)
• View
• The view ties the model to the template. The view is where you write the code that actually generates the web pages.
View determines what data is to be displayed, retrieves the data from the database and passes the data to the
template.

© 2019 Arshdeep Bahga & Vijay Madisetti

Design methodology for IaaS service model

Component Design

• Indentify the building blocks of the application and to be performed by each block
• Group the building blocks based on the functions performed and type of cloud resources required and identify
the application components based on the groupings
• Identify the inputs and outputs of each component
• List the interfaces that each component will expose
• Evaluate the implementation alternatives for each component (design patterns such as MVC, etc.)

Architecture Design

• Define the interactions between the application components

• Guidelines for loosely coupled and stateless designs - use messaging queues (for asynchronous
communication), functional interfaces (such as REST for loose coupling) and external status database (for
stateless design)

Deployment Design

• Map the application components to specific cloud resources (such as web servers, application servers,
database servers, etc.)

© 2019 Arshdeep Bahga & Vijay Madisetti

Design methodology for PaaS service model

• For applications that use the Platform-as-a-service (PaaS) cloud service model, the architecture and
deployment design steps are not required since the platform takes care of the architecture and deployment.
• Component Design
• In the component design step, the developers have to take into consideration the platform specific features.

• Platform Specific Software

• Different PaaS offerings such as Google App Engine, Windows Azure Web Sites, etc., provide platform specific software development
kits (SDKs) for developing cloud applications.

• Sandbox Environments
• Applications designed for specific PaaS offerings run in sandbox environments and are allowed to perform only those actions that do
not interfere with the performance of other applications.

• Deployment & Scaling

• The deployment and scaling is handled by the platform while the developers focus on the application development using the
platform-specific SDKs.

• Portability
• Portability is a major constraint for PaaS based applications as it is difficult to move the

© 2019 Arshdeep Bahga & Vijay Madisetti

 Image Processing App – Component Design

• Functionality:
• A cloud-based Image Processing application.
• This application provides online image filtering capability.
• Users can upload image files and choose the filters to apply.
• The selected filters are applied to the image and the processed
image can then be downloaded.

• Component Design
• Web Tier: The web tier for the image processing app has front
ends for image submission and displaying processed images.
• Application Tier: The application tier has components for
processing the image submission requests, processing the
submitted image and processing requests for displaying the Component design for Image Processing App
results.
• Storage Tier: The storage tier comprises of the storage for
processed images.

© 2019 Arshdeep Bahga & Vijay Madisetti

 Image Processing App – Architecture Design

• Architecture design step which defines the interactions

between the application components.
• This application uses the Django framework, therefore,
the web tier components map to the Django templates
and the application tier components map to the Django
views.
• A cloud storage is used for the storage tier. For each
component, the corresponding code box numbers are
mentioned.

Architecture design for Image Processing App

© 2019 Arshdeep Bahga & Vijay Madisetti

 Image Processing App – Deployment Design

• Deployment for the app is a multi-tier architecture

comprising of load balancer, application servers and a
cloud storage for processed images.
• For each resource in the deployment the corresponding
Amazon Web Services (AWS) cloud service is mentioned.

Deployment design for Image Processing App

© 2019 Arshdeep Bahga & Vijay Madisetti

 Cloud Drive App – Component Design

• Functionality:
• A cloud-based document storage (Cloud Drive) application.
• This application allows users to store documents on a cloud-
based storage.

• Component Design
• Web Tier: The web tier for the Cloud Drive app has front ends for
uploading files, viewing/deleting files and user profile.
• Application Tier: The application tier has components for
processing requests for uploading files, processing requests for
viewing/deleting files and the component that handles the
registration, profile and login functions.
• Database Tier: The database tier comprises of a user credentials
Component design for Cloud Drive App
database.
• Storage Tier: The storage tier comprises of the storage for files.

© 2019 Arshdeep Bahga & Vijay Madisetti

 Cloud Drive App – Architecture Design

• Architecture design step which defines the

interactions between the application components.
• This application uses the Django framework,
therefore, the web tier components map to the
Django templates and the application tier
components map to the Django views.
• A MySQL database is used for the database tier and a
cloud storage is used for the storage tier.
• For each component, the corresponding code box
numbers are mentioned.
Architecture design for Cloud Drive App

© 2019 Arshdeep Bahga & Vijay Madisetti

 Cloud Drive App – Deployment Design

• Deployment for the app is a multi-tier architecture

comprising of load balancer, application servers, cloud
storage for storing documents and a database server for
storing user credentials.
• For each resource in the reference architecture the
corresponding Amazon Web Services (AWS) cloud
service is mentioned.

Deployment design for Cloud Drive App

© 2019 Arshdeep Bahga & Vijay Madisetti

Social Media Analytics App – Component Design

• Functionality:
• A cloud-based Social Media Analytics application.
• This application collects the social media feeds (Twitter
tweets) on a specified keyword in real time and analyzes the
sentiments of the tweets and provides aggregate results.
• Component Design
• Web Tier: The web tier has a front end for displaying results.
• Application Tier: The application tier has a listener
component that collects social media feeds, a consumer
component that analyzes tweets and a component for
rendering the results in the dashboard.
• Database Tier: A MongoDB database is used for the database
tier and a cloud storage is used for the storage tier. Component design for Social Media Analytics App
• Storage Tier: The storage tier comprises of the storage for
files.

© 2019 Arshdeep Bahga & Vijay Madisetti

 Social Media Analytics App – Architecture Design

• Architecture design step which defines the

interactions between the application components.
• To make the application scalable the feeds collection
component (Listener) and feeds processing
component (Consumer) are separated.
• The Listener component uses the Twitter API to get
feeds on a specific keyword (or a list of keywords)
and enqueues the feeds to a queue.
• The Consumer component (that runs on a separate
instance) retrieves the feeds from the queue and
analyzes the feeds and stores the aggregated results
in a separate database.
• The aggregate results are displayed to the users from
Architecture design for Social Media Analytics App
a Django application.

© 2019 Arshdeep Bahga & Vijay Madisetti

 Social Media Analytics App – Deployment Design

• Deployment for the app is a multi-tier

architecture comprising of load balancer,
application servers, listener and consumer
instances, a cloud storage for storing raw data and
a database server for storing aggregated results.
• For each resource in the deployment the
corresponding Amazon Web Services (AWS) cloud
service is mentioned.

Deployment design for Social Media Analytics App

© 2019 Arshdeep Bahga & Vijay Madisetti

Social Media Analytics App – Dashboard

© 2019 Arshdeep Bahga & Vijay Madisetti

 Serverless Applications

Book website: www.hands-on-books-series.com © 2019 Arshdeep Bahga & Vijay Madisetti

Overview

• Serverless architectures & use cases

• Serverless design patterns
• Serverless concepts
• AWS Lambda

© 2019 Arshdeep Bahga & Vijay Madisetti

Serverless Computing

• Serverless Computing is an execution model for cloud computing environments where the
cloud provider executes a piece of code (a function) by dynamically allocating resources.
• While in serverless computing (also referred to as Serverless in short) servers (such as
physical servers, virtual machines or containers) are still required for execution of code, the
difference from server-based computing is that in serverless a layer of abstraction is added on
top of cloud infrastructure such that the application developers do not need to provision and
manage the underlying infrastructure required for execution of code.
• Unlike in server-based computing, where servers have to be provisioned and run continuously
to run the applications, in serverless computing, there is no need to provision the resources.
• The cloud provider manages the provisioning and scaling of the infrastructure required to run
the functions.
• Cloud providers charge for the amount of resources used to run the code which makes
serverless computing much more cost effective than server-based computing where servers
have to run continuously.

© 2019 Arshdeep Bahga & Vijay Madisetti

Functions-as-a-Service (FaaS)

• Serverless is also referred to as Functions-as-a-Service (FaaS). AWS Lambda is a

popular FaaS offering from Amazon Web Services.
• In the serverless computing model, the code is structured into functions.
• The functions are triggered by events such as an HTTP request to an API gateway, a
record written to a database, a new file uploaded to cloud storage, a new message
inserted into a messaging queue, a monitoring alert, and a scheduled event.
• When a function is triggered by an event, the cloud provider launches a container and
executes the function within the container.

© 2019 Arshdeep Bahga & Vijay Madisetti

Monolith to Microservices to Serverless applications

© 2019 Arshdeep Bahga & Vijay Madisetti

Cloud Services for Implementing Serverless Applications

Example of a multi-tier web application implemented with the serverless computing model.

© 2019 Arshdeep Bahga & Vijay Madisetti

Cloud Services for Implementing Serverless Applications

1. Amazon Route 53 is a Domain Name System (DNS) service that translates domain names into IP
addresses

2. Amazon Cognito is a cloud-based service offered by Amazon Web Services (AWS) that provides user
sign-up, sign-in, and access control for web and mobile applications.

3. Amazon DynamoDB is a NoSQL database service from Amazon Web Services (AWS) that supports
key-value and document data structures

4. AWS Lambda is a serverless computing service that lets you run code in response to events

5. API Gateway is a management tool that acts as an interface between users and microservices.
The Amazon API Gateway is an AWS service that allows users to create, publish, secure, maintain and
monitor APIs at any scale

6. Amazon Simple Storage Service (S3) is a web service that allows users to store and retrieve data
online.
© 2019 Arshdeep Bahga & Vijay Madisetti
Pros and Cons of Serverless

• Pros:
• Low Operational Cost
• Low Maintenance
• Scalability
• Availability & Fault Tolerance

• Cons:
• No control over the infrastructure
• Time limits
• Vendor lock-in
• Not suitable for all use cases

© 2019 Arshdeep Bahga & Vijay Madisetti

Serverless Use Case - Web Application

Using Lambda functions for web application backends

© 2019 Arshdeep Bahga & Vijay Madisetti
Serverless Use Case - Real-time Stream Processing

Using Lambda functions for real-time stream processing

Amazon Kinesis is a service from Amazon Web Services (AWS) that lets users process and analyze large
amounts of data in real time. It can be used to build applications that consume and process data from multiple
sources at once
© 2019 Arshdeep Bahga & Vijay Madisetti
Serverless Use Case - Real-time File Processing

Using Lambda functions for real-time file processing

© 2019 Arshdeep Bahga & Vijay Madisetti

Serverless Use Case - IoT Backends

Using Lambda functions for IoT backends

Amazon Kinesis is a service from Amazon Web Services (AWS) that lets users process and analyze large
amounts of data in real time. It can be used to build applications that consume and process data from multiple
sources at once
© 2019 Arshdeep Bahga & Vijay Madisetti
Serverless Use Case - Mobile Application Backends

Using Lambda functions for mobile application backends

Amazon Simple Notification Service (SNS) is a cloud service that sends messages between systems and
applications
© 2019 Arshdeep Bahga & Vijay Madisetti
Serverless Use Case - Extract, Transform, Load (ETL)

Using Lambda functions for Extract, Transform, Load

© 2019 Arshdeep Bahga & Vijay Madisetti

Serverless Design Patterns

• Asynchronous Processing with Messaging Queues

• Load Balancing with Multiple Consumers
• Priority Queues
• Command Pattern
• Fan-Out Pattern
• Pipes and Filters

© 2019 Arshdeep Bahga & Vijay Madisetti

Asynchronous Processing with Messaging Queues

• Messaging queues can be used between the data producers and data consumers for asynchronous
processing or load leveling.
• Queues are useful for push-pull messaging where the producers push data to the queues, and the
consumers pull the data from the queues.

© 2019 Arshdeep Bahga & Vijay Madisetti

 Load Balancing with Multiple Consumers
• While messaging queues can be used between data producer and consumer for load leveling, having multiple consumers can
help in load balancing and making the system more scalable, reliable, and available.
• Data producers push messages to the queue, and the consumers retrieve and process the messages.
• Multiple consumers can make the system more robust as there is no single point of failure.
• More consumers can be added on-demand if the workload is high.
• Load balancing between consumers improves the system performance as multiple consumers can process messages in parallel.

© 2019 Arshdeep Bahga & Vijay Madisetti

Priority Queues

• Priority Queue pattern is useful when you

want to process messages with different
priorities to be processed differently.
• In a priority queue system, different queues
are used for messages with different
priorities, and each queue has different
consumers.
• Multiple consumers may be used for queues
designated for high priority messages.

© 2019 Arshdeep Bahga & Vijay Madisetti

Command Pattern

• Command Pattern is useful when you want to decouple a sender or client who invokes a
certain operation from a receiver or worker who performs the operation.

© 2019 Arshdeep Bahga & Vijay Madisetti

Fan-Out Pattern

• The Fan-Out pattern is useful when you

want to perform multiple actions or invoke
multiple services or functions, while the
event source supports only a single target.
• In such a case, you can use a publish-
subscribe messaging or a push notification
system as the entry point, where the event
source pushes a message to the entry point
which invokes all the subscribed services or
functions.

© 2019 Arshdeep Bahga & Vijay Madisetti

Pipes & Filters
• In many big data applications, a complex
data processing task can be split into a
series of distinct tasks to improve the
system performance, scalability, and
reliability.
• This pattern of splitting a complex task into
a series of distinct tasks is called the Pipes
and Filters pattern, where pipes are the
connections between the filters (processing
components).

© 2019 Arshdeep Bahga & Vijay Madisetti

 AWS Lambda
• AWS Lambda is a serverless offering from Amazon Web Services (AWS). Lambda is a compute service that lets you run code
without provisioning or managing servers.
• Using Lambda, you can deploy your code as Lambda functions which are executed only when needed.
• Lambda handles the provisioning and scaling of the compute infrastructure required to execute the functions.
• The execution of Lambda functions is triggered in response to events.

© 2019 Arshdeep Bahga & Vijay Madisetti

Push and Pull Models of Invocation

• Lambda functions are invoked by event sources which

can be an AWS service or a custom application that
publishes events. The event-based invocation has two
modes: push and pull.
• In the push model, an AWS service (such as S3)
publishes events which invoke the lambda functions.
The pull model works for poll-based sources (Kinesis,
DynamoDB streams, and SQS queues).
• In the pull model AWS Lambda polls the source and
then invokes the Lambda function when records are
detected on that source.

© 2019 Arshdeep Bahga & Vijay Madisetti

Concurrent Execution

• Concurrent execution refers to the number of executions of the functions which are happening at
the same time.
• Cloud providers set limits on concurrent executions.
• In AWS Lambda, you can have at the most 1000 concurrent executions across all the functions in
your account, which is the account concurrency limit.
• You can also optionally set a function concurrency limit and reserve concurrency for a function out
of the unreserved account concurrency limit.
• For event sources that aren’t poll-based, you can use estimate the number of concurrent
invocations of your Lambda functions using the formula: Events/Requests per second × Function
Duration.
• For poll-based event sources that are stream based (Kinesis or DynamoDB streams) the
concurrency is equal to the number of active shards.
• For poll-based event sources that are not stream based (SQS queues), each message batch can
be considered a single concurrent unit.

© 2019 Arshdeep Bahga & Vijay Madisetti

Execution Duration

• Cloud providers set a timeout limit under which a function execution must complete.
• For example, AWS Lambda has a timeout limit of 5 minutes.
• If the function takes a longer time to execute than the timeout limit, the function execution
is terminated.
• This makes the serverless computing model more suitable for real-time or short running
operations rather than long-running batch operations.

© 2019 Arshdeep Bahga & Vijay Madisetti

Container Reuse

• Cloud providers typically use containers for executing the functions in their serverless
offerings.
• A container helps in isolating the execution of a function from other functions.
• When a function is invoked for the first time (or after a long time), a container is created,
the execution environment is initialized, and the function code is loaded.
• The container is reused for subsequent invocations of the same function that happen
within a certain period.
• However, as a developer, you should not assume that a container is reused.
• The functions should be designed to be stateless, and any application state should be
stored in external resources such as a database, cloud storage, or cache.

© 2019 Arshdeep Bahga & Vijay Madisetti

Cold and Warm Functions

• When a function has not been executed for a long time or is being executed for the first
time, a new container has to be created, and the execution environment has to be
initialized. This is called a cold start.
• Cold start can result in a higher latency as a new container has to be initialized.
• The cloud provider may reuse the container for subsequent invocations of the same
functions within a short period.
• In this case, the function is said to be warm and takes much less time to execute than a
cold start.
• To reduce the execution time of functions and avoid cold starts, you can keep the
functions warm by invoking them periodically.

© 2019 Arshdeep Bahga & Vijay Madisetti

Case Study: Serverless Photo Gallery Application

• The application has a static front end

implemented in HTML, Javascript, and CSS.
• The static files of the application are served
through an S3 bucket enabled for static
website hosting.
• The application backend has a REST API
implemented using Amazon API Gateway and
Lambda functions.
• Amazon Cognito is used for user
authentication.
• Photos uploaded to the application are stored
in an Amazon S3 bucket.
• The records of photos are maintained in a
DynamoDB table.

© 2019 Arshdeep Bahga & Vijay Madisetti