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

631–640 of 733 posts

Re: Serverless: slower and more expensive

#631

Post by kahnjw »

Bombthecat wrote: post #626
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…

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.

I see your point though POSIX imposes very few (if any) architecture decisions on application developers. The kind of design choices we’re talking about are very different from those of POSIX-like utilities so I’m not sure if that analogy is a good one.

Re: Serverless: slower and more expensive

#632

Post by mycall »

1337shadow wrote: post #549
abiro wrote: post #142

Earlier quoted context omitted.

> Serverless only makes sense if you have a fairly trivial problem That’s exactly the point. The web application needs of most startups are fairly trivial and best supported by a serverless stack. Put it another way: If your best choice was Rails or Django 10 years ago, then it’s serverless today.

> The web application needs of most startups are fairly trivial and best supported by a serverless stack. Pretty subjective statements, I suppose we don't have the same definition of "trivial". > If your best choice was Rails or Django 10 years ago, then it’s serverless today. Comparing the features of Rails or Django with serverless is like comparing a spaceship with a skateboard.

Because the django was riding a rail on her skateboard and bumped into a spaceship?

Re: Serverless: slower and more expensive

#633

Post by shangxiao »

Bombthecat wrote: post #626
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…

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.

I feel like we're just transferring the labour from ops to dev though. Where I work we still haven't got as good a development workflow with lambdas as we did with our monolith (Django).

Re: Serverless: slower and more expensive

#634

Post by jwilliams »

API Gateway appears to be the biggest bugbear here - and it's definitely got price/overhead issues.. that I'm sure AWS will resolve.

Serverless is great if you're starting from scratch, and have flexibility with your tech stack. If not, you're better of carving off chunks that make the most sense for lambda (with the upshot that this will make your existing components simplier/faster/etc).

Re: Serverless: slower and more expensive

#635

Post by dalanmiller »

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…

> 4. Use GraphQL to pool API requests from the front end.

What does this look like in practice? Doesn't this increase response time for the initial requester?

Re: Serverless: slower and more expensive

#636

Post by oliora »

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…

You forget C++. It’s a great choice for Lambda due to startup times. Python startup time is actually terrible and should be avoided if the call rate is really high. Actually, Lambda instance is reusable and after spinning up it will be used to handle multiple requests (if ones are coming often enough).

Re: Serverless: slower and more expensive

#637

Post by akoumis »

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.

I worked on a service a year ago that would stream a video from a source and upload it to a video hosting service. A few concurrent transfers would saturate the NIC. Putting each transfer job in a separate lambda allowed running any number of them in parallel, much faster than queuing up jobs on standalone instances

Re: Serverless: slower and more expensive

#638

Post by VvR-Ox »

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…

That's so true and I'm happy people begin to realize that.

The worst for me is the vendor lock in, directly followed by the costs.

Re: Serverless: slower and more expensive

#639

Post by abiro »

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…

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

Re: Serverless: slower and more expensive

#640

Post by abiro »

dalanmiller wrote: post #635
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…

> 4. Use GraphQL to pool API requests from the front end. What does this look like in practice? Doesn't this increase response time for the initial requester?

These are usually the read N items from a database type of queries that GraphQL makes trivial to batch together. Will barely increase response time, but will provide a better experience for users on bad connections.
Post reply on HN