3 ms·

Figma were running on ECS before, so they weren't just running dedicated servers. I'm a K8S believer, but it _is_ complicated. It solves hard problems. If you'

Figma were running on ECS before, so they weren't just running dedicated servers. I'm a K8S believer, but it _is_ complicated. It solves hard problems. If you're multi-cloud, it's a no brainer. If you're doing complex infra that you want a 1:1 mapping of locally, it works great. But if you're less than 100 developers and are deploying containers to just AWS, I think you'd be insane to use EKS over ECS + Fargate in 2024.

epgui 2y ago
I don’t know if it’s just me, but I really don’t see how kubernetes is more complex than ECS. Even for a one-man show.
- mrgaro 2y ago
  Kubernetes needs regular updates, just as everything else (unless you carefully freeze your environment and somehow manage the vulnerability risks) and that requires manual work. ECS+Fargate however does not. If you are a small team managing the entire stack, you need to factor this into accounts. For example EKS forces you to upgrade the cluster to keep in the main kubernetes release cycle, albeit you can delay it somewhat. I personally run k8s at home and another two at work and I recommend our teams to use ECS+Fargate+ALB if it is enough for them.
  - metaltyphoon 2y ago
    > Kubernetes needs regular updates, just as everything else (unless you carefully freeze your environment and somehow manage the vulnerability risks) and that requires manual work Just use a managed K8s solution that deals with this? AKS, EKS and GKE all do this for you.
    - ttymck 2y ago
      It doesn't do everything for you. You still need to update applications that use deprecated APIs. This sort of "just" thinking is a great way for teams to drown in ops toil.
      - Ramiro 2y ago
        I agree with @metaltyphoon on this. Even for small teams, a managed version of Kubernetes takes away most of the pain. I've used both ECS+Fargate and Kubernetes, but these days, I prefer Kubernetes mainly because the ecosystem is way bigger, both vendor and open source. Most of the problems we run into are always one search or open source project away.
      - metaltyphoon 2y ago
        Are you assuming the workloads have to use K8s APIs? Where is this coming from? If that’s not the case can you actually explain with a concrete example?
        ttymck 2y ago
        Any cluster extension. Helm is a good example. https://helm.sh/docs/topics/version_skew/ https://helm.sh/docs/topics/version_skew/ Istio: https://istio.io/latest/docs/releases/supported-releases/#support-status-of-istio-releases https://istio.io/latest/docs/releases/supported-releases/#su... Literally every kubernetes manifest that hits the server uses a k8s api: apiVersion: apps/v1
        epgui 2y ago
        You mean operators? (genuine tone, not rhetorical)
        ttymck 2y ago
        Sure, an operator is likely to use a wide array of APIs. But, to reiterate, everything uses APIs. The *betavX APIs are of course likely to be deprecated and replaced with stable APIs after a few versions.
        Too 2y ago
        Man, you don't need to use service mesh just because you use k8s. Istio is a very advanced component that 99% of users don't need. So if you are going to compare with a managed solution, compare with something equivalent. Take a bare managed cluster and add a single Deployment to it, it will be no more complex than ECS, while giving you much better developer ergonomics.
    - anonfordays 2y ago
      There's still Helm oddities, "annotations", CRDs, mutating web hooks, operators, etc. to comprehend before you have any idea of what the system is doing. All it takes is a random annotation to throw all your assumptions away. It's a complicated mess compared to something like a Nomad jobspec. That's one of the reasons we decided on Nomad while I was at Cloudflare.
mountainriver 2y ago
This just feels like a myth to me at this point. Kubernetes isn’t hard, the clouds have made is so simple now that it’s in no way more difficult than ECS and is way more flexible
- davewritescode 2y ago
  I’m not saying I agree with the comment above you but Kubernetes upgrades and keeping all your addons/vpc stuff up to date can be a never ending slog of one-way upgrades that, when they go wrong, can cause big issues.
  - organsnyder 2y ago
    Those are all issues that should be solved by the managed provider. It's been a while since I spun up a k8s instance on AWS, Azure, or the like, but when I did I was astounded at how many implementation decisions and toil I had to do myself. Hosted k8s should be plug-and-play unless you have a very specialized use-case.
    - adammarples 2y ago
      Yeah if you pay someone to manage something for you, it's not hard. That's because you're not doing it. Like air travel and taxes, it's easy.
      - organsnyder 2y ago
        If you're not paying someone to manage this for you, either you're a hobbyist (perhaps masquerading as a professional) or you have the scale or special use-case that makes you outside 95% of use-cases. Last I checked, managed k8s clusters weren't much more expensive than the compute they ran on.
- anonfordays 2y ago
  It is by no means "a myth". There's still Helm oddities, "annotations", CRDs, mutating web hooks, operators, etc. to comprehend before you have any idea of what the system is doing. All it takes is a random annotation to throw all your assumptions away. It's a complicated mess compared to something like a Nomad jobspec. That's one of the reasons we decided on Nomad while I was at Cloudflare.

epgui 2y ago

I don’t know if it’s just me, but I really don’t see how kubernetes is more complex than ECS. Even for a one-man show.

mrgaro 2y ago
Kubernetes needs regular updates, just as everything else (unless you carefully freeze your environment and somehow manage the vulnerability risks) and that requires manual work. ECS+Fargate however does not. If you are a small team managing the entire stack, you need to factor this into accounts. For example EKS forces you to upgrade the cluster to keep in the main kubernetes release cycle, albeit you can delay it somewhat. I personally run k8s at home and another two at work and I recommend our teams to use ECS+Fargate+ALB if it is enough for them.
- metaltyphoon 2y ago
  > Kubernetes needs regular updates, just as everything else (unless you carefully freeze your environment and somehow manage the vulnerability risks) and that requires manual work Just use a managed K8s solution that deals with this? AKS, EKS and GKE all do this for you.
  - ttymck 2y ago
    It doesn't do everything for you. You still need to update applications that use deprecated APIs. This sort of "just" thinking is a great way for teams to drown in ops toil.
    - Ramiro 2y ago
      I agree with @metaltyphoon on this. Even for small teams, a managed version of Kubernetes takes away most of the pain. I've used both ECS+Fargate and Kubernetes, but these days, I prefer Kubernetes mainly because the ecosystem is way bigger, both vendor and open source. Most of the problems we run into are always one search or open source project away.
    - metaltyphoon 2y ago
      Are you assuming the workloads have to use K8s APIs? Where is this coming from? If that’s not the case can you actually explain with a concrete example?
      - ttymck 2y ago
        Any cluster extension. Helm is a good example. https://helm.sh/docs/topics/version_skew/ https://helm.sh/docs/topics/version_skew/ Istio: https://istio.io/latest/docs/releases/supported-releases/#support-status-of-istio-releases https://istio.io/latest/docs/releases/supported-releases/#su... Literally every kubernetes manifest that hits the server uses a k8s api: apiVersion: apps/v1
        epgui 2y ago
        You mean operators? (genuine tone, not rhetorical)
        ttymck 2y ago
        Sure, an operator is likely to use a wide array of APIs. But, to reiterate, everything uses APIs. The *betavX APIs are of course likely to be deprecated and replaced with stable APIs after a few versions.
        Too 2y ago
        Man, you don't need to use service mesh just because you use k8s. Istio is a very advanced component that 99% of users don't need. So if you are going to compare with a managed solution, compare with something equivalent. Take a bare managed cluster and add a single Deployment to it, it will be no more complex than ECS, while giving you much better developer ergonomics.
  - anonfordays 2y ago
    There's still Helm oddities, "annotations", CRDs, mutating web hooks, operators, etc. to comprehend before you have any idea of what the system is doing. All it takes is a random annotation to throw all your assumptions away. It's a complicated mess compared to something like a Nomad jobspec. That's one of the reasons we decided on Nomad while I was at Cloudflare.

mountainriver 2y ago

This just feels like a myth to me at this point. Kubernetes isn’t hard, the clouds have made is so simple now that it’s in no way more difficult than ECS and is way more flexible

davewritescode 2y ago
I’m not saying I agree with the comment above you but Kubernetes upgrades and keeping all your addons/vpc stuff up to date can be a never ending slog of one-way upgrades that, when they go wrong, can cause big issues.
- organsnyder 2y ago
  Those are all issues that should be solved by the managed provider. It's been a while since I spun up a k8s instance on AWS, Azure, or the like, but when I did I was astounded at how many implementation decisions and toil I had to do myself. Hosted k8s should be plug-and-play unless you have a very specialized use-case.
  - adammarples 2y ago
    Yeah if you pay someone to manage something for you, it's not hard. That's because you're not doing it. Like air travel and taxes, it's easy.
    - organsnyder 2y ago
      If you're not paying someone to manage this for you, either you're a hobbyist (perhaps masquerading as a professional) or you have the scale or special use-case that makes you outside 95% of use-cases. Last I checked, managed k8s clusters weren't much more expensive than the compute they ran on.
anonfordays 2y ago
It is by no means "a myth". There's still Helm oddities, "annotations", CRDs, mutating web hooks, operators, etc. to comprehend before you have any idea of what the system is doing. All it takes is a random annotation to throw all your assumptions away. It's a complicated mess compared to something like a Nomad jobspec. That's one of the reasons we decided on Nomad while I was at Cloudflare.