Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

Post reply on HN
Print view View original

651–660 of 733 posts

Re: Serverless: slower and more expensive

#651

Post by philliphaydon »

laumars wrote: post #135
philliphaydon wrote: post #113

Earlier quoted context omitted.

That first link makes no sense. The C# is not reflective us my real-world usage in the slightest bit. The 2nd link is more accurate to my experience, and obviously contradicts the first link. I haven't tested the new VPC stuff yet to know what the impact is. https://aws.amazon.com/blogs/compute/announcing-improved-vpc...

> That first link makes no sense. The C# is not reflective us my real-world usage in the slightest bit. The 2nd link is more accurate to my experience, and obviously contradicts the first link. They don't contradict each other. They're different graphs demonstrating different workloads. You'd be surprised just how much peoples "real-world usage" can vary from one customer to another. > I haven't tested the new VPC st…

Ok, so I commented on the authors blog post and he linked me to the repo, I took his code and compiled it myself and was unable to reproduce the result he got, he also said:

> Yes, I'm also suspicious about my C# results at this point.

I'm not sure how he got the results he got. So it maybe worth him running the test again.

https://github.com/mikhailshilkov/mikhailio-hugo/issues/2

Re: Serverless: slower and more expensive

#652

Post by sriku »

Stuff like CloudFlare Workers and Fastly's Terrarium offer some interesting options - run WASM or JS at the edge. Maybe this can get enough compute done with low overhead and close to the user, which could push Lambda-like functionality further up.

Re: Serverless: slower and more expensive

#653

Post by jmnicolas »

abiro wrote: post #639
foxtr0t wrote: post #602

Earlier quoted context omitted.

So, to summarize, you should: 1. not use the programming language that works best for your problem, but the programming language that works best with your orchestration system 2. lock yourself into managed services wherever possible 3. choose your api design style based on your orchestration system instead of your application. 4. Use a specific frontend rpc library because why not. ... I've hacked a few lambdas toget…

Think about serverless as framework-as-a-service. It has a learning curve, but if you buy in, it is an amazing productivity boost. (If Reddit’s video hosting being built and operated on a serverless stack by a single a engineer won’t convince you, I don’t know what will.)

90% of Reddit videos are unwatchable for me : they start OK then the quality is downgraded to something unwatchable and there's nothing I can do about it.

I even tried to download them with youtube-dl but it doesn't work.

Re: Serverless: slower and more expensive

#654

Post by rodgerd »

jririi82zxn wrote: post #264
tus88 wrote: post #164

Earlier quoted context omitted.

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.

> Wow everyone all excited about hosted FreeBSD jails

Wow, FreeBSD weenies are excited about re-discovering CICS.

See how annoying and wrong you sound?

Re: Serverless: slower and more expensive

#655

Post by unicornmama »

abiro wrote: post #539
unicornmama wrote: post #468

Earlier quoted context omitted.

The technology age isn’t the issue. The issue is how many projects have successfully deployed large scale reliable systems built with Lambda.

The internet is full of success stories if you care to look. My favorites: - iRobot (maker of Roomba) has been running its entire IoT stack serverless since 2016 (architect Ben Kehoe is a worthwhile follow on Twitter) - Reddit’s video hosting service is built and operated by a single engineer on a serverless stack

Thanks. This is good info.

Re: Serverless: slower and more expensive

#656

Post by radicalbyte »

Pxtl wrote: post #491
radicalbyte wrote: post #78

Earlier quoted context omitted.

C# is compiled to an intermediate language (MSIL/CIL^) which is then JIT-ed. The JIT cost actually adds a fair bit to the start-up time for C# code. This is why on the webserver there's an option to keep the C# code resident so it's always ready to go. In the past - before this option - it was common have scheduled jobs which pinged your webapp regularly to keep it hot :) ^ https://en.wikipedia.org/wiki/Common_Interm…

This to me smells like "things I shouldn't have to care about when using a serverless architecture". I would expect the serverless provider to keep my code fully AOT compiled in the fastest cold-start-format instead (wasn't ".net native" a thing?) of JITing things at the last second.

Unfortunately .Net Native doesn't support a lot of project types at the moment.

Serverless is all built around fully automated and managed containers, right? So it abstracts the whole runtime environment for webserver code. You use it if you don't have the skills/capability to run your own deployment/scaling pipeline.

The technology is a great 80/20 style leveler; I would highly recommend it to new developers and to people coming from a less technical background (such as design, marketing etc).

Re: Serverless: slower and more expensive

#657

Post by iamsb »

foxtr0t wrote: post #602
abiro wrote: post #50

PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…

So, to summarize, you should: 1. not use the programming language that works best for your problem, but the programming language that works best with your orchestration system 2. lock yourself into managed services wherever possible 3. choose your api design style based on your orchestration system instead of your application. 4. Use a specific frontend rpc library because why not. ... I've hacked a few lambdas toget…

The way read above comment is - If you can live with following limitations, then use lambda/serverless, works great. I have got to a point where for any internal systems used by internal users, lambda is my defacto standard. Very low cost of operation and speed to market. For anything that is external facing I prefer not to use lambda, specially if growth of usage is unpredictable.

Re: Serverless: slower and more expensive

#658

Post by gchamonlive »

teacpde wrote: post #354
claudiusd wrote: post #311

I did the same experiment as OP and ran into the same issues, but eventually realized that I was "doing serverless" wrong. "Serverless" is not a replacement for cloud VMs/containers. Migrating your Rails/Express/Flask/.Net/whatever stack over to Lambda/API Gateway is not going to improve performance or costs. You really have to architect your app from the ground-up for serverless by designing single-responsibility mi…

To eliminate the need of a web framework? I don’t understand the rationale, if I can get all what’s mentioned done with a good web framework, I will be more than happy to do that.

With your own server and Web framework, you do all the work in provisioning the machine, configuring services, installing dependencies, building deployment and integration pipelines and, worst of all, maintaining all that when updates are released / something breaks. It is also harder to scale.

A serverless solution that eliminates the Web framework (and thus the stack in which is being run) does most of that for you, at the expense of extra cost or infrastructure deployment complexity, but once it is done, scaling and maintenance are easier.

Re: Serverless: slower and more expensive

#659

Post by purple_ducks »

jmnicolas wrote: post #653
abiro wrote: post #639

Earlier quoted context omitted.

Think about serverless as framework-as-a-service. It has a learning curve, but if you buy in, it is an amazing productivity boost. (If Reddit’s video hosting being built and operated on a serverless stack by a single a engineer won’t convince you, I don’t know what will.)

90% of Reddit videos are unwatchable for me : they start OK then the quality is downgraded to something unwatchable and there's nothing I can do about it. I even tried to download them with youtube-dl but it doesn't work.

100% agreed. The initial buffering time on them is ridiculous. I've started uploading to streamable and just posting that link rather than upload video straight to reddit.

Re: Serverless: slower and more expensive

#660

Post by amjd »

anderspitman wrote: post #604
zinckiwi wrote: post #569

Earlier quoted context omitted.

I've often looked at and played with Firebase since it does so much of what I need to back a React Native-based app for simple mobile games and utilities. I always end up talking myself out of it due to Google's history of pulling the plug on (what seem to an outsider to be) perfectly good, stable products that wouldn't do any harm to keep around indefinitely. As a hobbyist, I wouldn't have the time or motivation to…

It would be nice if there was a dead-simple Firebase-like tool you could self-host. ie just a single instance that you could point all your toy apps at to give them a little real-time persistence.

Around the time that Parse (mentioned by sibling) was killed and open sourced, a lot of open source Firebase-like solutions had sprung up, some of which are listed here: https://github.com/relatedcode/ParseAlternatives#open-source...
Post reply on HN