Re:Reasons Kubernetes is so complex
by hedora on Thursday January 27, 2022 @11:53AM
(#30102862)
Yes. You can do this without knowing about or modifying the applications. There was a big push for hardware consolidation a decade or so ago, where legacy apps were crammed on to fewer and fewer machines, and were cheaper/faster/more reliable as a result.
However, a permanent machine failure or unexpected reboot implies a few seconds or minutes of downtime.
These systems usually use a local disk, a synchronously updated disk across town (low latency, but on a different power grid, outside most natural disaster blast radii), and a far away asynchronously updated disaster recovery disk.
The disaster recovery disk provides a crash-consistent state that's less than a few seconds out of date.
These days, the "disks" tend to be deduped and compressed SSD's that use parity encoded raid. Their hardware cost is lower than a single copy on ext4, but they come with an enterprise tax / support contract, etc.
In practice, it's durable unless corporate HQ is wiped out. If that happens, it won't be the weak link in your business continuity plan (but a few customers' orders might've been dropped).
This stuff is tremendously unsexy, but it'll plug along just fine until you have some workload that can't be partitioned, and that needs more than roughly 40-100gbit of network/disk bandwidth, 128 cores, or 1TB of DRAM.
(Edit: Forgot to mention that the the apps run inside a VM infrastructure that supports live migration.)
Re:Reasons Kubernetes is so complex
by koffiezet on Friday January 28, 2022 @06:54AM
(#30113529)
Well, I didn't claim it was impossible, I only claimed I wouldn't want to pay for the engineering that would go into enabling this when building that from scratch. But there are of course alternatives to k8s which also enable this.
However, a permanent machine failure or unexpected reboot implies a few seconds or minutes of downtime.
These systems usually use a local disk, a synchronously updated disk across town (low latency, but on a different power grid, outside most natural disaster blast radii), and a far away asynchronously updated disaster recovery disk.
The disaster recovery disk provides a crash-consistent state that's less than a few seconds out of date.
These days, the "disks" tend to be deduped and compressed SSD's that use parity encoded raid. Their hardware cost is lower than a single copy on ext4, but they come with an enterprise tax / support contract, etc.
In practice, it's durable unless corporate HQ is wiped out. If that happens, it won't be the weak link in your business continuity plan (but a few customers' orders might've been dropped).
This stuff is tremendously unsexy, but it'll plug along just fine until you have some workload that can't be partitioned, and that needs more than roughly 40-100gbit of network/disk bandwidth, 128 cores, or 1TB of DRAM.
(Edit: Forgot to mention that the the apps run inside a VM infrastructure that supports live migration.)