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

641–650 of 733 posts

Re: Serverless: slower and more expensive

#641

Post by abiro »

matchagaucho wrote: post #591
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…

RE: #3. This still requires a Lambda to pre-sign the URL. No? Granted, this approach is much lighter than uploading an image directly.

If you use Cognito for identity management, then there isn’t even need for that. You can just assign users the appropriate IAM role and you can upload directly from the front end.

Re: Serverless: slower and more expensive

#642

Post by zaro »

frenchman99 wrote: post #289
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…

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…

I also feel the same about point 7.

The big difference we are migrating away from Heroku to Kubernetes for the same reason.

Re: Serverless: slower and more expensive

#643

Post by abiro »

xchaotic wrote: post #618
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…

As general rules these sound great at first sight, but don’t really address the main culprit from TFA - like for like API Gateway costs a lot more to process n number of requests.

Well, given the feature set of API Gateway compared to a Load Balancer I think it should be expected that it costs more. But that’s also beside the point which is to use managed services to do the heavy lifting. Eg. if you need a PubSub service for IoT, that shouldn’t go through API Gateway and Lambda, there is a specific AWS service for that.

Re: Serverless: slower and more expensive

#644

Post by kwakuDompreh »

As a new user of AWS services, I was planning to to migrate the website &app to Lambda services, does it mean the platform will get slower? Thanks for the feedback

But, I love to work in NodeJs for it’s easy scalability , using GraphQL will disrupt the process. What do you think about that ? Thanks

Re: Serverless: slower and more expensive

#645

Post by dragonelite »

snisarenko wrote: post #616
dragonelite wrote: post #184

Earlier quoted context omitted.

I tried using google cloud run, with a rust web server. I think google only counts request processing time and rounds up to the nearest 100ms. All i had to do was provide a container with a web service that reads a environment variable to listen to a specific port.

I am considering using g cloud run for my next project. How did you like it ?

Too be honest it was really just a small project to get used with Actix web a rust web frame work and to setup a google cloud build ci/cd that would build a container i could host somewhere. I only used cloud run because i saw a youtube suggestion about it xD So there was no load except me and some friends pushing f5 a couple of times.

You can create a web service in whatever language and framework you want, all you need to do is read a PORT environment variable for incoming messages. The freedom was really awesome, instead of being confined to supported languages and frameworks you get in the functions landscape. Only confinement was that you're pretty much limited to HTTP calls, unless that has changed.

Personally i find the freedom of pick your own language and framework a big positive, and billing is finer on cloud run compared to AWS Fargate(rounded up to next sec) if im not mistaken. I do wish they would make billing even more finer instead of rounding up to the next 100 ms, rounding up to the next 10ms would be nicer when you use non GC or Runtimed languages, like Rust.

Re: Serverless: slower and more expensive

#646

Post by jbverschoor »

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.

20 years ago. We had enterprise java, it’s still “there”, but running spring is very different from what it used to be.

You’d simply upload an ear or ear and the server and deployed would handle configuration like db etc.

It worked perfectly (ear/war, the persistence framework was too verbose and high level imo, but that was replaced by hibernate/jpa). There was too much configuration in xml, but that could easily be replaced my convention, annotations and some config

Again.. we are running in circles, and this industry will never learn, because most “senior” people haven’t been around long enough.

Re: Serverless: slower and more expensive

#647

Post by arthens »

bmm6o wrote: post #441
dullgiulio wrote: post #150

Earlier quoted context omitted.

Just to be clear: lambdas are not stateless if you, for example, connect to a DB or use any other external service. State could be somewhere else, but if you are not also "pure", you don't have any improvement over a normal service.

That's not what I've understood "stateless" to mean. Sure, anything more complicated than a calculator app is going to rely on data stored elsewhere, and in Lambda world that means you're reading from DynamoDB, S3, RDS or whatever. Those are definitely dependencies and that's where the state lies. But the pattern encouraged by Lambda is that your instance contains no state of its own. The disk is used as scratch for…

I see your point, but this definition is so lax that it applies almost perfectly to any application I've ever deployed to the cloud. Using external services to save state isn't unique to lambda, any app hosted on a normal ec2 instance needs to follow the same pattern because the instance and its filesystem can go away at any time (unless you attach a volume, but I've always considered that to be bad practice).

Re: Serverless: slower and more expensive

#648

Post by laurentl »

unicornmama wrote: post #468
abiro wrote: post #393

Earlier quoted context omitted.

Lambda is 5 year old technology. This is like arguing in 2011 that startups shouldn’t use EC2, because it’s “risky”.

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

Large scale reliable systems are antinomic with “launching a startup”. You’re going to go through 2 or 3 pivots and as many refactors, large scale is the last thing you want to optimize for.

Re: Serverless: slower and more expensive

#649

Post by jakoblorz »

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

Until he leaves and some poor other dev has to dig into his stack

Re: Serverless: slower and more expensive

#650

Post by nailer »

arthens wrote: post #647
bmm6o wrote: post #441

Earlier quoted context omitted.

That's not what I've understood "stateless" to mean. Sure, anything more complicated than a calculator app is going to rely on data stored elsewhere, and in Lambda world that means you're reading from DynamoDB, S3, RDS or whatever. Those are definitely dependencies and that's where the state lies. But the pattern encouraged by Lambda is that your instance contains no state of its own. The disk is used as scratch for…

I see your point, but this definition is so lax that it applies almost perfectly to any application I've ever deployed to the cloud. Using external services to save state isn't unique to lambda, any app hosted on a normal ec2 instance needs to follow the same pattern because the instance and its filesystem can go away at any time (unless you attach a volume, but I've always considered that to be bad practice).

No it's not. There's no in memory state. Your Django rails phoenix app has in memory state.
Post reply on HN