4 ms·

I kinda see your point, but before we talk about the GC, can we address kubelet and the absolute mindless frenzy, resume-driven technological orgy that Kubernet

I kinda see your point, but before we talk about the GC, can we address kubelet and the absolute mindless frenzy, resume-driven technological orgy that Kubernetes and "DevOps" has turned into?

outworlder 5y ago
No. Kubernetes actually solves problems. You'll know that's the case for you when people starts preferring to deploy their stuff in K8s. It's just that people have been using it where it doesn't belong. If you don't need it, you don't need it.
- blacktriangle 5y ago
  It's not that Kube doesn't solve problems. It's that Kube solves problems 99% of projects using it do not and never will have.
- wcarss 5y ago
  To be fair, it also can get overwrought: it's far from impossible to end up using a programming language to emit a templating language that emits a configuration language that itself describes configuration files. Sometimes, for simple things, those could have written by hand at the bottom without the extra tools. But even when writing them by hand would have been very hard or not the right choice, the devops stack is a daunting thing to reckon with! A developer coming from "jenkins invokes a script that runs npm install && npm start", or even the mildly more modern "jenkins invokes docker-compose on a file" has a lot of very abstract and difficult-to-play-around-with context to pick up. It's hard to learn fully even if you're at a shop with an established approach where someone knows what they're doing, but imagine moving yourself from Rackspace or Heroku onto AWS or GCP, and having to figure out IAM permissions and private VPC networking ingress configurations while also deciding if you really need to use helm. Especially if you're doing this because the team "doesn't have time to spend on ops". At the end of the day I of course agree that using k8s to manage moderately complex things can melt a lot of toil right off. In the right scenarios, more abstraction can help for more complex stuff too. But there's also a lot of marketing out there for tools-on-tools, and businesses that would love for folks to adopt solutions to problems which few people have, let alone really deeply understand.
  - outworlder 5y ago
    > A developer coming from "jenkins invokes a script that runs npm install && npm start", or even the mildly more modern "jenkins invokes docker-compose on a file" has a lot of very abstract and difficult-to-play-around-with context to pick up. Let's see. If you are deploying this on a physical machine: you have to connect to the machine somehow. You have to setup the correct permissions. You need auditing. You need to configure logging (and log rotation). You need to ensure your npm start script will be able to be restarted if needed. You may need cronjobs for various housekeeping chores. And then suddenly you need to run more instances of your app. What to do? Are you going to setup a proxy now and a bunch of different ports? Is your script picking them up or are they hard-coded? Are you instead doing network namespaces and iptables trickery? How do you upgrade your service without downtime? Are you going to write scripts to do that? What if your app need storage. And what if you now need more machines. How are you going to spread the workloads around? And how do you automate the above? One team prefers Ansible, the other goes with Chef, a third one likes to embed shell scripts inside a Terraform provisioner. These things are _hard_. There is a whole lot of context. It's just that we have got used to the way things have always been done. It does not help that K8s development is very fast and there are far too many people and companies jumping on the bandwagon, each with their own unique spin. The ecosystem is becoming big enough to the point of being unmanageable. Also, Kubernetes joins some of the work that was done by the development team or release teams with work that was traditionally done by the operations teams, and makes it all visible. Suddenly you have to _know_ what the heck a liveness probe is. You could get by with not knowing this in a standard deployment, your app would simply lack the check(and cause issues in production). You need to know what exactly your app needs to persist. Previously it would just dump data in whatever directory it had permissions to, and this became tribal knowledge. But K8s by itself? My heuristic is: am I running containers? Do I need to spread said containers across machines? Just use K8s. Trying to replicate this with homegrown scripts will be very painful. It may not seem like it's painful now, but trust me, it will be. Will K8s exist in 15 years? Hard to say. Probably but, for the reasons you describe, it's likely that there will be, at least, a high level abstraction to hide decisions most people don't need to make.
    - wcarss 5y ago
ltbarcly3 5y ago
Agree, people are spending weeks of effort to figure out how to deploy their app which has 3 webservers and one RDS database via kubernetes because 'thats the right way to do it'. Kubernetes is a solution to a problem hardly anyone has, and it is maddingly complex, and large parts of it are poorly designed. If you have a large team deploying many services and can afford full time devops staff, it is a good solution to many problems, but probably 90% of the people using it would find things to be simpler and more reliable without it.

I kinda see your point, but before we talk about the GC, can we address kubelet and the absolute mindless frenzy, resume-driven technological orgy that Kubernetes and "DevOps" has turned into?

outworlder 5y ago

No. Kubernetes actually solves problems. You'll know that's the case for you when people starts preferring to deploy their stuff in K8s. It's just that people have been using it where it doesn't belong. If you don't need it, you don't need it.

blacktriangle 5y ago
It's not that Kube doesn't solve problems. It's that Kube solves problems 99% of projects using it do not and never will have.
wcarss 5y ago
To be fair, it also can get overwrought: it's far from impossible to end up using a programming language to emit a templating language that emits a configuration language that itself describes configuration files. Sometimes, for simple things, those could have written by hand at the bottom without the extra tools. But even when writing them by hand would have been very hard or not the right choice, the devops stack is a daunting thing to reckon with! A developer coming from "jenkins invokes a script that runs npm install && npm start", or even the mildly more modern "jenkins invokes docker-compose on a file" has a lot of very abstract and difficult-to-play-around-with context to pick up. It's hard to learn fully even if you're at a shop with an established approach where someone knows what they're doing, but imagine moving yourself from Rackspace or Heroku onto AWS or GCP, and having to figure out IAM permissions and private VPC networking ingress configurations while also deciding if you really need to use helm. Especially if you're doing this because the team "doesn't have time to spend on ops". At the end of the day I of course agree that using k8s to manage moderately complex things can melt a lot of toil right off. In the right scenarios, more abstraction can help for more complex stuff too. But there's also a lot of marketing out there for tools-on-tools, and businesses that would love for folks to adopt solutions to problems which few people have, let alone really deeply understand.
- outworlder 5y ago
  > A developer coming from "jenkins invokes a script that runs npm install && npm start", or even the mildly more modern "jenkins invokes docker-compose on a file" has a lot of very abstract and difficult-to-play-around-with context to pick up. Let's see. If you are deploying this on a physical machine: you have to connect to the machine somehow. You have to setup the correct permissions. You need auditing. You need to configure logging (and log rotation). You need to ensure your npm start script will be able to be restarted if needed. You may need cronjobs for various housekeeping chores. And then suddenly you need to run more instances of your app. What to do? Are you going to setup a proxy now and a bunch of different ports? Is your script picking them up or are they hard-coded? Are you instead doing network namespaces and iptables trickery? How do you upgrade your service without downtime? Are you going to write scripts to do that? What if your app need storage. And what if you now need more machines. How are you going to spread the workloads around? And how do you automate the above? One team prefers Ansible, the other goes with Chef, a third one likes to embed shell scripts inside a Terraform provisioner. These things are _hard_. There is a whole lot of context. It's just that we have got used to the way things have always been done. It does not help that K8s development is very fast and there are far too many people and companies jumping on the bandwagon, each with their own unique spin. The ecosystem is becoming big enough to the point of being unmanageable. Also, Kubernetes joins some of the work that was done by the development team or release teams with work that was traditionally done by the operations teams, and makes it all visible. Suddenly you have to _know_ what the heck a liveness probe is. You could get by with not knowing this in a standard deployment, your app would simply lack the check(and cause issues in production). You need to know what exactly your app needs to persist. Previously it would just dump data in whatever directory it had permissions to, and this became tribal knowledge. But K8s by itself? My heuristic is: am I running containers? Do I need to spread said containers across machines? Just use K8s. Trying to replicate this with homegrown scripts will be very painful. It may not seem like it's painful now, but trust me, it will be. Will K8s exist in 15 years? Hard to say. Probably but, for the reasons you describe, it's likely that there will be, at least, a high level abstraction to hide decisions most people don't need to make.
  - wcarss 5y ago

ltbarcly3 5y ago

Agree, people are spending weeks of effort to figure out how to deploy their app which has 3 webservers and one RDS database via kubernetes because 'thats the right way to do it'. Kubernetes is a solution to a problem hardly anyone has, and it is maddingly complex, and large parts of it are poorly designed. If you have a large team deploying many services and can afford full time devops staff, it is a good solution to many problems, but probably 90% of the people using it would find things to be simpler and more reliable without it.