3 ms·

I worked on them a bit while at IBM. You can open a terminal and come back in a month and it will still be there. Unlikely kunernetes where containers regularl

I worked on them a bit while at IBM. You can open a terminal and come back in a month and it will still be there. Unlikely kunernetes where containers regularly go down. You can obviously achieve high reliability with Kunernetes, but you'll need queues and retry logic, that you don't need with SystemZ.

tryauuum 3y ago
Is this where we are right now as a society: a terminal which doesn't die in a month is presented as an achievement? I assume the achievement part is that any CPU can be replaced transparently to the terminal running?
- gitfan86 3y ago
  Yes, Hard drives can die, power supply can die, another user can write an infinite loop and it will not kill your terminal. Not a big deal today, but in the 80s hard drives died more frequently and a bank losing just 5 seconds of transactions could cost them millions.
- vidarh 3y ago
  I've not worked with a mainframe, but I've worked with an IBM storage system that worked on similar principles: We could connect our systems via dual controllers, to separate bays of controllers on the storage array. You could pull whole bays of controller cards and the system would stay up. You could pull whole bays of hard drives, and the system would stay up. You could pull power supplies and it'd remain up. You could swap RAM and CPUs in the servers managing it without shutting them down, but you could also pull one of those servers, and it'd remain up. If stuff started failing, and IBM engineer would show up because the system would call home. This was around 25 years ago. It wasn't cheap, but it made a typical "modern" high availability setup look like a crude homemade toy. But as impressive as it was, there are just very few places where that impressiveness provides enough value to justify the cost. And having to deal with IBM.
_joel 3y ago
> You can open a terminal and come back in a month and it will still be there. Unlikely kunernetes where containers regularly go down. You mixing apples and oranges there, by comparing kubernetes workloads to mainframes. Kubernetes isn't really designed to serve long-persistent workloads of that fashion. Although tbf I've had VM's that last for years and real hardware (albeit Sun) that's had over a decade of uptime, so I'm not sure what all the fluff is about.
- gitfan86 3y ago
  Both have a goal of high reliability. They are both solving the problem of running you application on a single server.
  - _joel 3y ago
    Kubernetes runs across multiple nodes to achieve that, that don't need to be in the same datacentre, though.

tryauuum 3y ago

Is this where we are right now as a society: a terminal which doesn't die in a month is presented as an achievement? I assume the achievement part is that any CPU can be replaced transparently to the terminal running?

gitfan86 3y ago
Yes, Hard drives can die, power supply can die, another user can write an infinite loop and it will not kill your terminal. Not a big deal today, but in the 80s hard drives died more frequently and a bank losing just 5 seconds of transactions could cost them millions.
vidarh 3y ago
I've not worked with a mainframe, but I've worked with an IBM storage system that worked on similar principles: We could connect our systems via dual controllers, to separate bays of controllers on the storage array. You could pull whole bays of controller cards and the system would stay up. You could pull whole bays of hard drives, and the system would stay up. You could pull power supplies and it'd remain up. You could swap RAM and CPUs in the servers managing it without shutting them down, but you could also pull one of those servers, and it'd remain up. If stuff started failing, and IBM engineer would show up because the system would call home. This was around 25 years ago. It wasn't cheap, but it made a typical "modern" high availability setup look like a crude homemade toy. But as impressive as it was, there are just very few places where that impressiveness provides enough value to justify the cost. And having to deal with IBM.

_joel 3y ago

> You can open a terminal and come back in a month and it will still be there. Unlikely kunernetes where containers regularly go down. You mixing apples and oranges there, by comparing kubernetes workloads to mainframes. Kubernetes isn't really designed to serve long-persistent workloads of that fashion. Although tbf I've had VM's that last for years and real hardware (albeit Sun) that's had over a decade of uptime, so I'm not sure what all the fluff is about.

gitfan86 3y ago
Both have a goal of high reliability. They are both solving the problem of running you application on a single server.
- _joel 3y ago
  Kubernetes runs across multiple nodes to achieve that, that don't need to be in the same datacentre, though.