Since serverless is a kind of a PaaS, it offers many of the same benefits. However, 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.

They are not always terminated, in an effort to avoid cold boot startup times. In fact, they run much like any other service framework, where your code is behind a function lookup, and called when an appropriate request is received.

AWS Lambda in particular will spin up a new container running their framework, which will then stay alive for a period of time before being terminated.

With socket activation (using xinitd or systemd) and a minimal framework, you could implement much the same on your own VMs.

>They are not always terminated, in an effort to avoid cold boot startup times.

That's true. I should have pointed out that from the developer's point of view it appears as if the execution is terminated, in the sense that no state is carried across code executions. However, the issue of whether the code is cold booted or not is an implementation detail of a specific serverless platform.

Atlassian did a nice blog post[1] on running Docker containers using socket activation. In principle that makes for a serverless platform but for a one that's difficult to manage. [1] https://developer.atlassian.com/blog/2015/03/docker-systemd-...

Any code written in a common web framework (such as Django, Rails, or Play) could easily be written with the same constraints - no state left over from request to request. That we typically choose to retain state between requests as an optimization speaks of one of the weaknesses in serverless architecture.

If you can't maintain state inside the application, you need to maintain it elsewhere (DB, Redis, memcache), and that elsewhere has a cost associated with accessing it.

That's a part of Twelve Factor apps as well. No state in the app! And while there is a cost to keeping state in an external data store like Redis, there are costs to keeping state in the app as well. First, there is the question of complexity and testability. Your app becomes harder to reason about, harder to test, and much more likely to be dependent on complex integration to get to a testable state. Second, there's the need for external support for internal state in any horizontally scaled app. This can be very expensive.

Consider session state in a web app. If you keep state in memory and scale horizontally, you need session affinity, so stateless inbound http connections hit the same server instance. That means a session-aware router, delicate and extremely expensive F5s and other "smart" routers. But if the app is stateless and session state is in external storage, then all you need for load balancing is a simple round robin. A cheap router, that's more reliable and requires less administration, for a fraction of the cost.

There are other ways stateful apps are expensive, but that's a big one. I'd rather pay $5k than $100k for a router.

Diego, the underlying scheduler for Cloud Foundry, has a concept of pre-defined one-off tasks. It'll eventually show up in the rest of the platform.

However, it'll be in the middle of the range for startup times, as some agents are sideloaded. Latency is around a second. The initial target is tasks like database migrations and batch jobs, so the ~1s delay isn't an issue.

One of my colleagues in NYC spiked on using one-off tasks for a FaaS and concluded it's not a slam dunk fit.

If I was to shimmy FaaS-style stuff into Cloud Foundry, I think it'd be easier to have standing apps with an array of functions already running, then push the magic into route services. I suspect this is how AWS already does it, given the vast difference in spinup times between Node and JVM requests -- Node makes hot-patching a list of functions easy, the JVM is less hot-patch friendly and really expects you to provide all the JARs at launch time.

Disclaimer: I work for Pivotal, we donate the majority of engineering to Cloud Foundry.

Sounds like inet.d, or CGI behind a webserver.

...or socket-activated systemd service [1, 2]

[1] http://0pointer.de/blog/projects/socket-activated-containers...

[2] https://developer.atlassian.com/blog/2015/03/docker-systemd-...

That's true, but for a public cloud service, you wouldn't let random people run arbitrary code based purely on inet.d or systemd socket activation.

Why not? RedHat will let you run arbitrary binaries just fine on OpenShift - both long-running/worker/"PaaS" and on-demand/per-request/"FaaS".

Obviously this is tightly locked down with cgroups.

How would you modify systemd unit files for each user of your public cloud? How would you manage the sockets once you have more users than sockets on a server?

You can create systemd units using the D-Bus API instead of files, though I'm not sure those can be socket-activated.

As for having more users than sockets, is that really likely, considering there are 64000 available ports?

Might get this wrong but from my understanding:

PaaS: Platform (as in Server eg used for API) on demand (as in api.something.com/*)

FaaS: Function (as in eg api endpoint) on demand (as in api.something.com/v1/get_latest_posts)

Of course you can create the 2nd with the approaches of the 1st but the from my understanding the main benefit is that you dont have to - as in: you can just take one endpoint and have it managed by something else.

Yes, you could simply upload some code to the service, and they will be called only when there's a request to that particular code, instead of running a process continuously.

It's called "shared hosting" and was invented in the 90s.

It's fundamentally different than that. This is a discreet function as a single function call that is deployed with no other code that you have written. This allows deployments of individual functions without affecting the rest of the services. While possible before almost noone actually did that.

I disagree, it was a common pattern to have a single .php file for each page, independent from each other, which would receive input params (GET, POST and COOKIE), sometimes connect to the database, and do all the processing inline, outputting the result. The whole file was essentially an implicit function. The appearance of frameworks with a single entrypoint and which load models and controllers and such is fairly recent in the PHP world. When I started writing websites, already in the 2000s, this was how I first learned.

I'm confused, how does "serverless" play into this? I opened this expecting something about p2p architecture

You don't run the server so I guess you can pretend it doesn't exist.

Kinda like s3... it involves servers, but you don't have to do anything. Its just a black box you put in or get out data. "Serverless" FaaS is just a place you park some code and it runs.

Yes the name is kinda dumb.

The latest installment just went live - conveniently I offer a comparison to PaaS in it (in that I think there are significant differences between PaaS and FaaS)

Thanks for the article, it was a good read. My problem with the FaaS nomenclature is that it positions serverless as different from PaaS while the two are more alike than different. Now, we need to be careful about the definition of PaaS because there are at least two: 1) PaaS as a cloud computing service model, and 2) PaaS as empirically defined by various PaaSes, like Heroku, Cloud Foundry, OpenShift, etc.

In my opinion, serverless is a kind of a PaaS per definition 1 above. However, in practice serverless is different from PaaS in the definition 2, because Heroku and others have focused on long running services. In contrast, serverless does not replace the need for long running services but works with them. The sweet spot for serverless are short lived, stateless functions, FaaS per your definition. I like to call them microflows to highlight the complementary relationship to the microservices.