Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless: Cold Start War

mikhail.io

Post reply on HN
Print view View original

81–90 of 110 posts

Re: Serverless: Cold Start War

#81

Post by jchrisa »

alpb wrote: post #19
jchrisa wrote: post #18

An alternative approach for user facing apps is to connect directly to the database from the browser. Lambda still has a role to play in such an architecture, but hopefully most of your basic crud operations can go direct, with less commonly called functions like login depending on Lambda. I address this option about 2/3 of the way through this webcast on serverless best practices https://blog.fauna.com/webcast-video…

Probably worth adding disclaimer you work on FaunaDB. :) I am wondering in what sort of cases users can just hit the DB. Do you mind giving a tl;dr? Does it only work for readonly/non-sensitive data?

Thanks. :) That was the last thing I wrote before falling asleep... TLDR is that many (not just FaunaDB) cloud databases have a security and connection model that's suitable for connecting from the browser. I know Firebase has been doing it forever, and you can also do it with DynamoDB if you don't mind complexity.

It takes a little bit of thinking to set up the security rules so that users can only see what they are allowed, but it's worth it for the performance and runtime simplicity. And of course you can always invoke a Lambda for code paths that need to run with privileged access.

Re: Serverless: Cold Start War

#82

Post by lostcolony »

village-idiot wrote: post #78
TrueTeller wrote: post #47

Earlier quoted context omitted.

That's all plausible except the price issue. Say, you keep 10 containers alive, so you make 10x 100ms calls every 5 minutes. That's gonna be $0.20 per month. 20 cents.

Internal math at my org says that lambdas cost about 20% more than an equivalent amount of EC2 power at full utilization. Now hitting full utilization is very hard, but the point is that lambas are only cheaper compared to underutilized EC2 hosts.

If you don't scale up at 80% usage you either have extremely non-volatile workloads (in which case, yes, of course, use EC2s), or you're doing it wrong.

Re: Serverless: Cold Start War

#83

Post by bni »

zackbloom wrote: post #28

One thing this doesn't talk about is Cloudflare Workers. Rather than running a separate container for each function we use V8 isolates directly, meaning the cold start time is under 5ms.

Interesting. I always thought AWS Lambda being a complete Linux environment with curl and everything is just supremely wasteful. What could be the reason AWS implemented it like that? To support many programming languages /runtimes?

Re: Serverless: Cold Start War

#84

Post by icebraining »

akvadrako wrote: post #59
abalone wrote: post #22

Two things. 1- It's amazing that Java has the fastest cold start time! Faster than Nodejs.[1] That's exactly the opposite of what I've heard before. 2- I am so tired of hearing about cold start times for dormant apps as if that is the only cold start scenario. It is arguably a worse problem to have cold starts when scaling! What do I mean by cold starts when scaling? You adopt serverless. Things go great. Your app is…

That chart is quite strange. Why would JS start take 500ms (on my system it's 80ms) and be slower to start with more dependencies? Maybe it's because the bulk of the time is just copying the deployment artifact to the local disk. In that case the overriding factor is the size of the package.

If you require() the libraries at the top, as it seems to be common in Node applications, it makes sense that more dependencies add to the cold start time.

Re: Serverless: Cold Start War

#86

Post by icebraining »

abalone wrote: post #22

Two things. 1- It's amazing that Java has the fastest cold start time! Faster than Nodejs.[1] That's exactly the opposite of what I've heard before. 2- I am so tired of hearing about cold start times for dormant apps as if that is the only cold start scenario. It is arguably a worse problem to have cold starts when scaling! What do I mean by cold starts when scaling? You adopt serverless. Things go great. Your app is…

I don't know how serverless platforms deal with it, but startup times could be "solved" by starting up the function and cloning it when it's ready to process requests, as Unix daemons have done for a long time.

Re: Serverless: Cold Start War

#87

Post by mrep »

village-idiot wrote: post #77
stephenr wrote: post #32

Tech, to Business: So, hear me out guys. With the power of "The Cloud", we can break our compute workload down to the function level, and have them run as a service for us, rather than say an entire VM, or even an entire container. And because it's a "Cloud" service, we pay for what we use, so if there's no workload for the functions to service, there's no cost. We just pay for the time the tiny little container is a…

My takeaway is that lambdas are pointless if you’re latency sensitive. If you’re not latency sensitive, such as queue to queue lambdas, then go for it.

Yes. It is pretty much useless for web servers as even the scale out from 1 vm container to 2 will require a cold start. In hindsight, this is kind of obvious as you don't expect them to keep a bunch of containers loaded with your dependencies ready to serve requests. They might offer something like that eventually, but at that point your setup is basically the same as ec2 servers loaded with your service in autoscaling groups so why not just use that?

Pretty sketchy marketing in my opinion.

Re: Serverless: Cold Start War

#88

Post by icebraining »

a_imho wrote: post #46

So, what is the killer app of faas? To my layman understanding the selling point is easy scale-ability, but it seems to be inherently at odds with serverless being the most expensive computing model?

Not necessarily; what matters is how peak-y the demand is. For example, my country's teachers portal gets orders of magnitude more requests during a couple of weeks of the year than the average (at the start of the school year). Going serverless for those processes might make sense.

Re: Serverless: Cold Start War

#89

Post by Nialna »

enitihas wrote: post #51

Has anyone here migrated back from lambda to conventional servers? How was the experience like. Is there any straightforward way to convert serverless projects to traditional services en masse. In what cases would you recommend moving away from serverless?

We have from Google cloud functions because they are a joke (see cold start graph on OP link). Even during development it was horribly painful to have 10+ second call times on many many requests while testing (and the same in production). Even requests that are only a few minutes or seconds away from each other would cold start randomly.

I already had a centralised entry point for cloud functions (just a basic abstraction), but generally they are pretty much wrapped Express requests, in GCP at least, and AWS too I think so the experience should be similar between AWS and GCP.

Changing that to be actual pure Express functions and not use the cloud functions API was pretty easy and quick, and while I was there I refactored our entry points a bit to be easier to migrate in the future.

The only thing that took time was making a new deployment process (we moved to App Engine so it's still "kinda serverless"). Since cloud functions have their own deployment system, I had to write our own deployment scripts, management of environments and so on rather than relying on the one provided by firebase cloud functions. Not a lot of work really, and this is something you would need if you have your own seevers anyway.

Once you have this done, it's pretty easy to move your "cloud functions" to any scaling node server host, or even to another cloud FaaS provider.

Re: Serverless: Cold Start War

#90

Post by 15155 »

bni wrote: post #83
zackbloom wrote: post #28

One thing this doesn't talk about is Cloudflare Workers. Rather than running a separate container for each function we use V8 isolates directly, meaning the cold start time is under 5ms.

Interesting. I always thought AWS Lambda being a complete Linux environment with curl and everything is just supremely wasteful. What could be the reason AWS implemented it like that? To support many programming languages /runtimes?

I would guess for these reasons and liability reasons: what happens when V8's sandboxing is exploited?
Post reply on HN