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.
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, 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.
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?
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:
Doesn't seem to be an issue. The files created inside the container and written to the mounted volume outside the container are the same user/group as the parent directory (outside the container), not root.
We actually have our own deployment tools for Go (and for Rails, our databases, etc). We built them before all the new hip options that are around today. We build on the target machines, although that's not a requirement since we all run the same architecture on our dev machines too (64 bit linux).
I'm not sure about writing a front end in Go, there's not a lot in terms of UI frameworks and Iron.io front end (HUD) is still in Rails so I can't really say much about it.
This was on Ruby 1.9, 2010 era. No patches. Memory was definitely a concern and probably contributed to some of it. Just to note though, after a machine was taken offline by the load balancer, it would generally come back to life.
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?