2 ms·

While I agree, I'd rather deal with the k8 nonsense than maintaining infrastructure to make multiple VMs load balance, fail and restart cleanly, etc.

• pjmlp 6y ago
  In almost 30 years of development, I never worked on Web scale Google style projects, and some of them did handle TB of data in a cluster. The golden rule is not to pretend to work at a FANNG when not having the same problems.
  • cinquemb 6y ago
    I agree, but man so many places are going in the opposite direction… I got lucky with my current gig that I got to implement load balancing/autoscaling with Fabric, ~1000 lines of python in a daemon using boto3, nginx and disk images…
• thu2111 6y ago
  systemd will happily health check a service, restart it when it fails and so on. The basics don't need much. Auto-scaling is something I'm suspicious of. I saw many experiments with that at Google when I worked there, under the name of elasticity. They found the same thing GitLab found here: it's really hard and the expected savings often don't materialise. Even in 2012 their elasticity projects were far more advanced than what Kubernetes or AWS provide. Most cloud auto-scaling efforts appear to be driven by the high base costs charged by the cloud providers in the first place. I've seen a few cases where simply moving VMs to cheaper colo providers saves more money than auto-scaling VMs or using managed Kubernetes in AWS/Azure.
  • secondcoming 6y ago
    I found AWS's autoscaling offering be better than GCP's, in that you could use custom CloudWatch metrics as a basis for scaling logic rather than just the standard metrics (CPU usage, latency, etc) GCP does offer custom metrics, but I couldn't figure out how to tie them to the LB scaling logic.