Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reliability: It’s not great

community.fly.io

Post reply on HN
Print view View original

21–30 of 476 posts

Re: Reliability: It’s not great

#21

Post by ilaksh »

jjtheblunt wrote: post #14
mixmastamyk wrote: post #11

Earlier quoted context omitted.

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 thought the only thing their tech stack was all in on was docker images being rewritten to run on firecracker as a substrate. is it not agnostic about things like Elixir etc, at the tech level, though they've got super nice documentation for those tools you mentioned?

What's necessary to change for them to run on Firecracker?

Re: Reliability: It’s not great

#22

Post by mbesto »

yamrzou wrote: 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…

Me too.

However, this is a double edge sword. Their key value proposition is scale / speed which makes it concerning that they haven't "solved" that yet.

Re: Reliability: It’s not great

#24

Post by outworlder »

> This is a theme. Existing open source is not designed for global deployment

Eh? Unless you are consuming something as a service and it actually advertises it as a feature, nothing is ready for 'global deployment'.

If you have a 'centralized' secret storage, then you have made it tied to a region. Want to have redundancies and lower latency? You'll have to distribute it. Vault has docs about this: https://developer.hashicorp.com/vault/tutorials/day-one-raft...

Re: Reliability: It’s not great

#26

Post by vineyardmike »

samwillis wrote: post #18

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 agree - fly is so easy to use (when it works) that it’s hard not to be impressed. BUT what I’ve found is that we don’t need edge compute, since our customers aren’t that latency sensitive, so it’s lost on us. It’s only a few more milliseconds to us-east-1.

I’ve heard (on HN) of a dozen different companies vying for the heroku replacement spots and yet Fly seemed to capture the attention. I couldn’t name another one off hand.

What I truly want and probably lots of other people too is Flyctl (and workflow) for AWS. The same simplicity to run as fly, but give me something cheap in Virginia or the Dalles.

Re: Reliability: It’s not great

#27

Post by nilsbunger »

soperj wrote: 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.

Their problem right now isn't adding more customers - they seem to have more than they can handle!

If I were them I'd focus as many resources as possible on making the stack rock-solid, and away from acquiring more customers or adding more capabilities.

In fact I'd try to down-scope some features if at all possible, like the example they give of disabling app deploys while they're doing platform updates.

We use fly.io at a small scale and it's worked really well for us, but the money is in customers at a larger scale who must have 100% reliability.

Re: Reliability: It’s not great

#28

Post by jpdb »

emschwartz wrote: post #2

One of my colleagues keeps repeating “reliability is our number one feature”. I’m not sure it is for 100% of early stage startups, but I guess it is once you exceed some minimum usage threshold. That said, definitely appreciate the detailed explanation.

> One of my colleagues keeps repeating “reliability is our number one feature”.

I think reliability is the #1 feature at any stage because if you're unavailable, you're at best useless and more than likely you are actively harmful because your users have an expectation.

However, if you're unavailable outside of times customers don't expect you to be there then you're not actually unavailable. This is more likely for an early stage start-up, but you don't typically choose or know when you're expected to be available nor do you always get to choose when you're unavailable.

Re: Reliability: It’s not great

#29

Post by tebbers »

I really feel for Fly, as a potential customer. They are trying really hard. I would still love to use them one day and this post is definitely a step in the right direction. Growing is painful but they have smart people working there so fingers crossed that they sort this ASAP and it doesn't become existential.

Re: Reliability: It’s not great

#30

Post by trilobyte »

samwillis wrote: post #18

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,

This is likely the biggest culprit for a lot of these companies. Too many of us have grown up in the culture of getting hosting and platform for "free", but at some point the companies providing it still have to pay the bills. There has to be a better pricing model that let's someone deploy their relatively small, low-traffic app for $10s/month or even $200 - $300 / year for the basics (e.g. - Heroku free tier type capabilities). It's not going to save these companies but it would limit excessive growth of their own costs from a free tier while at the same time still being affordable for 1 - 2 person teams who are trying to get something in front of users.

Post reply on HN