Many types of computing problem can be solved with a serverless design. Personally speaking, I have a hard time not using serverless systems nowadays due to the speed, flexibility, and adaptability they provide. The classes of problem that are suitable for serverless systems are extensive. Still, there is a sweet spot that is good to keep in mind when approaching new problems. Outside of the sweet spot, there are problems that are not a good fit.
When to use serverless
The sweet spot
Since serverless systems work on the basis of a single function, they are well suited to problems that are, or can be broken down into, the following subsystems:
- Stateless
- Computationally small and predictable
Serverless functions are ephemeral; that is, they have a known lifetime. Computation that is itself stateless is the type of problem where FaaS platforms shine. Application state may exist, and functions may store that state using a database or some other kind of data store, but the functions themselves retain no state between invocations.
In terms of computing resources, serverless functions have an upper bound, both in memory and total duration. Your software should have an expected or predictable upper limit that is below that of your FaaS provider. At the time of writing, AWS Lambda functions have an upper bound of 1,536 MB for memory and 300 seconds in duration. Google Compute advertises an upper limit of 540 seconds. Regardless of the actual values, systems, where you can reliably play within these bounds, are good candidates for moving to serverless architecture.
A good, albeit trivial, an example of this would be a data transformation function—given some input data, transform it into a different data structure. It should be clear with such a simple example that no state needs to be or is carried between one invocation and the next. Of course, data comes in various sizes, but if your system is fed data of a predictable size, you should be able to process the data within a certain timeframe.
In contrast, long-running processes that share state are not good fits for serverless. The reason for this is that functions die at the end of their life, leaving any in-memory state to die with them. Imagine a long-running process such as an application server handling WebSocket connections.
WebSockets are, by definition, stateful and can be compared to a phone call—a client opens up a connection to a server that is kept open as long as the client would like. Scenarios such as this are not a good fit for serverless functions for the two following reasons:
- State exists (i.e., state of a phone call is connected or disconnected)
- The process is long-lived because the connection can remain open for hours or days
Whenever I approach a new problem and begin to consider serverless, I ask myself these two questions:
- Is there any global state involved that needs to be kept track of within the application code?
- Is the computation to be performed beyond the system limits of my serverless platform?
The good news is that, very often, the answer to these questions is no and I can move forward and build my application using a serverless architecture.
