Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…
Serverless: slower and more expensive
261–270 of 733 posts
Re: Serverless: slower and more expensive
#262Earlier quoted context omitted.
Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?
Sure, it's not FaaS, but it fits the "you don't have to care for OS and servers" criteria, and it's always on (and auto-scalable). Running FaaS on AWS without knowing anything about servers and "OS stuff" screams like building the roof without the foundation. And I know that it sounds convenient to run everything as isolated little abstract functions, and ... it works, but it's pricey. But you can do it for cheap, yo…
Re: Serverless: slower and more expensive
#263Earlier quoted context omitted.
You should work in enterprises where you have to deal with stringent security requirements, emergency CVE mitigation across multiple regions, compliance requirements, etc., and you’ll quickly gain an appreciation for why enterprise folks don’t want to manage servers.
>> emergency CVE mitigation across multiple regions, compliance requirements These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line. Simply hand-waving -- this is running on…
Re: Serverless: slower and more expensive
#264Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…
This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.
Some of us had deploy pipelines into “containers” working like a Lambda in 2003.
Nothing in software is all that novel these days, IMO.
All these features that have been there for a decade plus are just wrapped in a corporate brand now.
Progress.
Re: Serverless: slower and more expensive
#265Re: Serverless: slower and more expensive
#266Earlier quoted context omitted.
You’re always locked into your infrastructure. People don’t willy nilly change their infrastructure once they reach a certain size any more than companies get rid of their six figure Oracle infrastructure just because a bushy tailed developer used the “repository pattern” and avoided using Oracle specific syntax. And the “lock-in” in lambda is over exaggerated. If you’re using lambda to respond to AWS events, you’re…
Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.
I'll typically write all the core functionality first, test it, then write the lambda_handler function.
Re: Serverless: slower and more expensive
#267hmm, only 15% slower for a service that spins up on demand? That's not too bad at all, actually..
my closest AWS DC is in Frankfurt with HTTP ping below 40ms. if i consider 100ms for actual work, the overhead for serverless is 46%. still impressive, i would have expected >100% there.
Re: Serverless: slower and more expensive
#268Earlier quoted context omitted.
Agreed, let me add my 2cts : >The whole idea of serverless is so you don't have to manage infrastructure. ...when you are validating your product/market (100 request/day is a success here). Not everyone on HN is a core dev, tech is getting democratised. So 1 week of time dealing with servers and accounts and infra is a week not asking the right questions.
Counterpoint to that though: "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. None of that is particularly "accessible" for someone trying to get running ASAP. I agree tech is getting democratised, but when talking abou…
When there is is no infra to deal with, U/DevX becomes much easier. "Remix this" is pure product joy
Re: Serverless: slower and more expensive
#269Re: Serverless: slower and more expensive
#270Earlier quoted context omitted.
Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.
seriously, its a function. if you remove the aws/lambda specifics you _should_ have something testable that you then call from your lambda handler.