4 ms·

Exactly this. I have seen hundreds of systems built by experienced gray beard Unix admins, which have been steady as rocks, some lasting 15+ years without ever

by spydum 9y ago

Exactly this. I have seen hundreds of systems built by experienced gray beard Unix admins, which have been steady as rocks, some lasting 15+ years without ever a peep of trouble. however I have seen many "new" boxes built by "devops", which can't survive a single upgrade cycle. If left alone for more than a few weeks, usually eat themselves and cause an outage. On one hand, am a little thankful of the devops box, it will be crashed long before it gets compromised due to neglect.

bitwize 9y ago
Devops is doing their job. No one really cares about the uptime of a single box anymore at cloud scale. Servers are cattle, not pets. If one instance goes down, spin up a new one to take the load. P.S. this is why, contrary to graybeard whinging, boot time matters and sysvinit cannot possibly keep up with systemd in the cloud. The faster your instances boot, the less capacity you lose while they're down.
- digi_owl 9y ago
  http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a-self-ddos/ http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a... Mooo...
- hedora 9y ago
  This is only really true for compute instances that don't have big caches or long warmup times. Even then, I think you'll find you want the bare metal the instances to run on to have high uptimes (on the order of years, not minutes), since the hardware with optimal $/perf can fit more and more workloads per machine (I think this is all Moore's law is doing to help compute these days). That means you need a decreasing number of physical machines to hold your workload. At some point your "cloud" has 10 nodes instead of 1000. Fun exercise: "cloud scale" code is typically 5-100 slower per node than single machine scale up code. How much money would you save by consolidating smaller workloads to big machines? More importantly, how much developer productivity would you gain by eliminating network latency / marshalling for internal requests? I think you'll see an increase of developers "coding around" devops over the next few years. I could be wrong, of course.

by spydum 9y ago

bitwize 9y ago

Devops is doing their job. No one really cares about the uptime of a single box anymore at cloud scale. Servers are cattle, not pets. If one instance goes down, spin up a new one to take the load. P.S. this is why, contrary to graybeard whinging, boot time matters and sysvinit cannot possibly keep up with systemd in the cloud. The faster your instances boot, the less capacity you lose while they're down.

digi_owl 9y ago
http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a-self-ddos/ http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a... Mooo...
hedora 9y ago
This is only really true for compute instances that don't have big caches or long warmup times. Even then, I think you'll find you want the bare metal the instances to run on to have high uptimes (on the order of years, not minutes), since the hardware with optimal $/perf can fit more and more workloads per machine (I think this is all Moore's law is doing to help compute these days). That means you need a decreasing number of physical machines to hold your workload. At some point your "cloud" has 10 nodes instead of 1000. Fun exercise: "cloud scale" code is typically 5-100 slower per node than single machine scale up code. How much money would you save by consolidating smaller workloads to big machines? More importantly, how much developer productivity would you gain by eliminating network latency / marshalling for internal requests? I think you'll see an increase of developers "coding around" devops over the next few years. I could be wrong, of course.