Ask HN: What are the alternatives to Amazon Lambda?

Depending on your use case and how much startup time you can tolerate...

We need the ability to run 1,000s to 100,000s of ~3 second jobs as fast as possible, but only sporadically (~100 times a day with our current customer base). At that "low" frequency, can't justify the cost of keeping that many dedicated servers up 24/7 to meet this intermittent need, and we need sub-second startup times so we can't launch normal VMs on demand.

However, the cost of servers on Google Compute Engine (GCE) is actually cheaper than lambda if you have big batches of jobs. The VMs could be launched via their autoscaler or Dataflow, and jobs could be dispatched via Pub/Sub. If you can secure enough preemptible GCE instances (which are of limited availability), these are even cheaper. GCE VMs launch in about a minute, compared to AWS's 3-7 minutes, so on-demand launching is actually doable for some use cases as long as you don't mind paying the 10 minute minimum. This also gives you access to huge resources (CPU and RAM) if needed.

Specifically, ~1.1 million 3300 ms 1536 mb lambda jobs cost us $90.04, and GCE would be $50 on regular or $15 on preemptible GCE VMs for the same number of jobs in the /same total execution time/. After requesting a Lambda quota of 100,000 concurrent jobs, we were only allowed 1,000 ("for now", they say) -- thus it takes an hour for that many jobs to complete, so GCE$ = (1 hr) * (cost per vCPU/hr) * (1000 vCPUs). Note that we're using the max allowable memory on Lambda because that ~linearly decreased our execution time, but we use an average of 400 mb. My estimate also doesn't take into account the overhead time that comes from launching lambda jobs that might be reduced via the home-brew solution I described above.

Someone else mentioned the issue with Lambda only having 0.10 vintage node. We have a somewhat complicated albeit elegant solution for communicating with a portable node 4.x binary via IPC. If AWS ever gets to allowing specified node versions, that would reduce our runtime marginally.

(BTW, I put in a feature request to GCE for a lambda-like service here: https://code.google.com/p/google-compute-engine/issues/detai...)

We've been hacking on something in this space for the past few months with StackHut - https://www.stackhut.com. We have a demo in a blog post at http://blog.stackhut.com/phantomjs-cloud/ showing headless web rendering-as-a-service.

We've tried to make it as simple as possible to get your code into the cloud. You write your classes and they're deployed as entrypoints into a lambda-esque service that you can call over JSON-RPC - making it trivial to write and deploy a backend.

As described in the blog, the great thing we think it has over tools like lambda is that you can describe your system declaratively, specifying any dependencies you may need, using a simple YAML file and it takes care of packaging your code. You can run this locally or deploy it to our hosted platform where it scales as needed.

Currently support JS and Python atm, and open-source at https://www.github.com/StackHut. We're super early but would love to hear your thoughts.

Thanks for mentioning! Working on getting an OS X packaged app out this weekend along with that Linux/Bash-as-a-service up!

As others have said, this is basically what inetd and the likes have been doing for a long time. The reason why it isn't used for heavy services anymore is that every request will spawn a new process, and that's extremely expensive. That's like CGI at the socket level. The natural "solution" you have is to let your process run, and every time a new request comes from the network, it is merely redirected to your process, possibly under another format; that's FastCGI for you. But then you lose the simplicity of programming your process as if it were called for every request.

The real innovation that Lambda brings on the table is container reuse [1]. Basically your process is started in a container the very first time a request hits Lambda, and the initialization step happens; when it's done the container is "snapshotted" and runs the request. If the request has been completely processed, the process should normally close, but instead the container is kept hot for the next requests. If they come not too far away, the container will be reused, right after the snapshot, as if it was run for the first time.

Because of this trickery having many requests is not so expensive anymore, there can be very little latency. Bring that to everyone and inetd/xinetd/systemd's socket activation can be seriously considered as a viable solution.

[1] https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

Seems like you could essentially implement an LRU container/process/etc. keepalive on top of and have your machines essentially fully-utilized with minimal latency for services being accessed recently.