> This has a huge impact on application architecture, albeit not a unique one - the ‘Twelve-Factor App’ concept has precisely the same restriction.
While 12 Factor does say that processes should be stateless I've never thought it really meant it. Connection Pools and in-memory caches are pretty typical in 12 Factor (or all non-serverless) apps. And for me that is what makes serverless kinda silly. Some global state is actually pretty useful when you can avoid the overhead of initializing things or going over the network.
Serverless apps should be stateless but should work in conjunction with stateful apps. Unlike Heroku, Cloud Foundry, OpenShift, and other traditional PaaSes focused on supporting long running applications and services, serverless frameworks offer a new kind of a platform for running short lived processes and functions, also called microflows.
The distinction between the long running processes and microflows is subtle but important. When started, long running processes wait for an input, execute some code when an input is received, and then continue waiting. In contrast, microflows are started once an input is received, and are terminated by the platform after the code in the microflow finishes executing. One way to describe microflows is to say that they are reactive, in the sense that they react to the incoming data.
But how is this different from coding in, say, Django?
In Django you write a "view", which is just a Python function that is started when an HTTP request is received, and terminates by returning an HTTP response object. Then there are models, but these are just a translation layer between the Database and the view function, they don't keep state either.
I don't see how a Django view isn't a "microflow". It seems to me that the architecture is exactly the same, it's just that you don't get to choose the web framework.
There's definitely a performance tradeoff, one which I reference a little in the latest part and will definitely talk about more when I get to drawbacks (likely in the 5th update.) There's definitely a big class of applications where FaaS with its current limitations isn't a good choice, but I wouldn't say that class is universal.
12 factor statelessness I read as meaning more application / domain state rather than infrastructure state btw.
> This has a huge impact on application architecture, albeit not a unique one - the ‘Twelve-Factor App’ concept has precisely the same restriction.
While 12 Factor does say that processes should be stateless I've never thought it really meant it. Connection Pools and in-memory caches are pretty typical in 12 Factor (or all non-serverless) apps. And for me that is what makes serverless kinda silly. Some global state is actually pretty useful when you can avoid the overhead of initializing things or going over the network.