Over the past two decades, considerable innovation has gone into making sure developers don’t have to think much about the underlying physical machine their code runs on. Serverless computing is a paradigm that takes this objective to its logical conclusion. With serverless, you don’t have to know anything about the hardware or operating system your code runs on, as it’s all managed for you by a service provider. While the segment has had its ups and downs, it’s currently on the upswing: A recent report from SkyQuest technology projected that serverless computing would be a $50 billion market by 2031.
What is serverless computing?
Serverless computing is an execution model for the cloud in which a cloud provider dynamically allocates only the compute resources and storage needed to execute a particular piece of code. Naturally, there are still servers involved, but the provider manages the provisioning and maintenance. The user is charged for the resources consumed along with the maintenance and whatever other fees might be tacked on. In an ideal serverless scenario, there would be no servers to manage or provision at all: No bare metal, nothing virtual, no containers. Serverless users are not involved with managing a host, patching a host, or dealing with anything on an operating system level.
Serverless has been used to describe back-end-as-a-service scenarios, where a mobile app would connect to a back-end server hosted entirely in the cloud. But when people talk about serverless computing or serverless architectures, they usually mean function-as-a-service (FaaS), in which a customer writes code that only tackles business logic and uploads it to a provider. That’s our definition for this article: The provider handles all the hardware provisioning, virtual machine and container management, and even tasks like multithreading that often are built into application code. All that’s left to do is provide the functions that specifically implement the application’s business logic.
How serverless computing works
In a FaaS serverless environment, functions are event-driven, meaning the code is invoked only when triggered by a request. Requests can include things like API calls, HTTP requests, or file uploads; they could also be triggered by a scheduler if your application involves tasks that happen regularly.
You would deploy these functions on a specific serverless platform. As we’ll discuss below, there are many serverless providers to choose from, each with strengths and weaknesses. You would generally tailor the code for your function to the platform where you plan to deploy it. The provider charges only for compute time used by that execution, rather than a flat monthly fee for maintaining a physical or virtual server. These functions can be connected to create a processing pipeline, or they can serve as components of a larger application, interacting with other code running in containers or on conventional servers.
Benefits and drawbacks of serverless computing
Based on what you’ve read so far, the major benefits of serverless computing should be clear:
Developers can focus on the business goals of the code they write, rather than on infrastructure questions. This simplifies and speeds up the development process and improves developer productivity.
Organizations only pay for the compute resources they use in a very granular fashion, rather than buying physical hardware or renting cloud instances that mostly sit idle. That latter point is of particular benefit to event-driven applications that are idle much of the time but under certain conditions must handle many event requests at once. Rather than provisioning a beefy server that is underused most of the time, with a serverless architecture, you only pay for the server resources you need.
But there are a few drawbacks, as well:
An obvious one is that serverless functions are intentionally ephemeral and often not suitable for long-term tasks. Most serverless providers won’t let your code execute for more than a few minutes, and when you spin up a function, it doesn’t retain any stateful data from previously run instances.
A related problem is that serverless code can take as long as several seconds to spin up—not a problem for many use cases, but if your application requires low latency, be warned.
Serverless functions also must be tailored to the specific platform they run on. This can result in vendor lock-in and less flexibility. Although there are open source options available, the serverless market is dominated by the big three commercial cloud providers (more about vendors shortly). Development teams often end up using tooling from their serverless vendor, which makes it hard to switch. And because so much of serverless computing takes place on the vendor’s infrastructure, it can be difficult to integrate serverless code into in-house development and testing pipelines.
Breaking down the pros and cons should provide insight into how serverless computing could be useful to you. It’s also helpful to be aware of the most common real-world applications for the technology:
Batch processing of files or data. One of the canonical examples of a serverless architecture use case is a service that uploads and processes a series of individual image files and sends them along to another part of the application. These sorts of compute-intensive but only occasionally necessary bursts of activity are a great fit for the serverless pay-for-the-compute-you-use model.
Scheduled or trigger-based tasks. Serverless functions can generate reports or backup images, send notifications, or perform other simple business logic, either in response to triggers delivered via APIs or HTTP calls or on a specified schedule.
Automating CI/CD pipelines. Many of the tasks involved in automating the CI/CD pipelines that power devops are run from serverless platforms.
Building RESTful APIs. Serverless platforms are a great foundation for RESTful API services because they can scale up cost effectively with use. The platforms provide infrastructure management along with high availability and reliability.
Serverless vendors: The big three and beyond
The modern age of serverless computing began with the launch of AWS Lambda, a platform based on Amazon’s cloud service. Microsoft followed suit with Azure Functions, and Google Cloud Functions reached production status after that. Martin Heller has a good rundown of serverless providers and how to choose a serverless platform. Offerings that have emerged in the past few years include Vercel Functions, Netlify Functions, Cloudflare Workers, and Fastify Serverless.
Also see: Serverless computing’s second act.
Serverless databases
One quirk of working with serverless code is that has no persistent state, which means the values of local variables don’t persist across instantiations. Any persistent data your code needs to access must be stored elsewhere. The triggers available in the stacks for the major vendors all include databases that your functions can interact with.
Some of these databases are themselves referred to as serverless. This means they behave much like other serverless functions discussed so far, with the obvious exception that data is stored indefinitely. But much of the management overhead involved in provisioning and maintaining a database is cast aside. As with function-as-a-service offerings, you only pay for the compute time you actually use, and resources are spun up and down as needed to match demand. Jozef de Vries discusses the pros and cons of a serverless database in Is a serverless database right for your workload?
The big three serverless providers each offer their own serverless databases: Amazon has Aurora Serverless and DynamoDB (the latter a NoSQL offering); Microsoft has Azure Cosmos DB, and Google has Cloud Firestore. These aren’t the only databases available, though, and much of what’s available is platform-agnostic. The list includes serverless variants of popular databases like CockroachDB and newer offerings catering to generative AI, such as the Pinecone Serverless vector database.
Serverless computing, Kubernetes, and Knative
Containers help power serverless technology under the hood, but the overhead of managing them is handled by the vendor and thus invisible to the user. Many see serverless computing as a way to get the advantages of containerized microservices without having to deal with their complexity. In fact, containers and serverless computing can complement each other, with serverless functions existing in the same application as containerized microservices.
Kubernetes, the most popular container orchestration platform, can enter the serverless world thanks to the open source extension Knative. With Knative, any container that runs on Kubernetes can be run as a serverless workflow in a way that’s transparent to container developers.
Knative is one example of a serverless framework—a set of infrastructure tools that provide the basis on which your code runs and does much of the work of interacting with the underlying platform. Unlike Knative, many serverless frameworks are tied to specific vendor platforms (there’s that vendor lock-in problem again) and will define much about how you end up building your application. Amazon has its own native offering, the open source Serverless Application Model (SAM), but there are others as well, some of which are cross-platform and also open source.
Get started with serverless computing
Starting out with serverless computing can be daunting, as it seems like you’d need to sign up with a vendor to even find out how it works. But fear not: There are ways to run serverless code offline on your own local hardware. For instance, the AWS SAM (Serverless Application Model) provides a Local feature that allows you to test AWS Lambda code offline. And, if you’re using the serverless application framework, check out serverless-offline, a plugin that lets you run code locally.
Happy experimenting!