4 ms·

I mean, it’s not the best argument to say a system is “one action away from disaster”. If you pull the escape lever in an F16 for no reason you’re also pretty s

I mean, it’s not the best argument to say a system is “one action away from disaster”. If you pull the escape lever in an F16 for no reason you’re also pretty screwed. If you intentionally fly into the ground no one blames General Dynamics for making the plane too complex. It turns out complex tools for complex tasks require some skilled operators. Yes kubernetes is overkill for your home lab, no it’s not overkill for enterprise-grade AWS orchestration with hundreds of apps and millions of users. News at 11.

ramraj07 3y ago
I want to host a website not bomb the Middle East. Most enterprise apps are still websites that need no more than elastic beanstalk. If your analogy is to compare k8s to f16 then maybe you are not doing your argument any service.
- alephnerd 3y ago
  If your dealing with dynamic scaling needs K8s are quite nice. There's a reason why most Telcos have deployed 5G functionality using K8s. If you are in a situation where you want to follow a decoupled/microservices development pattern (ie. split component ownership across dev teams) as well as manage scalability during high load periods, K8s is hard to beat. K8s is a useful tool, but can be overkill in a number of situations. Just like a hammer, you can't use it to solve for every usecase. P.S. F-35s use K8s clusters (or might be K3s) to deploy their EWS.
- erulabs 3y ago
  Well both hosting websites and bombing the middle east make use of Kubernetes. [1] 1. https://www.theregister.com/2020/06/03/kubernetes_b_21_bomber/ https://www.theregister.com/2020/06/03/kubernetes_b_21_bombe... I've spent my entire career being on-call for web servers and Elastic Beanstalk is not enough. Deployment failures, deployment speed, deployment safety, upgrades, local testing... There is a reason AWS themselves is pushing EKS and not Elastic Beanstalk, and it's not because Kubernetes is trendy, it's because it's incredibly useful.
  - ramraj07 3y ago
    I’ve had production SaaS apps running on elastic beanstalk just fine for years now. Better SLA than any of the kube apps I’ve seen. You’re right that if you have highly capable support team and the real need for it go with the pods but if you just have mediocre engineers and a straightforward deployment with no real scaling issues then just stick to simple systems.
    - deleted 3y ago
      [deleted]
- zerbinxx 3y ago
  Sure, then don’t use k8s. If you need extremely resilient leaf node architecture or high volume communication from distributed machines, then that’s a good time to start looking at k8s. Your lack of charity reveals your naïveté: the analogy is actually a good one because not all software development is equivalent to hosting a website.
crabbone 3y ago
It's nothing like that. Kubernetes was built with no program for how to do important things. Every important thing in Kubernetes is post-hoc, poorly bolted-on patch instead of real solution. Take for instance upgrades. Don't like upgrades? -- Try downgrades? -- Oh, what do I hear, you seem to not like that either... So, how about user management? -- Also no? -- Well, how about backups and recovery? -- What, again? Kubernetes solved some easy problems quickly with no program for how to solve hard problems. Security is one of those hard problems Kubernetes has no idea what to do about. The reason? -- Kubernetes, on its own, provides very little. It doesn't know how to do networking -- you need a CNI for it. But there's no good interface in Kubernetes to allow the admin to somehow control in general how the cluster is supposed to behave. Maybe some container somewhere will do something tricky, and will punch a hole in whatever firewall you though you've built around it. And you cannot make sure upfront that's not going to happen. There isn't a single way to punch that kind of hole... and the problem is, often time simply to make things work Kubernetes users will punch those holes. Maybe because they don't know how to do things better, or maybe because there isn't really a better way, or the better way is so tedious and convoluted that nobody will really follow it... It's unreasonable to expect anyone to be able to deal with this kind of complexity. We need to be able to manage complexity, but Kubernetes gives us no tools to do it. It's the same type of problem as Dijkstra described with "goto" -- it's the tools fault. It creates so much complexity that humans cannot cope. Not only humans, computer programs cannot cope -- too many things to check, to many possible problems to protect yourself against.
- erulabs 3y ago
  I disagree with everything you've said but there isn't enough content to any of your complaints to respond meaningfully. Upgrades and downgrades work fantastically. Putting "a firewall in front" is trivial - just... put a firewall in front. I don't know what "punch a hole" means, but if you mean "bind a port", yes, there are indeed a lot of ways to do that (on linux, windows, and osx!), and kubernetes provides excellent, organized, standardized and controllable ways to do that. Kubernetes does not create complexity in my experience. It's the other way around - developers who have never seen the complexity in the world complain about the complexity embodied in the tools. They think "you're not gonna need it", despite an entire industry of operators saying "actually yes, we do need this, and badly". I've seen developers who've never built a website in their life complain about React, and it sounds exactly the same as this. You might not need these tools, but they're not unneeded. If you can make a simpler and more powerful tool, please, go ahead, you'll be rich and famous, and everyone from the US Navy to telecoms to where I work will celebrate you.

ramraj07 3y ago

I want to host a website not bomb the Middle East. Most enterprise apps are still websites that need no more than elastic beanstalk. If your analogy is to compare k8s to f16 then maybe you are not doing your argument any service.

alephnerd 3y ago
If your dealing with dynamic scaling needs K8s are quite nice. There's a reason why most Telcos have deployed 5G functionality using K8s. If you are in a situation where you want to follow a decoupled/microservices development pattern (ie. split component ownership across dev teams) as well as manage scalability during high load periods, K8s is hard to beat. K8s is a useful tool, but can be overkill in a number of situations. Just like a hammer, you can't use it to solve for every usecase. P.S. F-35s use K8s clusters (or might be K3s) to deploy their EWS.
erulabs 3y ago
Well both hosting websites and bombing the middle east make use of Kubernetes. [1] 1. https://www.theregister.com/2020/06/03/kubernetes_b_21_bomber/ https://www.theregister.com/2020/06/03/kubernetes_b_21_bombe... I've spent my entire career being on-call for web servers and Elastic Beanstalk is not enough. Deployment failures, deployment speed, deployment safety, upgrades, local testing... There is a reason AWS themselves is pushing EKS and not Elastic Beanstalk, and it's not because Kubernetes is trendy, it's because it's incredibly useful.
- ramraj07 3y ago
  I’ve had production SaaS apps running on elastic beanstalk just fine for years now. Better SLA than any of the kube apps I’ve seen. You’re right that if you have highly capable support team and the real need for it go with the pods but if you just have mediocre engineers and a straightforward deployment with no real scaling issues then just stick to simple systems.
  - deleted 3y ago
    [deleted]
zerbinxx 3y ago
Sure, then don’t use k8s. If you need extremely resilient leaf node architecture or high volume communication from distributed machines, then that’s a good time to start looking at k8s. Your lack of charity reveals your naïveté: the analogy is actually a good one because not all software development is equivalent to hosting a website.

crabbone 3y ago

It's nothing like that. Kubernetes was built with no program for how to do important things. Every important thing in Kubernetes is post-hoc, poorly bolted-on patch instead of real solution. Take for instance upgrades. Don't like upgrades? -- Try downgrades? -- Oh, what do I hear, you seem to not like that either... So, how about user management? -- Also no? -- Well, how about backups and recovery? -- What, again? Kubernetes solved some easy problems quickly with no program for how to solve hard problems. Security is one of those hard problems Kubernetes has no idea what to do about. The reason? -- Kubernetes, on its own, provides very little. It doesn't know how to do networking -- you need a CNI for it. But there's no good interface in Kubernetes to allow the admin to somehow control in general how the cluster is supposed to behave. Maybe some container somewhere will do something tricky, and will punch a hole in whatever firewall you though you've built around it. And you cannot make sure upfront that's not going to happen. There isn't a single way to punch that kind of hole... and the problem is, often time simply to make things work Kubernetes users will punch those holes. Maybe because they don't know how to do things better, or maybe because there isn't really a better way, or the better way is so tedious and convoluted that nobody will really follow it... It's unreasonable to expect anyone to be able to deal with this kind of complexity. We need to be able to manage complexity, but Kubernetes gives us no tools to do it. It's the same type of problem as Dijkstra described with "goto" -- it's the tools fault. It creates so much complexity that humans cannot cope. Not only humans, computer programs cannot cope -- too many things to check, to many possible problems to protect yourself against.

erulabs 3y ago
I disagree with everything you've said but there isn't enough content to any of your complaints to respond meaningfully. Upgrades and downgrades work fantastically. Putting "a firewall in front" is trivial - just... put a firewall in front. I don't know what "punch a hole" means, but if you mean "bind a port", yes, there are indeed a lot of ways to do that (on linux, windows, and osx!), and kubernetes provides excellent, organized, standardized and controllable ways to do that. Kubernetes does not create complexity in my experience. It's the other way around - developers who have never seen the complexity in the world complain about the complexity embodied in the tools. They think "you're not gonna need it", despite an entire industry of operators saying "actually yes, we do need this, and badly". I've seen developers who've never built a website in their life complain about React, and it sounds exactly the same as this. You might not need these tools, but they're not unneeded. If you can make a simpler and more powerful tool, please, go ahead, you'll be rich and famous, and everyone from the US Navy to telecoms to where I work will celebrate you.