5 ms·

Except when they do go down it can be a catastrophic business interrupting event. Which is why the cloud model of assume everything is going to break and all yo

Except when they do go down it can be a catastrophic business interrupting event. Which is why the cloud model of assume everything is going to break and all your hardware is disposable works much better (IMO).

walshemj 8y ago
You can get very very redundant mainframes IBM Parallel Sysplex and so is Tandem
toomuchtodo 8y ago
AWS, Google Cloud, and Azure break more often than our mainframes. In this case, the cloud model is a con, essentially the self checkout lane at Walmart. You're paying more for the same ability you had before. "Well, you want redundancy right? Well you're supposed to be redundant across AZs, and then regions, and then you're going to have to have disparate vendors to mitigate sole vendor risks." And then we're right back to hosting our own mainframes in our datacenters.
- nickpsecurity 8y ago
  Clouds reinvent mainframes. They're still cheaper, run more FOSS, and have more talent available. They're a better form of lockin than mainframes.
  - deleted 8y ago
    [deleted]
  - mmt 8y ago
    > They're still cheaper Are they, though? Commodity hardware certainly is, but it's not as if cloud providers are charging a small margin on top of that. They're charging a multiple, potentially as large as 10x. Combined with the parent's proposed need of multi-cloud, that could turn what might otherwise be a few hundred $k of commodity servers into a few $M of cloud costs, which I understand is the OOM the cost of a mainframe.
    - dfox 8y ago
      Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure. With IaaS typical reliability issue is that whole location/datacenter/AZ goes down, with your own infrastructure the typical issue is that the colo-facility/datacenter goes down, which would be essentially identical save the fact that with IaaS there is significantly larger probability that the reason for going down is some byzantine failure of orchestration automation, which in the self-hosted case either isn't there or is under your control. One fact of running your own infrastructure is that you should plan for hardware failures, but not stress about it too much, because even entry-level enterprise-grade hardware just does not break (and if it does you will get signs that it is going to break well in advance).
      - mmt 8y ago
        Are you replying to the right sub-thread? I was asking about cost. That said.. > Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure. Although I'm a fan of running ones own hardware, I'm not sure I could make this claim. However, since I'd like to, do you have public data to back it up? > orchestration automation, which in the self-hosted case either isn't there or is under your control. I'm not sure how that would be different. Although a provider like AWS has portions of the automation toolchain not under your control, it's not obvious they're any more likely to fail (even due to some bizarre interoperability bug) than, say, BMC firmware, which is also not under your (full) control. > One fact of running your own infrastructure is that you should plan for hardware failures, but not stress about it too much, because even entry-level enterprise-grade hardware just does not break (and if it does you will get signs that it is going to break well in advance). This is something that I routinely have to point out to cloud proponents when they complain about having to "worry" about hardware failing: modern, commodity server hardware just doesn't fail often enough for it to be a significant consideration. Usually, it's just selection bias in that they remember every "nightmare" scenario from their past where hardware failed (possibly even as long as 20 years ago) but don't account for the overwhelming majority of times when it didn't. Of course, there are notable exceptions, such as high-density "blade" or half-U servers, which often suffer from thermal design failures, but I argue that those are a departure from commodity, even if they appear identical if one squints. Most importantly, though, it's not as if an IaaS cloud provider can somehow magically shield you from the consequences of such a failure: your VM will still go down. Sure, they have an arbitrarily large supply of spares to replace it, but you only ever need exactly 1 of those spares, and N+1 redundancy when self-hosted is very easy, if implemented merely as warm spares.
  - js8 8y ago
    It should be noted, though, that from physics perspective it makes sense to cram as much as computing power (although in case of MF, which unlike supercomputers do relatively simple calculations on high volumes of data, it rather means I/O throughput) into as small space as possible. So having interconnected commodity servers will always be marginally more expensive to run than mainframe boxes of the size of fridge, which have dedicated hardware for interconnect of internal components (for example on-book CPU caches and shared RAM).
mr_toad 8y ago
Mainframes share a lot of similarities with cloud data centres. Redundant hot swappable components (even the CPUs in some models). Virtualised operating systems (VMs were invented for mainframes). These days it wouldn’t be unusual for some mainframes to be running mostly Linux instances. You could almost think of a mainframe as a cloud in a box, and if one isn’t realiable enough, you can always run two or more.
johnmarcus 8y ago
It's catastrophic for your business if either your cliud model or mainframe breaks, ergo, it's worth to choose the more reliable one where that happens less frequently.

walshemj 8y ago

You can get very very redundant mainframes IBM Parallel Sysplex and so is Tandem

toomuchtodo 8y ago

AWS, Google Cloud, and Azure break more often than our mainframes. In this case, the cloud model is a con, essentially the self checkout lane at Walmart. You're paying more for the same ability you had before. "Well, you want redundancy right? Well you're supposed to be redundant across AZs, and then regions, and then you're going to have to have disparate vendors to mitigate sole vendor risks." And then we're right back to hosting our own mainframes in our datacenters.

nickpsecurity 8y ago
Clouds reinvent mainframes. They're still cheaper, run more FOSS, and have more talent available. They're a better form of lockin than mainframes.
- deleted 8y ago
  [deleted]
- mmt 8y ago
  > They're still cheaper Are they, though? Commodity hardware certainly is, but it's not as if cloud providers are charging a small margin on top of that. They're charging a multiple, potentially as large as 10x. Combined with the parent's proposed need of multi-cloud, that could turn what might otherwise be a few hundred $k of commodity servers into a few $M of cloud costs, which I understand is the OOM the cost of a mainframe.
  - dfox 8y ago
    Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure. With IaaS typical reliability issue is that whole location/datacenter/AZ goes down, with your own infrastructure the typical issue is that the colo-facility/datacenter goes down, which would be essentially identical save the fact that with IaaS there is significantly larger probability that the reason for going down is some byzantine failure of orchestration automation, which in the self-hosted case either isn't there or is under your control. One fact of running your own infrastructure is that you should plan for hardware failures, but not stress about it too much, because even entry-level enterprise-grade hardware just does not break (and if it does you will get signs that it is going to break well in advance).
    - mmt 8y ago
      Are you replying to the right sub-thread? I was asking about cost. That said.. > Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure. Although I'm a fan of running ones own hardware, I'm not sure I could make this claim. However, since I'd like to, do you have public data to back it up? > orchestration automation, which in the self-hosted case either isn't there or is under your control. I'm not sure how that would be different. Although a provider like AWS has portions of the automation toolchain not under your control, it's not obvious they're any more likely to fail (even due to some bizarre interoperability bug) than, say, BMC firmware, which is also not under your (full) control. > One fact of running your own infrastructure is that you should plan for hardware failures, but not stress about it too much, because even entry-level enterprise-grade hardware just does not break (and if it does you will get signs that it is going to break well in advance). This is something that I routinely have to point out to cloud proponents when they complain about having to "worry" about hardware failing: modern, commodity server hardware just doesn't fail often enough for it to be a significant consideration. Usually, it's just selection bias in that they remember every "nightmare" scenario from their past where hardware failed (possibly even as long as 20 years ago) but don't account for the overwhelming majority of times when it didn't. Of course, there are notable exceptions, such as high-density "blade" or half-U servers, which often suffer from thermal design failures, but I argue that those are a departure from commodity, even if they appear identical if one squints. Most importantly, though, it's not as if an IaaS cloud provider can somehow magically shield you from the consequences of such a failure: your VM will still go down. Sure, they have an arbitrarily large supply of spares to replace it, but you only ever need exactly 1 of those spares, and N+1 redundancy when self-hosted is very easy, if implemented merely as warm spares.
- js8 8y ago
  It should be noted, though, that from physics perspective it makes sense to cram as much as computing power (although in case of MF, which unlike supercomputers do relatively simple calculations on high volumes of data, it rather means I/O throughput) into as small space as possible. So having interconnected commodity servers will always be marginally more expensive to run than mainframe boxes of the size of fridge, which have dedicated hardware for interconnect of internal components (for example on-book CPU caches and shared RAM).

mr_toad 8y ago

Mainframes share a lot of similarities with cloud data centres. Redundant hot swappable components (even the CPUs in some models). Virtualised operating systems (VMs were invented for mainframes). These days it wouldn’t be unusual for some mainframes to be running mostly Linux instances. You could almost think of a mainframe as a cloud in a box, and if one isn’t realiable enough, you can always run two or more.

johnmarcus 8y ago

It's catastrophic for your business if either your cliud model or mainframe breaks, ergo, it's worth to choose the more reliable one where that happens less frequently.