This is newer and shinier, and not all use cases overlap, but at the end of the day, yes its someone else managing the execution of your processes.
Having worked on GAE in a very large scale, my gut thinks that while this has many different use cases, it will make sense for small to medium size projects, and there will be a tipping point surrounding cost and this will appear less like a silver bullet after some horror stories.
At small scale this may even save money, if you truly don't need your code running all the time, and can deal with latency of starting your code. For projects that think terms of N thousands of transactions per second, the math breaks down real badly. It would cost approximately $2,500 dollars to run a 100ms job a billion times in a month on a machine with only 1.5GB of allocated to this process. You could pay $4350 per year w/ reserved pricing (is there even reserved pricing w/ Lambda? Couldn't find it.) for a c3.4xlarge, which has 30 gigs of memory and 16 cores, which could easily process many more times work than a billion 100ms jobs per month. So lambda seemingly works out well over 6x more than rolling it yourself on EC2 with my overly conservative napkin math.
The other pain point these type of systems produce is that instead of scaling a server here or a few servers there, your thinking in terms of processes, and time and time again this becomes a very rapid way to not only provision more horsepower instantly, but also run up the bill instantly. Code that might have ran on 1000 processes on traditional infrastructure because you had to tune it to fit in that infrastructure (and I don't mean fine tuned, things like, setting your database pool correctly and having basic concurrency), can accidentally be scaled up to 10,000 processes and appear that everything is fine. Unfortunately have seen this quite a bit on GAE and lead to some very costly mistakes.
Processes are harder (in my humble opinion) to have a good feel for what costs what, especially if your scaling up rapidly. Instead of adding a few servers and understanding how that effects the bill, going from 1000 to 1500 processes happens much easier, and you pay for that convenience.
My .02 is that this would be ideal if your either in a hurry and money is no object, or you don't plan on growing past a certain size, or possibly for workloads that are truly not running that often. I think this whole craze of lets replace everything with lambda is going to lead to rapid development (awesome) at high prices if your project takes off, which will leave developers rushing to get off of it if/when their project needs to scale with financial constraints. (not awesome)
With AWS, once you start using multiple services (e.g. lambda, S3, dynamo db, etc), it's difficult to estimate/model the costs in advance.
First you have to estimate how many times your app is pulling down a file or hitting a given db table. But this is dependent on unpredictable user behavior. You don't really know what users will do with your app until they actually do it.
Then, with e.g. Dynamo DB, you have to think about how many indexes you have on a table, and how often your app will query those vs how many times your app might do a full table scan. You have to allocate these specially defined AWS resource units. I don't find it intuitive.
I wonder how many developers really know in advance what their app is going to cost per user.
It might make it faster and easier to get an idea to a functional state. While you'd have to pay for it later when you start getting a lot of users that's not necessarily a bad problem to have. If you account for it and plan for it, it might make a lot of sense for a small 1-2 person team.
Having worked on GAE in a very large scale, my gut thinks that while this has many different use cases, it will make sense for small to medium size projects, and there will be a tipping point surrounding cost and this will appear less like a silver bullet after some horror stories.
At small scale this may even save money, if you truly don't need your code running all the time, and can deal with latency of starting your code. For projects that think terms of N thousands of transactions per second, the math breaks down real badly. It would cost approximately $2,500 dollars to run a 100ms job a billion times in a month on a machine with only 1.5GB of allocated to this process. You could pay $4350 per year w/ reserved pricing (is there even reserved pricing w/ Lambda? Couldn't find it.) for a c3.4xlarge, which has 30 gigs of memory and 16 cores, which could easily process many more times work than a billion 100ms jobs per month. So lambda seemingly works out well over 6x more than rolling it yourself on EC2 with my overly conservative napkin math.
The other pain point these type of systems produce is that instead of scaling a server here or a few servers there, your thinking in terms of processes, and time and time again this becomes a very rapid way to not only provision more horsepower instantly, but also run up the bill instantly. Code that might have ran on 1000 processes on traditional infrastructure because you had to tune it to fit in that infrastructure (and I don't mean fine tuned, things like, setting your database pool correctly and having basic concurrency), can accidentally be scaled up to 10,000 processes and appear that everything is fine. Unfortunately have seen this quite a bit on GAE and lead to some very costly mistakes.
Processes are harder (in my humble opinion) to have a good feel for what costs what, especially if your scaling up rapidly. Instead of adding a few servers and understanding how that effects the bill, going from 1000 to 1500 processes happens much easier, and you pay for that convenience.
My .02 is that this would be ideal if your either in a hurry and money is no object, or you don't plan on growing past a certain size, or possibly for workloads that are truly not running that often. I think this whole craze of lets replace everything with lambda is going to lead to rapid development (awesome) at high prices if your project takes off, which will leave developers rushing to get off of it if/when their project needs to scale with financial constraints. (not awesome)