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

561–570 of 733 posts

Re: Serverless: slower and more expensive

#561

Post by Avalaxy »

CosmicShadow wrote: post #204
joelthelion wrote: post #107

Earlier quoted context omitted.

> 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. Shouldn't this not be a problem if you're doing 10 million requests a day? If you have enough requests, your lambdas should stay hot most if not all the time.

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.

Re: Serverless: slower and more expensive

#562

Post by kragen »

stevofolife wrote: post #503
kragen wrote: post #457

Earlier quoted context omitted.

You're using Lambda because you haven't figured out how to enable cgi-bin in Nginx?

How can cgi-bin in Nginx help in his case?

Option A above requires standing up a new server. Option B involves just writing a short piece of code that handles a form POST and uploading it to a server (in that case, Amazon's). Option C, "If you have spare capacity on a server you can probably squeeze in such functionality at no extra cost," has the following disadvantages, according to him: "Now you have to tweak the Nginx config to support the service that normally lives on that machine and the new system. And you still have to write and maintain the web service driving it (which may not be hard, like a Flask app with a single route, but still more than zero)."

But a CGI program, assuming you have cgi-bin already configured, gives you the benefits of option B without the drawbacks of option C: you don't need a Flask app or a route or a configuration tweak. You just write a short piece of code that handles a form POST and upload it to a server. The difference is that it's your server, not Amazon's, and you have to put this at the top of your code:

    #!/usr/bin/python
    import cgi
    qs = cgi.parse()
Then you can version-control it in Git so that when you need to figure out what broke last week you don't depend on AWS deployment logs.

Like, literally, the drawbacks of "serverless" that are being cited in this discussion (startup time and performance cost) are the reasons we moved away from CGI in the late 1990s, and literally every single advantage being cited for "serverless" in this discussion is also an advantage of CGI. "Serverless" also has disadvantages of vendor lock-in, lack of programming-language choice, and difficulty of monitoring and debugging that don't exist with CGI, but those aren't coming up much in this discussion.

The only real advantage seems to be if you can get by with literally zero servers of your own, thus saving the US$5 a month you would spend on a low-end VPS to run your potentially dozens of CGI scripts under Nginx, maybe inside Docker. In that case maybe you should look into shared web hosting. Or possibly get a job, if that's a possibility.

I'm not saying "serverless" isn't a good idea or that it isn't an improvement on CGI. The CGI interface is kind of sketchy and it's produced a lot of bugs in the past. It would be easy to do better, especially with a native-language binding. But the reasons we abandoned CGI are also reasons to abandon "serverless", and the actual advantages of "serverless" (if they exist) are not coming up in this discussion.

Re: Serverless: slower and more expensive

#563

Post by tarosnow »

mrich wrote: post #550

The AWS bill seems high already. $90 dollars for m1.small, which has 1 vcpu and less than 2GB memory? At my current hosting provider that machine costs less than 5euro! What am I missing? Looking at the hourly usage it seems to be the equivalent of 3 machines running 24/7, so 15 euro, but still?

It's not just a single instance. Look at the hours billed.

Re: Serverless: slower and more expensive

#564

Post by overgard »

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.

Is there really that much hype? I feel like I haven't heard that much. Serverless isn't even really much of a new thing, there have always been providers that hid the underlying aspects of running a web site on the internet. I think for most people they just don't want to have to worry about patching a machine, rolling logs, watching disk space, etc, if they don't need to.

Re: Serverless: slower and more expensive

#565

Post by mrich »

tarosnow wrote: post #563
mrich wrote: post #550

The AWS bill seems high already. $90 dollars for m1.small, which has 1 vcpu and less than 2GB memory? At my current hosting provider that machine costs less than 5euro! What am I missing? Looking at the hourly usage it seems to be the equivalent of 3 machines running 24/7, so 15 euro, but still?

It's not just a single instance. Look at the hours billed.

That's why I multiplied by 3.

Re: Serverless: slower and more expensive

#566

Post by [deleted] »

acd wrote: post #555

In AWS it is better to use Fargate. You can use standard docker containers with Fargate, you do not need to baby sit and patch servers. Fargate has warm caches in comparison to Lambda. Also it is easier to version control a docker container vs serverless functions. Plus if you do not like Fargate you can move, if you have written everything in proprietary Lambda code you are locked in. Performance comparison between…

[deleted]

Re: Serverless: slower and more expensive

#567

Post by orasis »

redblacktree wrote: post #540
falcolas wrote: post #443

Earlier quoted context omitted.

Add a couple of seconds when spinning up an ENI. New nodes in a VPC are around 3 seconds (and our last EBC with Amazon indicated that it won't get lower than that for awhile). It's worth noting that this impacts ECU scaling for Aurora Serverless as well. Why would you need to put a Lambda in a VPC? For access to a database, other EC2 bound resources, or overall network security reasons (such as outbound network monit…

You may be interested in the latest news re: allocating ENIs in VPCs for Lambda[1]. They've finally got the cold-start situation a little more under control in that scenario. Here's the meat, to save you a click: > AWS says that the one-time setup of the shared network interface can take 90 seconds to complete. But because the network interface gets created when Lambda functions are first created or VPC settings upda…

I did not know this. Thank you.

Re: Serverless: slower and more expensive

#568

Post by PKop »

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.

As other comment stated, Firebase does a lot.

First and foremost it is client side SDK's (web, mobile) for their database products, their newest being Firestore that provides better query capabilities compared to their original Firebase Realtime database (while still offering real-time capabilities).

Along with that is Firebase Authentication, which manages user accounts and authentication.

The real magic comes in with Cloud Functions (their version of Lambda) which allows for hooks in to all sorts of events occurring from usage of these database and authentication products (and other cloud services).

Hook into database writes, updates, deletes, user creation, Google Cloud's pub-sub events and many more. They also offer static website hosting as well as hooking website serving into cloud functions (for server side code execution).

In the context of a website, all of these work together to allow for usage of the JAMstack[0] architecture which decreases your infrastructure resources you need to manage and cost.

[0] https://jamstack.org/

Re: Serverless: slower and more expensive

#569

Post by zinckiwi »

anderspitman wrote: post #557
redisman wrote: post #509

Earlier quoted context omitted.

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

Firebase does a lot of stuff. Originally it was a small company that focused on providing a real-time JSON-like backend store for web apps. But then they got bought by Google and seem to have evolved into Google's answer to a lot of AWS services, ie hosting, real-time DB, serverless, and probably more I'm not aware of.

I've often looked at and played with Firebase since it does so much of what I need to back a React Native-based app for simple mobile games and utilities. I always end up talking myself out of it due to Google's history of pulling the plug on (what seem to an outsider to be) perfectly good, stable products that wouldn't do any harm to keep around indefinitely.

As a hobbyist, I wouldn't have the time or motivation to completely rewrite a project if that happened, which would be necessary since a Firebase app (like a heavily AWS-integrated serverless app) is not just technologically but architecturally tied to that environment.

Post reply on HN