Comment by karmakaze | Hacker News Reader

Comment by karmakaze | Hacker News Reader

Parent Full thread

TL;DR

3 WHY SERVERLESS TODAY IS TOO LESS

(1) Limited Lifetimes. After 15 minutes, function invocations are shut down by the Lambda infrastructure. Lambda may keep the function’s state cached in the hosting VM to support “warm start”, but there is no way to ensure that subsequent invocations are run on the same VM. Hence functions must be written assuming that state will not be recoverable across invocations.

(2) I/O Bottlenecks. Lambdas connect to cloud services—notably, shared storage—across a network interface. In practice, this typically means moving data across nodes or racks. With FaaS, things appear even worse than the network topology would suggest. Recent studies show that a single Lambda function can achieve on average 538Mbps network bandwidth; numbers from Google and Azure were in the same ballpark [26]. This is an order of magnitude slower than a single modern SSD. Worse, AWS appears to attempt to pack Lambda functions from the same user together on a single VM, so the limited bandwidth is shared by multiple functions. The result is that as compute power scales up, per-function bandwidth shrinks proportionately. With 20 Lambda functions, average network bandwidth was 28.7Mbps—2.5 orders of magnitude slower than a single SSD [26].

(3) Communication Through Slow Storage. While Lambda functions can initiate outbound network connections, they themselves are not directly network-addressable [...] can only communicate through an autoscaling intermediary service; today, this means a storage system like S3 [...]

(4) No Specialized Hardware. FaaS offerings today only allow users to provision a timeslice of a CPU hyperthread and some amount of RAM [...] no API or mechanism to access specialized hardware. However, [...], hardware specialization will only accelerate in the coming years.

While each of the above points are mostly quite factual, I don't personally find any of them to be restricting. We run a mixture of stateless and stateful services and serverless is suitable for the stateless ones.

The original problems for network security being solved by running functions in a VPC and secure connections to databases and even connection pools makes pretty much everything work.

Running functions in a VPC cause them to have cold starts of ~5 seconds. Connection pools need to be centralized to be of any use, since lambdas scale automatically.

I found myself in the middle of migrating a startup's entire "something" ingestion pipeline to be entirely done on Lambdas. For our purposes of one data block per every 10-20 minutes, and then processing and ingesting that data, Lambdas work perfectly, and about 10x cheaper than using ECS or EC2.

Well, non of the application we moved to AWS Lambda affected by these. I think the problem is that many of the users misunderstood the scope of Lambda and use it as the holy grail of computing. Simple price calculations usually makes it clear what Lambda is not for. You could pick on big data Hadoop for example and find projects when people wanted to use it for something that it is not good, it is not specific to "serverless".

re 1) Lots of production Lambda applications are not truly stateless. Checking for environment reuse is trivial. For instance, in Java, you can handle this by leaving your instantiation logic in the function constructor just as you would in a typical application.

re 2) I think that that they meant invocations from the same function use a single ENI. This is public knowledge and having any function size between 1.5GB (exclusive) and 3GB will leave you with the entire network interface bandwidth.

re 3) Absolutely a valid criticism, but DynamoDB is typically the source of information sharing among time critical applications and has a significantly different performance profile than S3.

What does "too less" mean? Is it a joke? (I've heard the saying "less is more").

I think it’s a play on the word serverless and their argument that serverless is a lot less performant than “serverful” in the general use case.

“Less is more” ==> “serverless is more” ==> “But serverless is too much less performant” ==> “Too much ‘less’” ==> “Too less”

...or something like that? I wouldn’t worry about it. I’m a native English speaker and I also thought it was awkward, though I (think I) know what they were going for.

Reply on news.ycombinator.com