Live data from Hacker News

Reliability: It’s not great

community.fly.io

211–220 of 476 posts

Re: Reliability: It’s not great

#211

Earlier quoted context omitted.

I'm going to plug Coolify, an open source Heroku alternative (with Docker support too) that I'm using on a cheap $5 Hetzner server which is a lot cheaper than the equivalent Fly or Render etc service, and it really doesn't have much upkeep from me even if you add in the time setting up the server initially, which is like an hour, and afterwards, it Just Works™. https://coolify.io

Dokku is also nice and battle-tested: https://dokku.com/ And may I also plug Lunni, a self-hosted Docker Swarm-based PaaS I'm working on right now: https://lunni.dev/ Both work pretty well on $5 servers.

Lunni has got an interesting concept — and I can actually see some good uses for it!

Is the actual "production" workflow still pasting a Docker Compose file in? I would much rather have an automated deployment process that doesn't require human input, that way it can be scripted as part of CI/CD, etc.

Personally, I fell in love with `git push production` (naming a git remote `production`) to trigger a deploy. Ironically I didn't like this back when I first tried Heroku, but it's grown on me since. As of now, I have a custom git receive hook on my server (building a NAS from "scratch" using IaC on my home server) that triggers a redeployment using Docker Compose.

Also, you mention Swarm... what does Lunni bring with Swarm as opposed to simple Docker Compose? Does it distribute across multiple systems?

Re: Reliability: It’s not great

#212

Earlier quoted context omitted.

I'm going to plug Coolify, an open source Heroku alternative (with Docker support too) that I'm using on a cheap $5 Hetzner server which is a lot cheaper than the equivalent Fly or Render etc service, and it really doesn't have much upkeep from me even if you add in the time setting up the server initially, which is like an hour, and afterwards, it Just Works™. https://coolify.io

Dokku is also nice and battle-tested: https://dokku.com/ And may I also plug Lunni, a self-hosted Docker Swarm-based PaaS I'm working on right now: https://lunni.dev/ Both work pretty well on $5 servers.

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 services simultaneously.

Re: Reliability: It’s not great

#213

Earlier quoted context omitted.

I read your review, and had a question so I thought I'd follow up here. You mentioned render.com as a competitor - does render host its own infrastructure or do they act as a go-between between their users and AWS/GCP/whatever?

They act as a go-between in that they ultimately host on AWS/GCP. They host their own infrastructure in that they appear to run Kubernetes and have built out their own deployment and service fabric, so they're just using the underlying machines as dumb compute, they're not, eg, building on RDS. In March 2021, someone asked a question about carbon emissions of their data centres. They said they hosted on both GCP and…

Once you've built a system that works well in production (and scales elastically, too, it seems), it is really difficult to switch out the underlying infrastructure. Makes sense about walking it back.

The problem with running your own servers in data centers as a startup is that elasticity is genuinely a difficult problem to solve if you don't have a large budget for unused compute, storage, and so on. As we are seeing in Fly.io's case.

Ultimately, my bet is that both startups end up as Heroku-like acquisitions for some large cloud company or another. I think that render will sell for a lot more because the value it provides is agnostic to the underlying cloud infrastructure.

Re: Reliability: It’s not great

#214
post #193

Earlier quoted context omitted.

> who doesn't want instantaneous global writes I want to gently note since I see a lot of misunderstanding around Spanner and global writes: Global writes need at least one round trip to each data center, and so they're still subject to the speed of light.

Like most things, it's more complex than that, and as a result it can be either faster or slower than 'median(RTT to each DC in quorum)'. It's a delicate balance based on the locations that rows are being read and written. In the case where a row being repeatedly written from only one location and not being read from different location, the writes can be significantly faster than would be naively expected.

> Like most things, it's more complex than that,

Sure, no doubt. My point wasn't really about the particularities. It was around the mistaken idea that I see sometimes where people believe that TrueTime allows for synchronized global writes without any need for consensus.

Re: Reliability: It’s not great

#215
post #88

Earlier quoted context omitted.

I know I've personally spent a large portion of my time updating systems to be compliant in the last few years, in North American companies.

might well have been yak shaving. If a company is under US jurisdiction it simply cannot comply to EU data protection.

[deleted]

Re: Reliability: It’s not great

#216

Almost half of the issues are caused by their use of HashiCorp products. As someone that has started tons of Consul clusters, analyzed tons of Terraform states, developed providers and wrote a HCL parser, I must say this: HashiCorp built a brand of consistent design & docs, security, strict configuration, distributed-algos-made-approachable... but at its core, it's a very fragile ecosystem. The only benefit of HashiC…

[deleted]

Re: Reliability: It’s not great

#217

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…

I coincidentally tweeted the exact same thing earlier today. I selfishly hope Fly put all their focus toward becoming Heroku 2.0. I’m sure some people care about all the edge latency stuff but I don’t know many of them.

Yeah, I guess devs first will need to learn better SQL before it will start to matter.

Re: Reliability: It’s not great

#218
post #159

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…

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…

I shared your post with Render's engineering team and it got a lot of love because we know the struggle and can truly empathize because of our own Heroku-accelerated growth. What Fly and Render are doing is hard, but someone needs to do it.

If the market is big enough to support AWS/GCP/Azure as $N00B businesses each, it’s not a leap to imagine a future where both Fly and Render are incredibly successful, loved, and independent businesses spanning decades. Let's keep at it.

Re: Reliability: It’s not great

#219
i also wanted a good cli for aws, and built one:

https://github.com/nathants/libaws

companies like fly are fantastic.

they provide a good service, and they put market pressure on aws.

a free tier isn’t important anymore. with usage based pricing for lambda/dynamo/s3, an app with usage approaching zero has no cost.

Re: Reliability: It’s not great

#220
post #127

Earlier quoted context omitted.

What are the limitations to heroku that people are going to Fly for? Maybe there's a standard article that would be useful to read about it?

It's more about Heroku dropping free and low-cost plans, which is them demonstrating that they don't currently care about three low end of the market, more than any specfic feature.

Also the absolute disaster with security they had just before dropping free tiers, and the awful response which took months to even acknowledge some kinds of data (such as pipeline keys) where affected. [0]

[0]: https://github.blog/2022-04-15-security-alert-stolen-oauth-u...

Post reply on HN