Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

261–270 of 733 posts

Re: Serverless: slower and more expensive

#261

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…

The true cost of any product is the project lifecycle cost. There are many cases where a serverless architecture would cut down on that.

Re: Serverless: slower and more expensive

#262
post #229

Earlier 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…

It’s not a “knowledge gap”. I know how to set up databases, queueing/messaging servers, software load balancers, etc., but maintenance takes time and companies pay to save time.

Re: Serverless: slower and more expensive

#263
post #231

Earlier 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…

But they do go away. They go straight away to a vendor which is very likely to address them faster, and with more competent resources, than you and your team (or, if that sound insulting - me and my team). They become covered with that famous someone else's problem field

Re: Serverless: slower and more expensive

#264
post #164

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…

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.

Wow everyone all excited about hosted FreeBSD jails

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

#266

Earlier 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've found unit testing to work fine for Lambdas. The biggest difference between running as a Lambda and running locally is the entry point. With a Lambda you have an event payload that (usually) needs to be parsed and evaluated.

I'll typically write all the core functionality first, test it, then write the lambda_handler function.

Re: Serverless: slower and more expensive

#267

hmm, only 15% slower for a service that spins up on demand? That's not too bad at all, actually..

he's going from Iceland to us-west (Oregon). surely his RTT is dominated by the length of the cable, not any useful work.

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

#268
post #70

Earlier 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…

Agreed, AWS lambda is still (very) scary. To me, serverless is more glitch.com [1] than AWS.

When there is is no infra to deal with, U/DevX becomes much easier. "Remix this" is pure product joy

[1]: https://glitch.com/~mapbox-demo

Re: Serverless: slower and more expensive

#270

Earlier 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.

That works for unit testing a specific component, but not so well for testing your system end-to-end.
Post reply on HN