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.
Ah, I think the part that I didn't consider was that an "idle" VM is not zero CPU cost, unlike a container, so indeed from a hypervisor owner perspective you'd like other active VMs to be able to use that CPU time. But again, doesn't that presuppose oversubscription? If a node is fully reserved, it doesn't matter if all of the running VMs are idle, you're still not going to be able to schedule another job on that node, so your costs remain the same unless you oversubscribe the host and count on the fact that there will be unused capacity available most of the time (similar to AWS Flex instances).
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)
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
Experience is subjective. People seem to be fine with what Fly offers already. If the high-level experience was a requirement, nobody would be using Fly today. And enterprise customers, who need multi-region already have a solution or seek a solution based on their own cloud (AWS, Azure, GCP all have multi-region offerings)
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 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
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.