A concrete example: video upload and processing. Your frontend handles uploads, then you can offload conversion to AWS while you continue to handle other requests.
I see this being most useful if you have a one-off analytic you need to write against some big data in S3 or RDS. For one-off scripts dealing with the raw AWS APIs is just useless overhead, and the expense of running the script will be negligible.
(a) measure each of the points of your service (b) deploy your code in an automated manner (c) deploy your monitoring in an automated manner (d) make sure your code is under supervision (e) setup alerting on the monitoring (f) scale up / down and within price constraints as needed (g) repeat this for all supporting services (queue, db, etc) (h) write your actual application code
The potential to handle certain classes of problems via SQS/SNS/S3 pipelines is pretty alluring. You still have to do configuration, but the bet is that the configuration necessary for the SQS/SNS/S3/Lambda pipeline is far lower than that necessary to setup random autoscaling Celery, Resque, or random JMS/AMQP system on top of Ubuntu with Chef/Puppet/whatever.
1. I agree that JMS sounds like a hassle but is that really necessary? I would think that you can batch process data on an EC2 instance, then pick it up in your local code directly using AWS APIs... not sure.
2. I am not so familiar with the Lambda system but I'm also not sure how it would scale db as necessary (item "g" in your list) thus overall processing time would still be bottlenecked by other resources (database IO, for example), no? I agree with your points but in all these cloud-compute scenarios I always wonder "Are we trying to reach a theoretical limit of fastest-possible computation, or just reach some reasonable saturation point close to the natural bottlenecks/throttles of our system integrations?".
3. Having been burned a few times now by over-optimizing when considering cloud I would probably now first consider just picking a slightly oversized EC2 instance and throwing some high-performing code onto it (Java, C++). Dynamic languages + auto-scalable resources (though I'm talking about web hosting in particular now) seems to drain clients wallets more than anything. At this point I'd actually recommend anyone with new web infrastructure to just buy a static instance and write optimized Java rather than trying their hand at auto-scaling Ruby/Python/Node. Do you notice a similar issue with your clients regarding code optimization vs. auto-scaling?
I think I remember this concept in Matlab back from when I did some research in grad school -- basically an instance of Matlab can be setup as a compute server, and the parallel processing functions of Matlab code on other computers can portion out work to it. This is the ideal model in my mind.
1. Write high-performance code in any language with some function that should be happening remotely in parallel.
2. Configure AWS to auto-provision the resources necessary.
3. Execute code, have it behave as if it is all running locally.
Really all these things can already be achieved with SOA, RMI, message queues, etc., the trick is just in making it transparent to the programmer so there is no deploy step involved. With the right spec it could even become platform agnostic (change small config file somewhere to target different cloud platform... would be nice to see a JSR about that in the near future!).
And then move it off EC2 onto dedicated hardware and you'll see another ~30x cost savings.
Running a permanent transcode cluster on EC2 would be rather insane. Hetzner rents you i7's for $50 per month, the EC2 equivalent (c3.8xlarge) costs $40 per day.
Yes you can cut EC2 cost with spot-instances, but at least in our case that would still have been significantly more expensive than just renting some scrap metal.
If you need cheap, disposable compute for semi-predictable loads then the Hetzner flea market (yes, they really have one!) is hard to beat on bogomips per dollar.
I was targeting my comment toward a startup that'd likely be building a product like the OP suggested, though, with maybe a dozen devs who are all generalists. Setting up a bunch of EC2 instances to pull videos out of SQS/S3 and run them through ffmpeg is something an ordinary full-stack developer can do in a morning, and scaling it up just involves clicking a button. Running and scaling a dedicated server farm reliably usually needs a dedicated ops person to keep it all working.