4 ms·

> kubernetes's insane complexity proliferating Is K8S any more complex than the other options for deploying apps across a fleet? I’m genuinely curious because

by bsg75 7y ago

> kubernetes's insane complexity proliferating Is K8S any more complex than the other options for deploying apps across a fleet? I’m genuinely curious because it looks complex to me, but I have little background to determine if what I see is complexity or unfamiliar territory.

naniwaduni 7y ago
Deploying apps across a fleet is far more complex than most of its practitioners need.
- theyinwhy 7y ago
  How is that? You create an object with some metadata and that's it. Don't know how that can be done any easier. I honestly get the feeling only people who have never used K8s deem it complex. Running a cluster yourself is another topic, although there are way more complex orchestrators on the market than K8s.
  - sascha_sl 7y ago
    It seems to be a typical "if I don't understand it and reading up on it for 5 minutes doesn't help it must be too complex" case. Turns out turning a bunch of machines and maybe a cloud API into a functional PaaS includes a lot of logic, a lot of which is dedicated to handling edge cases.
- deleted 7y ago
  [deleted]
krinchan 7y ago
For my team, we abandoned k8s because of the insanity of just managing the cluster itself in AWS pre-EKS. Our team has a lot of low level OS and AWS knowledge, and it was just this massive undertaking and at every turn we were told, "Lol, just use Google Cloud." My employer is all in on AWS, there's no way to change that. Furthermore, our accounts come with a lot of restrictions imposed by our central AWS team. VPCs, subnets, NAT gateways, etc. are all pre-provisioned and we are prevented from modifying them or creating new ones ourselves. The only real tool for k8s in AWS was kops at the time. It was so opinionated that it broke down very quickly when faced with all the IAM restrictions on our user accounts. Now that EKS is a thing, we're looking to revisit it. But a lot of the pain might be coming from the fact that it seemed that "manage my k8s cluster for me" was under-developed on AWS at the time. Elastic Beanstalk's ECS platform was just the easier thing to start with for us.

by bsg75 7y ago

naniwaduni 7y ago

Deploying apps across a fleet is far more complex than most of its practitioners need.

theyinwhy 7y ago
How is that? You create an object with some metadata and that's it. Don't know how that can be done any easier. I honestly get the feeling only people who have never used K8s deem it complex. Running a cluster yourself is another topic, although there are way more complex orchestrators on the market than K8s.
- sascha_sl 7y ago
  It seems to be a typical "if I don't understand it and reading up on it for 5 minutes doesn't help it must be too complex" case. Turns out turning a bunch of machines and maybe a cloud API into a functional PaaS includes a lot of logic, a lot of which is dedicated to handling edge cases.
deleted 7y ago
[deleted]

krinchan 7y ago

For my team, we abandoned k8s because of the insanity of just managing the cluster itself in AWS pre-EKS. Our team has a lot of low level OS and AWS knowledge, and it was just this massive undertaking and at every turn we were told, "Lol, just use Google Cloud." My employer is all in on AWS, there's no way to change that. Furthermore, our accounts come with a lot of restrictions imposed by our central AWS team. VPCs, subnets, NAT gateways, etc. are all pre-provisioned and we are prevented from modifying them or creating new ones ourselves. The only real tool for k8s in AWS was kops at the time. It was so opinionated that it broke down very quickly when faced with all the IAM restrictions on our user accounts. Now that EKS is a thing, we're looking to revisit it. But a lot of the pain might be coming from the fact that it seemed that "manage my k8s cluster for me" was under-developed on AWS at the time. Elastic Beanstalk's ECS platform was just the easier thing to start with for us.