6 ms·

I was hoping to migrate to Fly.io and during my testing I found that simple deploys would drop connections for a few seconds during a deploy switch over. Try a

I was hoping to migrate to Fly.io and during my testing I found that simple deploys would drop connections for a few seconds during a deploy switch over. Try a `watch -n 2 curl <serviceipv4>` during a deploy to see for yourself (try any one of the the strategies documented including blue-green). I wonder how many people know this? When I tested it I was hoping for at worst early termination of old connections with no dropped new connections and at best I expected them to gracefully wait for old connections to finish. But nope, just a full downtime switch over every time. But then when you think about the network topology described in their blog posts, you realize theres no way it could've been done correctly to begin with. It's very rare for me to comment negatively on a service but that fact that this was the case paired with the way support acted like we were crazy when we sent video evidence of it definitely irked me for infrastructure company standards. Wouldn't recommend it outside of toy applications now. > It feels like it's compelling to those scared of or ignorant of Kubernetes I've written pretty large deployment systems for kubernetes. This isn't it. Theres a real space for heroku-like deploys done properly and no one is really doing it well (or at least without ridiculously thin or expensive compute resources)

asaddhamani 3y ago
Yeah I had a similar experience where I got builds frozen for a couple days, such that I was not able to release any updates. When I emailed their support, I got an auto-response asking me to post in the forum. Pretty much all hosts are expected to offer a ticket system even for their unmanaged services if its a problem on their side. I just moved over all my stuff to Render.com, it's more expensive, but its been reliable so far.
- loloquwowndueo 3y ago
  The first (pinned) post in the fly.io forum explains it: https://community.fly.io/t/fly-io-support-community-vs-email-read-this-first/9962 https://community.fly.io/t/fly-io-support-community-vs-email...
  - malfist 3y ago
    That forum post just says what OP said, that they will ignore all tickets from unnmanaged customers. Which is a pretty shitty thing to do to your customers.
    - yencabulator 3y ago
      The cheapest plan that gets email support is nothing more than a commitment to spend a minimum of $29/mo on their services. That is, if you spend >=$29/mo, it costs nothing extra. Not what I'd call "managed".
sofixa 3y ago
> I've written pretty large deployment systems for kubernetes. This isn't it. Theres a real space for heroku-like deploys done properly and no one is really doing it well (or at least without ridiculously thin or expensive compute resources) Have you tried Google Cloud Run(based on KNative) I've never used it in production, but on paper seems to fit the bill.
- parhamn 3y ago
  Yeah we're mostly hosted there now. The cpu/virtualization feels slow but I haven't had time to confirm (we had to offload super small ffmepg operations). It's in a weird place between heroku and lambda. If your container has a bad startup time like one of our python services, autoscaling can't be used as latency becomes a pain. Its also common deploy services on there that need things like health checks (unlike functions which you assume are alive), this assumes at least 1 instance of sustained use as well, assuming you do minute health checks. Their domain mapping service is also really really bad and can take hours to issue a cert for a domain so you have to be very careful about putting a lb in front of it for hostname migrations. I don't care right now but the fact that we're paying 5x in compute is starting to bother me a bit. A 8core 16gb 'node' is ~$500/month ($100 on DO) assuming you don't scale to zero (which you probably wont). Plus I'm pretty sure the 8 cores reported isn't a meaty 8 cores. But its been pretty stable and nice to use otherwise!
  - jetbalsa 3y ago
    A 6c / 12t Dedicated Server with 32GB of ram is 65$ a month with OVH I do get that it is a bare server, but if you deploy even just bare containers to it, you would be saving a good bit of money and get better performance from it.
    - doctorpangloss 3y ago
      Another interpretation is the so-called dedicated servers are too good to be true.
      - 3y ago
rollcat 3y ago
> Try a `watch -n 2 curl <serviceipv4>` during a deploy You need blackbox HTTP monitoring right now, don't ever wait for your customer to tell you that your service is down. I use Prometheus (&Grafana), but you can also get a hosted service like Pingdom or whatever.

asaddhamani 3y ago

Yeah I had a similar experience where I got builds frozen for a couple days, such that I was not able to release any updates. When I emailed their support, I got an auto-response asking me to post in the forum. Pretty much all hosts are expected to offer a ticket system even for their unmanaged services if its a problem on their side. I just moved over all my stuff to Render.com, it's more expensive, but its been reliable so far.

loloquwowndueo 3y ago
The first (pinned) post in the fly.io forum explains it: https://community.fly.io/t/fly-io-support-community-vs-email-read-this-first/9962 https://community.fly.io/t/fly-io-support-community-vs-email...
- malfist 3y ago
  That forum post just says what OP said, that they will ignore all tickets from unnmanaged customers. Which is a pretty shitty thing to do to your customers.
  - yencabulator 3y ago
    The cheapest plan that gets email support is nothing more than a commitment to spend a minimum of $29/mo on their services. That is, if you spend >=$29/mo, it costs nothing extra. Not what I'd call "managed".

sofixa 3y ago

> I've written pretty large deployment systems for kubernetes. This isn't it. Theres a real space for heroku-like deploys done properly and no one is really doing it well (or at least without ridiculously thin or expensive compute resources) Have you tried Google Cloud Run(based on KNative) I've never used it in production, but on paper seems to fit the bill.

parhamn 3y ago
Yeah we're mostly hosted there now. The cpu/virtualization feels slow but I haven't had time to confirm (we had to offload super small ffmepg operations). It's in a weird place between heroku and lambda. If your container has a bad startup time like one of our python services, autoscaling can't be used as latency becomes a pain. Its also common deploy services on there that need things like health checks (unlike functions which you assume are alive), this assumes at least 1 instance of sustained use as well, assuming you do minute health checks. Their domain mapping service is also really really bad and can take hours to issue a cert for a domain so you have to be very careful about putting a lb in front of it for hostname migrations. I don't care right now but the fact that we're paying 5x in compute is starting to bother me a bit. A 8core 16gb 'node' is ~$500/month ($100 on DO) assuming you don't scale to zero (which you probably wont). Plus I'm pretty sure the 8 cores reported isn't a meaty 8 cores. But its been pretty stable and nice to use otherwise!
- jetbalsa 3y ago
  A 6c / 12t Dedicated Server with 32GB of ram is 65$ a month with OVH I do get that it is a bare server, but if you deploy even just bare containers to it, you would be saving a good bit of money and get better performance from it.
  - doctorpangloss 3y ago
    Another interpretation is the so-called dedicated servers are too good to be true.
    - 3y ago

rollcat 3y ago

> Try a `watch -n 2 curl <serviceipv4>` during a deploy You need blackbox HTTP monitoring right now, don't ever wait for your customer to tell you that your service is down. I use Prometheus (&Grafana), but you can also get a hosted service like Pingdom or whatever.