Communications of the ACM

code, however, was typically limited to mobile use cases.

Software-as-a-Service (SaaS) may support the server-side execution of user-provided functions, but they are executing in the context of an application and hence limited to the application domain. Some SaaS vendors allow the integration of arbitrary code hosted somewhere else and invoked via an API call. For example, this is approach is used by the Google Apps Marketplace in Google Apps for Work.

The boundaries defining serverless
computing functionality overlaps with
PaaS and SaaS. One way to categorize
serverless is to consider the varying lev-
els of developer control over the infra-
structure. In an IaaS model, the devel-
oper has much more control over the
resources, but is responsible for man-
aging both the application code and
operating the infrastructure. This gives
the developer great flexibility and the
ability to customize every aspect of the
application and infrastructure, such
as administering VMs, managing ca-
pacity and utilization, sizing the work-
loads, achieving fault tolerance and
high availability. PaaS abstracts away
VMs and takes care of managing un-
derlying operating systems and capac-
ity, but the developer is responsible for
the full life cycle of the code that is de-
not used the instance is kept running.
Later, GAE added Flexible version
with a more fine-grained billing unit,
but still developers will be billed even
if server is not used. That can lead to
unexpected outcomes when the bill ar-
rives at the end of month for forgotten
test services.g
Mobile Backend as-a-Service (MBaaS)
or more generalized Backend as-a-
Service (BaaS) bears a close resem-
blance to serverless computing. Some
of those services even provided “cloud
functions” (for example, Facebook’s
now-defunct Parse Cloud Code). Such
g https://stackoverflow.com/questions/47125661/
Table 1. Comparison of different choices for cloud as a service.

IaaS 1st Gen PaaS FaaS BaaS/SaaS
Expertise required High Medium Low Low
Developer Control/Customization allowed High Medium Low Very low
Scaling/Cost Requires high-level
of expertise to build
auto-scaling rules and
tune them
Requires high-level
of expertise to build
auto-scaling rules
and tune them
Auto-scaling to work
load requested (function
calls), and only paying
for when running (scale
to zero)

Hidden from users, limits set based on pricing and QoS

Unit of work deployed Low-level infrastructure
building blocks (VMs,
network, storage)

Packaged code that
is deployed and running
as a service
One function execution App-specific extensions

Granularity of billing Medium to large
granularity:
minutes to hours per
resource to years for
discount pricing
Medium to large
granularity:
minutes to hours per
resource to years for
discount pricing
Very low granularity:
hundreds of
milliseconds of function
execution time
Large: typically,
subscription available
based on maximum
number of users
and billed in months