4 ms·

k8s is, and I wrote it countless times, a huge waste of resources. The whole event driven distributed design is. There aren't many use cases that require more

k8s is, and I wrote it countless times, a huge waste of resources. The whole event driven distributed design is. There aren't many use cases that require more than 5k concurrent clients and the number is even higher without the HTTP overhead (a single bare metal server can handle with the proper language). For most companies it's a waste of money. k8s is hype tech designed to drive business to public cloud providers, because of its complexity and high hardware demands. 9 bare metal servers minimum. And then you have those pods, which are collections of services (e.g. postgres + api server + some cache). But in the case of postgres, why wouldn't you have a dedicated cluster instead of multiple, isolated instances as it is the case with k8s? I know, now the EDA faction chimes in with their dogma. Again most cases don't require even 5k concurrent clients. And most projects never will grow to the point of that many concurrent clients. Addendum: And then I read the who is hiring thread and it's all k8s k8s k8s... frustrating

achempion 3y ago
k8s is a complex solution for complex problems. You don't need k8s to host landing or personal blog type of service. Once you move to a type of project with complex demands around deployments, log management, failover management, secrets, environments, resource isolation, etc., then building something to solve this set of problems over and over again is very expensive when off-the-shelf battle-tested solution is available.
- sureglymop 3y ago
  What about using docker swarm or even a single node docker swarm cluster? I think that could be a viable alternative for small stuff.
  - SirensOfTitan 3y ago
    The thing is, k8s has a lot of mindshare. It's entirely easier to go and find some pertinent issue with your k8s set-up through a simple search, whereas e.g. nomad and swarm have much less mindshare. You don't have to go full complexity with k8s. You can just use a managed k8s provider and ship a simple deployment with an anti-affinity policy to distribute across VMs on creation. Sure, there are other solutions [and this one is likely to not be the cheapest], but they're all vendor locked--k8s is about as close to a cloud agnostic compute as we're likely to get.
  - achempion 3y ago
    I enjoy docker swarm for small hobby projects. It's simple and easy to maintain if you want to benefit from container apps and configuration. Once your service grows, you'll notice some rough edges around the docker swarm. When you start having dedicated SRE/DevOps roles, moving from heroku/swarm to k8s will make sense.
- lakomen 3y ago
  The arrogance of you. You can do more on a single server than hosting "landing pages" or "personal blog". I host seemingly complex projects with simple methods, without needing any complex k8s crap. That's what you people aren't getting. You're so full into the complexity that you don't see the simple solution as something worthwhile. WHAT about k8s is more battle tested than decades of doing the simple and efficient on a 1-3 servers? You're brainwashed. Possibly even a shill of one of those expensive cloud providers.
thinkmassive 3y ago
> And then you have those pods, which are collections of services (e.g. postgres + api server + some cache). Pods are not intended to bundle those 3 services. Typically one would use higher level abstractions (Deployment for the API, StatefulSet for the database), each composed of multiple Pods that should be scheduled on different physical machines. It’s no wonder you’ve had a bad experience trying to use it the way you describe. Following the intended patterns provides a standard way to achieve rolling updates, horizontal autoscaling, and a ton of other functionality that used to be bespoke code at each organization. The old way was often buggy, and onboarding new engineers took much longer.
- thunky 3y ago
  Maybe their terminology was wrong, but what about this point: > But in the case of postgres, why wouldn't you have a dedicated cluster Does k8s not push you to mix postgres pods in the same host as your API pods? Unless you go out of your way to handicap it. I understand the appeal of applying the k8s (or swarm, or nomad) model to stateless API containers, but mixing in stateful db containers and pretending they're all equivalent makes less sense to me.
  - thinkmassive 3y ago
    Many applications don't need multiple physical machines worth of database. Persistent storage has been a solved problem, especially when using a managed Kubernetes service. What's the problem with running stateful workloads on a cluster?
    - thunky 3y ago
      What's wrong is that it adds extra layers of abstraction just to satisfy k8s. Extra layers aren't free.
- lakomen 3y ago
  I'm not an idiot so don't treat me like one. I know what I'm talking about, unlike you apparently. You can have all that without k8s. k8s doesn't equal auto scaling, "rolling updates". You are a booksmart idiot.

achempion 3y ago

k8s is a complex solution for complex problems. You don't need k8s to host landing or personal blog type of service. Once you move to a type of project with complex demands around deployments, log management, failover management, secrets, environments, resource isolation, etc., then building something to solve this set of problems over and over again is very expensive when off-the-shelf battle-tested solution is available.

sureglymop 3y ago
What about using docker swarm or even a single node docker swarm cluster? I think that could be a viable alternative for small stuff.
- SirensOfTitan 3y ago
  The thing is, k8s has a lot of mindshare. It's entirely easier to go and find some pertinent issue with your k8s set-up through a simple search, whereas e.g. nomad and swarm have much less mindshare. You don't have to go full complexity with k8s. You can just use a managed k8s provider and ship a simple deployment with an anti-affinity policy to distribute across VMs on creation. Sure, there are other solutions [and this one is likely to not be the cheapest], but they're all vendor locked--k8s is about as close to a cloud agnostic compute as we're likely to get.
- achempion 3y ago
  I enjoy docker swarm for small hobby projects. It's simple and easy to maintain if you want to benefit from container apps and configuration. Once your service grows, you'll notice some rough edges around the docker swarm. When you start having dedicated SRE/DevOps roles, moving from heroku/swarm to k8s will make sense.
lakomen 3y ago
The arrogance of you. You can do more on a single server than hosting "landing pages" or "personal blog". I host seemingly complex projects with simple methods, without needing any complex k8s crap. That's what you people aren't getting. You're so full into the complexity that you don't see the simple solution as something worthwhile. WHAT about k8s is more battle tested than decades of doing the simple and efficient on a 1-3 servers? You're brainwashed. Possibly even a shill of one of those expensive cloud providers.

thinkmassive 3y ago

> And then you have those pods, which are collections of services (e.g. postgres + api server + some cache). Pods are not intended to bundle those 3 services. Typically one would use higher level abstractions (Deployment for the API, StatefulSet for the database), each composed of multiple Pods that should be scheduled on different physical machines. It’s no wonder you’ve had a bad experience trying to use it the way you describe. Following the intended patterns provides a standard way to achieve rolling updates, horizontal autoscaling, and a ton of other functionality that used to be bespoke code at each organization. The old way was often buggy, and onboarding new engineers took much longer.

thunky 3y ago
Maybe their terminology was wrong, but what about this point: > But in the case of postgres, why wouldn't you have a dedicated cluster Does k8s not push you to mix postgres pods in the same host as your API pods? Unless you go out of your way to handicap it. I understand the appeal of applying the k8s (or swarm, or nomad) model to stateless API containers, but mixing in stateful db containers and pretending they're all equivalent makes less sense to me.
- thinkmassive 3y ago
  Many applications don't need multiple physical machines worth of database. Persistent storage has been a solved problem, especially when using a managed Kubernetes service. What's the problem with running stateful workloads on a cluster?
  - thunky 3y ago
    What's wrong is that it adds extra layers of abstraction just to satisfy k8s. Extra layers aren't free.
lakomen 3y ago
I'm not an idiot so don't treat me like one. I know what I'm talking about, unlike you apparently. You can have all that without k8s. k8s doesn't equal auto scaling, "rolling updates". You are a booksmart idiot.