Hacker News Reader

Comment by pdhborges | Hacker News Reader

> While it would certainly have been possible to lift and shift this workload to EC2

Unfortunately I think that the article doesn't make a good case of why this was discarded right off the bat. In particular it is not clear why this wasn't a lift and shift with the NAS storage replaced by S3 and Celery workers placed under an autoscale policy.

Looking at the conclusions the first two are consequences of having on demand compute power while the third one is just surpring (was 70% of the code dedicated to celery infrastructure?).

View on HN

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.

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

Yes that’s what serverless is. It’s running compute jobs via a scheduling layer. That’s all it is.

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

Reply on news.ycombinator.com