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

621–630 of 733 posts

Re: Serverless: slower and more expensive

#621

Post by mycall »

ses1984 wrote: post #617
hallman76 wrote: post #605

Earlier quoted context omitted.

> I've hacked a few lambdas together but never dug deep Then why comment? You clearly don't understand the use-case that AWS fits. I've had jobs that took 18 hours to run on single machine finish in 12 minutes on Lambda. I could run that process 4 times a month and still stay within AWS's free tier limits. For the right workloads it is 100% worth realigning your code to fit the stack.

>I've had jobs that took 18 hours to run on single machine finish in 12 minutes on Lambda. I could run that process 4 times a month and still stay within AWS's free tier limits. Ok I'll bite. What takes 18 hours to run on a single machine but finishes in 12 minutes on Lambda.

An unoptimized query?

Re: Serverless: slower and more expensive

#622

Post by mycall »

rogem002 wrote: post #596
frenchman99 wrote: post #289

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…

Once you factor in the learning time for AWS per a developer the cost is even higher. At my previous company we had project with an AWS deploy process that only two developers could confidently use. Teaching a new developer & keeping them up to date was a big time sink. For comparison we had a Rails app setup on heroku that on day one junior devs were happily deploying to (plus we had Review apps for each PR!)

https://docs.microsoft.com/en-us/azure/app-service/container...

Re: Serverless: slower and more expensive

#623

Post by kovek »

mycall wrote: post #621
ses1984 wrote: post #617

Earlier quoted context omitted.

>I've had jobs that took 18 hours to run on single machine finish in 12 minutes on Lambda. I could run that process 4 times a month and still stay within AWS's free tier limits. Ok I'll bite. What takes 18 hours to run on a single machine but finishes in 12 minutes on Lambda.

An unoptimized query?

Why would the processing time differ? Would you have multiple lambdas running different subsets of the unoptimized query?

Re: Serverless: slower and more expensive

#624

Post by Illniyar »

redisman wrote: post #509
Illniyar wrote: post #381

Earlier quoted context omitted.

Firebase now makes most of these painless. They've done a really good job. If your starting from the grounds up and can stomach using a google product Firebase is the easiest to work with by far.

Do you have some more to read about that? Sounds interesting but I'm now confused as to what FireBase is/does.

For this purpose it does realtime database, faas, scheduling, pub/sub, authentication, file storage, notifications and web hosting.

Everything you need for a web or native app, and it's all integrated together rather well.

Re: Serverless: slower and more expensive

#625

Post by kahnjw »

kovek wrote: post #623
mycall wrote: post #621

Earlier quoted context omitted.

An unoptimized query?

Why would the processing time differ? Would you have multiple lambdas running different subsets of the unoptimized query?

You could achieve the same with basically any decent concurrency model on a single machine.

Re: Serverless: slower and more expensive

#626

Post by Bombthecat »

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…

You are not wrong. But it is all about saving money on labor. The rest are just the constraints of the system you use. (Aka requirements) its like complaining about the need to use posix for Linux.

Re: Serverless: slower and more expensive

#627

Post by ericd »

coldtea wrote: post #73
peterwwillis wrote: post #56

Earlier quoted context omitted.

> The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really con…

> If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. This is "you'll always have to do X, so might as well do 10x" argument...

Maybe I'm not patching correctly, but I never found keeping an LTS OS up to date to add a significant amount of work over keeping frameworks up to date, let alone 10x.

Re: Serverless: slower and more expensive

#628

Post by mycall »

kovek wrote: post #623
mycall wrote: post #621

Earlier quoted context omitted.

An unoptimized query?

Why would the processing time differ? Would you have multiple lambdas running different subsets of the unoptimized query?

Maybe one lambda is timing out to fallback, slowing sagas down. I don't know.

Re: Serverless: slower and more expensive

#629

Post by mycall »

Avalaxy wrote: post #561
CosmicShadow wrote: post #204

Earlier quoted context omitted.

I built an azure function that runs for free that just pings my .NET MVC pages periodically so they are always hot on my cheap hosting.

You can just use application insights for this. It can also show you the results of the ping over time in a scatter chart.

I need to include this into my builds.

Re: Serverless: slower and more expensive

#630

Post by mycall »

missosoup wrote: post #120
abiro wrote: post #105

Earlier quoted context omitted.

I don’t think anybody advocates for rewriting all existing projects as serverless. But if you’re starting a startup, going all in on serverless will let you deliver better products faster. If Paul Graham’s Beating the Averages would be written today, the secret weapon would be serverless, not Lisp.

> going all in on serverless will let you deliver better products faster Can you show some empirical evidence that supports this? In my experience this is another nebulous serverless hype claim that doesn't withstand scrutiny.

Isn't Netflix serverless?
Post reply on HN