[x0x0]

Or it's pure RDD (resume driven development.)

That said, you can figure out (just ask!) if this person was brought in as the result of an already-made decision to move to this type of development, or if this person is pushing it. As an EM, I'd have no problem with a report directly asking that question.

If the answer is the decision was made, and this hiring was a downstream result, then your choice is likely to deal with it or move on. If the decision hasn't been made / this architect is advocating for it, then a cost benefit analysis (which you'd think would be a standard part of any work) will be illuminating. My understanding of the tooling / debugging / monitoring tooling for serverless is that it's still quite raw. Although my bias is towards not wasting innovation tokens on things like serverless / I align strongly with the choose boring technology view advocated by Dan McKinley [1], amongst others.

[1] https://mcfunley.com/choose-boring-technology