Yes definitely as an operator, you want to oversubscribe hosts. What I was mentioning is that there are still small benefits when an host is not full: the CPU gains _and_, for users, the fact that they're not paying/paying less (even though the operator is still paying for the full underutilized hypervisor, but hey, that's the game)
You got everything correctly. The advantages are:
- For the end-user: not paying or paying less
- For the hypervisor owner: a sleeping instance uses no CPU, so it reduces the load on the hypervisor
Other than that, it's still possible to oversubscribe, but you're right, we need to trump the scheduler. Another cool thing is that in the worst case scenario where an hypervisor gets full and it's over capacity, sleeping instances are great candidates for eviction.
Maybe experience is not the right term; "offering" would probably be better (or "more managed experience"). Although some people are perfectly happy with what Fly offers, it's probably less accessible to some others -and they hence do not use it.
imo Fly targets more techy users than Koyeb. For example, to setup continuous deployments, you are expected to setup a Github Action (https://fly.io/docs/app-guides/continuous-deployment-with-gi...). If you know what you are doing, it's fine. We want to provide a more managed experience by embedding this kind of capabilities in the platform.
So I would say that Fly is more flexible while we are more accessible
I think that we provide a higher level experience than Fly. Regarding AWS global accelerator, I haven't tested the product, but from what I see we also provide a higher-level experience: we take as input a GitHub repo or a container image, so we can abstract away the VM layer, EC2 - we directly run "applications", not virtual machines
I completely agree with you . I would even go further: even if you can, you probably do not want to build a set of fully zonal services. As you said, there are some features that you want to provide which should affect "global" entities, like IAM or billing. For this kind of stuff, I believe that it makes sense to have some simple, globally unique components -and carefully plan around their failure scenarios