3 ms·

I started with some comparison of cost of big IaaS instances vs. mainframe vs. commodity HW and then got sidetracked on the reliability and ended up deleting th

by dfox 8y ago

I started with some comparison of cost of big IaaS instances vs. mainframe vs. commodity HW and then got sidetracked on the reliability and ended up deleting the first paragraph :) That said I believe that when your workload really necessitates such a big systems and if you can use all of the mainframes capability and have the capability to manage the mainframe (which requires Ops team with totally different skillset and mainly willingness to do such a thing), I believe that cost of mainframe will be comparable to IaaS, with self-hosted commodity HW being somewhat cheaper. It is anecdotal, but when I used to work in more of an Ops role I cannot remember single time when server hardware failed in production without external environmental cause (there were flooded servers and servers that were DoA from manufacturer), it is somewhat surprising that this experience even extends to spinning rust harddrives, where most common causes of failure I've seen were flaky SATA/SAS connetors, followed by simply bad series (eg. Constellation ES.2) and then by extreme overheating.

mmt 8y ago
> if you can use all of the mainframes capability > cost of mainframe will be comparable to IaaS I'd be very interested in seeing even a rough cost comparison, since I have no experience with mainframes. I also have, essentially, no experience with that first "if", which I'd say is a big one. Workloads that are (already) suited to that particular system design may be rare (and obviously getting rarer). > self-hosted commodity HW being somewhat cheaper. I'm pretty sure "somewhat" grossly understates it. However, I realized that one of the problems here is that we're talking about these costs as if they're single numbers, rather than ranges. For mainframes, it may as well be a single number, because there's only one vendor (for the latest hardware). For IaaS and self-hosted, the ranges can be very broad, because it's very easy to pay a multiple of the minimum cost with merely a naive implementation. Trivial examples would be not leveraging "reserved instances" on AWS or not getting competitive quotes for self-hosted. In fact, if one removes the "commodity" constraint from self-hosted and allows "enterprise" hardware (especially storage), the top end of the range can easily balloon above the top of the IaaS range. I've been assuming a comparison of the bottom ends of the ranges, but including the cost of the expert labor for each. What's difficult to know, of course, is how scarce the experts (capable of keeping costs near the bottom of the range) in each category actually are. > I cannot remember single time when server hardware failed in production without external environmental cause I think that's just a matter of too small a sample size. > servers that were DoA from manufacturer I wouldn't even count that, since it's not in production yet. > it is somewhat surprising that this experience even extends to spinning rust harddrives That's definitely too small a sample size, then. If you're not seeing at least a 1% AFR (realistically closer to 3%), you don't have enough of them or haven't been running them long enough yet. > simply bad series (eg. Constellation ES.2) That's not an external environmental cause, though, and counts the same as any other failure due to (presumably) a manufacturing defect (defined broadly), including RAM bit errors. It's merely something that can be engineered around with best practices. None of this is to say that any of these inevitable failures are actually frequent or voluminous enough (even on, e.g., 5 year old hardware, which is ancient by most standards) to require outsized worry or effort/cost to mitigate/repair them.

by dfox 8y ago

mmt 8y ago

> if you can use all of the mainframes capability > cost of mainframe will be comparable to IaaS I'd be very interested in seeing even a rough cost comparison, since I have no experience with mainframes. I also have, essentially, no experience with that first "if", which I'd say is a big one. Workloads that are (already) suited to that particular system design may be rare (and obviously getting rarer). > self-hosted commodity HW being somewhat cheaper. I'm pretty sure "somewhat" grossly understates it. However, I realized that one of the problems here is that we're talking about these costs as if they're single numbers, rather than ranges. For mainframes, it may as well be a single number, because there's only one vendor (for the latest hardware). For IaaS and self-hosted, the ranges can be very broad, because it's very easy to pay a multiple of the minimum cost with merely a naive implementation. Trivial examples would be not leveraging "reserved instances" on AWS or not getting competitive quotes for self-hosted. In fact, if one removes the "commodity" constraint from self-hosted and allows "enterprise" hardware (especially storage), the top end of the range can easily balloon above the top of the IaaS range. I've been assuming a comparison of the bottom ends of the ranges, but including the cost of the expert labor for each. What's difficult to know, of course, is how scarce the experts (capable of keeping costs near the bottom of the range) in each category actually are. > I cannot remember single time when server hardware failed in production without external environmental cause I think that's just a matter of too small a sample size. > servers that were DoA from manufacturer I wouldn't even count that, since it's not in production yet. > it is somewhat surprising that this experience even extends to spinning rust harddrives That's definitely too small a sample size, then. If you're not seeing at least a 1% AFR (realistically closer to 3%), you don't have enough of them or haven't been running them long enough yet. > simply bad series (eg. Constellation ES.2) That's not an external environmental cause, though, and counts the same as any other failure due to (presumably) a manufacturing defect (defined broadly), including RAM bit errors. It's merely something that can be engineered around with best practices. None of this is to say that any of these inevitable failures are actually frequent or voluminous enough (even on, e.g., 5 year old hardware, which is ancient by most standards) to require outsized worry or effort/cost to mitigate/repair them.