treeder

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...

Yes, default is 100: http://docs.aws.amazon.com/lambda/latest/dg/limits.html

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.

There's also the mgo library for MongoDB which is probably one of the best Mongo libraries out there (even 10gen thinks so): http://labix.org/mgo

And http://github.com/lib/pq for Postgres.

This first rewrite in Go was for the IronWorker API so all the operations are here: http://dev.iron.io/worker/reference/api/

There were less endpoints back then, but you can get the idea. The most heavily used operation being queuing up tasks/jobs.

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.

We got a bunch of the little plastic ones sitting behind my desk: https://plus.google.com/u/0/101022900381697718949/posts/1Dbe...

Hah, nice photo! Are you ok with that? Found it on google images.

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.

Mostly because I can't stand Javascript. It makes me cringe just thinking about it. Go is much nicer to work with.

Built from the ground up, made for the cloud. We use Go as our language.

You're welcome. ;) Let us know what you think after you've tried it.

Some queues offer "at-least-once" delivery (such as SQS) meaning even if you do ack/delete the message, you can still get it again. IronMQ will not deliver a message again if it's been acked/deleted.

And yes, work should be idempotent, as is the case with any queue you use.

The static website part is nice, unfortunately working with Jekyll isn't. Such a painful process to update docs.

This is awesome, nice work. Although I'd prefer one that transferred them to Picasa/Google+.

What is meant by elasticity is that you can handle varying load on demand. You don't need to provision/scale for spiky/unexpected loads in advance, your infrastructure will expand and contract on demand. This is a very difficult problem to solve.

Also, this is on a much different scale than a small queue on a mobile app like you are comparing it to. A queue on a mobile app doesn't really need elasticity or scale. But when you're dealing with millions/billions of messages, the complexity is on a whole different level. And providing the ability to scale/grow with zero effort is extremely compelling.

Now if you had millions of users of your mobile app and they all sent messages for processing, an elastic, scalable message queue would be a godsend.

I've been reading Fooled by Randomness by Taleb, great book, same topic.

Not yet, but very soon we'll add the upload function to the API so you don't need the cli.

It's really not that complicated. The example on github works and you can try it out pretty easily to see for yourself. And if you need any help or have any questions, you can get some real-time help in our public chat: http://get.iron.io/chat

Are you referring to polling vs web sockets or something? A lot of chat systems use polling at scale, Campfire being one of them.

You could start by reaching out to companies you have relationships with. We could probably use someone like you.