> I good reason not to use kubernetes though is if you know your app is probably never going to scale Suggesting that you can only scale with Kubernetes just i

> I good reason not to use kubernetes though is if you know your app is probably never going to scale Suggesting that you can only scale with Kubernetes just isn't true. Our tech stack originally ran on AWS in multi-regions. Then we moved to GCP. The architecture was the same for both: - public facing Load Balancer - instance groups attached to the LB - add health checks so unresponsive instances get killed - add scaling rules based on whatever metric you want (AWS's offering was far better than GCP's) - choose your instance type(s). And for the record, we handle ~15 billion HTTP requests per day (traffic is seasonal). Our busiest data centre is us-east, which has a max of 50 instances (16 vCPU, 31GB RAM), and we rarely need them all. You can also mix spot and non-spot instances too, so we know we have a least one or two machines that GCP won't kill. Rolling out updates involves building a debian package, building a new VM image, and then clicking a 'deploy' button (GCP makes this easier than AWS).