Live data from Hacker News

Reliability: It’s not great

community.fly.io

171–180 of 476 posts

Re: Reliability: It’s not great

#171

Earlier quoted context omitted.

> What I truly want and probably lots of other people too is Flyctl for AWS. The same simplicity to run as fly, but give me something cheap in Virginia or the Dalles. Google Cloud. It is painfully easy to spin up managed postgres, super easy to deploy gcp cloud functions or gcp cloud run. It isn't expensive either and just works.

If someone is not already using the holy trinity (AWS/Azure/GCP) there is probably a reason.

Egress pricing, for one.

fly.io charges an outrageous 2 cents/GB. Google is over 4x that.

At fly.io rates, 1Gbps average over a month is $6400/mo. Google is tiered and you’re looking at over $10k/mo.

For comparison, a cheap managed switch that can handle 1Gbps costs about $100, maybe a bit more if you want a nice one. A nice router is more. You can rent an entire rack, including power, cooling, and an unmetered 1Gbps for $300-$1k/mo (with maybe some wiggle room on both ends). You can buy a pretty nice server, amortize the price over a week or two, and still come out ahead.

You certainly get considerable value from a major cloud provider, and a lot of their other services are reasonably priced, but, depending on your workload, the egress prices and the corresponding Hotel California factor may make using a major cloud provider a poor proposition.

Re: Reliability: It’s not great

#172
post #5

I'm not a user of Fly.io. I can't help but notice how remarkable the effect of open communication on potential end users like me. I remember reading about their reliability problems on HN some time ago. That biased my view of the company. After reading this, the open communication and transparency restored my trust in them, and would make them again a potential candidate for future projects. Because now I know that t…

This is probably therapy, but your message and fly.io's post resonates a lot with what I'm going through. I took a product owner role about 6 months ago, my first, with a company that has turned out to be just a mired mess, and a product universally hated both internally and externally. Long story short, it's completely over-engineered by a bunch of intellectual engineers with no focus, no discipline, and no oversigh…

Your job sure does sound depressing, and it's not one I would succeed at, but if you can power through and turn this product around that's a hell of an accomplishment you'll have to be proud of.

I'm curious what you'd like to do next. You could probably have a great career doing these sorts of turnarounds repeatedly across companies, maybe even as a consultant, but would you want to?

Re: Reliability: It’s not great

#173
post #154

I'm a bit sour reading this. I've always liked fly and particularly the engineering blog, so much so that a couple of months ago I decided to apply for an infra position, to work on some of these very topics. Sadly after 4~5 rounds of interviews (including a workday) they just ghosted me.

> Don't feel too bad nor take it personal. They probably have a lot of applicants, and are looking to grow their team by hiring someone with very specific skills.

> I also applied a few months ago while I was in the middle of my job search. For one, I couldn’t really answer their "favorite syscall question" because I’ve never dealt with syscalls :) so maybe I just wasn't a good fit.

Surely, everyone's favourite syscall is exit()

Re: Reliability: It’s not great

#174
post #58

This reads like a mea culpa from an indie hacker, but Fly.io had 5+ years and raised $40M to get these basic fundamentals right. And we get promises of a new status page.

Big companies fail spectacularly as well, so it is refreshing to read a indie hacker-style mea culpa than a pile of nonsense PR one would expect from a company that raised $40M.

Honesty pays off in the long run, but it's something businesses quickly forget past a certain stage.

Re: Reliability: It’s not great

#175
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/

Yes, we are partnering with many companies like Hasura and Replit to help with managed Postgres. Since Neon scales to 0 and also autoscales to your workload it very economical for the long tail of low usage customers.

Re: Reliability: It’s not great

#177
post #3

For django, they should really contribute to 2 scoops django cookie cutter program, so that you can get an out of the box django instance that can just deploy to Fly.io.

May be wrong, but they seem to be very focused on interesting stacks like Elixir and RoR while building on Go/Rust. The corollary being neglect of the bread/butter stacks with high market share, like Python and Java/JavaScript. Don't think I've seen a blog post discussing those three beyond a passing mention? Not the end of the world, but mildly disappointing. At least they are all in with Postgres and Linux, a great…

I don't disagree with you, but they tweeted

> We’ll readily admit our docs still have a Django-shaped hole in them.

https://twitter.com/flydotio/status/1578039196618575874?t=nu...

Re: Reliability: It’s not great

#178

At first I was all like “Ha ha, losers can’t scale” And then I was “Huh, these technical challenges are actually pretty difficult” And then I was all “crap, these are a bunch of technologies I was about to add to our stack” Thanks heaps fly.io people; having the humility to honestly talk about the challenges and failures massively helps people such as myself as we navigate new unfamiliar technologies. If more compani…

The tech in their stack is still pretty good. Unless you’re supporting tens of thousands of customers and trying to make the promises that fly makes today. Look at the fly engineer replies in this thread.

Also they basically only use OSS versions, they could go give Hashicorp some money to solve their Vault problems. They could probably partner with SecondQuadrant for PG as two examples. That might not make sense for their business though.

Hard problems are hard no matter the choice.

Re: Reliability: It’s not great

#179

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…

We are asking to HashiCorp products to do things they were not designed to do, in configurations that they don't expect to be deployed in. Take a step back, and the idea of a single global namespace bound up with Raft consistency for a fleet deployed in dozens of regions, providing near-real-time state propagation, is just not at all reasonable. Our state propagation needs are much closer to those of a routing protoc…

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!

Re: Reliability: It’s not great

#180
post #118
post #95

Earlier quoted context omitted.

I'm not sure why the cynicism around their candor. Do you think it's not genuine just because it was posted by a company employee? Your post implies corporate messaging is bad. And anything posted by a company—or at least I don't know where you draw the line—can be considered corporate messaging. Am I just reading too much into your phrasing?

It's strategic messaging. It can't be genuine, because of what it is. The benefit they get is publicity and damage control, and as you can tell by the many responses here, it buys them time because many developers are willing to give them the benefit of the doubt. Companies that engage in this kind of candor are careful not to disclose those things that would really hurt their business. Those things are still kept se…

Sorry, what? Do you expect that no company can think about what to write before they post it, or that any post about anything internal must cover all internal issues? Posts must be either all roses or a no-thought laundry list of everything bad?
Post reply on HN