But on the other, the same sentence could be written about software deployed to traditional servers. "Because of course, how can you hurt yourself without the joys of badly configured servers?".
You can hurt yourself with a badly held butter knife, and you can hurt yourself juggling katanas. Which situation would get people saying you're crazy?
Well, if you narrow down the metaphor to just knives, a dull knife is more dangerous to a chef than a sharp knife, because you need to apply more pressure and you get less control over the cutting action.
Dull knives are dangerous to most people, not just chefs. Most beginner's cooking books/lessons will tell you to keep your knives very sharp, because dull knives are dangerous (for the reasons explained by grandparent comment).
This affects amateurs just as much (if not more) as experienced chefs.
Which of the two, "going serverless" or "managing your own servers" would you say is unequivocally like juggling katanas?
I don't think the analogy is very good, since juggling katanas is always a crazy idea, while choosing whether to go serverless or not is always a respectable discussion.
I understood the pun about the "cutting-edge" cutting you, I just went deeper than the joke to note many hurt themselves by not going serverless when they should have, and that server maintenance/configuration often becomes a mismanaged nightmare.
Do you mean figuratively that OP is replacing Cobol? Because I don't see that in the article. It mentions other technology that I would not associate with a super-conservative stack - like Databricks, JSON, Postgres and Google Analytics. So I'm a bit confused by your comment. And by all the downvotes, honestly.
I just pointed out that personally I would not consider Lambda - which has been a stable and popular technology for 10 years - to be cutting-edge. It's not old but also not cutting-edge imo. I would reserve that term to newer technology. Apparently a controversial view on HN, which is interesting.
To respond to your question, I did work for a bank in 2017 with moving certain burst-type processing to a set of Lambdas.
I worked for a company that went all in on Lambda as well. The knots they had to twist themselves into so that everything ran nice and smooth in Lambda environment was mindboggling. We have certain actions like orders that would pass through 8 Lambdas before completion because of execution time or just the big code base would result in 7 seconds start up time (node) so it would get broken down. If any of them failed, and it felt like failed a ton due to Amazon backend stuff, it was a nightmare to resolve.
All of it could probably been handled by larger node application in docker container somewhere but AUTO SCALING, FAILOVER, SERVERLESS!
Once I started as SRE for a new team, we built a larger monolith using Node and docker on EC2. We would get massive complements for our uptime and reliability but there were some architects extremely unhappy when I revealed in division presentation that it was just Docker + m4.xlarge running Ubuntu 18.04. When I left, more and more Lambdas were being broken down into docker running on EC2. They are probably on some container managed solution now.
A beautiful epigram.