Hacker News new | past | comments | ask | show | jobs | submit login

> all seem to follow the same model of central, allocating schedulers based on distributed consensus about worker inventory.

Because frankly, it's easy to code. You just look thru list of what you have, list of what you put on it, and assign based on this and that algorithm.

It keeps workers simple - register to cluster, send status (or wait for healthckeck), wait for request to start the job, done, you got a worker.

It keeps the scheduler to just be scheduler - take state, apply list of "changes" (jobs to start/stop), execute.

It keeps client simple - submit to scheduler, observe progress.

It is also easy to debug. You just have one place doing the scheduling (and not a bunch of workers playing the "stock market" of resources), running on one node without distributed mess to worry about. Any test is just "feed this state to code and see whether it reacted as we need". Any job that got "rejected" for scheduling have clear reason.

It also allows bigger optimizations to happen from point of view of a cluster.

Some designs are reinvented so many times because they are just good or easy to implement first approximation of solution.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: