I use $5 servers to setup images and then destroy them, but I spin up $10+ servers from those images for everything that runs all the time - just as another data point for you.
Thanks. That's the thing; the expense of SSD being what it is, competing with their $10 or $20 plan (where they have 3 and 2 gigabytes of ssd per dolar) is going to be way easier than competing with their $5 plan (where they have 4 gigabytes of ssd for every dollar.) again assuming no disk oversubscription.
The best answer sounds like it would be to decouple disk and ram allocations, use network storage and oversubscribe disk, as I imagine utilization on the disk of the $5 plans is low, but I would prefer to avoid doing that for the same reason that I believe Linode and DO avoids doing that. Network storage: reliable, fast, cheap. Pick two, if you choose really well.
From what I understand of my industry, and if nothing else, I've been in it for a while, new multi-user hardware, usually, is expected to be covered by subscription fees usually within 4-6 months, for this sort of thing. SSD is going to cost you between $0.6 (for cheap consumer-grade in raid5) and $2 (for intel S3500 level 'enterprise' mlc stuff in raid10) per gigabyte, so... it makes a difference.
ObLinode:
Of course, if you are using real live 'enterprise' slc, the price goes way up from there... but I doubt anyone in my sector is using those for anything but cache; in fact, I think Linode posted a while back that they were doing just that, using really good SSD for write-cache.
It's a good idea, really; once your server warms up, for most use cases, most of your reads are going to be cached in ram (assuming you have enough, which at today's prices, you should.) - If good ssd write-cache with something like bcache or dm-cache or your hw raid driver or what have you can get you good write speeds, that might be just as good as SSD in a real-world environment, assuming your ram cache is larger than the data you access often.
Of course, you are still going to get killed by the all-ssd host on disk benchmarks and on metrics like 'how long does it take to spin up a new guest?' - there are other ways to cheat on those metrics, but all that I know of have pretty big downsides for real-world performance.
Yeah, that is the real question I have about SSD; I mean, normally you want to buy enough ram to cache all the data you regularly access, because the overhead of hitting spinning disk absolutely kills you.
Now, SSD is still slower than ram... way slower than ram. But it's way faster than spinning disk, especially on reads. I imagine there are some applications where SSD is fast enough that hitting disk is okay; you don't need to worry about having enough ram to cache all data you might read, and ram is still like eight or nine bucks a gig (vs. $0.6 to $2 for mlc ssd) - and if we're talking about reads here? MLC is fine for reads.
Of course, part of that ram difference might be that ram prices haven't fallen much over the last year or two, (in fact, most of the ram I bought last year, I bought at a lower price than the ram I'm looking at now.) while SSD prices have really fallen fast, so I don't know if this is the long-term price-equilibrium; still, I would expect ssd to continue to be significantly less expensive than ram.
No, I was talking about caching disk reads in ram. Nearly all modern operating systems do this. If you have enough ram, the data you read from disk is cached in ram. With spinning disk, especially shared 7200rpm spinning disk, for interactive use? generally speaking, you have human-noticeable latency every time you do a blocking read that isn't cached.
Because of this, having enough ram to cache all the data you read often is extremely important to system performance when you are on spinning disk. (and having a pagecache that doesn't dump all the stuff you use often when you do a one-time read of a big file.)
I was suggesting that SSD might have fast enough read-access that for some applications, the penalty for reading from ssd rather than from pagecache might be small enough to not be a big deal, meaning you could get acceptable performance out of a system with less total ram.
