3 ms·

> In comparison computers have gotten many orders of magnitude faster in a much shorter time. But there is a physical limit, and we are very likely to run into

> In comparison computers have gotten many orders of magnitude faster in a much shorter time. But there is a physical limit, and we are very likely to run into that soon. And once that happens the only way to progress is to make more efficient use of the resources you've already got. Good points. And I will even argue that while we didn't hit a physical limit in hardware yet, it's still important to have a reasonable performance because not having performance means resources are wasted, money are wasted and it might lead to user frustration. But it seems to not be the majority's opinion or at least not most of the business owners opinion.

freedomben 4y ago
Unfortunately until crappy and slow performing software starts losing business to well-implemented alternatives, it will never change. The current PM model is purely based on shipping fast, and any thought to performance is immediately dismissed as "pre-mature optimization." I've been consulting for companies that had to rolling reboot their entire cluster of app servers every couple of hours because a host of memory leaks (that also added O(n) runtime) would slowly exhaust resources. Rather than have someone fix the problem, they chose to invest in devops to automate the rolling restarts. This is not all that unusual in my experience, because customers will tolerate very sluggish response times so it's not worth fixing to the business.
- DeathArrow 4y ago
  Entirely my experience. I worked for a very large company and since our microservices were running in Kubernetes it was totally OK for the services to crash. We just logged the things in elastic stack, used data dog to monitor, used some SRE to restart services when things were messy. I've lost days to solve a memory bug in one of the services and no one cared. The original architect and programmers were gone, the engineering managers were pushing Clean, SOLID and design patterns hopping that will help and the domain was hard because we had to deal with real money while respecting tens of different laws and locales. We tried at our best to do the impossible, we were understaffed by a factor of 5X. And the services were crashing like crazy but it looked like a no downtime because we provisioned another POD in Kubernetes. Provisioning was like: how many pods do we need? 3? Let's make it nine. How much memory do we need? Half a gig? Let's make it 4 gig to be sure. So it was a mess and it worked and that mess continues to work somehow. Not sure if mess driving engineering is a sound bussineses idea, though.
  - jacquesm 4y ago
    Erlang has taken 'let it crash' to entirely new heights, but that's from a top level viewpoint, components are allowed to crash but the service isn't. And you're still supposed to figure out why your service crashed but I'm pretty sure not everybody does that. So as long as your supervision mechanism is bulletproof (supervision trees) then you can get away with this for very long.

freedomben 4y ago

Unfortunately until crappy and slow performing software starts losing business to well-implemented alternatives, it will never change. The current PM model is purely based on shipping fast, and any thought to performance is immediately dismissed as "pre-mature optimization." I've been consulting for companies that had to rolling reboot their entire cluster of app servers every couple of hours because a host of memory leaks (that also added O(n) runtime) would slowly exhaust resources. Rather than have someone fix the problem, they chose to invest in devops to automate the rolling restarts. This is not all that unusual in my experience, because customers will tolerate very sluggish response times so it's not worth fixing to the business.

DeathArrow 4y ago
Entirely my experience. I worked for a very large company and since our microservices were running in Kubernetes it was totally OK for the services to crash. We just logged the things in elastic stack, used data dog to monitor, used some SRE to restart services when things were messy. I've lost days to solve a memory bug in one of the services and no one cared. The original architect and programmers were gone, the engineering managers were pushing Clean, SOLID and design patterns hopping that will help and the domain was hard because we had to deal with real money while respecting tens of different laws and locales. We tried at our best to do the impossible, we were understaffed by a factor of 5X. And the services were crashing like crazy but it looked like a no downtime because we provisioned another POD in Kubernetes. Provisioning was like: how many pods do we need? 3? Let's make it nine. How much memory do we need? Half a gig? Let's make it 4 gig to be sure. So it was a mess and it worked and that mess continues to work somehow. Not sure if mess driving engineering is a sound bussineses idea, though.
- jacquesm 4y ago
  Erlang has taken 'let it crash' to entirely new heights, but that's from a top level viewpoint, components are allowed to crash but the service isn't. And you're still supposed to figure out why your service crashed but I'm pretty sure not everybody does that. So as long as your supervision mechanism is bulletproof (supervision trees) then you can get away with this for very long.