I think you missed most of the points in the post. To address your points which are well covered in the post (I'm guessing you didn't read it):

1) Printing bills is very expensive 2) Credit card payment networks are also very, very expensive (2.5-3.5% or more of every transaction) 3) Billions of people can't get credit cards. 4) How do you send printed bills around the world?

You might want to check out IronFunctions that was released last week: https://github.com/iron-io/functions . You can run Lambda functions anywhere, can even export/import them directly from Lambda. It doesn't have the burst to Lambda part you speak of though... yet.

Unfortunately, Docker has a fair bit of overhead, more on that here: https://medium.com/travis-on-docker/the-overhead-of-docker-r... . That said, the overhead is probably not a big deal in a lot of cases.

And for the those cases, where it is a big deal, the next two major milestones on the roadmap aim to work around that issue, namely hot containers and streaming input. https://github.com/iron-io/functions#roadmap . Once that's in place, it should perform similar to any API.

Yes, we are! Follow this issue: https://github.com/iron-io/functions/issues/100

Yes, Java is supported. Like the other comment, anything you can run in a Docker container, which is pretty much any language. It also supports the same format/structure as Lambda in Java.

Yes, both are supported. See the main README for how to use both.

I talk about cost being the main factor in this post about the benefits of Serverless. It's definitely the driving factor: https://www.iron.io/what-is-serverless-computing/

I"m pretty sure that's not why Docker was created. And Nix is definitely not a simpler solution for packaging/dependency management. It's a good idea, but with all the advantages of Docker (full isolation, flexibility of using any OS and any package manager, easy distribution), why bother with Nix?

Typically a couple seconds.

Docker support is a new feature to enable more complex jobs where you need to control the entire stack, for instance, maybe you need imagemagick installed on the core machine, or ghostscript. IronWorker can support that. It also allows you to test your workers locally before uploading: http://blog.iron.io/2015/03/the-new-ironworker-development-w....

That said, you don't need to think about Docker if you don't want to and an IronWorker can be a few lines of code too, for example:

https://github.com/iron-io/dockerworker/blob/master/ruby/hel...

Or node: https://github.com/iron-io/dockerworker/blob/master/node/hel...

Thanks for posting those, their splash page gave me the feeling that you were always responsible for the docker mental overhead.