This breaks my mental model. It’s so convenient when things revolve around the apps. But the notion of a machine breaks that powerful simplicity. Why do we have to think about machines when everything most business care about is apps? Instance resources, regions, number of instances. That’s almost all we need to be happy.
As a side note, this is one of the main reasons we are migrating from Azure to Fly. The incremental complexities added to Azure through the years made working with it unbearable. The amount of configuration and lock-in is through the roof. It was a very good day when we deleted convoluted Azure resources after the migration to Fly.
Now it seems that Fly is going the same route trying to make things more complex than it’s needed to be for the end-users. I always thought that people love Fly because it has a simple mental model, but maybe I was mistaken. Maybe people love playing with machines… If so, then what makes Fly different from offerings like Digital Ocean? Those relicts are painful to manage in this day and time, and this is why we choose Fly (Apps v1) in the first place. Because we do not want machines! Those who want them use VPS or self-host.
I can demonstrate analogy from the world of programming. When a program is written in functional style and consists of mostly stateless functions without side effects, such a program is quite easy to develop, manage, scale and debug. However, the same program can be written in a different way. For instance, it can have tons of shared state. The presence of that state makes the progress of development slow, code changes become brittle, the algorithms written in that style are prone to errors. Bug fixes are hard because every fix tends to have a side effect that breaks another seemingly unrelated thing. The excessive presence of state puts a toll on multi-threading, etc.
Now, how does it all relate to Fly? In my opinion, machine is the ultimate form of state, and any state is the ultimate form of pain, which makes machine = pain analogy quite vivid. Cloning a machine for scaling means cloning a state. And we know that state is pain, so our pain multiplies. Scaling becomes brittle, complex and dangerous. It becomes something I would never ever touch again (hello Azure).
In contrast, Fly Apps v1 have no observable state. Dockerfile defines all the state the app should have (there is a bit of additional state for Fly scaling parameters, DNS, volumes and that is). This simple fact gives a monster power to the whole paradigm, because everything I have to worry about is just Dockerfile. I can put it to a Git repo and upgrade/rollback as I see fit. Every change is self-documented in the history of Dockerfile. The absence of pesky state means productive work and happy life.