The lede is kind of buried. The authors were attempting to use FaaS for a long-running, number crunching, distributed computing algorithm.
Case of selecting the wrong tool for the wrong job. Not what serverless was designed to do.
Case of selecting the wrong tool for the wrong job. Not what serverless was designed to do.
Code repo -> docker build -> AWS Fargate. Easy to set up CI/CD pipeline that doesn't require you manage servers and can support long-running, CPU intensive, and even GPU applications.
(You may have to manage the fleet a bit for GPU support, ie create your own ECS cluster with autoscaling -- but not actively manage the deployment of instances.)
I think the point of the piece was more "what serverless could be" rather than what we have right now. I don't think there's any concrete definition of what serverless is, let alone what its designed to do!
The thing the article brushes over is the maintenance/operational burden of running stuff on VMs. It says they achieved much better performance training a machine learning model on a single EC2 instanec, but failed to mention setting up monitoring, logging, deploying code, making that reliable etc.
That's the trade off you make
See https://arxiv.org/abs/1702.04024 [cited by this paper] for promising results doing linear algebra using aws lambda.