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

121–130 of 476 posts

Re: Reliability: It’s not great

#121

Post by ghiculescu »

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

Re: Reliability: It’s not great

#122

Post by hiAndrewQuinn »

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…

God, I'm glad someone else sees it as clearly as I do. I learned about Fly from them acquiring freaking Litestream! The SQLite replicator! The canonical database at the edge of the network! Of course that's what they want to do.

Re: Reliability: It’s not great

#123

Post by russellthehippo »

pier25 wrote: post #61

I've been using Fly for over two years or so. The sentiment of this post doesn't align with my personal (anecdotal) experience. The PG issues hit me two times in the previous weeks but other than that it's been working great for me. With the move to v2 apps (using their new machines infra) things are actually faster and smoother than ever. About a year or so ago their CLI was quite buggy but I haven't really hit any…

Agree - V2 apps on machines are incredibly slick to launch (create/start/stop), get info on with graphql, and scale up and out. Magic. When the PG administration experience is that good I'll move it all over.

Re: Reliability: It’s not great

#124

Post by ignoramous »

jpdb wrote: post #28
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…

Our team at AWS had a poster up on the wall that more or less went:

1. Security

2. Durability

3. Availability

4. Speed

Similar: https://twitter.com/colmmacc/status/1071088017190711296

Re: Reliability: It’s not great

#125

Post by chris_st »

tptacek wrote: post #73
pier25 wrote: post #61

I've been using Fly for over two years or so. The sentiment of this post doesn't align with my personal (anecdotal) experience. The PG issues hit me two times in the previous weeks but other than that it's been working great for me. With the move to v2 apps (using their new machines infra) things are actually faster and smoother than ever. About a year or so ago their CLI was quite buggy but I haven't really hit any…

We're nowhere even within the line of sight of closing up shop. We just haven't been doing a good job of aggressively communicating (a) when things go wrong and (b) what we're doing to account for it. The Fly.io of 2023 looks almost nothing like that of 2021 (all for the better), and it's not obvious to our users what's changed. We've been doing a shitty job of communicating, and we're taking our licks for it now.

A lot can happen in 11 years :-)

And thanks a lot for fly.io -- it's working great for my (rather small) use cases.

Re: Reliability: It’s not great

#126

Post by vorticalbox »

alexgrover wrote: post #75
vorticalbox wrote: post #57

Earlier quoted context omitted.

Render has some great features like making a new sub domain for when a PR is opened so you can test it as a fully working API before you merge

That’s supported on most PAAS these days, including Heroku.

On their free tiers though?

Re: Reliability: It’s not great

#127

Post by zamnos »

richardhod wrote: post #82
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…

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.

Re: Reliability: It’s not great

#128

Post by ignoramous »

karmelapple wrote: post #72
trilobyte wrote: post #30

Earlier quoted context omitted.

> 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 basi…

I agree. And I know this is unpopular, but I think none of these companies should be expected to have a free tier. A low-cost tier? Certainly. Perhaps even a free trial with a credit card? Great. But our team, who has used Heroku for over a decade, got bit multiple times by Heroku having a free tier. Why were we impacted by other apps? Because Heroku’s load balancers are shared amongst all their apps. That includes a…

> And I know this is unpopular, but I think none of these companies should be expected to have a free tier.

Free tier is a GTM motion which makes sense for novel tech products like Fly because: https://en.wikipedia.org/wiki/Technology_adoption_life_cycle

Re: Reliability: It’s not great

#129

Post by morelisp »

te_chris wrote: post #48
cldellow wrote: post #33

Earlier quoted context omitted.

Render.com is another spiritual successor of Heroku. I'd love a world where Fly and Render are both very successful companies.

Not gonna happen. Both will get acquired because that’s how things work now

These threads from mrkurt a few months ago seem relevant here -

https://news.ycombinator.com/item?id=32955520

If they are a multiplier for a whole portfolio, there's not much reason for any particular branch to purchase them.

(This post seems like some evidence they might actually be building the wrong thing, though.)

Re: Reliability: It’s not great

#130

Post by ashiban »

One of the key challenges we observe is that if you're small enough, a Heroku like experience works well - and most of your needs would be covered by virtually any combination of techstacks.

It gets significantly more challenging when you grow, either in feature complexity or scale complexity - and then very few services can offer what AWS/GCP/Azure offer - albeit at the increased engineering/monetary cost of using them.

We're building a different kind of approach[0] that aims to absorb the mechanical cost of using public cloud capabilities (that are proven to scale) without hiding it altogether.

[0] https://github.com/KlothoPlatform/klotho

Post reply on HN