It seems to me take that because a group of machines serving one same program share the same IP address regardless of their actual regions, Fly decided to name that group as “app”, and provide “volume” to attach to that app. On high-level, this preserves the mental model of how Docker works, and I like it. However, when you uncover the abstraction, then the analogy breaks down:
- In Docker, the app runs inside a container, which runs inside a VM, which runs inside a physical machine. In this scenario, thinking that your volume is always there storing data for your program is reasonable, because it only runs in one physical machine.
- But in Fly, what the app actually do is to control the VMs inside different physical machines, which will then control the containers, which will then run the program. In this scenario, you cannot think that your volume is always available to your program, because it runs on different physical machines.
I guess this is the difference in how we view what app is in the development phase and deployment phase.
I have some further questions:
- Why can’t different VMs hosted under one physical machine attach to the same volume? In general, why doesn’t Fly auto sync the volumes in different machines of a same app? Is it because it’s not optimal in term of cost?
- Can a machine (which is a VM) belong to different apps? Because if it’s only managed by one app (via fly.toml), then I don’t see the role of container in Fly. The role of machine in Fly seems to be the same with the role of container then, because all containers inside a machine should run the same image. We mostly discuss about machine and not container.
Also, can you share the downtime data? When does downtime frequently happen, especially in a particular region?