Live data from Hacker News

Reliability: It’s not great

community.fly.io

281–290 of 476 posts

Re: Reliability: It’s not great

#281

Earlier quoted context omitted.

Nice write up! I wish I shared your enthusiasm for where Heroku could go but I have a few friends at Salesforce I've asked about how they see Heroku internally and it really doesn't seem like it is going to get much love. Hope to be wrong though.

Thanks! I have talked with two Heroku folks who say (to me, a paying customer of Heroku Enterprise) that Heroku is absolutely in active development. I let them know they need to demonstrate that to me. They have a roadmap [1], but it seems to have barely anything moving forward, including some really important concepts like http/2 support. [1] https://github.com/orgs/heroku/projects/130

Well, they’re owned by bigcorp now right? Everything probably takes 10 times as long for no good reason.

Re: Reliability: It’s not great

#282
post #276
post #264

Earlier quoted context omitted.

Does Neon support triggers and subscriptions?

yes to triggers - it's full postgres. logical replication is not exposed just yet, but soon

Subscriptions should still work with scale to 0. NOTIFY/LISTEN doesn't: https://neon.tech/docs/reference/compatibility.

We will have an option to not scale all the way to 0 to support this scenario.

Re: Reliability: It’s not great

#283
post #211

Earlier quoted context omitted.

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. Ironica…

I'll start with the Swarm since it's a major point actually: Docker's Swarm mode is comparable to Kubernetes or Nomad: you can launch a cluster of servers and run your application there. Unlike Kubernetes or Nomad though, it uses mostly the same concepts Docker Compose does, to the point that your development docker-compose.yml file will likely just work there (with some minimal tweaks). I love this website that talk…

You can set up a git hook on repositories that listens for the completion of the docker_build task and then redeploys the app while pulling new images?

Re: Reliability: It’s not great

#284

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.

Personally I use portainer for basically the same thing. My only real requirement was that I could easily copy-paste in docker-compose files and have it just work.

I use caddy as the proxy, since I found the traefik configuration absolutely incomprehensible. Now I use only 2 labels to proxy instead of 15.

Re: Reliability: It’s not great

#285
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…

> if you want global CRUD with read-your-own-writes semantics, the yardstick people measure you against is Google's Spanner. I’m trying to build more of an intuition around distributed systems. I’ve read DDIA and worked professionally on some very large systems, but I’m wondering what resources are good for getting more on the pulse of what the latest best practices and cutting edge technologies are. Your comment sou…

Not sure it's what you are looking for, but how Spanner mitigated CAP to delivery a relational DB at scale is a really interesting read[1]

[1] https://research.google/pubs/pub45855/

Re: Reliability: It’s not great

#286
I have two extremely tiny sites (like, "handful of users/1 user" sites) on Fly. I have had multiple incidents despite me not even touching them.

The thing that worries me about these incidents is they haven't been, like, full service outages. A small subset of users talking about issues in forums. This makes me just feel like Fly has an immense amount of issues.

At least if like 50% of fly goes down then it feels like a config fat finger. When it's a bunch of tiny issues now all my ops debugging has to start with going to the fly forums (and it's _always been issues on fly's side_).

The price is "right" (though like with all PaaS the gaslighting about running multiple processes in one container makes me feel bad about the state of cloud computing). And I really like the CLI stuff mostly! But I extremely don't care about edge computing so for me fly is just heroku and I would love to feel more confident on that end.

(EDIT: the nice thing is I get email support with a bit of cash. This is a thing that will go away when they get bigger but it's here while things are still breaking often)

Re: Reliability: It’s not great

#289
This is a great blog and have so many insights for an SRE or devops person. But this goes to show you how difficult it is self host stuff at scale.

I used to work for a company that built deployment platforms for law firms. All our deployments where on prem and we had the same complexity with kubernetes. We had similar setup with vault and stolon for HA PG. More moving parts you have in infra, more permutations and combinations of failure modes you have.

What these guys are building is something I have seen in many orgs trying to do it internally and fail. PaaS is a hard problem if you want to solve it "reliabily"

Re: Reliability: It’s not great

#290

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…

> generous free level of service,

Can't you make the argument that Heroku got out of this market on purpose? I know they were bought out by "ye old corporate greedy meanie overlord" or whatever but... I'm sure there is data that showed it made sense from a "make money business" perspective to not be in that market.

Post reply on HN