How are serverless computing and Platform-as-a-Service different? | PaaS vs. Serverless

Although both PaaS and serverless computing involve no backend management from the developer, several factors separate the two models, including scalability, pricing, and the ability to deploy at the network edge.

Share

Serverless vs PaaS

Learning Objectives

After reading this article you will be able to:

  • Be able to compare and contrast PaaS and serverless
  • Understand why the ability to run code on the network's edge is important

How are serverless computing and Platform-as-a-Service (PaaS) different?

Because both serverless computing and Platform-as-a-Service (PaaS) backend architectures keep the entire backend invisible to developers, they are somewhat similar. However, several big differences separate the two kinds of architecture, and most use cases will work best with either one or the other, but not with both. The major divergences between PaaS and serverless are scalability, pricing, startup time, tooling, and the ability to deploy at the network edge.

Serverless and PaaS Comparison

Which scales better, PaaS or serverless architecture?

Serverless applications scale instantly, automatically, and on demand, without any extra configuration from the developer or the vendor. They are able to scale up by definition. In contrast, while developers can program PaaS-hosted applications to scale up and down with user demand, this is not an intrinsic feature of PaaS, and developers will have to do a certain amount of forecasting to properly scale.

Serverless computing can be compared to drawing water from a tap, with water representing computing power. A tap in a modern home can be switched on at any time and can produce as much water as is necessary. PaaS is more like using a water dispenser and a water bottle delivery service. It is still possible to obtain as much drinking water as is needed, but it is not as simple as turning on the tap; the consumer has to ask the vendor to deliver more if demand increases. In both scenarios, someone else is handling the 'backend' – purifying the water, bringing it to the building, etc. – but only tap water can be scaled precisely, on demand, and in real time.

A serverless architecture is able to scale up quickly by spinning up new instances of application functions as they are requested. It also scales down quickly by shutting functions down when they are no longer needed or once they have run for a set time period. In fact, a serverless web application is able to scale all the way down to no activity and then start up again in response to an event within seconds, or milliseconds. Applications built on PaaS are not able to scale up and down so quickly or to such a degree.

How is pricing different between PaaS and serverless?

To continue the water metaphor, consumers who use water from the tap pay for exactly as much water as they use. Similarly, serverless billing is extremely precise, and developers only pay for what they use. Some serverless vendors only charge developers for the precise amount of time their functions are running, down to fractions of a second for each individual instance of each function. Other providers charge by the number of requests.

Consumers who use a water dispenser and have jugs of water delivered also only pay for what they use, but they pay by the jug, not by fluid ounces. In the same way, some PaaS vendors charge developers only for what their application uses. However, billing is not nearly as precise as it is for serverless. Other PaaS vendors charge a flat monthly fee for their services. Developers are usually able to customize how much computing power they are paying for. However, this is decided upon in advance and is not responsive to increases and decreases in usage in real time.

This difference does not necessarily mean that serverless architecture is always more affordable. Just as it quickly becomes prohibitively expensive to constantly have a water tap running, web applications that have a large, constant stream of usage that does not fluctuate much may become expensive to run using serverless computing.

What is the difference in launch time between PaaS and serverless applications?

As described above, serverless applications can be active almost instantly, as soon as an event triggers an application function. PaaS-built applications can be up and running quickly, but they are not as lightweight as serverless applications and take longer to be up and running. To avoid latency from the user's perspective, at least some functions of PaaS applications have to be running most of the time or all the time.

What tools do PaaS and serverless vendors provide?

Generally speaking, PaaS vendors will provide developers with more tools to build and manage their applications, including tools for testing and debugging. Because serverless applications do not run on specified machines, virtual or otherwise, and serverless functions should run the same no matter what, serverless vendors may provide some tools, but they do not provide a complete environment for building and testing the application.

Can serverless applications be deployed on the network edge?

Serverless code does not run in specific servers and can run anywhere on any part of the Internet, which makes it possible to deploy serverless applications very close to end users on the network edge, vastly reducing latency. Service workers and Cloudflare Workers are examples of serverless functions that run close to the user (see How Does Serverless JavaScript Work?).

Can applications built using PaaS be deployed on the network edge?

From the developer's point of view, there are no servers in PaaS. However, PaaS is still different from serverless computing in terms of where the code is hosted. PaaS vendors will either leverage another vendor's IaaS (Infrastructure-as-a-Service) offering or will have their own physical data centers. The result is that applications built on a cloud platform will likely run on certain designated machines only, preventing developers from optimizing their application's performance by running code at the edge.