2 ms·
This matches our experience as well. As long as you treat your managed k8s cluster as autoscaling-group as-a-service you'll do fine. k8s's worst property is th
by Spivak 3y ago
This matches our experience as well. As long as you treat your managed k8s cluster as autoscaling-group as-a-service you'll do fine.
k8s's worst property is that it's a cleverness trap. You can do anything in k8s whether it's sane to do so or not. The biggest guardrail against falling into is managing your k8s with terraform-ish so that you don't find yourself in a spot where "effort to do it right" >> "effort to hack in YAML" and finding your k8s cluster becoming spaghetti.
- x86x87 3y agoWhy not just use an autoscaling group? Re: cleverness trap. I feel like this is the tragedy of software development. We like to be seen as clever. We are doing "hard" things. I have way more respect for engineers that do "simple" things that just work using boring tech and factor in whole lifecycle of the product.
- p_l 3y ago> Why not just use an autoscaling group? Not everyone has money to burn, even back in ZIRP era. And before you trot out wages for experienced operations team - I've regularly dealt with it being cheaper to pay for one or two very experienced people than deal with AWS bill. For the very simple reason that cloud provider's prices are scaled to US market and not everyone has US money levels.
- Spivak 3y agoSorry, I could have explained that better. The biggest value add that k8s has is that it gives you as many or as few autoscaling groups as you need at a given time using only a single pool (or at least fewer pools) of heterogeneous servers. There's lots of fine print here but it really does let you run the same workloads on less hardware and to me that's the first and last reason you should be using it. I wouldn't start with k8s and instead opt for ASGs until you reach the point where you look at your AWS account and see a bunch of EC2 instances sitting underutilized.