Unlikely a useful lesson here. If it would have been written as "political correct" version up to the point of not calling Jarred out at all would have missed the core message. The fact that it was written blunt is the reason it went viral.
uhhh, that's not how the how that figure speech goes. There's a reason why people say all publicity is good publicity, and you can't just flip that to fit your perspective.
doesn't this imply that they buy massive hardware and thus replace their hardware constantly? At what rate? It seems the rate is massive. I'd gladly use a 4year old server for the old price.
Then check out the Serverbörse https://www.hetzner.com/de/sb/ that's exactly what you're asking for. Used servers, some of them with Skylake (2015) processors, some even with Haswell (2014) processors.
Hetzner keeps running the old machines as long as they can find customers for them, which means they have entire buildings of 10+ year old machines still running.
It's not even the reliability which is the issue. Newer servers can put hundreds of cores in one physical machine, while taking up the same amount of rack space and using the same amount of electricity as older systems with tens of cores.
How long do you want to run something that uses 3x the electricity for the same level of performance when you're buying power by the megawatt? How about the even older ones that use 10x as much?
Yes that's a thing too, but it's a question of cost and potential revenue. So if replacement hardware is really expensive then maybe you make the inefficient stuff hang out longer, as long as it's not broken and you have paying customers.
But at some point hardware does break and if you're going to keep the datacenter open for business you'll need to address turnover of inventory on an ongoing basis, and if you haven't locked in long-term deals for hardware then you'll have to bear current market prices when you do that.
I would suspect that "hardware breaks over time" is a minor component of the cost. If you put computer hardware in a climate controlled environment with conditioned power, generally >90% of it will still be operational after a decade, with the expected replacement of wear items like fans and drives. To the point that the fraction of older hardware that fails will typically be smaller than the fraction you would replace for efficiency reasons regardless, and wouldn't be a large proportion of operating costs even if it wasn't.
Exceptions naturally if you for some reason had an abnormally high failure rate, e.g. capacitor plague.
the reason mongo is a joy to use in scaled env is because no additional setup/software needed and all drivers natively support secondary/primary writes/reads and topological changes. so it's end to end, and adding is as a new proxy in frontend of postgres leads to all clients being incompatible or the code itself has no control anymore about when to use a secondary and what allowed stall is acceptable for a particular query. Any solutions to this by pgdog?
> all drivers natively support secondary/primary writes/reads and topological changes.
Expanding on that a bit, mongo drivers even have a shared specification of the state machine for monitoring topology changes[1] and algorithm for selecting the server to send an operation to[2] (along with various declarative test cases that the drivers use to validate them alongside the specs in the repo). I think people sometimes underestimate how important the client-side work is to this sort of experience; for all of the faults mongo has had over the years, the amount of investment that they put into the client libraries is something I've never seen anywhere else (although having spent several years working on some of these libraries, my take is likely very biased).
once mongo rewrote their engine - it's performant, scales & easy to run. seems a lot of devs got burnt by the early issues don't consider it all together.
its probably the easiest database to run at scale. run & forget. you just have to do a little more work on the data modeling part before you write your application i.e consider your query patterns.
Honestly, Docker Swarm is so great. We use it with 6 very beefy machines (each 1tb memory/96cpu cores) for years already. It's so stable and well done, no restarts, crashes, or weird behaviors. We use it in a Hetzner VLAN and performance is excellent. We are very satistfied with it, and I would use it for even bigger scenarios. I even thought about building something like coolify/flightcontrol on top of it, so I can really easy have proper deployments of my stuff
Do I understand this right: if these 3 nodes shutdown for some reason, all data is lost and you have to actually restore from backup instead of just starting the machine again. And even if you have to restart one node (due to updates, or crashes) you also have to restore from backup?
If so, why not pick a hosting provider that doesn't wipe the disk when machine shuts down?
It's more than just shutting down. You'd have to have an actual failure. Data isn't lost on a simple restart. It'd require 3 nodes to die in 3 different AZs.
While that's not impossible, the reality is that's very low.
So simply restarting nodes wouldn't trigger restoring from backup, but yes, in our case, replacing nodes entirely does require that node to restore from a backup/WALs and catch back up in replication.
EBS doesn't entirely just solve this, you still have failures and still need/want to restore from backups. This is built into our product as a fundamental feature. It's transparent to users, but the upside is that restoring from backups and creating backups is tested every day multiple times per day for a database. We aren't afraid of restoring from backups and replacing nodes by choice or by failure. It's the same to us.
We do all of the same operations already on EBS. This magic is what enables us to be able to use NVMe's since we treat EBS as ephemeral already.
