Web Apps on FaaS: Six Weeks In (after Six Years Away)

I just realised two things about web development in 2020.

(1.) A lot of web application frameworks now assume responsibility for being HTTP (web) servers also. 

Initially, web servers were designed to serve static content. Then, people started serving dynamic content, and because language runtimes didn't come out of the box with HTTP servers, you typically had this kludge of middleware between a language runtime and a specialised web server program (the driver).

But now it is de rigueur that scripting languages must treat HTTP as a first-class environment, and so language runtimes are much more supportive of HTTP out of the box, leading us to gradually reduce reliance on specialised web server programs. The old web server layer has basically become absorbed by the old web application framework layer, and now they are often (but not always) the same thing.

This is particularly true of web-first language runtimes, like NodeJS and Go. Furtheronto this is the common trait: web application frameworks today have an opinionated approach to parsing HTTP. 

 (2.) FaaS throws a wrench into this. Functions as a service are basically ways to carve up vCPU time ... but their implementations range from being specialised in one web application runtime, to being web-application runtime-agnostic. In the latter case, this means that FaaS implementors have to pick some lower-level abstraction, which at this point in history, turns out to be typically (2.1.) a cGroups-type Linux containers (I haven't yet figured out what MSFT is doing in Azure Functions), with (2.2.) some sort of gateway/reverse proxy sitting in front of the former. So now F/PaaS providers are inserting themselves in a very minimal fashion as dependencies because there doesn't yet exist any common vendor-agnostic consensus on how to implement a F/PaaS. Nearly all of them have an opinionated approach to parsing HTTP.

Now as a web application developer, I want to be able to use FaaS without being overly concerned about vendor lock-in. However given that each FaaS vendor provides different host runtimes, we now need to write our applications in a way that is decoupled from those idiosyncrasies. Which brings me to my main point: FaaS web application frameworks are a strange beast. They have to address the following:

 ... oh where do we begin, close to or far from the metal? Let's begin closer to the metal:

(A) sufficient abstraction over operating system and kernel variables; fortunately this is largely handled by ...

(B) ... the language runtimes, whether they are compiler or interpreter oriented, they typically now all offer some sort of low-level virtual machine (not to be confused with The LLVM);

(C) ... THE VENDOR'S GATEWAY/REVERSE PROXY's opinion about how HTTP should be handled; that is to say, how you get your request data, and how you return your response data, will vary based on which cloud you are using at the moment;

(D) and finally, if you happen to be basing your FaaS web application framework on some PRE-FAAS WEB APPLICATION FRAMEWORK, then be prepared to have to abstract over ITS opinions about how HTTP should be processed. 

In summary, this is going to be a problem most FaaS developers can ignore. Using any D usually wraps up all the complexity of { A, B, D }, leaving us to figure out how to glue those all to C, which usually doesn't take too long. 

But what if we want to write a framework that abstracts over all of { A, B, C, D }? Well that seems to be a little more challenging. And that's what I'm thinking about today.