Serverless Computing –

Architectural Considerations & Principles

January 2018
 Serverless Computing – Architectural Considerations & Principles

Serverless Computing –
Architectural
Considerations & Principles
Introduction have also gone down significantly
The last decade has seen tremendous while improving time-to-market for Serverless as a concept is not
innovation in the enterprise IT space. enterprises. new
The primary focus of this technological Amazon launched its cloud
innovation has been enabling Server computing is now evolving storage service (AWS S3)
businesses agility, improve resiliency towards even smaller units of scale – in 2006, which was also
and drive cost efficiencies. from virtual machines to containers a ‘serverless service’ that
to serverless1. The technology provided unlimited storage at
The revolution in the server computing evolution has been depicted below. infinite scale without having to
space over the past decade has maintain servers. However, the
allowed enterprise IT to develop and This thought paper provides a differentiation now is that the
deploy scalable software without vendor neutral summary of industry compute services are becoming
worrying about the underlying recommended principles and key ‘serverless’ thus defining a
infrastructure. At the same time, considerations for architecting new paradigm in software
cost of technology operations serverless systems. architecture.

Figure: Evolution of technology

Enterprise Data Cloud

Enterprise Hardware Co-location Hybrid Cloud
Center Computing

Virtual
Atomic Unit of Compute Physical Server Containers Functions
Machines

Software Architecture Monolith n-Tier Microservices Serverless

1.
 Evolution of Server Computing: VMs to Containers to Serverless — Which to Use When?, Gartner, June 2017

03
Serverless Computing – Architectural Considerations & Principles

So, what exactly is ‘serverless’ To summarize, serverless is an

The word ‘serverless’ doesn’t stand for event-driven computing model or Serverless computing can
‘No Servers’. Instead, servers are an code execution where underlying complement the API economy
integral part of this concept; however, infrastructure (including physical APIs are end-user interfaces
it is the cloud provider which handles and virtual hosts, virtual machines, of a service that allows
the complexity of managing individual containers as well as the operating another piece of a software
servers and provides an ephemeral systems) is abstracted from the to communicate and in-turn
compute service2, that will execute a developer and the service consumer. consume the same. With
piece of code on-demand triggered Applications run in stateless serverless computing, APIs
through requests and events, with the containers that are spawned will remain at the heart of the
service consumer being charged only based on triggering of events. services; however, the backend
for the duration of execution. The application logic or business would be serverless – an
logic is encapsulated in Functions 3 invocation of the API would in
In the traditional cloud computing which runs on containers in the turn trigger the function or a
scenario, enterprises needed to cloud provider’s infrastructure. series of functions.
pay a fixed and a recurring amount As the application load increases,
for using virtual servers to run its more Functions are executed
websites or applications irrespective proportionately, the scaling of
of whether the cloud services are the underlying infrastructure is
being used or not. However, with taken care by the cloud provider. activities associated with maintaining
serverless computing enterprises will The consumer of these services, virtual machines, server farm
need to pay only for service usage does not need to plan for scaling, capacity and operating systems.
with no charge for idle time i.e. pay- capacity planning and management
per-execution. and corresponding administration Serverless computing: An
evolution of cloud computing
Serverless computing is an evolution
of cloud computing service models
–from Infrastructure-as-a-Service
(IaaS) to Platform-as-a-Service (PaaS)
to Function-as-a-Service (FaaS).
While IaaS abstracts the underlying
infrastructure to provide virtual
machines for ready consumption and
PaaS abstracts the entire operating
system and middleware layer to
provide the application development
platform, FaaS goes one step further
in terms of abstracting the entire
programming runtime to provide
options to readily deploy a piece of
code and execute without worrying
about its deployment.

Leading cloud providers like Amazon,

Microsoft, Google and IBM have
launched serverless services in the
last 2 years. While Amazon’s service
is called AWS Lambda (launched
in 2014), the respective services
of Microsoft and Google are called
Azure Functions (launched in 2015)

2.
 Denotes the fact compute resources in serverless disappears immediately after use
3.
 Functions are units of deployment or work in serverless computing and contains application or business logic in the form of code which is executed when
a certain event is triggered
04
 Serverless Computing – Architectural Considerations & Principles

IaaS PaaS FaaS

Unit of deployment Operating System Applications Functions
Provides Virtual machines packaged Application development Execute code (with business
with operating systems platform logic) on-demand
Abstracts Physical hardware Operating system & Programming runtime
middleware

and Google Functions (launched in 2016 – alpha release).

IBM has also released its serverless service called
OpenWhisk.

Re-imagining the technology stack

As depicted below the traditional technology stack for
service delivery can be re-imagined to fit the serverless
stack across each layers of network, compute and
database.

Traditional Stack Serverless stack

Network API Gateway

Function as a Service
Compute
(FaaS)

Database as a Service
Database
(DbaaS)

The three key core technology components of serverless computing stack includes the following:

01 02 03
API Gateway: The API Gateway Functions or Function as a Service Backend as a Service (BaaS): This is
acts as the communication layer (FaaS): This is the layer that executes essentially a cloud based distributed
between the frontend and the FaaS specific business logic (or code) with NoSQL database which essentially
layer. It maps REST API endpoints the cloud provider providing the level removes database administration
with the respective functions that of abstraction in terms of executing overheads.
runs the business logic. With servers the business logic.
out of equation there is no need for
deploying and manage load balancers
also in this model.

4.
 Relational databases like SQL are not preferred in a serverless architecture because they have a limit on the number of database connections that can be
opened simultaneously at a time which can result in scalability and performance challenges

05
Serverless Computing – Architectural Considerations & Principles

Benefits of serverless computing

Key attributes of serverless computing include the following:

01
Fully managed service: As iterated earlier, it is a fully managed service provided by the cloud service
providers and the developers doesn’t need to worry about the underlying infrastructure, operating
system, middleware, language runtime and its management and dependencies.

02
Supports event-driven approach: Functions are triggered based on events. Different cloud
services5 and existing applications that supports a trigger mechanism can initiate and launch a
function.

03
Provides infinite scalability and built-in high availability: Depending on the user traffic,
functions scale horizontally in a completely automatic and elastic fashion which is managed by the
cloud service provider.

04
Less-Ops: Serverless doesn’t necessarily mean NoOps6 for the service consumers; however, it can
definitely mean ‘Less-Ops’ as operational tasks like debugging, testing, trouble-shooting etc. remains
while the infrastructure management is fully outsourced to the cloud service provider.

05
Pay for execution time: In a serverless computing model service consumers pay only for the
duration of execution of a function and the number of functions executed. When a function is not
executed no charge is levied – thus eliminating any idle time. This is a significant benefit over cloud
computing where users are charged on an hourly basis for running virtual machines.

5.
 F or example, AWS services like S3, DynamoDB, Kinesis Streams, SNS and SES etc. can trigger AWS Lambda function. HTTP triggers either from a REST API
are also supported
6.
 No operations is a concept which refers to an IT environment becoming automated to the extent that the underlying infrastructure is abstracted without
need for a dedicated team to manage the same

06
 Serverless Computing – Architectural Considerations & Principles

Industry incumbents can of internal business processes by legacy infrastructure. In fact,

regain competitive advantage effectiveness. And all of these serverless can be the exit strategy
through this smallest form of are driven by technology with for enterprises from their legacy IT
computing architectural design and deployment footprint.
Competitive advantage in today’s of software being at the core.
business landscape is determined by Key considerations for
the quality of customer interaction Serverless computing gives industry architecting serverless
and service, customized products incumbents the required computing systems
and services and effectiveness model to compete with the high-tech Serverless computing might
new comers in their industry. In seem a lot more attractive over
this technology approach, software other traditional infrastructure
"We are a technology applications can be broken down consumption and computational
company", into individual functionalities or models. However, we at Deloitte
JPMorgan CFO Marianne Lake functions in the serverless computing believe that without the right
(Source: Business Insider, 2016) parlay (i.e. a micro-services based software architecture it is not
With tech start-ups disrupting architecture) that are portable, possible to realize the benefits.
almost every industry with cost-efficient and most importantly
technological innovations, not bound to a legacy infrastructure
footprint. The separation of the Not all application or service
industry incumbents are
application functionalities from can be delivered in a serverless
struggling with their legacy IT
the supporting infrastructure model – we believe the future
footprint to innovate at the
provides the greatest opportunity enterprise IT landscape will be a
required pace to keep up with
for enterprises for application hybrid landscape.
the changing customer
modernization and remove all
development constrains posed

07
 Serverless Computing – Architectural Considerations & Principles

In addition, not all application or service can be delivered in a serverless model – we believe the future enterprise IT
landscape will be a hybrid landscape. Hence, to ensure that the optimum architecture is in place, we have outlined
certain architectural considerations that needs to be kept in mind while architecting serverless systems.

Key architectural considerations for serverless are as follows:

Functions are stateless: This implies that any kind

of resource within a function will not exist after
Functions are ephemeral i.e. persist 01 the function ceases to exist. This is an important
for a certain period of time only: consideration and hence appropriate measures must
Functions are deployed in a container7. be implemented. For example, storing the session state
These containers are started when a in a persistent database if the session needs to be
specific event is triggered and remains preserved.
active for a certain duration beyond
which it shuts-down automatically and
all resources within the container cease
to exist thereafter 8 . Hence, applications Language support: Currently different
with larger processing requirements serverless services support different
may not be suitable candidates for languages for development. For example,
serverless. 02 03 AWS Lambda supports Node.js, Python
and Java; Azure Functions support C#,
Javascript and (preview of F#, Python,
Batch, PHP, PowerShell); and, Google
Functions supports only Javascript. Hence,
selection of the platform may dictate the
Cold start: Cold start happens when an inactive (i.e.
choice of language for development.
cold) function is invoked for the first time. This is
typically the time taken by the underlying container
running the function to load the runtime along with
the libraries and associated dependencies. Cold 04
starts can increase the execution time significantly
and affect application performance if not handled
appropriately. One way of addressing this bottleneck
is to ensure functions stay alive (i.e. hot)
Functions don’t allow file systems level
before execution.
access: This essentially means features
like reading attributes from configuration
Functions provide limited ability files or spilling over in-memory cache to
to configure database indexes: disk is not supported. Hence, serverless
Use of relational database in
05 06 may not be the right architectural model
serverless architectures creates for applications requiring file system level
scalability and performance access or operating system level access.
challenges due to limitations
of the number of simultaneous
connections that can be opened
in relational databases. Instead Comes with built-in logging & monitoring
NoSQL databases can be the mechanisms: Serverless services today comes with
preferred choice. In addition, there their own in-built logging and monitoring mechanisms 9.
can be limitations with regard to This can be an architectural and operational shift in case
configuring nodes and indexes.
07 an enterprise has been using custom tools for similar
purposes.

7.
 Containerization involves splitting applications into small parts, or containers, all sharing the same underlying operating system
8.
 For example, AWS Lambda and Azure Functions have maximum execution time (per request) of 300 seconds (i.e. 5 minutes)
9.
 For example, AWS Lambda supports CloudWatch and Azure Functions support App Service monitoring

08
 Serverless Computing – Architectural Considerations & Principles

Recommended serverless architectural principles

We believe designing the appropriate technology architecture, aligned to the business requirements is the foundation
for capitalizing on the technology innovations to drive competitive advantage in business. This is the reason why
companies like are Netflix, Amazon are successful. CIOs and Senior IT executives will need to realize this fact and the
sooner they do its better.

Below are some of the industry recommended guiding principles or best practices that can be kept in mind while
architecting serverless systems:

Develop single-purpose functions that

are stateless: Since functions are stateless
and persists for a limited duration only, it is
recommended to write single-purpose codes
for function. This limits the execution time of a

01
function which has a direct impact on cost. In
addition, single purpose codes are easier to test,
deploy and release thus improving enterprise
agility. Finally, even though statelessness may
be perceived as a limitation, it provides infinite
scalability to a platform to handle an increasing
number of requests, which otherwise would not
Design push-based, event-driven
have been possible.
patterns: Designing push-based and

02
event-driven architecture patterns
Create thicker and powerful frontends: where a chain of events propagate
Executing more complex functionality at the without any user input imparts
front-end especially through rich client-side scalability to an architecture.
application framework helps reduce cost by
minimizing function calls and execution times.

03
Completely decoupling back-end logic from the
front-end while not compromising on security is
Incorporate appropriate security
one way of doing. This also allows more services
mechanism across the technology
to be accessed from front-end resulting in
stack: Appropriate security
better application performance and richer user
mechanisms must be incorporated at
experience.
the API Gateway layer and also at the

04 FaaS layer. These security mechanisms

include features like access controls,
authentication, identify and access
management, encryption and
Identify performance bottlenecks: On-going
establishing trust relationship etc.
measurement of performance bottlenecks in

05
terms of identifying which functions are slowing
down a particular service is critical to ensure
optimal customer experience. Leverage third party services:
Serverless being an emerging field
existing enterprise tools for various
services like logging, monitoring etc.

06 may not be compatible. Choosing the

right third party tools for executing the
task at hand will be key for enterprises
to ensure the benefits of serverless are
utilized to the fullest.

10.
 S erverless: The future of cloud computing by Peter Sbarski, ServerlessConf, 2016

09
Serverless Computing – Architectural Considerations & Principles

Conclusion

With the right architectural legacy monolithic model with the before mainstream adoption happens.
considerations and due diligence, serverless paradigm where the Serverless has the potential to change
serverless may present industry focus isn’t on infrastructure but on the economic model of IT consumption
incumbents with an exit strategy delivering the required business of enterprises leading to significant
to move from legacy infrastructure functionalities which in turn changes cost reductions associated primarily
to adopt public cloud models – this the economic model for IT service with IT support and maintenance
was not observed earlier. However, delivery. (which can be a significant 50 – 60%
industry incumbents will need of the total IT budget of enterprises),
move away from the status-quo and There are concerns though with regard reduce time-to-market and foster
embrace the change. A structured to vendor lock-in and adherence innovation to support changing
approach with a defined roadmap to industry specific compliance business requirements and provide an
is required to move away from requirements in a serverless model. edge over competitors.
the current software architecture Like any emerging technology,
paradigms which is based on the Serverless will go through its cycle

10
Serverless Computing – Architectural Considerations & Principles

11
Contacts
Rakesh Barik
Partner, Technology Consulting Leader
Deloitte Touche Tohmatsu India LLP
E-mail: [email protected]

Anubrata Chakrabarti
Partner, Consulting
Technology Strategy & Architecture
E-mail: [email protected]

Ritesh Pal
Manager, Consulting
Technology Strategy & Architecture
E-mail: [email protected]

Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company
limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL
and each of its member firms are legally separate and independent entities. DTTL (also
referred to as “Deloitte Global”) does not provide services to clients. Please see www.deloitte.
com/about for a more detailed description of DTTL and its member firms.

The information contained in this material is meant for internal purposes and use only
among personnel of Deloitte Touche Tohmatsu Limited, its member firms, and their related
entities (collectively, the “Deloitte Network”). The recipient is strictly prohibited from further
circulation of this material. Any breach of this requirement may invite disciplinary action
(which may include dismissal) and/or prosecution. None of the Deloitte Network shall be
responsible for any loss whatsoever sustained by any person who relies on this material.

©2018 Deloitte Touche Tohmatsu India LLP. Member of Deloitte Touche Tohmatsu Limited