To combat this, you need to justify the complaint.
In the case of lambda, I think being tied into an ecosystem of things that you can't run locally is a net loss, but Amazon has done a terrific job at making a bunch of people not super comfortable with compute, see just running a share-nothing process as the way to bridge the gap, like PHP never existed.
Same thing happens with IT orgs that end up owning cloud. You get azure, regardless of whether you want such a thing.
I’ve never seen anyone say this at $faang-gig. Ive certainly never been it used as a stick. While it’s true that any process can be abused, I’m taking about default burden of proof.
> To combat this, you need to justify the complaint.
Yeah, of course you can’t just say a magic word and expect others to fall in line. I’m claiming there should be justification for proposed increases in complexity. There is an asymmetry in where adding complexity is so trivial it is often accidental, whereas reducing complexity is labor intensive and so difficult that it’s often not cost-effective to even attempt it. Because of this asymmetry, complexity accumulates uncontrollable over time, unless you actively reduce it (expensive) or prevent it before it is implemented (cheaper). Otherwise your software engineers turns into software alchemists, imo.
> I think the prime video team's presentation should have been called "Moving from lambda to container microservices"
There is nothing particularly bad about this move. Prototype something in a FaaS, move it to a container based microservices when you know which features you want and how they perform.
Not doing much FaaS prototyping myself but I agree with the author that FaaS beats containers in time to production (even if the difference might be negligible in some cases)
I am disappointed that the top comment and all of the discussion is once again not related to the article at hand in the slightest and just focused on the easy "complex is bad, guys!" dunk.