I would say that it strongly depends on the type of requests you are handling.
Saying that you can run a 1GB lambda for 1 month nonstop for $32 does not impress me, and its kind of strange that it impresses you.
You could run a t2.micro with the same RAM for $6/mo if you reserve it for a year. And if you want to give that t2.micro a workload where it only has to respond to 1 request at a time, the same terms we are affording the lambda system, then it's no comparison.
Now, for responding to disparate requests every once in a while? Lambda is ideal. You can spin it up and you don't have to pay when it is isn't processing requests. But continuous requests? Hard no.
We can argue that the cost overhead at full load is worth it for the ability to "infinitely" scale with no effort. Alright, that's fine. But let's not pretend that it is "cheaper".
You can't compare it to a t2.micro because that's not what you're getting with lambda. t2.micro is a single, weak piece of hardware meant to handle 30 requests per second? I forsee issues there. For the same traffic would be called in parallel when the spikes require it, which is something you would not get without scaling the t2 micro and programming concurrency. And that is ultimately where the comparison comes in. Because hardware needs to be able to accommodate unpredictable traffic, it is running all the time, and it is beefier than it needs to be. The performance buffer to account for unpredictable traffic is completely eradicated when using FaaS.
I still use dedicated hardware where I deem it appropriate, but the proof is in the pudding. For the right services, pulling them out into lambdas is proving to be a huge savings and performance boost for countless architectures.
I don't have a strong opinion one way or the other, but I'd like to point out that micro instances also have diminished networking (besides processing/memory). Depending on what you're doing, this could be a factor.
We can afford a t2.medium or an m3.medium at the price he quoted, which will have better RAM, processing capability, and probably equivalent networking capability, so that isn't really the takeaway point.
The point is, his lambda setup has vastly better capability than your instance, should he need it. Unless you're able to bring instances up fast enough to address your need, which clearly doesn't put you in the same ballpark as him.
Saying that you can run a 1GB lambda for 1 month nonstop for $32 does not impress me, and its kind of strange that it impresses you.
You could run a t2.micro with the same RAM for $6/mo if you reserve it for a year. And if you want to give that t2.micro a workload where it only has to respond to 1 request at a time, the same terms we are affording the lambda system, then it's no comparison.
Now, for responding to disparate requests every once in a while? Lambda is ideal. You can spin it up and you don't have to pay when it is isn't processing requests. But continuous requests? Hard no.
We can argue that the cost overhead at full load is worth it for the ability to "infinitely" scale with no effort. Alright, that's fine. But let's not pretend that it is "cheaper".