Thanks for your response @wjordan I believe I understand, but what about stateless applications that don’t need to be tied to a volume though, would those be allowed to drift between servers for quick recovery?
Also, when you say “making automatic migration/recovery more challenging” for volumes, does this mean that this could technically be feasible in the future? As in something that may be possible to be tackled? Just curious (and hopeful)!
I dunno… sometimes I just feel like I see constant “goal post stretching”. When reading forums, I see the following sequence quite often:
“Looks like you’re deploying only a single machine”
Then
“Although somewhat rare for hardware failure, make sure you’re deploying multiple machines”
Then
“Although somewhat rare for a region to go down, make sure you’re deploying to multiple regions”
It’s this kind of confusion that frustrates some people (i.e. me lol). And also with the barrier of entry being so darn easy, I see a lot of new engineers frustrated with Fly because of this mismatch of simplicity to deploy and difficulty to maintain when they see verbiage like the above
lastly, for what it’s worth, basically all my Fly apps are either multi-region RAFT or stateless multi-region…my TimescaleDB Postgres cluster was in a single-region, and that is my fault
I wrote this back when it happened if it helps anyone in the future.
Appreciate your time!