3 ms·

I suppose the authors assumed the reader is familiar with the benefits of the serverless model. When running functions as a service, you don't have to administ

I suppose the authors assumed the reader is familiar with the benefits of the serverless model. When running functions as a service, you don't have to administer the OS, you just request the computation, provide an input event, and wait for the results to be computed. If you use EC2 you need to handle the work submission, the scaling and registration of the workers, and the security and life-cycle of the OS yourself. It seems to me they didn't get all the benefits of serverless, because they had to write thier own custom workload management code. But probably it would still be simpler than managing the workload across thousands of EC2 instances.

arinlen 4y ago
> When running functions as a service, you don't have to administer the OS, you just request the computation, provide an input event, and wait for the results to be computed. You don't have to administer any OS when you run them with a container orchestration system as a short-lived job. It's also perplexing how suddenly "managing an OS" is depicted as such a blocker, specially in a time when treating servers as cattle is the norm.
- diroussel 4y ago
  Yes that’s what serverless is. It’s running compute jobs via a scheduling layer. That’s all it is.
  - arinlen 4y ago
    > Yes that’s what serverless is. It’s running compute jobs via a scheduling layer. That’s all it is. I'm not sure you got the point. The whole point is that you don't need to throw "serverless" buzzord nonsense around to be able to launch long-running processes in the cloud. Al you need is a way to launch processes, and that just happens to be the main responsibility of container orchestration systems, which just so happen to support launching them transparently in your own cluster.