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.
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.
“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.
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.