5 ms·

What stops me from using such platforms is the risk that one day for any reason my account can be suspended and I will have to migrate my apps and data. Do you

What stops me from using such platforms is the risk that one day for any reason my account can be suspended and I will have to migrate my apps and data. Do you have a strategy for that situation? Your old Ansible branch hopefully is still there and compatible with your recent production code changes. And your sqlite DB is replicated to an external storage and your data is reachable even if you have lost control over “your” PaaS account.

biorach 4y ago
> What stops me from using such platforms is the risk that one day for any reason my account can be suspended and I will have to migrate my apps and data. You have found a hosting provider where this is not a risk?
- Noughmad 4y ago
  If you're on AWS or GCP or Azure, and they terminate your account, and you use only the "standard" services (raw instances, k8s, database, redis, queues, email, etc.) it's generally relatively easy to migrate to one of the other two. Fly is different enough that moving to or from it takes much more time and effort.
  - bilinguliar 4y ago
    Yes, this is my approach, as long as you stick to standard interfaces, you can migrate rather quickly. Your level of abstraction may vary. I stick to VMs after realising how much overhead I had with the cloud as a one-person shop. Teams can interface with k8s which is also standard nowadays, taking you can spawn a cluster fast.
  - nicoburns 4y ago
    > Fly is different enough that moving to or from it takes much more time and effort. It is? Fly seems to be only docker containers. You can't get much more standard than that these days!
  - biorach 4y ago
    > Fly is different enough that moving to or from it takes much more time and effort. Have you actually used fly? It's pretty vanilla. Having migrated to and from fly I don't think your assessment is accurate. It uses Docker files or Heroku style procfiles - not particularly exotic. Your apps live in a private network, which is managed for you.
- bilinguliar 4y ago
  With the standard tools you have a whole spectrum of options: a) Cloud providers; b) Hosting providers; c) Collocation; d) On-prem;
  - jsty 4y ago
    All of which have a counter-party who can suspend your service if they believe you're abusing the service: A&B your cloud / hosting provider, C&D the transit provider - all will have language in their contracts allowing for suspension or termination if they suspect abuse. The only things that help protect you against this are (1) having named contacts on your account who will vouch internally at a supplier; (2) negotiating these clauses in contracts to prevent instant suspension in all but the most serious cases; and (3) utilising multiple suppliers.
    - bilinguliar 4y ago
      This is also about the number of suppliers. Clouds - a dozen. Hosting providers, collocation - thousands. I agree that in all cases, you depend on someone, but you can lower the risk to the point where other dangers that threaten your business become more probable.
ericpauley 4y ago
One nice thing fly has going for it is that you’re just deploying standard OCI containers, so there’s pretty minimal lock-in if you need to get off in a hurry. Due to some edge cases I recently transitioned a workload from Fly to AWS in 2 hours or so.

biorach 4y ago

> What stops me from using such platforms is the risk that one day for any reason my account can be suspended and I will have to migrate my apps and data. You have found a hosting provider where this is not a risk?

Noughmad 4y ago
If you're on AWS or GCP or Azure, and they terminate your account, and you use only the "standard" services (raw instances, k8s, database, redis, queues, email, etc.) it's generally relatively easy to migrate to one of the other two. Fly is different enough that moving to or from it takes much more time and effort.
- bilinguliar 4y ago
  Yes, this is my approach, as long as you stick to standard interfaces, you can migrate rather quickly. Your level of abstraction may vary. I stick to VMs after realising how much overhead I had with the cloud as a one-person shop. Teams can interface with k8s which is also standard nowadays, taking you can spawn a cluster fast.
- nicoburns 4y ago
  > Fly is different enough that moving to or from it takes much more time and effort. It is? Fly seems to be only docker containers. You can't get much more standard than that these days!
- biorach 4y ago
  > Fly is different enough that moving to or from it takes much more time and effort. Have you actually used fly? It's pretty vanilla. Having migrated to and from fly I don't think your assessment is accurate. It uses Docker files or Heroku style procfiles - not particularly exotic. Your apps live in a private network, which is managed for you.
bilinguliar 4y ago
With the standard tools you have a whole spectrum of options: a) Cloud providers; b) Hosting providers; c) Collocation; d) On-prem;
- jsty 4y ago
  All of which have a counter-party who can suspend your service if they believe you're abusing the service: A&B your cloud / hosting provider, C&D the transit provider - all will have language in their contracts allowing for suspension or termination if they suspect abuse. The only things that help protect you against this are (1) having named contacts on your account who will vouch internally at a supplier; (2) negotiating these clauses in contracts to prevent instant suspension in all but the most serious cases; and (3) utilising multiple suppliers.
  - bilinguliar 4y ago
    This is also about the number of suppliers. Clouds - a dozen. Hosting providers, collocation - thousands. I agree that in all cases, you depend on someone, but you can lower the risk to the point where other dangers that threaten your business become more probable.

ericpauley 4y ago

One nice thing fly has going for it is that you’re just deploying standard OCI containers, so there’s pretty minimal lock-in if you need to get off in a hurry. Due to some edge cases I recently transitioned a workload from Fly to AWS in 2 hours or so.