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

71–80 of 110 posts

Re: Serverless: Cold Start War

#71

Post by acjohnson55 »

biztos wrote: post #53
acjohnson55 wrote: post #26

I'm still a bit puzzled by the hype around FaaS. It seems like a useful tool for things where you don't want major queuing under pressure, but you can tolerate human perceptible delays. But it also seems easy to build a big ball of mud deeply tied to the nuances of the chosen FaaS provider. It just seems like most use cases are probably going to be just fine with more conventional horizontal scaling techniques. But I…

I'm pretty new to it but so far I think the big selling points in a corporate environment are: 1. (Maybe, someday) no real Ops work. 2. 100% utilization (at a cost). 3. Measurability of cost in #2. I agree about the ball-of-locked-in-mud danger. And so far I've seen the Ops part be actually a bigger issue than it was before, because there's so much opaque, badly documented madness involved. With AWS Lambda + API Gate…

The no-ops part is compelling, but we've already had that for years in the form of PaaS for small teams and K8s for large ones.

I think the billing part sounds a bit like a trap to me. At least while FaaS retains so many quirks, it's like trading billing for the engineering time of contorting a business process to a given FaaS model (e.g. trying to eek out the lowest average and worst case latency; also working within language runtime limitations).

I'm pretty sure ops will never be automated away; it can only be transmuted to a different form :). But, at best, you can achieve elegant separation of ops and process concerns. That's where I worry FaaS could be a bit of a hazard, if not carefully utilized.

Re: Serverless: Cold Start War

#72

Post by lilbobbytables »

XorNot wrote: post #52
bartread wrote: post #44

Earlier quoted context omitted.

This made me smile because I too have been puzzled by the hype around serverless. I'm sure it does have its uses but it wouldn't provide an acceptable solution for any of the problems we currently need to solve. Not saying that won't change but I do find it vaguely irritating that serverless has at times been presented to me as an end to all woes when that clearly is not the case.

Having just spent sometime actually learning "serverless" between lambda and GCP I am presently baffled as to how this isn't weirdly hard to use docker containers.

To your point, it seems like AWS ECS really is the best of both. You get the no-infrastructure benefits of Lambda with the flexibility/control of a docker container.

You keep the ability to exercise a fair amount of control, easily, and clearly. And you don't sit inside really opaque execution environment.

Sure, the scaling and provisioning of those Docker containers is opaque, but I'm much more willing to deal with it at that level.

Re: Serverless: Cold Start War

#73

Post by falcolas »

lilbobbytables wrote: post #72
XorNot wrote: post #52

Earlier quoted context omitted.

Having just spent sometime actually learning "serverless" between lambda and GCP I am presently baffled as to how this isn't weirdly hard to use docker containers.

To your point, it seems like AWS ECS really is the best of both. You get the no-infrastructure benefits of Lambda with the flexibility/control of a docker container. You keep the ability to exercise a fair amount of control, easily, and clearly. And you don't sit inside really opaque execution environment. Sure, the scaling and provisioning of those Docker containers is opaque, but I'm much more willing to deal with…

I'm guessing you're thinking of their Fargate option. ECS itself is not terribly opaque (at least to my eyes). Fargate's biggest downside is its own cold start times - unlike Lambda, there's no caching to give you warm starts on jobs.

The flip side - so long as its a service and not a job, who cares? :D

Re: Serverless: Cold Start War

#74

Post by falcolas »

pjc50 wrote: post #62

What if we had smaller programs, such that an executable could be started on demand for each request? You could also avoid GC and long-term stability issues this way by having a short-lived program. It even allows you to have multiple different microservice functions written in different languages served by the same system. So long as they use a similar API - we could call it a Common Gateway Interface? (Yes, this is…

It's somewhat amazing to me how some CGI services are so often faster than full-blown-listening-on-port-8080 "micro" services.

It's unfortunate that we consider 1-3 seconds to be acceptable response times.

Re: Serverless: Cold Start War

#75

Post by snaky »

pjc50 wrote: post #62

What if we had smaller programs, such that an executable could be started on demand for each request? You could also avoid GC and long-term stability issues this way by having a short-lived program. It even allows you to have multiple different microservice functions written in different languages served by the same system. So long as they use a similar API - we could call it a Common Gateway Interface? (Yes, this is…

Inetd was a thing since 4.3BSD actually.

And IncludeOS is a modern way to do it.

Re: Serverless: Cold Start War

#77

Post by village-idiot »

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.

Re: Serverless: Cold Start War

#78

Post by village-idiot »

TrueTeller wrote: post #47
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…

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.

Re: Serverless: Cold Start War

#79

Post by village-idiot »

acjohnson55 wrote: post #26

I'm still a bit puzzled by the hype around FaaS. It seems like a useful tool for things where you don't want major queuing under pressure, but you can tolerate human perceptible delays. But it also seems easy to build a big ball of mud deeply tied to the nuances of the chosen FaaS provider. It just seems like most use cases are probably going to be just fine with more conventional horizontal scaling techniques. But I…

From what I’ve seen, managing and deploying FaaS is also a major train wreck.

Re: Serverless: Cold Start War

#80

Post by village-idiot »

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…

A shockingly large number of people run around repeating what they remember from Java 6 or earlier, without bothering to realize tha Java and the JVM have changed a lot.
Post reply on HN