Build ’em now! 5 uses for serverless frameworks

It’s easy to be befuddled about “serverless” or “function as a service” architectures. For one, “serverless” is a bit of a misnomer — there are servers, but you don’t have to maintain them. All you do is upload a snippet of code and let the hosting service handle the rest.

But what sorts of applications are suited to this kind of deployment? The answers tend to be the same whether you’re dealing with AWS Lambda or Azure Functions; the designs of those systems all depend on blocks of code triggered by specific actions. Here are five common kinds of apps built out of such pieces.

APIs

This is one of the simplest and most direct applications for a serverless architecture: creating REST APIs that return data to be consumed by either another service or by a single-page application.

REST APIs in general are not hard to build. Most of the time, all you need is a basic web framework, a library for rendering data in the format you’re returning (typically JSON), and whatever glue code is needed to talk to the back end from which you’re pulling data. With a serverless architecture, the developer can focus exclusively on writing and deploying the code needed to serve the API, and not be distracted by much else.

Many common functions that need hand-tuning in a REST API, like autoscaling to meet demand, are addressed automatically by serverless frameworks. Plus, the pay-what-you-use model that’s become the staple of cloud pricing means a lightweight, minimally accessed API costs next to nothing to deploy.

Creating webhooks

This widely adopted mechanism of callbacks over HTTP is a common strategy to implement push, pipes, and plugins — all of which increase the utility of web applications. Serverless frameworks are particularly well suited for webhooks for the same reason they’re useful for creating APIs generally: low overhead, minimal maintenance, automatic scaling. For example, a webhook can be implemented on Azure Functions with Node.js to process SMS messages or phone calls through the Twilio service.

What’s more, most webhook-type actions don’t need a lot of code to get to work. Thus, they’re ideal for the function-oriented approach provided by a lambda-style serverless setup and less likely to outgrow such a delivery mechanism.

Serving static content

Serverless architectures also provide a straightforward method to serve up static content: images, audio, or HTML pages that aren’t modified by an application. Static assets can be stored on a number of back ends, including an Amazon S3 bucket, and be accelerated through a geolocated cache, such as Cloudflare. (If you’re using S3, it’s possible to choose Amazon Route 53 to map URLs to specific resources; AWS Lambda itself isn’t even needed for these rudimentary cases.)

Again, the big advantage is that each piece of the puzzle automatically scales to fit demand. It’s also relatively easy to add dynamic functionality over time if needed. However, with this approach, spin-up time for the function might impact performance, so geocaching becomes more useful.

Single-page applications

Think of this as a combination of the above approaches. The basic assets for a page can be served as static content; to render data on the front end, the necessary API calls can be implemented as serverless functions. Rendering of data happens on the front end via a JavaScript framework.

Upside: Each separately served element of the application can scale independently. Downside: The app has to be implemented as a collection of disparate functions rather than a single unified project, though this shouldn’t be much of a hurdle for anyone using modern source control and project management techniques. Also, you’ll need to implement a front-end framework like React, Angular, or Vue.js — but again, any self-respecting web developer should already have at least one of them.

Event-driven applications that run in the background

Serverless apps run in response to events, but nothing says an event has to be a HTTP request. It could be an event or a message piped in from a cloud service or triggered to run on a schedule — a convenient method to perform passive or low-priority functions. For example, an image uploaded to an S3 bucket could trigger a function that causes the image to be labeled with appropriate metadata, resized, and cropped based on feedback from an image recognition or analysis API.

The most consistent detail about working with serverless frameworks right now is that they involve creating loosely coupled components — microservices, for lack of a better word. If the app you have in mind doesn’t lend itself to being composed in this manner or if you’re trying to port a monolithic app that will be difficult to pull apart and rework, don’t shoehorn a serverless setup into that role. Build new, little elements, and grow them from there.