3 ms·

But how many orgs need that scale?

trashtester 2y ago
A very small percentage of orgs, a not-as-small percentage of developers, and at the higher end of the value scale, the percentage is not small at all.
- dartos 2y ago
  I think the developers who care about knowing how their code works tend to not want hyperscale setups anyway. If they understood their system, odds are they’d realize that horizontal scaling with few, larger services is plenty scalable. At those large orgs, the individual developer doesn’t matter at all and the EMs will opt for faster release cycles and rely on internal platform teams to manage k8s and things like it.
  - dzikimarian 2y ago
    Exact opposite - k8s allows developers to actually tailor containers/pods/deployments themselves, instead opening tickets to have it configured on VM by platform team. Of course there are simpler container runtimes, but they have issues with scale, cost, features or transparency of operation. Of course they can be good fit if you're willing to give up one or more of these.
    - dartos 2y ago
      > k8s allows developers to actually tailor containers/pods/deployments themselves Yes, complex tools tend to be powerful. But when I say “devs who care about knowing how their code works” I’m also referring to their tools. K8s isn’t incomprehensible, but it is very complex, especially if you haven’t worked in devops before. “Devs who care…” I would, assume, would opt for simpler tools. I know I would.
themgt 2y ago
You can run single-node k3s on a VM with 512MB of RAM and deploy your app with a hundred lines of JSON, and it inherits a ton of useful features that are managed in one place and can grow with your app if/as needed. These discussions always go in circles between Haters and Advocates: * H: "kubernetes [at planetary scale] is too complex" * A: "you can run it on a toaster and it's simpler to reason about than systemd + pile of bash scripts" * H: "what's the point of single node kubernetes? I'll just SSH in and paste my bash script and call it a day" * A: "but how do you scale/maintain that?" * H: "who needs that scale?"
- apitman 2y ago
  The sad thing is there probably is a toaster out there somewhere with 512MB of RAM.
  - mkzetta 2y ago
    It's not sad until it becomes self-aware.
efitz 2y ago
Most of the ones that are profitable for cloud providers.
dzikimarian 2y ago
We're almost 100 devs in a few teams - works well. There's a bunch of companies of our size even in the same city. What's a bit different is we're creating own products, not renting people to others, so having uniform hosting platform is actual benefit.
duped 2y ago
Something I've discovered is that if you're a small team doing something new, off the shelf products/platforms are almost certainly not optimized to your use case. What looks like absurd scale to one team is a regular Tuesday for another, because "scale" is completely meaningless without context. We don't balk at a single machine running dozens of processes for a single web browser, we shouldn't balk at something running dozens of containers to do something that creates value somehow. And scale that up by number of devs/customers and you can see how thousands/hundreds of thousands can happen easily. Also the cloud vendors make it easy to have these problems because it's super profitable.

A very small percentage of orgs, a not-as-small percentage of developers, and at the higher end of the value scale, the percentage is not small at all.

dartos 2y ago
I think the developers who care about knowing how their code works tend to not want hyperscale setups anyway. If they understood their system, odds are they’d realize that horizontal scaling with few, larger services is plenty scalable. At those large orgs, the individual developer doesn’t matter at all and the EMs will opt for faster release cycles and rely on internal platform teams to manage k8s and things like it.
- dzikimarian 2y ago
  Exact opposite - k8s allows developers to actually tailor containers/pods/deployments themselves, instead opening tickets to have it configured on VM by platform team. Of course there are simpler container runtimes, but they have issues with scale, cost, features or transparency of operation. Of course they can be good fit if you're willing to give up one or more of these.
  - dartos 2y ago
    > k8s allows developers to actually tailor containers/pods/deployments themselves Yes, complex tools tend to be powerful. But when I say “devs who care about knowing how their code works” I’m also referring to their tools. K8s isn’t incomprehensible, but it is very complex, especially if you haven’t worked in devops before. “Devs who care…” I would, assume, would opt for simpler tools. I know I would.

themgt 2y ago

You can run single-node k3s on a VM with 512MB of RAM and deploy your app with a hundred lines of JSON, and it inherits a ton of useful features that are managed in one place and can grow with your app if/as needed. These discussions always go in circles between Haters and Advocates: * H: "kubernetes [at planetary scale] is too complex" * A: "you can run it on a toaster and it's simpler to reason about than systemd + pile of bash scripts" * H: "what's the point of single node kubernetes? I'll just SSH in and paste my bash script and call it a day" * A: "but how do you scale/maintain that?" * H: "who needs that scale?"

apitman 2y ago
The sad thing is there probably is a toaster out there somewhere with 512MB of RAM.
- mkzetta 2y ago
  It's not sad until it becomes self-aware.

efitz 2y ago

Most of the ones that are profitable for cloud providers.

dzikimarian 2y ago

We're almost 100 devs in a few teams - works well. There's a bunch of companies of our size even in the same city. What's a bit different is we're creating own products, not renting people to others, so having uniform hosting platform is actual benefit.

duped 2y ago

Something I've discovered is that if you're a small team doing something new, off the shelf products/platforms are almost certainly not optimized to your use case. What looks like absurd scale to one team is a regular Tuesday for another, because "scale" is completely meaningless without context. We don't balk at a single machine running dozens of processes for a single web browser, we shouldn't balk at something running dozens of containers to do something that creates value somehow. And scale that up by number of devs/customers and you can see how thousands/hundreds of thousands can happen easily. Also the cloud vendors make it easy to have these problems because it's super profitable.