4 ms·

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

by tnolet 7y ago

outside1234 7y ago
Often it is that they think they have never encountered the problem Kubernetes solves or have "gotten lucky" and never encountered it.
devoply 7y ago
Well how else do you build webscale software? What if later you want to deploy microservices. Premature optimization seems like a good idea with infrastructure because you have room to grow.
dkarl 7y ago
I think the crux of the problem is that everyone encounters the problem Kubernetes solves. As the GP states, Kubernetes gives you "infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a collection of individual machines with specific designations Who doesn't want that? Of course you want that. But will the investment of time and effort pay off for your organization, and if so, how quickly? That's the hard question to answer. It depends on scale, personnel, the types of workloads involved, how easily your tools and practices can be updated, and presumably many other considerations. From my personal experience it seems like in practice the answer to this question is so murky that the deciding factors turn out to be social, including the personal risk aversiveness of the people making the decision, people's loyalty to the company versus their own resume, and whether leadership cultivates a hyperoptimistic growth mentality of making 10x or even 100x decisions (i.e., make decisions assuming the company will be 10x or 100x bigger in a year.) The problem, then, is helping people compare the cost/benefit of Kubernetes compared to their current practices, for their own organization.
- cweagans 7y ago
  There are lots of tools that give you "infrastructure as code". Why is Kubernetes special?
  - honkycat 7y ago
    What is the point of this question? Why are the other tools special?
    - cweagans 7y ago
      My point is that if "infrastructure as code" is your sole requirement, Kubernetes doesn't seem like the first choice. Adopting Kubernetes is not a small task, but it seems to be the go-to answer for a lot of the HN crowd. Don't get me wrong: it's a great tool for some things. But IMO, for 80% of projects it's completely overkill.
      - dragonwriter 7y ago
        K8s is the only IaC platform with heavy buy in by all the major public clouds.
        cweagans 7y ago
        I'm not particularly interested in limiting myself to using only the tools that large companies have deemed worthy. There are plenty of tools out there that can get the job done at the scale that the vast majority of businesses operate in with lower operational and cognitive overhead than Kubernetes.
      - auslander 7y ago
        +1. Infrastructure as code is exactly that, code. For AWS it is Cloudformation template code, Cloudformation service and some CI/CD on top, like jenkins or ansible. Or Terraform for unlucky ones. K8s is container orchestration, like AWS ECS, totally different beast.
ownagefool 7y ago
Lots of people have some the problems k8s solve. Infrastructure as Code - If you're not doing infrastructure as code, how do you know who is taking what actions on your infrastructure? How do you know your tests are running on an environment that represents production? How do you know the tester or dev hasn't fixed and not commited? CI/CD - Do you have a quicker way to create test environments than just running kubectl create ns? Resource Utilisation - Sharing servers to save money. Obviously you can use VMs, but do you want to do nested VMs on cloud? I'm not sure most people should run k8s, but in a world where you can use GKE, I can't really see why not. What offers a better solution?
tracker1 7y ago
I'm in the situation that Kubernetes does solve the problem I have... deploying application stacks across varied configurations for purposes of testing at a PR level. Working on software that is customized and delivered to multiple downstream clients is hard to test against. Yes, there are other options, but K8s is a very good fit, and the best option we have. YMMV... I've also been in a scenario where I just did separate pushes to dokku boxes behind a load balancer. There's plenty of room for in between. Right now, I feel kind of like I'm treading water though.

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

by tnolet 7y ago

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

outside1234 7y ago

Often it is that they think they have never encountered the problem Kubernetes solves or have "gotten lucky" and never encountered it.

devoply 7y ago

Well how else do you build webscale software? What if later you want to deploy microservices. Premature optimization seems like a good idea with infrastructure because you have room to grow.

dkarl 7y ago

I think the crux of the problem is that everyone encounters the problem Kubernetes solves. As the GP states, Kubernetes gives you "infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a collection of individual machines with specific designations Who doesn't want that? Of course you want that. But will the investment of time and effort pay off for your organization, and if so, how quickly? That's the hard question to answer. It depends on scale, personnel, the types of workloads involved, how easily your tools and practices can be updated, and presumably many other considerations. From my personal experience it seems like in practice the answer to this question is so murky that the deciding factors turn out to be social, including the personal risk aversiveness of the people making the decision, people's loyalty to the company versus their own resume, and whether leadership cultivates a hyperoptimistic growth mentality of making 10x or even 100x decisions (i.e., make decisions assuming the company will be 10x or 100x bigger in a year.) The problem, then, is helping people compare the cost/benefit of Kubernetes compared to their current practices, for their own organization.

cweagans 7y ago
There are lots of tools that give you "infrastructure as code". Why is Kubernetes special?
- honkycat 7y ago
  What is the point of this question? Why are the other tools special?
  - cweagans 7y ago
    My point is that if "infrastructure as code" is your sole requirement, Kubernetes doesn't seem like the first choice. Adopting Kubernetes is not a small task, but it seems to be the go-to answer for a lot of the HN crowd. Don't get me wrong: it's a great tool for some things. But IMO, for 80% of projects it's completely overkill.
    - dragonwriter 7y ago
      K8s is the only IaC platform with heavy buy in by all the major public clouds.
      - cweagans 7y ago
        I'm not particularly interested in limiting myself to using only the tools that large companies have deemed worthy. There are plenty of tools out there that can get the job done at the scale that the vast majority of businesses operate in with lower operational and cognitive overhead than Kubernetes.
    - auslander 7y ago
      +1. Infrastructure as code is exactly that, code. For AWS it is Cloudformation template code, Cloudformation service and some CI/CD on top, like jenkins or ansible. Or Terraform for unlucky ones. K8s is container orchestration, like AWS ECS, totally different beast.

ownagefool 7y ago

Lots of people have some the problems k8s solve. Infrastructure as Code - If you're not doing infrastructure as code, how do you know who is taking what actions on your infrastructure? How do you know your tests are running on an environment that represents production? How do you know the tester or dev hasn't fixed and not commited? CI/CD - Do you have a quicker way to create test environments than just running kubectl create ns? Resource Utilisation - Sharing servers to save money. Obviously you can use VMs, but do you want to do nested VMs on cloud? I'm not sure most people should run k8s, but in a world where you can use GKE, I can't really see why not. What offers a better solution?

tracker1 7y ago

I'm in the situation that Kubernetes does solve the problem I have... deploying application stacks across varied configurations for purposes of testing at a PR level. Working on software that is customized and delivered to multiple downstream clients is hard to test against. Yes, there are other options, but K8s is a very good fit, and the best option we have. YMMV... I've also been in a scenario where I just did separate pushes to dokku boxes behind a load balancer. There's plenty of room for in between. Right now, I feel kind of like I'm treading water though.