New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

FaaS, PaaS, and the Benefits of the Serverless Architecture

| by Abel Avram on Jun 25, 2016. Estimated reading time: 6 minutes |

This article discusses what serverless is, comparing it with PaaS and SPaaS, the benefits and costs of a serverless architecture and the need for a framework.

Initially, serverless meant developers did not have to care for setting up and administering the servers running their back-end applications. Not that there were no servers involved, but the back-end infrastructure was maintained by third party providers and the functionality needed was offered as services, covering databases, messaging, authentication, etc. This service infrastructure was usually called Backend-as-a-Service (BaaS) or Mobile Backend-as-a-service (MBaaS).

But Amazon took the serverless paradigm to another level when they announced AWS Lambda back in 2014, introducing a new system architecture for applications running in the cloud. There is no perpetual process running on a server and waiting for HTTP requests or API calls, but an event mechanism that triggers the execution of a piece of code, usually just a function, on one of AWS’ servers.

One does not have to consider the server when using this paradigm. All that matters is to write the piece of code to be executed when a certain event takes place. The cloud provider takes care of finding a server where the code is to run, and to scale up when necessary. The containers used to run these functions are decommissioned as soon as the execution ends. And the execution is metered in units of 100 ms, the user being charged only for the resources consumed when the code is run. Some have called this type of functionality Function-as-a-Service (FaaS), which is Yet-Another-as-a-Service (YAssS), one of many that have appeared since cloud computing made its debut.

Amazon is not the only FaaS provider. Others include Google Cloud Functions, Microsoft Azure Functions, IBM OpenWhisk with an open source implementation,, and Webtask.

The serverless architecture goes well with nanoservices. If a microservice is a process meant to address a relative small business capability, a nanoservice deals with a fraction of the respective capability. For example, a microservice could be represented by the code needed to perform all CRUD operations on an account, while there is a nanoservice for each account operation: create, read, update, and delete. When a “Create Account” event is triggered, the respective nanoservice is executed as a AWS Lambda function. Few use the term nanoservice, most preferring microservice or even just service.

Some consider FaaS as just another PaaS, but Mike Roberts, VP of Engineering at Intent Media, has another opinion:

Most PaaS applications are not geared towards bringing entire applications up and down for every request, whereas FaaS platforms do exactly this. …

The key operational difference between FaaS and PaaS is scaling. With most PaaS’s you still need to think about scale, e.g. with Heroku how many Dynos you want to run. With a FaaS application this is completely transparent. Even if you setup your PaaS application to auto-scale you won’t be doing this to the level of individual requests (unless you have a very specifically shaped traffic profile), and so a FaaS application is much more efficient when it comes to costs.

Roberts did not consider that everybody should dump PaaS and start using FaaS, naming a few reasons: “tooling, and maturity of API gateways, are probably the biggest. Furthermore, 12-Factor Apps implemented in a PaaS may use an in-app read-only cache for optimization, which isn’t an option for FaaS functions.”

Camille Fournier, who calls herself a Senior Thinker and Raconteur, wondered in a tweet “if serverless services will become a thing like stored procedures, a good idea that quickly turns into massive technical debt.” Addressing this issue, Roberts considered that FaaS could be replaced with SPaaS (Stored-Procedures-as-a-Services) only if serverless functions are just “small pieces of code that wrap access to a database.” But since FaaS functions can be used for many other purposes, the comparison is invalid. He also noted that unlike stored procedures, serverless functions do not require a vendor-specific language or framework, they can be tested and can be versioned easily.

Discussing serverless architectures, Badri Janakiraman, a ThoughtWorks developer, noted a shift introduced by FaaS: the long-lived server process which usually contains most of the logic is broken down into proprietary and third party services while the flow control of the application moves to the client:

Serverless applications often make extensive use of third party services to accomplish tasks that are traditionally taken care of by servers. These services could be rich ecosystems of services that interoperate, such as Amazon AWS and Azure, or they could be a single service that attempt to provide turnkey set of capabilities such a Parse or Firebase. The abstraction provided by these services could be infrastructural (such as message queues, databases, edge caching…) or higher-level (federated identify, role and capability management, search…).

One of the primary responsibilities of a general purpose server based web application is to control the request-response cycle. Controllers on the server side process input, invoke appropriate application behavior and construct dynamic responses, typically using a templating engine. In a serverless application, where application behavior is woven together from third party services, client side control flow and dynamic content generation replaces the server side controllers. Rich JavaScript applications, mobile applications (and increasingly, TV or embedded IoT applications) coordinate the interaction between the various services by making API calls and using client side UI frameworks to the generate dynamic content.

Regarding the benefits of implementing a serverless application, Janakiraman listed a significant reduction in costs because one does not have to pay for renting an entire server in the cloud but only for resourced consumed during execution; scalability, because it is easy to scale independent services triggered to action by events; and the lack of operating and maintaining infrastructure. When it comes to costs, Janakiraman remarked the “conceptual overhead of splitting a single application into something that woven from a fabric of services is significant and increases with the number and variety of services used,” and the raise in development and testing complexity.

And there is another hidden cost in using a serverless approach when creating an entire back-end based on FaaS. explains in their documentation:

While AWS Lambda offers a powerful new way of developing/running applications, when we began building our first project based entirely on AWS Lambda, we realized structure was badly needed. Managing all of the containers that Lambda introduces is a difficult task. Add to that multi-developer teams, multi-stage and multi-region support and you will quickly get into a messy situation.

For that purpose, Serverless Inc. has created the Serverless Framework, an open source project meant to help with building web, mobile, and IoT applications with FaaS. Currently working with AWS Lambda, the creators of the framework intend to support other providers in the future. The framework has a number of features, including: running and testing Lambda functions locally or remotely, deploying Lambda functions, deploying REST APIs to the AWS API Gateway, deploying Lambda events, support for multiple AWS regions, and others. The supported languages are JavaScript/Node.js, Python and they are working on adding Java to the mix. Other languages will be added later.

Another serverless framework is Apex, with similar functionality, support for AWS, JavaScript/Node.js, Go, Java and Python and plans to support other providers in the future.

For those interesting in learning more on the serverless architecture, Werner Vogels, CTO at, has published a number of reference architectures for building applications with AWS Lambda. He provided guidance on creating a Mobile Back-end, a Real-time File Processing, a Web Application, a Back-end for IoT, and a Real-time Stream Processing based on Kinesis. The principles outlined in these reference architectures are applicable to other FaaS providers, the only change being the services used.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

IaaS + PaaS by Azaz Qadir

IaaS + PaaS has made my life really easy. I have been hosting my website on AWS EC2 with Cloudways managed hosting. I don't need to own any hardware nor do I need to hire a networking staff. This is because my website are hosting on AWS servers at their datacenter and server management and maintenance is handled by Cloudways.

What's the catch by Stéphane Wojewoda

Reading this news, I feel pretty uneasy. There are lots of buzzwords and YAaaS, and lambda architecture has some great use cases. Though, I'm wondering:

1) what is really new there: giving a computer an order to act only as required? Seems like a batch process you could find on the first micro-computers. The really new stuff is the cloud-base part, implying that you do not need to own it, you can pay per use. So what we are talking about is commoditizing action.

2) what is the real total cost for the planet of such a process? what the net profit or cost of idle-serverless architecture? As a developer, a CEO, I may pay less. I'm pretty sure that owning servers is not efficient (in a P&L view), but there are other objectives for a company, small or big that the bottom line.
But, as a citizen, what do I pay by the end of the day? What is the legacy for my children? What's my responsibilities here? I wonder.

Startup overhead by Sanjay Bhl

These FaaS services seemingly run for s/ms/ns. But what is the overhead to start them is it seconds/minutes. That is typical deploy start for any typical service I deploy. I have my services running - eliminate starting overhead. And if your FaaS depends on other FaaS - you have a daisy chain, despite failure recovery mechanisms - it could lead to a mess. Am I thinking right?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you