3 ms·

Digital Ocean are going to be dead last in the transition to ARM.

diggan 2y ago
Are GitHub and Digital Ocean competitors nowadays? Or you're just referring to anything that offers "run code on someone elses computer, somehow"?
- drcongo 2y ago
  Sorry, my post was rather lacking context wasn't it. What I meant was that the vast majority of my work is now done end to end on ARM CPUs and even the bits that haven't been, like GitHub runners, are starting to make ARM an option. Customers have been asking Digital Ocean for ARM servers for years [0], and every time they do, DO just tell you to upvote the suggestion on their feedback site, but you can't, because they closed it [1]. [0] https://www.digitalocean.com/community/questions/feature-request-any-chance-of-arm-instances?comment=119804 https://www.digitalocean.com/community/questions/feature-req... [1] https://ideas.digitalocean.com/core-compute-platform/p/arm-based-droplets https://ideas.digitalocean.com/core-compute-platform/p/arm-b... edit for additional context: An ARM server on Hetzner costs roughly 1/10th that of an x86 one on DO with the same core count and memory, and in my tests out-performs it too.
bdcravens 2y ago
AWS still only supports X64 on Fargate Spot instances (they do support ARM on the non-spot instances)
- trueismywork 2y ago
  T4g is available as spot
  - endgame 2y ago
    GP's talking about Fargate, which is their "serverless" container runtime offering.
- booleanbetrayal 2y ago
  We waited on this issue for 2 years before migrating off EKS Fargate to Managed Node Groups due to this very reason. In the end, it turned out to be much better of an environment anyway, because you didn't have to deal with Kubernetes oddities (like lack of Daemonsets) requiring anti-patterns and ultimately resulted in cheaper pricing due to better bin-packing. If you're doing K8s orchestration with Fargate, I highly recommend the switch.
  - suryao 2y ago
    (founder of WarpBuild - we offer hosted GHA runners) This is a common issue. A common pain point we see with users approaching some scale with self-hosting on k8s is that the k8s node autoscaling can become inefficient because of spiky loads. We have a lot of users migrating off self-hosted setups using `actions-runner-controller` to ours because of this. Essentially, not having to deal with bin-packing is more efficient and concurrency, uptime guarantees are nice.
  - watermelon0 2y ago
    To be honest, lack of daemonsets makes sense, because you don't have hosts per se. Each pod is running on it's own Linux VM. Daemonsets are generally intended if you have multi-pod nodes; otherwise, you can just use sidecars.
    - booleanbetrayal 2y ago
      Sidecars are definitely a workaround but are hard to manage lifecycle for in conjunction with the primary container. This is now easier to do in 1.29+ with Sidecars officially supported via restartPolicy, but it was a colossal hassle prior to the advent of that. Also, we had noticed (maybe this has changed) that often logging frameworks were distro'd as DaemonSets (Helm, etc) and you'd have to shoe-horn the sidecar approach a bit.

Are GitHub and Digital Ocean competitors nowadays? Or you're just referring to anything that offers "run code on someone elses computer, somehow"?

drcongo 2y ago
Sorry, my post was rather lacking context wasn't it. What I meant was that the vast majority of my work is now done end to end on ARM CPUs and even the bits that haven't been, like GitHub runners, are starting to make ARM an option. Customers have been asking Digital Ocean for ARM servers for years [0], and every time they do, DO just tell you to upvote the suggestion on their feedback site, but you can't, because they closed it [1]. [0] https://www.digitalocean.com/community/questions/feature-request-any-chance-of-arm-instances?comment=119804 https://www.digitalocean.com/community/questions/feature-req... [1] https://ideas.digitalocean.com/core-compute-platform/p/arm-based-droplets https://ideas.digitalocean.com/core-compute-platform/p/arm-b... edit for additional context: An ARM server on Hetzner costs roughly 1/10th that of an x86 one on DO with the same core count and memory, and in my tests out-performs it too.

bdcravens 2y ago

AWS still only supports X64 on Fargate Spot instances (they do support ARM on the non-spot instances)

trueismywork 2y ago
T4g is available as spot
- endgame 2y ago
  GP's talking about Fargate, which is their "serverless" container runtime offering.
booleanbetrayal 2y ago
We waited on this issue for 2 years before migrating off EKS Fargate to Managed Node Groups due to this very reason. In the end, it turned out to be much better of an environment anyway, because you didn't have to deal with Kubernetes oddities (like lack of Daemonsets) requiring anti-patterns and ultimately resulted in cheaper pricing due to better bin-packing. If you're doing K8s orchestration with Fargate, I highly recommend the switch.
- suryao 2y ago
  (founder of WarpBuild - we offer hosted GHA runners) This is a common issue. A common pain point we see with users approaching some scale with self-hosting on k8s is that the k8s node autoscaling can become inefficient because of spiky loads. We have a lot of users migrating off self-hosted setups using `actions-runner-controller` to ours because of this. Essentially, not having to deal with bin-packing is more efficient and concurrency, uptime guarantees are nice.
- watermelon0 2y ago
  To be honest, lack of daemonsets makes sense, because you don't have hosts per se. Each pod is running on it's own Linux VM. Daemonsets are generally intended if you have multi-pod nodes; otherwise, you can just use sidecars.
  - booleanbetrayal 2y ago
    Sidecars are definitely a workaround but are hard to manage lifecycle for in conjunction with the primary container. This is now easier to do in 1.29+ with Sidecars officially supported via restartPolicy, but it was a colossal hassle prior to the advent of that. Also, we had noticed (maybe this has changed) that often logging frameworks were distro'd as DaemonSets (Helm, etc) and you'd have to shoe-horn the sidecar approach a bit.