Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

251–260 of 733 posts

Re: Serverless: slower and more expensive

#251

This is how a conversation with a colleague who were enthusiastic about Serverless, and who's company was mostly on Java/JVM stack went: Colleague: Lambda is awesome, we can scale down to zero and lower costs! We love it! We use cool tech!! Me: What did you do about JVM warm up? Colleague: We solved it by having a keepalive daemon which pings the service to keep it always warmed up. ... Me thinking: Uhh, but what abo…

It’s useful for services which fit its design: using an extremely heavy environment like Java will rarely be a good fit but for even Python/Node it works much better, without even considering things like Go/Rust.

Re: Serverless: slower and more expensive

#252

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.

State is saved somewhere, sure. How many useful applications are truly stateless when considered in their entirety? This isn't the sense in which servers are usually said to be stateless, however. A Lambda that reads and writes state from a database when invoked is not maintaining state outside of the request-response cycle itself, so it can be said to be stateless.

Yes, but the parent said "statelessness that makes it easier to TEST". It is not stateless in that sense: purity makes it easier to test. Here you need to mock all interactions with external services, just like you'd do with non-serverless applications.

Re: Serverless: slower and more expensive

#253

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.

State is saved somewhere, sure. How many useful applications are truly stateless when considered in their entirety? This isn't the sense in which servers are usually said to be stateless, however. A Lambda that reads and writes state from a database when invoked is not maintaining state outside of the request-response cycle itself, so it can be said to be stateless.

It's funny because the only use case I was considering lambda for was a pure / stateless function. As soon as you add state / side-effects I assume you've greatly increased your complexity and testing (you'd want to have separate tests for all of the inputs / outputs that resemble production... which is when things can get complicated).

I'm probably looking at it wrong I guess. I considered using lambda to unload some CPU intensive calculations / logic and that's it. I figured it would be good for that as long as the latency didn't outweigh any benefits.

Re: Serverless: slower and more expensive

#254
post #237
post #137

Earlier quoted context omitted.

"No because Lambdas are proprietary which means you can't run it in a CI or locally." It kinda is, but not really. You get an event object as param and often only need a few fields from it. Also, you can run Lambda locally, AWS SAM CLI lets you run them in Docker for debugging purposes.

I found SAM to be extremely difficult to use, especially on windows where docker is just plain old terrible.

I have the latest Windows insiders build on a spare machine. I've found all the aws tooling including SAM works pretty well under WSL 2 now that WSL uses a true Linux kernel.

Re: Serverless: slower and more expensive

#255

Earlier quoted context omitted.

Exactly. Like anything, right tool for the right job. I was hosting my personal website on EC2 with an RDS instance and it cost around $20/month. But since the site gets little-to-no traffic and I got sick of EC2 upkeep, I switched S3 & Cloudfront: now my bill is $0.80/month. Another example: at work we inherited an old EC2 instance that was set up solely to run cron jobs on other servers. Occasionally it would lock…

How did you replace a site that needed rds with s3? Was it a blog that you moved to Jekyll or something?

If you are comfortable with React, look at GatsbyJS. It is pretty amazing what you can build into a static site.

Re: Serverless: slower and more expensive

#256

Earlier quoted context omitted.

Not if you have to serve 1 million requests in one second (with low latency) and then don't get any requests for the rest of the day. On the contrary, traditional options will probably end up costing a lot more since you'll need to have them ready in advance to serve the requests instantly and so you could be paying for the entire day of capacity or at least several hours.

All Lambda does is spin up a bunch of containers to handle that. Why is that any different than traditional options? You would just horizontally auto scale in the exact same way. You don't HAVE to pre-provision anything. Plus, receiving 1 million requests in one second, you'll have cold starts for every new container that gets created for you, so achieving consistent low latency would be impossible since you don't co…

Does AWS let me spin up containers as fast as it lets me spin up lambda processes? I've never seen that but then they do add things regularly.

Re: Serverless: slower and more expensive

#257
post #83
post #69

Earlier quoted context omitted.

> We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless…

> That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle. Other forms of serverless might save time. However there's always edge c…

Can't agree more. One example is CI/CD through docker image, building image / deploying container may take ten to thirty minutes long. It's a hindrance for quick bugfix / tempering on test server.

Re: Serverless: slower and more expensive

#258

"Serverless" is basically yet another manifestation of the fact that (despite recent controversy about, well, him being weird) Stallman was right about open-source. The alternative to serverless - open-source products like Mesos, DCOS, Nomad, etc. - offer the same functionality to engineering organizations at lower cost with vastly more pleasant (and manageable) support for things like CI. It's been a great money-mak…

Tell that to https://github.com/apache/openwhisk , https://github.com/knative , etc.

Re: Serverless: slower and more expensive

#259

Earlier quoted context omitted.

Exactly. Like anything, right tool for the right job. I was hosting my personal website on EC2 with an RDS instance and it cost around $20/month. But since the site gets little-to-no traffic and I got sick of EC2 upkeep, I switched S3 & Cloudfront: now my bill is $0.80/month. Another example: at work we inherited an old EC2 instance that was set up solely to run cron jobs on other servers. Occasionally it would lock…

How did you replace a site that needed rds with s3? Was it a blog that you moved to Jekyll or something?

most likely either Jekyll or Gatsby

Re: Serverless: slower and more expensive

#260

Earlier quoted context omitted.

Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?

> Heroku is not Serverless in the modern definition of the word Heroku seems to be serverless in the way cloud vendors, including Amazon, have been using it recently; it's not serverless in the sense that Amazon first introduced it, which was a synonym for Lambda. It's pretty similar to GAE, which is definitely within the current usage of “serverless”.

Heroku is just an easier way to deploy to servers. It doesn’t scale down to zero, scale up as needed, etc. You still have distinct servers that you know about, can manage. S3, Fargate (Docker), DynamoDB, even SNS/SQS are considered Serverless by AWS’s nomenclature.
Post reply on HN