I used Lambdas as our core logic processor for 4 years. We cared about every failure and the core motivation was it's scaling ability as our traffic was bursty and would scale 1000x on random days.
Lambda -- Serverless in general -- is fantastic when your application has any amount of downtime (on the order of 10 seconds). If there is even the briefest moment your system can be turned off, you'll save dramatically over a traditional server model.
This is actually a decent use case for it. I should have been more nuanced in my response.
I have seen more then one project fail when they use lamdas to serve apis. This is because of the cold start problem, but also because lambda does have scaling issues unless you work around them. By scaling I mean greater then 1000 tps.
All of the services performed within lambdas SLA but failed to meet the requirements that the project had.
The solution was always to wrap whatever function it called in a traditional app and deploy it using a contanerized solution where response times dramatically improved and services became more reliable.
The idea behind lambda is good, but it can't beat more traditional stacks at the moment. One could argue that most projects don't have these requirements, and I would agree, but the marketing behind lambda doesn't make that clear.
That's because it is. What makes restaurants different is their specialization in an area, and excelling at that along with atmosphere. Without that there's no value add.
I have worked with these large kitchens that can make different types of cuisines depending on your want, but they all turn out mediocre.
My family completely stopped ordering out during this pandemic because most restaurants have lost the key employees who make their food special, there is no atmosphere, and GrubHub et al add no value.
I agree with OP that writing a task in a non-core language is concerning, and also agree with you that there might be more going on.
I've worked with both types of team leads -- those that are there because they are technically proficient, as well as those that are good at handling the politics so the team doesn't and relies upon Sr. engineers to guide the project technically.
It's completely situational as to what is appropriate. Are you a 6+ person team in a large org (or in a small dysfunctional org)? Then you want some one who can handle the politics. Are you a 4 person team that owns your company's entire tech stack? Then you want someone who is really technically proficient.
Since OP mentioned the manager of this person, I suspect it's a larger org where politics is king, otherwise they would report to a VP or higher directly.
I thought a lot of other large "fast food" retailers do the same for their equipment? Chik-fil-a does something similar for quality control and some predictive cooking if I recall correctly.
Something like that happened to me. I was a grad student until the project I was working on ran out of funding. Their website said if you left the program you could pay for health insurance out of pocket under the same plan you had while a student.
What they left out was that the company could reject you as a customer if you had a pre-existing condition. (This was before the ACA took effect.) They can legally do this because COBRA does not apply to grad students.
Fortunately, Oregon at the time had a state-subsidized health insurance plan called OMIP for people that were rejected by private health plans. The premiums weren't cheap, but they weren't worse than equivalent plans. Eventually OMIP was superceded by the ACA marketplace.
I worked for a company that was sold for scraps and they laid off all but there people. It didn’t affect me, I got a contract the next week with one of our clients that I worked with and paid for Cobra.
However, my Cobra eligibility died when the acquiring company cancelled their health care and moved everything to India.
I've re-platformed so many projects these past few years because of these issues.
I wish more would take that to heart instead of marketing for Amazon.