Serverless: A simple overview

Serverless is a trend in computing that decouples the execution of code, such as in web applications, from the need to maintain servers to run that code. The operational overhead to create, provision, and care for applications running on servers (in the traditional sense) is significant. Reducing or eliminating that work can help organizations manage costs and free up time for staff. Serverless also offers an innovative billing model and easier scalability.

In What is Serverless?, authors Mike Roberts and John Chapin identify the core insight that makes serverless unique:

With a fully serverless app, you are no longer thinking about any part of your architecture as a resource running on a host. All of your logic—whether you’ve coded it yourself, or whether you are integrated with a third-party service—runs within a completely elastic operating environment. Your state is also stored in a similarly elastic form. Serverless doesn’t mean the servers have gone away; it means that you don’t need to worry about them any more.

Different flavors of serverless

Serverless technologies come in a few different versions. While AWS Lambda is viewed as the specific technology that kicked off the movement, other vendors offer platforms for reducing operational overhead. Serverless offerings tend to fall into two types:

1. Backends as a Service (BaaS) – BaaS provides serverless approaches to handle things like storage, authentication, and user management. AWS Aurora Serverless is an example of a BaaS offering.
2. Functions as a Service (FaaS) – FaaS platforms run code in discrete “function” units that are invoked as needed. AWS Lambda is the canonical example and can be invoked from applications directly or triggered by other AWS services.

Some of the different use cases for these types of serverless are outlined below.

Serverless for APIs

Using cloud infrastructure such as API Gateway, end users can construct entire services that are invoked as needed instead of listening constantly. The cloud provider will route incoming requests to the correct serverless function, which will then do the work and write the response back to the end user.

This allows for the development of APIs that only bill when they are used, and can be scaled out massively with minimal changes. Slobodan Stojanovic and Aleksandar Simovic’s book Serverless Applications with Node.js offers an example as to why you would want to use serverless for APIs:

To understand serverless, consider for a moment washing machines. A clothes-cleaning appliance might sound like a crazy place to start, but owning a server nowadays is similar to owning a washing machine. Everybody needs clean clothes, and the most logical solution seems to be buying a washing machine. But most of the time the washing machine is plugged in, doing nothing. At best, it’s used 5 to 15 hours per week. The same goes with servers. Most of the time, your average application server is just waiting to receive a request, doing nothing.

Serverless for storage

Traditionally, managing data storage for web applications has been one of the most difficult parts of operating an application, and database administration can sometimes seem like a dark art. But the introduction of serverless data stores, such as Firebase and Aurora, have freed developers from worrying about optimizing instance types, executing backups, and other operational database woes.

Instead, cloud providers handle hosting the data store for the end users. The providers frequently have billing models that are pay-as-you-go. The data stores are fast by default and often have flexibility that appeals to developers, such as a lack of predefined schemas.

Serverless for cloud events

In the cloud landscape, applications are born and live their whole lives in platforms such as Amazon Web Services. This is in contrast to applications that are more “traditional” and may be intended to run on generic commodity hardware in self-operated data centers. Since cloud-based applications operate at a higher level of abstraction, they can also work with “events” that inform end users of what is occuring in the abstracted infrastructure, thus obviating the burden of figuring this out from lower-level pieces such as filesystem APIs. Serverless truly comes into its own when engineers have a need to react to events happening on a cloud platform. As one example of efficiency for cloud events, developers might want to do something when a new file is pushed to an S3 bucket, such as modifying its dimensions and publishing the new file elsewhere.

By using the cloud provider’s native abstraction for these events, the development and deployment burden is greatly reduced. This allows for creative new architectures that scale well and can even be weaved together into large data transformation pipelines. An example using S3 events can be found in Peter Sbarski’s Serverless Architectures on AWS.

Other serverless use cases

Serverless has other use cases as well, said Mike Roberts, co-founder of Symphonia, in an interview. For instance, any system that can be modeled as a set of asynchronous, “real-time” (i.e., faster than human perception) events can benefit from the use of serverless to react to all of those events quickly. This could come in handy for use cases that have inconsistent request patterns such as webhooks. A webhook might not fire off very often, but when it does, having a serverless function perform the work instead of a process on a server reserving compute power around the clock could translate to big cost and operational savings for businesses.

One area where companies like to experiment with serverless is with operations and on-call related automation. Alerts, auto-scaling, chat bots that respond to user messages, and more all fit into a niche of asymmetrically invoked work that is useful, but safer to experiment with as it’s not directly end-user facing. Once these systems have been proven successful, a company might feel more comfortable rolling out user-facing services to production using serverless.

When to use serverless

One of the biggest benefits that serverless has to offer is its ability to decrease the amount of time it takes to get something to market. Not having to worry as much about ordering and configuring servers might free engineers to focus on other tasks, such as shipping software quickly. Likewise, as serverless offerings continue to move up the stack to make web applications easier to snap together, the labor cost can be reduced dramatically as much less code needs to be written and maintained.

Reducing toil not only has a direct monetary benefit, it also leads to happier, more productive developers. When a developer knows that taking an idea from conception to production is likely to have fewer stumbling blocks and operational burdens, more software is likely to get shipped and better products are more likely to be made.

Serverless obstacles

Serverless is a relatively new technology and best practices are still being refined. As such, serverless is a good fit for the forward thinking who don’t mind rolling up their sleeves and are comfortable with ambiguity and risk.

One specific area those new to serverless should watch out for is its less predictable usage model. A traditional setup using something like AWS EC2 has a more predictable billing cost, as the cost is based on things mostly known ahead of time, such as the instance type, how many hours it will be running, and bandwidth usage. Serverless, on the other hand, has a high ceiling for horizontal scalability, which makes scaling up easier, but also makes accumulating billing charges easier. Likewise, invoking serverless functions might be inexpensive, the cost of writing their outputs to a logging utility could end up generating high costs faster than expected. For instance, AWS CloudWatch logging costs will increase rapidly as AWS Lambdas write to it. Further charges can be incurred if third-party monitoring tools such as Datadog also ingest this data from CloudWatch.

Lastly, understanding what a serverless vendor is actually committing to can be fuzzy. With traditional servers, an agreement about the availability and resources allocated to your machine is well understood up front and detailed in contracts. With serverless, cold start times, errored function invocations, and other “gotchas” potentially lurk around the corner. These might end up being a deal breaker for your intended use case. For instance, Mike Roberts says applications that require sub-millisecond response times are still not a good fit for most serverless offerings today. Like any new paradigm, clear expectations and ways to deal with shortcomings are likely to mature over time, but for now, serverless users are left to do their own experimentation.

Learn more about serverless

Check out the following resources for guidance on where and how you can apply serverless in your organization.

What is Serverless? by Mike Roberts and John Chapin is a great introduction to the big ideas of serverless.

In Cloud Native from Boris Scholl, Peter Jausovec, and Trent Swanson, you can learn more about how serverless fits into the cloud native movement.

Microservice Architecture by Mike Amundsen, Matt McLarty, Ronnie Mitra, and Irakli Nadareishvili, helps you understand when and where to use microservices, which you might decide is a direction you’d like to pursue if you go serverless.

In Serverless Applications with Node.js, Slobodan Stojanovic and Aleksandar Simovic explain how to deploy a Node.js API using serverless.

In Serverless Architectures on AWS, Peter Sbarski walks through serverless use cases on the world’s most popular cloud provider.