5 ms·

It seems to me like a vast majority of startups and use cases don't serve a _ton_ of traffic, nor do they do too much heavy data processing. If we're being real

It seems to me like a vast majority of startups and use cases don't serve a _ton_ of traffic, nor do they do too much heavy data processing. If we're being realistic, most webapps could probably run on a Raspberry Pi and be fine. With this being the case, why is such a heavy-weight and complicated system so popular?

abraxas 4y ago
Literally, design by resume. I see it at my current workplace. Top talent guys are fucking around wit K8s even though we really have no use for it and could host the whole shebang on a single EC2 instance and be no worse off for it. But that "won't scale" I'm told. Never mind our startup has a TAM that involves no more than 1,000 customers with maybe a dozen accounts each.
- jskrablin 4y ago
  It's not always about traffic scale. Sometimes it's about having a common deployment platform at different locations, on premise. Where relatively simple and small setups still bring a lot of value via pure convenience - suddenly everything is packed into Helm charts, running off basically identical CICD pipelines. But I guess that's not what "top talent guys" are interested in doing?
  - dvtrn 4y ago
    Sometimes it's about having a common deployment platform at different locations, on premise. That’s fair, that’s valid, that doesn’t however strike me as a compelling case to go off and hoist all of your stuff into k8s if there’s other equally performant and fault tolerant methods of running your application that require less operational complexity and cognitive load to triage and resolve failures. It seems to me the problem you bring up would serve an engineering team well to solve and solidify even if the application isn’t running on k8s
bri3d 4y ago
Transferrable experience in both directions, in and out, is a huge reason. Cynics see this as "resume driven development," but the reality is that offering training and an opportunity to use an industry standard tool isn't a bad move for hiring and retention. Additionally, as you grow, you can hire experts in k8s who have "been there before" with scale - at a huge cost, yes, but this is still a value versus something homegrown. Also, cloud-hosted k8s systems (especially GKE) aren't half bad these days. Starting with one (carefully, to avoid lock-in) and knowing you can expand later is appealing.
eddieroger 4y ago
Attempting a serious answer, because I agree most things can be run on a Pi and be fine. Let's say you're a developer who's comfortable making Docker containers and running them locally. One day, you learn that you could go to Azure|Google|$OTHER and spin up something called Kubernetes, push your container, and now you get a trove of features like scaling, availability, health checks, the safety that you can lose a node and stay online. That sounds appealing to me. Of course, the marketing materials are never the same as where the rubber meets the road, but you stand up your service and all is well. It's an appealing offer. It's why people use Heroku. If all you have to do is one-click a cluster and go, why wouldn't you want to do that?
- TheNewsIsHere 4y ago
  > It's an appealing offer. It's why people use Heroku. If all you have to do is one-click a cluster and go, why wouldn't you want to do that? I think you’ve hit upon what seems evident in this discussion to me, but that doesn’t seem to be highlighted well. Even the most ardent Kubernetes advocates here are noting it’s not a panacea. It’s simply solving a need that exists at an immense scale. Underlying all of that, though, is a need to understand what you’re deploying no matter what it is. Click to deploy is very tempting, but should only be undertaken when you have an understanding of what you’re clicking and the how and why of the deployment process, the technology stack that makes it possible, etc.

abraxas 4y ago

Literally, design by resume. I see it at my current workplace. Top talent guys are fucking around wit K8s even though we really have no use for it and could host the whole shebang on a single EC2 instance and be no worse off for it. But that "won't scale" I'm told. Never mind our startup has a TAM that involves no more than 1,000 customers with maybe a dozen accounts each.

jskrablin 4y ago
It's not always about traffic scale. Sometimes it's about having a common deployment platform at different locations, on premise. Where relatively simple and small setups still bring a lot of value via pure convenience - suddenly everything is packed into Helm charts, running off basically identical CICD pipelines. But I guess that's not what "top talent guys" are interested in doing?
- dvtrn 4y ago
  Sometimes it's about having a common deployment platform at different locations, on premise. That’s fair, that’s valid, that doesn’t however strike me as a compelling case to go off and hoist all of your stuff into k8s if there’s other equally performant and fault tolerant methods of running your application that require less operational complexity and cognitive load to triage and resolve failures. It seems to me the problem you bring up would serve an engineering team well to solve and solidify even if the application isn’t running on k8s

bri3d 4y ago

Transferrable experience in both directions, in and out, is a huge reason. Cynics see this as "resume driven development," but the reality is that offering training and an opportunity to use an industry standard tool isn't a bad move for hiring and retention. Additionally, as you grow, you can hire experts in k8s who have "been there before" with scale - at a huge cost, yes, but this is still a value versus something homegrown. Also, cloud-hosted k8s systems (especially GKE) aren't half bad these days. Starting with one (carefully, to avoid lock-in) and knowing you can expand later is appealing.

eddieroger 4y ago

Attempting a serious answer, because I agree most things can be run on a Pi and be fine. Let's say you're a developer who's comfortable making Docker containers and running them locally. One day, you learn that you could go to Azure|Google|$OTHER and spin up something called Kubernetes, push your container, and now you get a trove of features like scaling, availability, health checks, the safety that you can lose a node and stay online. That sounds appealing to me. Of course, the marketing materials are never the same as where the rubber meets the road, but you stand up your service and all is well. It's an appealing offer. It's why people use Heroku. If all you have to do is one-click a cluster and go, why wouldn't you want to do that?

TheNewsIsHere 4y ago
> It's an appealing offer. It's why people use Heroku. If all you have to do is one-click a cluster and go, why wouldn't you want to do that? I think you’ve hit upon what seems evident in this discussion to me, but that doesn’t seem to be highlighted well. Even the most ardent Kubernetes advocates here are noting it’s not a panacea. It’s simply solving a need that exists at an immense scale. Underlying all of that, though, is a need to understand what you’re deploying no matter what it is. Click to deploy is very tempting, but should only be undertaken when you have an understanding of what you’re clicking and the how and why of the deployment process, the technology stack that makes it possible, etc.