3 ms·

>This even covers basic things: for example, look at all of the reports of Hetzner customers losing data due to something like a drive failure. It's not like th

>This even covers basic things: for example, look at all of the reports of Hetzner customers losing data due to something like a drive failure. It's not like there isn't a way to deal with that yourself but now you're in the business of monitoring the drives, setting up software RAID and testing/benchmarking it to make sure your configuration is robust, scheduling downtime to reflash servers with storage updates following some process which depends on the hardware & software combo you're using, etc. Your competitor using AWS isn't paying their sysadmins to do that because they do it for you, and it's completely transparent. If you're using dumb boxes to deploy something like a k8s cluster why do you care about drive failure ? You rent out an extra machine to account for the downtime (and peaks) and you're still well below AWS infra cost. >Similarly, the major cloud providers can live migrate VMs off of failing hosts without your awareness — another thing you have to build and operate yourself on bare metal which isn't trivial to get right. When Spectre et al. came out, the major cloud providers' customers were all patched on the day of the annoucement. Bare metal hosting users had to schedule downtime, roll patches, and make sure nothing broke. Again cattle not pets. >say you went all-in on Hetzner But that's what I am saying - going "all in on Hetzner" doesn't really mean much if you're using dumb blocks available elsewhere (plain container/VM hosting, network object storage). >This is the opposite of my experience: with a few exceptions, you're looking at significantly more work to build an equivalent service yourself, especially if you need to worry about reliability, security, etc. That last part is important if you need to be able to make strong statements about who has access to data, whether logging can be tampered with, etc. — those are all things you _can_ setup yourself but the cost of doing so is greater than years of your usage until you're at a pretty large scale. That's the problem I guess - I haven't built a on-prem system in 10 years now, maybe I forgot the pain points, maybe the automation tools really don't work outside of big cloud providers. But right now all I'm seeing is insane margins on cloud services and we still have a bunch of devops that are busting their ass off to monkeypatch everything together.

acdha 4y ago
> If you're using dumb boxes to deploy something like a k8s cluster why do you care about drive failure ? You rent out an extra machine to account for the downtime (and peaks) and you're still well below AWS infra cost. k8s doesn't mean you don't care about data integrity or performance, and if you don't build and debug more automation yourself dealing with failures creates more manual labor recovering from them. Again, you can definitely do that yourself but it adds time commitments which blow the cost savings away unless you are running at least hundreds servers to have the savings exceed the staff cost. > Again cattle not pets. That's an orthogonal concern — neither environment will prevent you from treating servers as pets, and not having things like auto-scaling or higher-level service abstractions definitely encourages pet servers because the overhead of managing a full server and improving utilization adds up. > But that's what I am saying - going "all in on Hetzner" doesn't really mean much if you're using dumb blocks available elsewhere (plain container/VM hosting, network object storage). Actually, it does for the reasons I mentioned before. If you care about reliability, performance, security, etc. you're not just picking any random hoster around the world — you have to spend time selecting vendors, signing contracts, getting set up with their environment and tools, etc. Again, that's totally possible and there's a break-even point where those costs are canceled out by lower service costs but it's higher than people typically assume. > (plain container/VM hosting, network object storage) This is true but also means you need to factor in the cost of greater maintenance commitments and lower productivity.

acdha 4y ago

> If you're using dumb boxes to deploy something like a k8s cluster why do you care about drive failure ? You rent out an extra machine to account for the downtime (and peaks) and you're still well below AWS infra cost. k8s doesn't mean you don't care about data integrity or performance, and if you don't build and debug more automation yourself dealing with failures creates more manual labor recovering from them. Again, you can definitely do that yourself but it adds time commitments which blow the cost savings away unless you are running at least hundreds servers to have the savings exceed the staff cost. > Again cattle not pets. That's an orthogonal concern — neither environment will prevent you from treating servers as pets, and not having things like auto-scaling or higher-level service abstractions definitely encourages pet servers because the overhead of managing a full server and improving utilization adds up. > But that's what I am saying - going "all in on Hetzner" doesn't really mean much if you're using dumb blocks available elsewhere (plain container/VM hosting, network object storage). Actually, it does for the reasons I mentioned before. If you care about reliability, performance, security, etc. you're not just picking any random hoster around the world — you have to spend time selecting vendors, signing contracts, getting set up with their environment and tools, etc. Again, that's totally possible and there's a break-even point where those costs are canceled out by lower service costs but it's higher than people typically assume. > (plain container/VM hosting, network object storage) This is true but also means you need to factor in the cost of greater maintenance commitments and lower productivity.