Live data from Hacker News

Reliability: It’s not great

community.fly.io

81–90 of 476 posts

Re: Reliability: It’s not great

#81

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 can second this. We were evaluating moving off Heroku and to Fly.io, but we didn't need all of the edge compute stuff. We just want a better Heroku without having to think about infrastructure and having to think about edge compute just got in our way. I feel like Next.js is in a similar position. While their main vision is SSR, I wonder if they are missing out on a chunk of the market that simply doesn't want to t…

Why would they be missing out? Vercel can host static sites just fine, whether that’s one generated by Next or any other framework or written by hand

Re: Reliability: It’s not great

#82

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?

Re: Reliability: It’s not great

#83

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…

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.

Re: Reliability: It’s not great

#84

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…

> dirt simple managed Postgres

Heroku PostgreSQL is very simple, yes. But once you need non-trivial scale it's expensive and extremely non-performant. Even a medium-sized RDS will outperform Heroku's most expensive database offering by 20x in my experience. My company doesn't even run PG on Heroku anymore. We have a VPC/Private Space connection to AWS Aurora because the cost/performance difference is so extreme.

Re: Reliability: It’s not great

#85

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 can second this. We were evaluating moving off Heroku and to Fly.io, but we didn't need all of the edge compute stuff. We just want a better Heroku without having to think about infrastructure and having to think about edge compute just got in our way. I feel like Next.js is in a similar position. While their main vision is SSR, I wonder if they are missing out on a chunk of the market that simply doesn't want to t…

One of the key design choices of Next.js was to enable granularity on the runtime (Node.js or Edge[1]) and the rendering method (static or dynamic[2]) on a per-route basis. If you want a full SSR site, that's okay. If you want a full static site, that's also okay.

We often see folks wanting a mix of both. For example, maybe the /about page is static, but the home page is dynamic and personalized based on the visitor. You can do all of this with Next.js. Our future direction is adding even further granularity, enabling this decision at the data fetch level, allowing you to cache results across deployments[3].

[1]: https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runti...

[2]: https://beta.nextjs.org/docs/rendering/static-and-dynamic-re...

[3]: https://vercel.com/blog/vercel-cache-api-nextjs-cache

Re: Reliability: It’s not great

#86

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 spot on. I found myself using Fly for a project because it was super easy, not because I needed edge compute. TBH it's still actually unclear to me who needs edge compute? What apps require this sort of infra? It's not 99% of web apps right?

Re: Reliability: It’s not great

#87

Earlier quoted context omitted.

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…

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

Yeah I like them both a lot, having tried deploying small projects on each. However, I’ve defaulted to render at the moment because I’ve found it painless for my current project, and edge compute is low on my list of priorities.

Though to be fair, even if render collapsed overnight, I think I’d still be equally satisfied after moving to fly.

Re: Reliability: It’s not great

#88
post #74
post #62

Earlier quoted context omitted.

The US CLOUD Act means a EU customer cannot use a US cloud provider to host PII, even if the server itself is physically in the EU, because US law will still compel the provider to yield the data to US authorities. The European Commission is trying to paper over the cracks with a fig leaf of judicial review, but it's only a matter of time until a Schrems III decision from the CJEU invalidates that polite fiction.

The amount of EU companies following this law is exactly 0.

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.

Re: Reliability: It’s not great

#89

Very interesting to see Kurt assert theyre going to "solve managed Postgres", and I'm super curious to know what that means. Does it mean something like RDS, or more like CrunchyData? I could see them building something RDS-like on their own, but if they're trying to go further than that I wonder if they'll buy or partner with other companies rather than doing it themselves. Neon strikes me as a Postgres-as-a-service…

Craig here from Crunchy Data. Not sure if you mean Crunchy Data is like RDS or isn't, in some cases we're very similar as a managed service provider. But are focused on a better developer experience and quality support. We've had a number of customers that use us for the database and fly for the app. We had a user benchmark a number of heroku alternatives with various database providers and we were actually better re…

I haven't used CrunchyData for work, but I see you as offering what RDS does plus plenty more. RDS does a lot, but after using Timescale Cloud professionally I saw how much RDS doesn't do, like actually-simple upgrades, one-click forks, etc. and Crunchy looks similar in going beyond RDS.

I think the community would really love to see a direct Fly+Crunchy integration!

Re: Reliability: It’s not great

#90

Very interesting to see Kurt assert theyre going to "solve managed Postgres", and I'm super curious to know what that means. Does it mean something like RDS, or more like CrunchyData? I could see them building something RDS-like on their own, but if they're trying to go further than that I wonder if they'll buy or partner with other companies rather than doing it themselves. Neon strikes me as a Postgres-as-a-service…

I don't even understand what you mean as the difference between "something like RDS" and "something like CrunchyData" -- they seem like similar products to me?

I see RDS as the absolute bare minimum for a managed database; providers like Timescale or Crunchy tend to add some pretty useful stuff on top.
Post reply on HN