| ▲ | xorcist 16 hours ago |
| Every item on that list is "boring" tech. Approximately everyone have used load balancers, test environments and monitoring since the 90s just fine. What is it that you think make Kubernetes especially suited for this compared to every other solution during the past three decades? There are good reasons to use Kubernetes, mainly if you are using public clouds and want to avoid lock-in. I may be partial, since managing it pays my bills. But it is complex, mostly unnecessarily so, and no one should be able to say with a straight face that it achieves better uptime or requires less personnel than any alternative. That's just sales talk, and should be a big warning sign. |
|
| ▲ | YZF 15 hours ago | parent | next [-] |
| It's the way things work together. If you want to add a new service you just annotate that service and DNS gets updated, your ingress gets the route added, cert-manager gets you the certs from let's encrypt. You want Prometheus to monitor your pod you just add the right annotation. When your server goes down k8s will move your pod around. k8s storage will take care of having the storage follow your pod. Your entire configuration is highly available and replicated in etcd. It's just very different than your legacy "standard" technology. |
| |
| ▲ | gr3ml1n 13 hours ago | parent [-] | | None of this is difficult to do or automate, and we've done it for years. Kubernetes simply makes it more complex by adding additional abstractions in the pursuit of pretending hardware doesn't exist. There are, maybe, a dozen companies in the world with a large enough physical footprint where Kubernetes might make sense. Everyone else is either engaged in resume-driven development, or has gone down some profoundly wrong path with their application architecture to where it is somehow the lesser evil. | | |
| ▲ | sampullman 12 hours ago | parent [-] | | I used to feel the same way, but have come around. I think it's great for small companies for a few reasons. I can spin up effectively identical dev/ci/stg/prod clusters for a new project in an hour for a medium sized project, with CD in addition to everything GP mentioned. I basically don't have to think about ops anymore until something exotic comes up, it's nice. I agree that it feels clunky, and it was annoying to learn, but once you have something working it's a huge time saver. The ability to scale without drastically changing the system is a bonus. | | |
| ▲ | gr3ml1n 10 hours ago | parent | next [-] | | > I can spin up effectively identical dev/ci/stg/prod clusters for a new project in an hour for a medium sized project, with CD in addition to everything GP mentioned. I can do the same thing with `make local` invoking a few bash commands. If the complexity increases beyond that, a mistake has been made. | |
| ▲ | xorcist 7 hours ago | parent | prev [-] | | You could say the same thing about Ansible or Vagrant or Nomad or Salt or anything else. I can say with complete confidence however, that if you are running Kubernetes and not thinking about ops, you are simply not operating it yourself. You are paying someone else to think about it for you. Which is fine, but says nothing about the technology. |
|
|
|
|
| ▲ | lmm 10 hours ago | parent | prev | next [-] |
| > Every item on that list is "boring" tech. Approximately everyone have used load balancers, test environments and monitoring since the 90s just fine. What is it that you think make Kubernetes especially suited for this compared to every other solution during the past three decades? You could make the same argument against using cloud at all, or against using CI. The point of Kubernetes isn't to make those things possible, it's to make them easy and consistent. |
| |
| ▲ | drw85 3 hours ago | parent | next [-] | | But none of those things are easy.
All cloud environments are fairly complex and kubernetes is not something that you just do in an afternoon. You need to learn about how it works, which takes about the same time as using 'simpler' means to do things directly. Sure, it means that two people that already understand k8s can easily exchange or handover a project, which might be harder to understand if done with other means. But that's about the only bonus it brings in most situations. | |
| ▲ | eadmund an hour ago | parent | prev [-] | | > The point of Kubernetes isn't to make those things possible, it's to make them easy and consistent. Kubernetes definitely makes things consistent, but I do not think that it makes them easy. There’s certainly a lot to learn from Kubernetes, but I strongly believe that a more tasteful successor is possible, and I hope that it is inevitable. |
|
|
| ▲ | threeseed 11 hours ago | parent | prev | next [-] |
| Kubernetes is boring tech as well. And the advantage of it is one way to manage resources, scaling, logging, observability, hardware etc. All of which is stored in Git and so audited, reviewed, versioned, tested etc in exactly the same way. |
|
| ▲ | andreasmetsala 4 hours ago | parent | prev [-] |
| > But it is complex, mostly unnecessarily so Unnecessary complexity sounds like something that should be fixed. Can you give an example? |
