Live data from Hacker News

Reliability: It’s not great

community.fly.io

261–270 of 476 posts

Re: Reliability: It’s not great

#261

Earlier quoted context omitted.

How do Coolify and Dokku compare? I've been aware of Dokku for a long time already, however I've never been confident enough to rely on these interfaces to deploy applications, specially because of their business model to keep things going. I'll have to try them both eventually though, I absolutely hate PaaS honestly, the prices are all just too high, but the convenience is really nice when managing a multitude of se…

Dokku Maintainer here. I don't really have a business model. I do take donations from Open Collective (and Github Sponsors, which funnels to OC) and there is Dokku Pro, but those don't collect anywhere near the funds I'd need to stop my dayjob (at least now. Maybe someday?). My business model is that code releasing is something I'm pretty passionate about. Dokku isn't even originally my project (Jeff Lindsay started…

Thank you so much for your tremendous work!

Re: Reliability: It’s not great

#262
post #239

What an earnest post, and how damn refreshing it is to see such concern for users, accountability, honesty and openness (quite a contrast to another PaaS)! I moved one app successfully from heroku to fly and attempted to move a few others. These are my experiences (both good and bad): Great: - The load time on the pages is insanely faster on fly than heroku. Sometimes I thought I was on the localhost version of the a…

Did you try migrating with this guide? https://fly.io/docs/rails/getting-started/migrate-from-herok... The issues you ran into with older versions of Rails was probably because the Dockerfile that `fly launch` generated was for new versions of Rails. We switched to https://github.com/rubys/dockerfile-rails to streamline Dockerfile generation and support older versions of Rails. If you try it again and run into issues…

You bet, that guide is gold.

I encountered a few issues. One was definitely something to do with older postgres. From memory, I tried downgrading it using apt, but then other things played up and I put the project aside.

Another rails 6 app I tried to move into fly encountered this: https://community.fly.io/t/rails-app-problem-with-node-modul...

I followed Sam's suggestions to regenerate the Dockerfile with dockerfile-rails (btw, thanks for your work on dockerfile-rails, super excited about it) and solved a couple more issues, but I again ran out of steam when new issues kept coming and coming. I'm sure when I'm more comfortable with docker these will become trivial to solve.

These were not super determined attempts by me, more playing around. I look forward to more serious attempts when I'm more capable with docker.

Re: Reliability: It’s not great

#263

Earlier quoted context omitted.

I think overall Coolify is a bit more modern. It uses some different components (e. g. Traefik vs Nginx for reverse proxying), and includes a UI in its basic package (Dokku was CLI only for a long time, now they have Dokku Pro with a Web UI). Otherwise it looks like the architecture is pretty much the same. Re: business model: both Coolify and Dokku are open source, so even if their development stops, you can continu…

Dokku maintainer here For proxying requests, Dokku currently supports: - nginx on the host (default) - traefik (via docker labels) - caddy (via docker labels) - haproxy (via docker labels) We'll also soon support nginx via docker labels, which will work around issues where Docker sometimes assigns random IP addresses (and unlock TCP/UDP proxying as well). I can't say anything else about Coolify since I haven't used i…

Wow, looks like Dokku got a lot of upgrades since last time I used it thoroughly. I'm wondering though, why support four different proxies?

About the modern part: that was my opinion based on the way I recall Dokku and Coolify, and a quick scroll through the docs of both, so I might be really wrong here! I definitely need to check out both Dokku and Coolify again sometime.

Re: Reliability: It’s not great

#264
post #159

Earlier quoted context omitted.

This is, indeed, the exciting part. As Heroku fans, we never really felt like it needed a replacement. And if it did, it seemed like Render was the natural Heroku v.next. One thing we've noticed, though, is that people do actually want Heroku but close to users. It's not exactly edge compute. In some cases, it's "Heroku in Tokyo". In others it's "Heroku, but running in all the english speaking regions". I think the t…

Just partner with Neon or other similar companies in this space. Scale-to-zero distributed databases is well understood technology. https://neon.tech/

Does Neon support triggers and subscriptions?

Re: Reliability: It’s not great

#265
post #79

Earlier quoted context omitted.

There's a wonderfully blunt saying that applies here (too): you are not in the business you think you are, you are in the business your customers think you are. If you offer data volumes, the low water mark is how EBS behaves. If you offer a really simple way to spin up Postgres databases, you are implicitly promising a fully managed experience. And $deity forbid, if you want global CRUD with read-your-own-writes sem…

In a nutshell if you offer cloud services you need to be better than the MAG clan, Digital Ocean too. And people will want it dirt cheap. It’s still hard to be a profitable web host as it always was (MAG has the advantage that none of them were web hosts at first base)

I am willing to pay a little extra for a nice dev/ops experience and simple/easy solutions that doesn't require spending days reading docs and diving into dashboards with thousands of options.

Usually this results in me jumping on new platforms and then abandoning them once they add too much complexity.

Re: Reliability: It’s not great

#266
Where does fly.io document their per-account services limits? For example, max apps, databases, etc.

I took a quick look and couldn't find them. Do they have any documented service limits?

A google search turned up [0] which does not inspire optimism.

> ...there isn’t a limit to number of apps from a billing standpoint...

[0] https://community.fly.io/t/free-tier-limits-and-quota-needs-...

Re: Reliability: It’s not great

#267

Earlier quoted context omitted.

I respect that. Can you elaborate a bit on the routing protocol thing? I assume you used WAN gossip? I love the simplicity of fly.io & wish you all the best improving Fly's reliability!

If you've ever implemented IS-IS or OSPF before, like 80% of the work is "LSP flooding", which is just the process that gets updates about available links from one end of the network to another as fast as possible without drowning the links themselves in update messages. Flooding algorithms don't build consensus, unlike Raft quorums, which intrinsically have a centralized set of authorities that keep a single source…

this doesn't paint a full picture of your options, as there's nothing that stops you from having zonal/regional consensus and then replication across regions/long-range topologies for global distribution.

to be pithy about it, going full-bore gossip protocol is like going full-bore blockchain: solves a problem, introduces a lot of much more painful problems, and would've been solved much more neatly with a little bit of centralization.

Re: Reliability: It’s not great

#268

Fundamentally I think some of the problems come down to the difference between what Fly set out to build and what the market currently want. Fly (to my understanding) at its core is about edge compute. That is where they started and what the team are most excited about developing. It's a brilliant idea, they have the skills and expertise. They are going to be successful at it. However, at the same time the market is…

Edge of what exactly? The software resides within networks they control. There is no edge in this scenario.

Re: Reliability: It’s not great

#269

Earlier quoted context omitted.

Dokku maintainer here For proxying requests, Dokku currently supports: - nginx on the host (default) - traefik (via docker labels) - caddy (via docker labels) - haproxy (via docker labels) We'll also soon support nginx via docker labels, which will work around issues where Docker sometimes assigns random IP addresses (and unlock TCP/UDP proxying as well). I can't say anything else about Coolify since I haven't used i…

Wow, looks like Dokku got a lot of upgrades since last time I used it thoroughly. I'm wondering though, why support four different proxies? About the modern part: that was my opinion based on the way I recall Dokku and Coolify, and a quick scroll through the docs of both, so I might be really wrong here! I definitely need to check out both Dokku and Coolify again sometime.

We support 4 different ones to give folks choice. Some folks want/need features that aren't available on one vs the other (traefik has a ton of features, caddy is simple to configure, nginx has a ton of documentation) so it made sense from that perspective. It was also easy to add once I had the pattern going (though the default has stayed nginx).

One of the main features of Dokku is it's extensibility. You can cut one part out and replace it with another quite easily, and proxying is an example of that. I think that flexibility allows folks to use it in more situations than one otherwise would, though at the cost of being more difficult to maintain (and harder to have cohesion between parts of the system at times).

Re: Reliability: It’s not great

#270
post #62

Earlier quoted context omitted.

The CloudFlare folks wrote a good blog post on how they are seeing their customers use Edge compute — latency is far down on the list: https://blog.cloudflare.com/cloudflare-workers-serverless-we...

The US CLOUD Act means a EU customer cannot use a US cloud provider to host PII, even if the server itself is physically in the EU, because US law will still compel the provider to yield the data to US authorities. The European Commission is trying to paper over the cracks with a fig leaf of judicial review, but it's only a matter of time until a Schrems III decision from the CJEU invalidates that polite fiction.

Assuming best practices are followed, AWS would have have to crack into multiple systems to offer up data for EU residents from AWS machines in the EU. Is there any record of them being required to do so?
Post reply on HN