VMs as usual.

kkapelon · on Sept 17, 2020

Have you ever worked at a company that has more than 300 VMs that run more than 10 different apps?

Kubernetes solves a specific set of problems. Just because you personally don't have these problems, doesn't mean that Kubernetes is a fad.

pjmlp · on Sept 17, 2020

A small company called Nokia Networks, on a tiny product for telecommunication cluster monitoring called NetAct.

Then there was that tiny physics research center close to Geneva creating what was one of the first grid computing platforms.

But what do I know, that was almost 15 years ago.

ex_amazon_sde · on Sept 17, 2020

I did, it's called Amazon. It does not need k8s or containers at all.

kkapelon · on Sept 17, 2020

Great. So you also believe that Kubernetes is a fad and doesn't solve any problems for anybody and we should all stick with VMs?

ex_amazon_sde · on Sept 17, 2020

I know what problems it solves, what problems it creates and how very expensive it is to learn, operate, optimize and debug.

Its features do not justify its complexity and the cost of operating it.

spicybright · on Sept 17, 2020

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 · on Sept 17, 2020

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 · on Sept 17, 2020

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 · on Sept 17, 2020

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 · on Sept 17, 2020

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.