5 ms·

Good article, until: > Use Kubernetes. Dear God no lol If you're running a startup that's starting to scale dramatically, I think maybe this is valid advice.

by dimgl 4y ago

Good article, until: > Use Kubernetes. Dear God no lol If you're running a startup that's starting to scale dramatically, I think maybe this is valid advice. But nowadays you can keep things dead simple and still be able to accomplish most business use-cases.

pgwhalen 4y ago
Time and time again, commenters suggest that the reason to use Kubernetes is to enable easy scaling, but this is not the case in my organization. Kubernetes is valuable because it is a standardized and flexible deployment model. Easy scalability is a nice side effect of that.
jstx1 4y ago
Doing simple things in Kubernetes isn't that much more complicated than doing simple things outside of Kubernetes.
- mikedelago 4y ago
  I agree - I think the hardest hump for developers is to learn Kubernetes first. After that, it's really not bad for most workloads.
w0m 4y ago
Kube has hit enough market/mind saturation that using it for more trivial use case isn't isn't necessarily a horrendous idea anymore. Just having a Kube available I can run a quick kron on is valuable.
- rednerrus 4y ago
  How much overhead does it require to feed and water k8s?
  - w0m 4y ago
    After initial setup, a managed GKE/AKS is pretty hands-off.
- dimgl 4y ago
  > Kube has hit enough market/mind saturation I agree with this. But I really see this from a business perspective. I think k8s works better at companies with large, complex engineering teams and infra. A lot of companies simply aren't ready, nor will they benefit from, introducing k8s into their stack.
  - dividedbyzero 4y ago
    GKE/EKS/AKS lower the bar by a huge lot. There is a ton of value in having just one platform, toolchain, deployment language, set of templates/blueprints, set of dashboards, set of alerts, target for hardening/securing, etc. pp. One of the big upsides of this for me is that it becomes a lot more tractable to get ordinary devs and others involved since you only have to polish things and train people once. I've found it's quite neat for e.g. data scientists to be able to toss a quick yaml into git and have their thing running to their specifications in non-prod. Things like flux and Kyverno make sure they are boxed in tightly enough that they can't cause a lot of damage, and if that thing works out, someone adds CI in front of the yaml and some templating to the yaml itself and off we go to prod, and the result is still quite comprehensible, so people are enabled at least to ask the good questions to the right people. That's what I see as one of the killer applications of Kubernetes, to build a lingua franca interface for all things ops that doesn't change (much) for different service levels and even totally different needs, like frontend devs and data scientists. It's probably not a great choice for a three-person startup trying to gain traction by moving fast, but IMO the threshold where k8s starts making sense is a lot lower than many here appear to think.
    - deleted 4y ago
      [deleted]
RajT88 4y ago
That stuck out to me as well as being suspect. > Assuming you have more than one service and more than one instance, you either need or will need stuff like service discovery, autoscaling, and deployment versioning, and you do not want to manage all that by yourself. To paraphrase, "If you have anything but a tiny amount of complexity to your architecture, you must add in a high degree of complexity". It sounds insane, right? Like, we're skipping some middle steps. Yes, Kubernetes solves those problems, BUT ALSO the care and feeding of Kubernetes clusters themselves is a significant time investment. Manual scaling sucks, but if you have a good automation game, it's not that bad. Often what people think is a need to scale extremely rapidly is really an organizational problem they are trying to automate around (example: An ECommerce site sends out coupons to 10 million customers without telling the devops teams).
- klooney 4y ago
  > BUT ALSO the care and feeding of Kubernetes clusters themselves is a significant time investment AWS and GCP will do this for you for a small markup
  - RajT88 4y ago
    While this is true (btw, Azure as well has a managed offering) the complexity is not the only issue. Cost! The article is basically advocating, "if you have more than one service, you need K8S", and sticking your app on Kubernetes in the cloud (managed or not) is a huge cost upgrade from a single or handful of servers.
    - klooney 4y ago
      You're right, but the higher your service count gets, the more you should probably be on k8s. Large scale ECS or Lambda stuff is much worse to maintain
      - RajT88 4y ago
        I would disagree in a couple of important ways: 1. The higher your service count gets, the more you should probably be on some container orchestrator. There is more than one. 2. The number of services you have to manage to justify moving to a container orchestrator is most certainly not just > 1. That is crazy. I don't know the right number, as it probably varies according to how mature your organization is and how well the parts work together. But it is definitely higher than > 1! My last point is: If all teams worked together smoothly, or one team had infinite capacity, or if automation was perfect, etc. etc. etc. we wouldn't need containers, let alone container orchestration. These are solutions to people problems, not technology problems.
mikedelago 4y ago
I think better phrasing for this would be "develop 12-factor apps". At scale, Kubernetes is great. When things are still small and simple, an Ansible Playbook and a Docker container can take a company pretty far while still being able to move to k8s pretty easily.

by dimgl 4y ago

pgwhalen 4y ago

Time and time again, commenters suggest that the reason to use Kubernetes is to enable easy scaling, but this is not the case in my organization. Kubernetes is valuable because it is a standardized and flexible deployment model. Easy scalability is a nice side effect of that.

jstx1 4y ago

Doing simple things in Kubernetes isn't that much more complicated than doing simple things outside of Kubernetes.

mikedelago 4y ago
I agree - I think the hardest hump for developers is to learn Kubernetes first. After that, it's really not bad for most workloads.

w0m 4y ago

Kube has hit enough market/mind saturation that using it for more trivial use case isn't isn't necessarily a horrendous idea anymore. Just having a Kube available I can run a quick kron on is valuable.

rednerrus 4y ago
How much overhead does it require to feed and water k8s?
- w0m 4y ago
  After initial setup, a managed GKE/AKS is pretty hands-off.
dimgl 4y ago
> Kube has hit enough market/mind saturation I agree with this. But I really see this from a business perspective. I think k8s works better at companies with large, complex engineering teams and infra. A lot of companies simply aren't ready, nor will they benefit from, introducing k8s into their stack.
- dividedbyzero 4y ago
  GKE/EKS/AKS lower the bar by a huge lot. There is a ton of value in having just one platform, toolchain, deployment language, set of templates/blueprints, set of dashboards, set of alerts, target for hardening/securing, etc. pp. One of the big upsides of this for me is that it becomes a lot more tractable to get ordinary devs and others involved since you only have to polish things and train people once. I've found it's quite neat for e.g. data scientists to be able to toss a quick yaml into git and have their thing running to their specifications in non-prod. Things like flux and Kyverno make sure they are boxed in tightly enough that they can't cause a lot of damage, and if that thing works out, someone adds CI in front of the yaml and some templating to the yaml itself and off we go to prod, and the result is still quite comprehensible, so people are enabled at least to ask the good questions to the right people. That's what I see as one of the killer applications of Kubernetes, to build a lingua franca interface for all things ops that doesn't change (much) for different service levels and even totally different needs, like frontend devs and data scientists. It's probably not a great choice for a three-person startup trying to gain traction by moving fast, but IMO the threshold where k8s starts making sense is a lot lower than many here appear to think.
  - deleted 4y ago
    [deleted]

RajT88 4y ago

That stuck out to me as well as being suspect. > Assuming you have more than one service and more than one instance, you either need or will need stuff like service discovery, autoscaling, and deployment versioning, and you do not want to manage all that by yourself. To paraphrase, "If you have anything but a tiny amount of complexity to your architecture, you must add in a high degree of complexity". It sounds insane, right? Like, we're skipping some middle steps. Yes, Kubernetes solves those problems, BUT ALSO the care and feeding of Kubernetes clusters themselves is a significant time investment. Manual scaling sucks, but if you have a good automation game, it's not that bad. Often what people think is a need to scale extremely rapidly is really an organizational problem they are trying to automate around (example: An ECommerce site sends out coupons to 10 million customers without telling the devops teams).

klooney 4y ago
> BUT ALSO the care and feeding of Kubernetes clusters themselves is a significant time investment AWS and GCP will do this for you for a small markup
- RajT88 4y ago
  While this is true (btw, Azure as well has a managed offering) the complexity is not the only issue. Cost! The article is basically advocating, "if you have more than one service, you need K8S", and sticking your app on Kubernetes in the cloud (managed or not) is a huge cost upgrade from a single or handful of servers.
  - klooney 4y ago
    You're right, but the higher your service count gets, the more you should probably be on k8s. Large scale ECS or Lambda stuff is much worse to maintain
    - RajT88 4y ago
      I would disagree in a couple of important ways: 1. The higher your service count gets, the more you should probably be on some container orchestrator. There is more than one. 2. The number of services you have to manage to justify moving to a container orchestrator is most certainly not just > 1. That is crazy. I don't know the right number, as it probably varies according to how mature your organization is and how well the parts work together. But it is definitely higher than > 1! My last point is: If all teams worked together smoothly, or one team had infinite capacity, or if automation was perfect, etc. etc. etc. we wouldn't need containers, let alone container orchestration. These are solutions to people problems, not technology problems.

mikedelago 4y ago

I think better phrasing for this would be "develop 12-factor apps". At scale, Kubernetes is great. When things are still small and simple, an Ansible Playbook and a Docker container can take a company pretty far while still being able to move to k8s pretty easily.