In a cloud context, something like AWS spot instances or GCE preemptible instances is a neat tool for this specific niche of minimizing cost when you can accept

In a cloud context, something like AWS spot instances or GCE preemptible instances is a neat tool for this specific niche of minimizing cost when you can accept delays. The context: providers need more instances than will sell at list price, so they sell access substantial discounts if you accept that a customer paying full fare can bump you out. (Note instance shutdowns might be correlated, not random.) I've definitely heard of folks running tools like Spark that way. From the software angle, being able to efficiently use various types of machine and being able to minimize work lost when a worker dies (i.e. to checkpoint) can help there. I've heard of analogous setups for companies that own their boxes, e.g. Google's Borg paper talks about the tricks they do to make production and non-production jobs share the same box effectively. I think sometimes cost optimization will lead you to counterintuitive answers. For example, obviously the post is right that memory is pricier than disk is. (Also, external memory algorithms are cool; more people should read about them.) But when box time itself isn't free, and more RAM or faster storage allows you to use less of it, the pricier computing resources can end up paying for themselves. Like a cost version of the race to idle in power management. And the (good) discussion of the costs of going distributed may lead you to want to have big enough boxes available to allow you to distribute fewer jobs, even when those boxes cost (more-than-linearly) more than smaller ones. I'm not saying this to advocate for a particular strategy; more want to say the right approach can depend in super tricky ways on the specific workloads and constraints you have.