Simply put, serverless systems remove you from having to deal with infrastructure issues, such as storage and compute server provisioning or operations.

Indeed, many refer to serverless as “no-ops,” but it’s really “reduced-ops,” or as my friend Mike Kavis likes to say, “some-ops.” Clearly the objective is to increase simplicity and make building and deploying net-new cloud-based serverless applications much more productive and agile.

But serverless is not always a good idea. Indeed, it seems to be a forced fit a good deal of the time, causing more error than trial. Serverless is an especially bad idea when it comes to stateful applications.

A stateless application means that every transaction is performed as if it were being done for the very first time. There is no previously stored information used for the current transaction. In contrast, a stateful application saves client data from the activities of one session for use in another. The data that is saved is often called the application’s state.

Stateful applications are a bad fit for serverless. 

Why? Serverless applications are made up of sets of services (such as functions) that are short running and stateless. Consider them transactions in the traditional sense, in that they are invoked and they don’t maintain anything after being executed.

Serverless systems have to approach application development and deployment this way, considering that the serverless system evaluates the function. It allocates only the resources needed to run that function, process it, and then the system returns the resources to the shareable pool.

Maintaining state would be much more complex for both the serverless systems and the serverless developers. This way the applications are divided into cleanly running services that are independent of each other and loosely coupled.

Although there are tricks and hacks to building and running stateful applications on serverless systems, typically they are a bad idea. If I see any failures when it comes to serverless development and deployment, it’s the stateful square peg attempting to be stuck in the serverless round hole. It just doesn’t fit.