| ▲ | Havoc 6 hours ago |
| “let me install everything myself” doesn’t generalise well and gets messy even if you IaC it. There is a reason k8s gang keeps going on about “cattle not pets”. The starting assumptions and goals are fundamentally different vs “give me a physical server” Both have their place I think so not really one is right other is wrong |
|
| ▲ | tombert 2 hours ago | parent | next [-] |
| Everyone says this, but do we actually have data to back that up? I feel like I spend so much time working around CloudSQL for postgres support in GCP at work, to a point where I'm not actually sure I'm saving a ton of time over running and managing it myself. That's probably not true, I'm sure there are edge cases that I'm not accounting for, but I'm a little tired of everyone acting like AWS and GCP and Azure are the "set it and forget it" thing that they advertise. |
| |
| ▲ | Havoc 33 minutes ago | parent [-] | | Not sure how you’d even measure that meaningfully. My comment above was more k8s vs classic server rather than thinking about cloud k8s in particular. I do agree that cloud is stuff is a huge time sink. I’ve learned to look at it in terms of how close it is to FOSS like world. Things that follow normal protocols and standards like say it speaks Postgres or is a docker image then cloud is ok. Things that are cloud vendor specific or a custom product…run for the hills. Not only is it lock in but also that’s where the pain you describe is. The engineering around it just becomes so much more granular and fragile |
|
|
| ▲ | immibis 5 hours ago | parent | prev [-] |
| And people tend to vastly underestimate the power of a single server. These days you can get a terabyte of RAM, 96 cores and dual 10G Ethernet for a low-to-mid 4-digit price (used). Do you need the cloud? Some do, but often your highest conceivable scale fits on one or two servers. Stack Exchange famously ran this way for a long time (until recently when they've been bought by large investors and they're going full cloud and AIshit). |
| |
| ▲ | Havoc 3 hours ago | parent [-] | | Scaling wasn’t really what I was getting at there per se. Said generalise but that’s admittedly quite fuzzy. Meant it more in the abstraction layer and standardisation sense. Installing stuff straight on server is very messy especially if it’s lots of different providers with their own dependencies. So you need to do some form of containers or VMs to isolate them. At which point you need some sort of tooling around that. And deal with failures etc. Before you know it you’ve reinvented k8s except with less standardization and more duck tape. So it think there is a strong case for a k8s cluster but being mindful to keep it as simple as possible within that paradigm. Ie k8s but just the basic building blocks |
|
