Use Cases

In the previous section, we saw one example use case: The CMS Bartholomew is completely serverless and powers Fermyon.com. In this section, we’ll look at several other areas where serverless applications really shine.

Serverless apps are great for:

• writing microservices and web application backends. Frequently, these run for only milliseconds or seconds per request and already store state in a database.
• running REST APIs. Speed is of the essence with REST APIs, making nearly instant startup times like Spin’s really shine.
• AI inferencing (e.g. as with LLMs). Inferences are often done infrequently, and the state persists only for short sessions. The combination of a serverless architecture, state storage like key/value storage and burstable access to GPUs can make an otherwise very expensive application far cheaper to operate. handling webhooks. Webhooks are run only intermittently, often as rarely as a few times a day or week. This makes them a perfect fit for serverless applications, which are cheaper to operate for intermittent workloads.
• acting as chatbots. Like webhooks, most of a chatbot’s lifetime is idle. Only when the bot receives a request does it do anything. Again, this is an excellent application of serverless functions.
• serving static sites. This is straightforward enough that it can be done out of the box with Fermyon Cloud.
• reading and writing data to a publish/subscribe (pubsub) message queue. We built a game called Finicky Whiskers to showcase this. We also wrote a detailed blog series about how it works.
• responding to cloud events. Each cloud provider has its implementation, and many of these are done over HTTP. That means that many different serverless app platforms can work with cloud-specific events.
• periodically running to do discrete (and short) chunks of work, much like Cron in UNIX systems.

So, what are use cases that should be avoided?

• Apps that require in-memory state. Many existing enterprise applications rely on an in-memory state for things like atomic counters or caches. (Though many of these can be rewritten to use external state storage.)
• Apps that require frequent low-level disk I/O. Serverless apps tend to mount slow network volumes for frequent disk I/O. Likewise, technologies like WebAssembly insert security layers between an app and storage. For normal file access, the time added for security checks is not noticeable. But thousands of disk I/O operations per request will begin to introduce latency.
• Applications that must start server sockets. Server sockets are long-running and tend to work against the design paradigm of serverless applications. Most serverless application platforms will terminate an app that runs too long, making running a socket server untenable.