5 ms·

Not a day goes by where there isn’t some greybeard having a huge sulk about how nobody wants to use his collection of esoteric bash scripts that nobody else wil

Not a day goes by where there isn’t some greybeard having a huge sulk about how nobody wants to use his collection of esoteric bash scripts that nobody else will ever understand, but HE does.

jauntywundrkind 2y ago
Erulabs top comment nailed it so hard. There's been such a vocal force in comments for so long, of revulsion to "complexity", believing "simpler" is better. > Yes, the standard approach is more complex. But it is better _in practice_ to have a single approach, rather than many individually-simpler, but in-aggregate-more-complex approaches. There still remains such a strong reflexive "you don't need Kubernetes for that" response that shows up. But we really are seeing a lot more people who get the value of there being a standard way of doing things, of having common platform & expectations underneath. The cost of starting up may be significant, but it results in a more legible understandable result, and we can keep reusing that base of capabilities again and again and again. Its such an exciting change. Open source has been around for a long time, but running software has been the wild West, until very very recently. We now have this awesome, scalable, extensible way to manage containers, volumes, load balancers, databases, and whatever else have we. Love to see it. Folks aren't wrong about it having complexity, but so much of the complexity already existed, was just not clearly visible or well harnesses (different example is like how systemd makes it so easy to restrict services, give them temporary/unprivileged users). We are closer to a real shared understanding, to having so many particular decisions offloaded & so much more we can work together atop. Love it so much.
- quectophoton 2y ago
  > There still remains such a strong reflexive "you don't need Kubernetes for that" response that shows up. If you're already using docker-compose, the jump from there to Docker Swarm is arguably tiny in comparison to the jump from there to Kubernetes, while still bringing most of its value. So yes, I will keep evaluating the tradeoffs every time and choose accordingly.
- skydhash 2y ago
  Complex solutions exists for complex needs. If you just need to crop an image, you don’t install Photoshop to do so. If you only have a simple web app for a few thousands users, you don’t go and setup k8s. Yes, having photoshop means you may do what all the cool kids are doing, but if you’re only cropping image, Preview.app is good enough. Eschewing simpler solutions because “standard” is how you start to see everything as a nail for your hammer. There’s another thing that no one who advocates for these systems wants to mention: The cost of maintenance. I’m ok with systemd as 98% is outsourced to the maintainers. But I’d be more comfortable if k8s was a more monolithic system a la BSD. At least linux have distros.
  - fesc 2y ago
    > for a few thousands users It makes absolutely no sense to base this decision on the number of users. We have some applications that don't even have 10 users but still use k8s. Try to understand the point that was made in the original comment: Kubernetes is a way to actually make infrastructure simpler to understand for a team which maintains lots of different applications, as it can scale from a deployment with just one pod to hundreds of nodes and a silly microservices architecture. The point is not that every application might need this scalability, no the point is that for a team needing to maintain lots of different applications, some internal, some for customers, some in private datacenters, some in the cloud, Kubernetes can be the single common denominator. Hell, I'm a hardcode NixOS fan but for most services, I still prefer to run them in k8s just as it is more portable. Today I might be okay having some service sitting on some box, running via systemd. But tomorrow I might want to run this service highly available on some cluster. Using k8s that is simple, so why not do it from the start by just treating k8s as a slighly more powerful docker-compose.
  - nucleardog 2y ago
    > But I’d be more comfortable if k8s was a more monolithic system a la BSD. At least linux have distros. k3s is essentially a single binary and installed, up and running with a single command. With a handful of command line flags you can have a full cluster up and running with some master nodes and some agents and high availability through etcd and load balancing and network policies and ingress and distributed clouds via WireGuard/Tailscale… They also have “blessed” options (that you can generally install with a single command) for things like persistent storage, etc. I would not want to build a k8s cluster from scratch. Setting up and maintaining a k3s cluster is pretty trivial.
imtringued 2y ago
To be fair, the problem isn't the greybeard. It is that nobody understands bash.
trabant00 2y ago
Look up how much bash is in the k8s codebase. :)

Not a day goes by where there isn’t some greybeard having a huge sulk about how nobody wants to use his collection of esoteric bash scripts that nobody else will ever understand, but HE does.

jauntywundrkind 2y ago

Erulabs top comment nailed it so hard. There's been such a vocal force in comments for so long, of revulsion to "complexity", believing "simpler" is better. > Yes, the standard approach is more complex. But it is better _in practice_ to have a single approach, rather than many individually-simpler, but in-aggregate-more-complex approaches. There still remains such a strong reflexive "you don't need Kubernetes for that" response that shows up. But we really are seeing a lot more people who get the value of there being a standard way of doing things, of having common platform & expectations underneath. The cost of starting up may be significant, but it results in a more legible understandable result, and we can keep reusing that base of capabilities again and again and again. Its such an exciting change. Open source has been around for a long time, but running software has been the wild West, until very very recently. We now have this awesome, scalable, extensible way to manage containers, volumes, load balancers, databases, and whatever else have we. Love to see it. Folks aren't wrong about it having complexity, but so much of the complexity already existed, was just not clearly visible or well harnesses (different example is like how systemd makes it so easy to restrict services, give them temporary/unprivileged users). We are closer to a real shared understanding, to having so many particular decisions offloaded & so much more we can work together atop. Love it so much.

quectophoton 2y ago
> There still remains such a strong reflexive "you don't need Kubernetes for that" response that shows up. If you're already using docker-compose, the jump from there to Docker Swarm is arguably tiny in comparison to the jump from there to Kubernetes, while still bringing most of its value. So yes, I will keep evaluating the tradeoffs every time and choose accordingly.
skydhash 2y ago
Complex solutions exists for complex needs. If you just need to crop an image, you don’t install Photoshop to do so. If you only have a simple web app for a few thousands users, you don’t go and setup k8s. Yes, having photoshop means you may do what all the cool kids are doing, but if you’re only cropping image, Preview.app is good enough. Eschewing simpler solutions because “standard” is how you start to see everything as a nail for your hammer. There’s another thing that no one who advocates for these systems wants to mention: The cost of maintenance. I’m ok with systemd as 98% is outsourced to the maintainers. But I’d be more comfortable if k8s was a more monolithic system a la BSD. At least linux have distros.
- fesc 2y ago
  > for a few thousands users It makes absolutely no sense to base this decision on the number of users. We have some applications that don't even have 10 users but still use k8s. Try to understand the point that was made in the original comment: Kubernetes is a way to actually make infrastructure simpler to understand for a team which maintains lots of different applications, as it can scale from a deployment with just one pod to hundreds of nodes and a silly microservices architecture. The point is not that every application might need this scalability, no the point is that for a team needing to maintain lots of different applications, some internal, some for customers, some in private datacenters, some in the cloud, Kubernetes can be the single common denominator. Hell, I'm a hardcode NixOS fan but for most services, I still prefer to run them in k8s just as it is more portable. Today I might be okay having some service sitting on some box, running via systemd. But tomorrow I might want to run this service highly available on some cluster. Using k8s that is simple, so why not do it from the start by just treating k8s as a slighly more powerful docker-compose.
- nucleardog 2y ago
  > But I’d be more comfortable if k8s was a more monolithic system a la BSD. At least linux have distros. k3s is essentially a single binary and installed, up and running with a single command. With a handful of command line flags you can have a full cluster up and running with some master nodes and some agents and high availability through etcd and load balancing and network policies and ingress and distributed clouds via WireGuard/Tailscale… They also have “blessed” options (that you can generally install with a single command) for things like persistent storage, etc. I would not want to build a k8s cluster from scratch. Setting up and maintaining a k3s cluster is pretty trivial.

imtringued 2y ago

To be fair, the problem isn't the greybeard. It is that nobody understands bash.

trabant00 2y ago

Look up how much bash is in the k8s codebase. :)