Eight teams submit a hundred jobs a day, from seconds long to hours long. How would you place those workloads across the three supply models?

## The question is per workload, not per organisation The weak answer picks a favourite and standardises on it. The strong answer observes that a hundred jobs a day across eight teams is not one workload, and that the three supply models differ on exactly the axes those jobs differ on. Two definitions the argument needs: a **worker process** is the process on a cluster machine that runs pieces of a job and owns their memory, and a **coordinating process** is the single process that plans the pieces, hands them out and tracks what finished. Every model produces both; the models differ in who owns the machines under them and for how long. ## The axes that decide a placement 1. **Tolerance for the wait before the first piece runs.** Machines that already exist start work now. Machines that must be raised first spend a fixed wait doing so, and how long that is varies widely by platform. For a job that runs for hours, the wait is a rounding error. For work someone is sitting and waiting on, it can be most of the elapsed time. 2. **Whose lifecycle the workload needs.** A job that wants its own runtime and library versions, its own restart schedule and a blast radius of exactly itself wants its own machines. A job that is happy with whatever everyone else has does not need to pay for that. 3. **Who will operate it.** Keeping machines up is an ongoing job with an owner. A team without one is better off with a model where the provider owns sizing, starting and stopping. 4. **How predictable the arrival is.** Steady, known demand is what a long-lived pool is sized against. Spiky, unpredictable demand from many teams is what it is worst at, because it is sized in advance for everyone at once. 5. **What the workload keeps.** If the second run genuinely benefits from a warm working set, machines that die with the job cannot provide it; you must either keep machines up or persist the result to shared storage deliberately. ## A placement that usually falls out | workload shape | model | why | |---|---|---| | short interactive or exploratory work, all day | machines already up | the wait to raise machines would dominate the work itself | | long scheduled jobs, heavy, predictable | a cluster per job | isolation and independent versions are worth the start-up wait | | continuous jobs that never end | a cluster per job | one owner, one lifecycle, no neighbours for something that runs forever | | occasional work from a team with no operator | a service that shows no machine | nobody has to own sizing, patching or restarts | | anything odd, rare and one-off | a service that shows no machine | the least standing commitment for the least frequent work | The continuous-job row is worth defending in an interview: a job that never ends does not mix well with machines shared by everyone, because it holds its share forever and it is the job most disrupted by a restart of the shared thing it lives on. ## The counterweight nobody volunteers Each model you operate has a cost that is not machine time: - a separate way of submitting work, and a separate thing that goes wrong on submission; - a separate access and permission path; - a separate place logs and run history end up; - a separate sizing conversation to have with each team; - a separate runbook, and a separate set of failures an on-call person must recognise at three in the morning. So the principal's move is not to place every workload optimally; it is to pick **the smallest set of models that covers the real spread**, and to make the default obvious so teams do not have to choose. Two is usually the honest answer for an organisation of this size — something warm for interactive work, and per-job machines for everything scheduled — with the third reserved for the long tail if it is already available. ## What varies, and must be said out loud The platform decides much of this for you, and the market genuinely differs. On some platforms a cluster is raised in well under a minute and the wait argument nearly disappears. On others a job is sized from a hint rather than an exact request, so "we will size it ourselves" is not on offer. Some services accept no machine sizing at all, only a coarse capacity tier. Any recommendation that does not say which of these is true of your platform is a recommendation about somebody else's platform. ## What this decision does not settle It does not settle how a finite pool is divided when several jobs want it at once, nor what a pool costs while nobody is submitting to it. Those are separate calls with separate owners, and conflating them with the supply model is how placement discussions turn into budget arguments.