This, but it was told by serverless experts, on stage, in front of hundreds of people. If that was their sales pitch, their reality was likely even less impressive.
Re:The Serverless Revolution Has Stalled
by C1sc0cat on Tuesday October 13, 2020 @09:11AM
(#24765223)
This sounds a bit like the posh workshop I went to on WAP (wireless access protocol) years ago when I worked for BT.
It was a complete omnishambles - to the point I avoided the fancy lunch and went to the Pub for a ploughman's lunch, In case I suddenly blurted out "this is all S*&T" and caused a political row with the mobile side of the company I worked for.
Re:The Serverless Revolution Has Stalled
by blablabla123 on Tuesday October 13, 2020 @08:53AM
(#24765108)
Never tried something marketed as Serverless but Google App Engine. If you wanted any performance, you had to follow the Guidelines really closely. Which could be legit, if it's worth the effort but I think it isn't. I think people under-estimate the effort and that the code will require much more not so nice optimizations than expected. That includes very verbose logging. It's sold as carefree and elegant but it only works when using patterns that nobody enjoys. I really liked the log browser and Dashboard though ;) It's like a stripped down version of New Relic and Elastic Search combined.
Re:The Serverless Revolution Has Stalled
by methodin on Tuesday October 13, 2020 @02:15PM
(#24768216)
Most of your points are not relevant to my original statement of the code being generic - they are talking more about the architectural decisions. If I want to use DynamoDB I can do so in EC2 or Lambda, serverless doesn't dictate that. You also seem to believe one chooses Lambda because of complexity reduction and that's not really the only reason. I can very easily port a node/express API backend that connect to RDS to any other cloud provider. What about serverless makes you think that's not the case?
Re:The Serverless Revolution Has Stalled
by selfhoster11 on Tuesday October 13, 2020 @11:24AM
(#24766470)
Then your service becomes just a tiny stub of vestigial logic buried under layers and layers of YAML, vendor libraries and locked assumptions.
Re:The Serverless Revolution Has Stalled
by thinkharderdev on Tuesday October 13, 2020 @10:11AM
(#24765691)
Or even worse, giant yaml config files
* Well, obviously we use a hosted database
* And obviously, AWS provides our logging and all our analytics.
* Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms.
* Of course, we can't blindly let everything access everything, so naturally we have IAM roles and permissions for every lambda function.
* Well, the cloud provider will look after secrets and things like that for us, no need for us to worry about database passwords.
* Naturally, with all these functions and IAM roles to look after, and we need tagging for billing. We should define it all with CloudFormation scripting.
* Well, the nosql database the they provide comes with their specific library. And as it shards things like this, and doesn't let you index things like that, you've got to structure your data this specific way if you want to avoid performance problems.
* You don't want your function to take 200ms+ to respond, your users will notice how slow it is. So no installing things with apt-get or pip for you, let me get you a guide on how to repackage those into the vendor-specific bundle format.
* You want to test your functions locally, with access to an interactive debugger? You're living in the past, modern developers deploy to a beta environment and debug exclusively with print statements.
* And so on.
In this case, a lot of the 'complexity' one hoped to eliminate has just been moved into XML files and weird console GUIs.