I completely disagree with this point, as it goes totally against the experience that I and my team have piled up after a couple of years of running a couple of serverless apps that rely heavily on a few AWS Lambdas. The API Gateway and ALB code was pretty much a one-and-done, with the bulk of the work consisting of setting up TLS termination, and the bulk of the work was on writing and testing all the business logic.
The only exception I've seen to this rule is if your serverless apps consists of a bunch of event handler from a large bunch of AWS services, like S3 triggers and message queues, that are not much than one-liners that don't do much beyond plumbing around events. Still, I don't feel it's right to describe this sort of application around lambdas that don't do much by design.
> I’m apparently atypical here! Folks don’t like to spend an order of magnitude more to monitor a system than the system itself costs to run. (...)
I also don't believe this point is fair or reasonable. It makes no sense to complain about serverless because it can be dirt-cheap (or even free to use) but your choice of monitoring service, coupled with the way you chose to use it, ends up costing more. You pick what you use and decide how you use it, and if your personal choices lead to a price tag greater than zero then that's the outcome of your own design decisions.
This complain is particularly eggregious given that AWS CloudWatch has a free tier that's very clear and included in basic intro to AWS tutorials.
> (...) It turns out that while it’s super easy to find folks who know WordPress, you’re in trouble if both of the freelance developers who understand serverless are out sick that day — not to mention that they cost roughly as much as an anesthesiologist.
Again, this is hardly a serverless issue. You'd experience the exact same problem if you ran a Spring monolith.