4 ms·

"Point and click" is unnecessarily derogatory. During my career as a developer I spent my share of time racking my own systems, diagnosing (both network and dis

"Point and click" is unnecessarily derogatory. During my career as a developer I spent my share of time racking my own systems, diagnosing (both network and disk) cable faults, etc. I also spent time working with the kinds of software tools needed to manage dozens of clusters up to 10K machines each at 36 disks per machine. At that scale you really need to minimize the number of people who get to muck with the physical bits, and the amount of time they spend doing so. The complexity has merely shifted, not disappeared, and most developers or sysadmins from the previous generation would themselves be hard pressed to master the management of modern systems. It's no more "point and click" now than it was "lift heavy things" before. > if all you know is cloud, you don't need to know things like this. That's part of the cloud value proposition, isn't it? Leave the physical (and other low-level) stuff to people who do know that stuff, and can also reap economies of scale, while you focus on your own parts of the problem. Do you not approve of such specialization?

pclmulqdq 4y ago
I think the unfortunate reality of this is that even if you don't take care of the physical and OS stuff yourself, it will still hurt you when it goes wrong. Abstracting it away doesn't really take care of it for you, at least not in the same way that someone who really knows how to deal with it AND knows your system well does. And you pay through the nose for the privilege of that abstraction - even DigitalOcean is 2-3x more expensive than renting your hardware from a hosting provider, and things like managed databases and AWS lambda will run you 20x more than renting servers. When AWS fails, it fails spectacularly. It also experiences outages fairly often, and you as the developer often have nothing you can do about it, but twiddle your thumbs and hope that your application was amenable to "high-availability architecture" (which is more expensive...). Finally, this particular failure mode brought down HN's servers, rented from a reputable hosting provider, and arguably this is something that a hosting provider should know.
- toast0 4y ago
  > I think the unfortunate reality of this is that even if you don't take care of the physical and OS stuff yourself, it will still hurt you when it goes wrong. Abstracting it away doesn't really take care of it for you, at least not in the same way that someone who really knows how to deal with it AND knows your system well does It's also really hard to fix things when they're surrounded by a black box operated by someone who doesn't care. I kind of enjoy doing it, but it would be a lot more productive if I was able to diagnose network link problems by checking the error counters on all the routers/switches rather than by sending pings that hash over the numerous lacp alternate routes between two servers to figure out how to get a traceroute that shows the issue so the network owner can look at counters and fix the underlying issue.

pclmulqdq 4y ago

I think the unfortunate reality of this is that even if you don't take care of the physical and OS stuff yourself, it will still hurt you when it goes wrong. Abstracting it away doesn't really take care of it for you, at least not in the same way that someone who really knows how to deal with it AND knows your system well does. And you pay through the nose for the privilege of that abstraction - even DigitalOcean is 2-3x more expensive than renting your hardware from a hosting provider, and things like managed databases and AWS lambda will run you 20x more than renting servers. When AWS fails, it fails spectacularly. It also experiences outages fairly often, and you as the developer often have nothing you can do about it, but twiddle your thumbs and hope that your application was amenable to "high-availability architecture" (which is more expensive...). Finally, this particular failure mode brought down HN's servers, rented from a reputable hosting provider, and arguably this is something that a hosting provider should know.

toast0 4y ago
> I think the unfortunate reality of this is that even if you don't take care of the physical and OS stuff yourself, it will still hurt you when it goes wrong. Abstracting it away doesn't really take care of it for you, at least not in the same way that someone who really knows how to deal with it AND knows your system well does It's also really hard to fix things when they're surrounded by a black box operated by someone who doesn't care. I kind of enjoy doing it, but it would be a lot more productive if I was able to diagnose network link problems by checking the error counters on all the routers/switches rather than by sending pings that hash over the numerous lacp alternate routes between two servers to figure out how to get a traceroute that shows the issue so the network owner can look at counters and fix the underlying issue.