Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

691–700 of 733 posts

Re: Serverless: slower and more expensive

#691
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.)

In 2010 I was 24 yr old and built a myspace clone SaaS with music and video hosting with everything it implies: large uploads, background jobs, compiling an nginx patch to support range requests, ajax to have videos and music playing while browser, with Django on a 20 bucks/month server. If you're not convinced I don't know what will.

that sounds cool, what happened to it? that'd be a fun project to work on today :)

Re: Serverless: slower and more expensive

#692
Server less seems very case specific. Either it works for your model or it doesn't. And if it doesn't then its a lost cause given the inflexible nature of the limitations. Its not tweak able in most cases

This just reads like a casestudy where it was not the right answer.

I also think people giving others flak for "abusing" the free tiers are missing the point. The free allocation is there to be used. Sure don't go create 5x fake accounts but to me structuring your app to stay within limits is a very reasonable proposition

Its not like the cloud provider is getting screwed - they want as much mindshare to their ecosystem as they can get.And someone learning and deploying their tech gets them quite far on that

Re: Serverless: slower and more expensive

#693

Earlier quoted context omitted.

> Again.. we are running in circles, and this industry will never learn, because most “senior” people haven’t been around long enough. And that likely won't change in our lifetime, given the rate of growth in demand for software: we literally can't create senior engineers fast enough for there to be enough to go around. As an aside, I have the privilege of working with a couple of senior folks right now in my current…

The percentage of seasoned engineers is so low that 'senior' as a title often seems to stretch to "whoever is most experienced around here". That's probably fine, since people understand that experience is not reducible to that title. But this does bring to mind a metric for finding "objectively" senior engineers: What's the biggest idea you've seen abandoned and then reinvented with a new name?

Cooperative multitasking => Node

Re: Serverless: slower and more expensive

#694
post #670
post #584

Earlier quoted context omitted.

this? https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws... https://github.com/awslabs/aws-lambda-rust-runtime https://crates.io/crates/lambda_runtime you rock! That docker based build system makes building those MUSL based rust binaries a snap!

Yep! Thank you so much! I really need to update the documentation, but I think `cross` ( https://github.com/rust-embedded/cross ), a drop-in cargo replacement, is the probably the best available solution for building musl-based binaries.

I've struggled with this before, will have to take a look at it.

Re: Serverless: slower and more expensive

#695

Earlier quoted context omitted.

The parallelism argument doesn’t pass muster because you can do the same thing with a cluster of free tier t2.micro machines with any good orchestration platform, not just lambda. This argument is basically: no counterpoint to the original post, but you can do things that are also easy on any other comparable platform. Tell me again what I don’t understand?

> Tell me again what I don’t understand? As someone who has done both, it's far, far easier to stand up a lambda than it is to manage a cluster of servers.

This still doesn’t make sense. There are portable systems that do the same, and have fully managed options, such as kubernetes.

In my mind the thing that makes lambda “easier” is they make a bunch of decisions for you, for better or worse. For real applications probably for the worse. If you have the knowledge to make those decisions for yourself you’re probably better off doing that.

Re: Serverless: slower and more expensive

#696
post #664

Earlier quoted context omitted.

Paying one guy is cheaper than two. So... You are not wrong :)

Unless your work doubles and you need to hire another dev.

No, that is always the way of work: reduce workers, increase load. We in IT were just spared from it so far. Now it arrives too.

Re: Serverless: slower and more expensive

#697

Earlier quoted context omitted.

Yes but running multiple lambda jobs in parallel would still add upto more time than 12 minutes. What am I missing?

If I was running 10,000 transfer jobs in parallel and the longest of them took 12 minutes, the job would take 12 minutes

Yes but you are still charged for 18 hours of compute time?

Re: Serverless: slower and more expensive

#698
post #574

Earlier quoted context omitted.

This seems more applicable to consumer products, not business / cloud services, though I imagine I might be overlooking something.

That's a fair observation. I do go back and forth but in the end it's enough to swing me, in the principle-of-least-regret way.

It seems like a pretty reasonable concern to me. We can presume the odds are pretty low, yeah. But the consequences are very high - you would need to redesign and possibly rewrite in another language your entire application. People complained up a storm about Reader dying, but it was a 5min process to export your subscriptions and import into another web reader that had basically the same feature set. Conventional Linux hosting, or even Docker, could be pretty easily re-hosted as-is on any of hundreds of other places.

Re: Serverless: slower and more expensive

#699
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…

I can't support point 7. enough. People often forget about the cost of labor. We migrated our company webapp to Heroku last year. We pay about 8 times what a dedicated server would cost, even though a dedicated server would do the job just fine. And often times, people tell me "Heroku is so expensive, why don't you do it yourself? Why pay twice the price of AWS for a VM?" But the Heroku servers are auto-patched, I ge…

The cost you're talking about is really hard to measure. Were they able to reduce the team sizes and get rid of positions after the change? Did the payroll reduce at all?

Re: Serverless: slower and more expensive

#700
post #674

Earlier quoted context omitted.

I can't support point 7. enough. People often forget about the cost of labor. We migrated our company webapp to Heroku last year. We pay about 8 times what a dedicated server would cost, even though a dedicated server would do the job just fine. And often times, people tell me "Heroku is so expensive, why don't you do it yourself? Why pay twice the price of AWS for a VM?" But the Heroku servers are auto-patched, I ge…

Same for us. - Corrupted build? Reverse button for the rescue. - SSL? They got you. - Adding new apps in less than 1m? and so on ...

How is that any different than running your app in Kubernetes or, heck, even deploying it with ansible?
Post reply on HN