What about OpenWhisk? console.ng.bluemix.net/openwhisk

Before get to server-less, can we first define what is a "server"?

Once upon a time, we had a machine in the office, and we opened a port in the firewall, forwarded it, managed its IP address, and let people access it's /var/www/html from the internet. A real server that we could touch and feel.

Then, some Data Center folks came by and said you don't need to deal with the power, internet and cooling for this machine, we'll keep it in our racks. So we moved the machine to the Data Center. We no longer had to manage the infrastructure. But it was our server, we still owned it.

Then the Cloud happened. We installed the same Ubuntu 10.04 on a "virtual" machine on AWS and ran our application on it. Now, we didn't have to worry about IBM vs. HP servers, or the efficiency of an FSB and the merits of RAID-5 vs. RAID-1. When people asked me where's your server, I said AWS. Yes, a server, just someone else's, we rented a portion of it.

Soon, Google AppEngine and Heroku appeared on the scene. They called themselves PaaS. We still had to write all the code and deploy it, but we didn't have to worry about whether it was Ubuntu 10.04 or 11.10, ext3 or ext4, ssh keys, and LC_LANG errors. Slightly better than a cloud server, but I'd say, still a server. We were now renting a portion and a time-slice of it.

Now, we have Lambda and Google Functions. Great, I thought at first, but it is just old wine in a new bottle. They are containers like AppEngine and Heroku, but at a much granular time-slice of billing. Seconds instead of hours. In return for this gain, we're penalized with a high spin up time (or latency) for every request and lack of local storage. Is this a server? Oh, yes, That's why we've to specify the amount of RAM, the amount of CPU etc. that's allocated for the function's execution.

Note that you cannot run a real web-server that supports a user interface (because of the spin-up latency). It's good only for background or batch jobs. Also, the fact that you are billed even when waiting for downstream servers (eg, an S3 request or a database call) to respond seems a waste. Within the Lambda, if we make an API call, and it takes 5 seconds, you're billed for those 5 seconds just for waiting!

Here's my vision of truly server-less computing:

(a) Imagine a farm of Node.js servers already up and running. It has all the common npm modules already available -- like express, body-parser and google-apis, aws-sdk and mongoose. All your code snippet has to do is define is a route handler, which is just a few KB at max. And you can have lots of such code snippets.

When a request hits one of the Node.js servers in the farm with your matching route, it downloads the appropriate code snippet from a nearby cache (no spin up time, mind you) and runs it. While any async calls to downstream APIs or databases are waiting, we're charged a small amount for saving the context (closure) of the function but not the CPU time.

(b) Another thought: really no servers, just API calls. All the code runs on the browser. For persistence, the code uses Google Drive, S3 or Firebase to save data using their APIs. For other services, it uses other APIs, mostly third-party. We're billed only for the API calls, and the code is hosted on a static web-server such as S3 or Google Cloud Storage.

In either case, you are not specifying how much RAM you need etc. That to me, is truly serverless (although there is a server there, we're not forced to think about it.)

At this risk of sounding old, this feels like repacking all the ideas from thirty years ago about lowering coupling and raising cohesion of services.

Serverless; microservices; Enterprise Java Beans; CORBA services; Remote Procedure Calls; or even RESTful interfaces are this idea that, for the subset of problems possible, the right answer is to make a tight, highly cohesive, low state or stateless block of code. The less callers need to know about blocks of code, the better. Also, the less the blocks code need to know about anything but themselves, the better.

Some problems are trivial, leaf nodes of your call tree: accept a login token; get the product name given a product id; etc. These are stateless, short-lived, and call nothing. Some are orchestrating calls, but can be tricked into single chains of state. Mostly, its all about good design.

Stateless appears to just emphasize the value of having no or trivial state and that blocks of code shouldn't know about the processor unless it important to its purpose. For the moment, there is a huge set of code that assumes long running processes to add state to inherently stateless protocols. I expect that there will arise easier to compute tradeoffs on the cost of a long running process, the start up costs for a process, and the cost of different coding styles.

Write code cleanly; that is still the goal.

We are considering a move from Rackspace to AWS for various reasons. At Rackspace, everything is made up of pretty basic components - servers, load balancers, CDN, MySQL db, etc... All of this will move and translate well to AWS and fairly easily.

Now what if this was in the reverse; what if we needed to leave AWS for Rackspace and our code was in Lambda - someone would need to take the code and convert it into something that works on a regular server + setup the server + security + scaling, etc...

Or - let's take it another step - a multi cloud setup - I'm 99% positive an AWS Lambda function won't translate well into a Google or Azure function. What if I wanted to use both services to ensure very low downtime in case of an outage (and it does happen...) ?

1 or 2 functions - ok - no big deal - but to use it for an entire site or an entire API or etc... that's to much vendor lock in for me.

Just because a company offers a feature, doesn't mean you need to use it or should use it. Weight your options; figure out how much it'll hurt if the stuff hits the fan and you need to leave and if your comfortable with that. Building / maintaining a server and all that goes with that may be a pain; but it'll be more of a pain if you need to leave those vendor lock in services and don't have the resources to rebuild them somewhere else.

Eagerly waiting for your findings.

Super, You fully utilise you week-end. We also start this.