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

My thoughts about Fly.io (so far) and other newish technology I'm getting into

blog.hartleybrody.com

Post reply on HN
Print view View original

81–90 of 111 posts

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#81

Post by jamesmcintyre »

tpetry wrote: post #43
julianbuse wrote: post #16

I think some things need to be built out some more, like their postgres and adding more storage after creation, but in general it's really enjoyable to use. The pricing seems fair, and their blog is intersting and fun to read.

Completely agree. Their offering for running containers is great, but nobody wants to maintain a database. They should add DBaaS on their architecture with automatic backups etc.

I totally agree with this! This would really add so much value to fly.io. And if they don't want to allocate resources to this right now I wonder if they could work with DBaaS providers like Planet Scale or FaunaDB where they'd wireguard their nearest instances into the fly.io network, add cli integrations/automations that'd link to their respective dashboards, etc.

I plan to use fly.io + planetscale and I'm hoping to still get low latency between those two services but it's no where near the low latency cloudflare can achieve with their new edge redis/db offerings (or the fly.io db at edge strategies) but after looking into fly.io's db strategies I really feel hesitant to take on that level of devops/additional-engineering when something like planetscale provides so much value out of the box.

Hope the fly.io team has something in the works either way! (And I'd love if they chime in with any input here in terms of performance between fly.io and existing DBaaS providers that are regionally replicated by default.)

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#82

Post by tptacek »

treis wrote: post #75
simonw wrote: post #61

> It seems like this would add a whole new class of bugs, like “I just submitted a form to change a setting and when the page reloaded, it still showed my previous value in the form” – since the write hadn’t propagated to the local read replica yet. There's a very solid solution to this that isn't as widely known as it should be. Read after write consistency is extremely important. If a user makes an edit to their co…

This is a ton of effort to save the RTT of sending all the requests to a central server. And it all goes out the window the second you need to call an external API in the processing of your requests. And to get what benefit there may be you need to, more or less, pay for a server in every big city. IMHO, outside of gaming there's no real need for what fly.io does. For something like this to be useful I think the code…

If you're getting 80ms response times for user requests, consistently, then it doesn't change much.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#83

Post by tptacek »

csmpltn wrote: post #3

An unrelated, yet honest question. There have been many posts hitting the HN frontpage regarding fly.io recently. Is it healthy to have so much content about a single PAAS platform showing up here so often now?

We agree! It's flattering and it's super interesting to read what people think about us and we're all blushing about the "heir to the vast Heroku fortune" stuff (even if it's probably not true), but we're also cringing a bit.

We have a big announcement/technical post queued up --- we'd planned to run it on Monday --- and we're holding off on it because of the "organic" attention we're getting this week. We'd much rather talk about things like Litestream, app pentests, hiring processes, and how we replaced Nomad in our architecture.

But we're as aware as everyone else is that the front page has limited bandwidth, and we can't be on it all the time, so we're waiting for this (hopefully short) wave of attention to crest before we post our own stuff.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#84

Post by evanelias »

danpalmer wrote: post #29
Dave3of5 wrote: post #21

Earlier quoted context omitted.

That's actually like what was done on the project in question. If you use a transaction it was set to always use the primary that way you can read and write all you want in your queries. For this ACK that you talk about. It's AWS aurora mysql specifically here do you know if that's a setting you can setup?

Sorry no idea about AWS Aurora, but I think MySQL will do this itself.

Unfortunately, it won't. Traditional MySQL replication does not provide a built-in option for fully synchronous behavior.

You can optionally use MySQL's "semi-sync" replication feature, in which replicas ACK receipt of transactions. This is purely for durability though, not consistency: it ensures commits are durable even if the primary DB has an unrecoverable hardware failure, but without having the massive latency penalty of fully-synchronous replication.

With semi-sync, the replicas are essentially just confirming they've queued up the transaction in their local relay log, rather than acknowledging execution of the transaction. The replicas may still be lagging behind the primary, in terms of what transactions they've applied locally; this means they'll return stale reads.

That said, the story is completely different in AWS Aurora, which (by default) uses proprietary physical (storage-level) replication. Within one region, AWS docs say their lag is "usually much less than 100 milliseconds", but they also note lag depends on transaction volume, so it's unclear what sync/async tradeoffs they're making behind the scenes.

In any case, for a nice third-party implementation of read-after-write consistency in MySQL, ProxySQL has a really powerful feature: https://proxysql.com/blog/proxysql-gtid-causal-reads/

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#85

Post by tptacek »

pid-1 wrote: post #38
dan-robertson wrote: post #12

Earlier quoted context omitted.

A big competitor of theirs, tailscale, also does well here. I think the lesson is partly that the typical somewhat-deranged writing style/topics are popular. More companies should try to write engaging blog posts and be more open if they want to be successful. It seems to have paid off for them as I would guess at least some of the people trying it out are learning about fly.io from HN.

> A big competitor of theirs, tailscale, also does well here. How does a container/database as a service platform competes with a Wireguard as a service platform?

We do not, at all, unless that commenter knows something about Tailscale that we don't.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#86

Post by tptacek »

ctvo wrote: post #68
rvz wrote: post #8

Earlier quoted context omitted.

Generally, it is all YC hype. HN is biased towards YC startups. There are other alternatives like Render.com, railway.app, etc but it is clear that fly.io is unsurprisingly overhyped by the HN crowd, especially if you are looking for a Heroku alternative. It’s like asking a barber if you need a haircut.

Give credit where it's due: fly.io spends a tremendous amount of time on creating interesting technical content that attracts this type of attention. The company is intentional about this as a customer acquisition strategy. They have an illustrator on staff for their unique art style, for example. Their founder and senior technical staff engage with these posts and answer questions, etc.. It's not YC favoritism, it's…

That's incredibly generous of you, and it's true that our illustrator fucking rules, but if there are other startup people wondering why we do well on HN, I think it's actually really simple: we write for HN, not for our own marketing goals. One of the first rules in our style guide is that our model reader is never going to use Fly.io, and that our posts still have to be worth their time. I think that's all there is to it? If you can clear that bar, you're all set. Tailscale does that, too, and so does Cloudflare.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#87

Post by tptacek »

Just a quick note that the list of applications for Fly.io at the end of this post was taken from our Launch HN --- https://news.ycombinator.com/item?id=22616857 --- and we've changed (expanded) since then.

When we launched, we didn't do persistent storage for instances, so it didn't make as much sense to run ordinary apps here; rather, the idea was that you'd run your full-stack app somewhere like us-east-1, and carve off performance-sensitive bits and run them on Fly.io. That's "edge computing".

But a bit over a year ago, we added persistent volumes, and then we built Fly Postgres on top of it. You can store files on Fly.io or use a bunch of different databases, some of which we support directly. So it makes a lot more sense to run arbitrary applications, like a Rails or Elixir app, which is not something we would have said back in March 2020.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#88

Post by Stampo00 »

I'm enjoying fly.io so far.

I just dropped DigitalOcean because of their price hike. No hard feelings. I was barely using it, and the product is growing more towards full-featured apps and teams, which is not as good a fit for me, an individual just screwing around. I don't fault them. I'm not their target customer.

Fly.io is very much designed for use primarily via their CLI tool. Their web interface needs some polish. But it does everything it says on the tin, for a price that's more than reasonable.

I only used Heroku briefly so I can't comment on similarities or differences with any authority.

As someone who is already very comfortable with container-based development, I'm happy with fly.io.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#89

Post by zoomzoom »

There's been a lot of talk about fly.io lately - it's clearly an awesome and exciting platform. But I'd have to agree with the author here that it doesn't solve the core problems faced by most web devs and web dev teams.

There are 3 relevant (for this comment) "performance layers" in building software:

- Cycle time of a team or of the project - this is affected the most by language/framework choice, DevOps infrastructure, and team working style - this should be measured in days/weeks

- Feedback loop for an individual dev working on a new ticket - this is based on the team's cycle time but in addition is really about the dev environment, team collaboration, how the team maintains quality, and how well-defined work is before being started - this should be measured in muinutes/hours

- Performance of the software deployed in terms of response time to end users - milliseconds

Fly.io helps the most with category #3. But how often is that really the most important issue in choosing where to deploy your app? If an alternative made small sacrifices there (for example went form 99.99% performance to 99%) but gained velocity for individual devs and the team to be able to ship better product more quickly, would the company/project be better off?

At Coherence (www.withcoherence.com) - disclosure that I'm a cofounder - we're laser-focused on a post-Heroku development platform that goers further than Heroku on categories 1 & 2 above (where I'd argue Heroku is still the gold standard) rather than focusing on category 3.

We're super early but in closed beta - if it sounds exciting please check us out and request a demo on the site!

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#90

Post by simonw »

treis wrote: post #75
simonw wrote: post #61

> It seems like this would add a whole new class of bugs, like “I just submitted a form to change a setting and when the page reloaded, it still showed my previous value in the form” – since the write hadn’t propagated to the local read replica yet. There's a very solid solution to this that isn't as widely known as it should be. Read after write consistency is extremely important. If a user makes an edit to their co…

This is a ton of effort to save the RTT of sending all the requests to a central server. And it all goes out the window the second you need to call an external API in the processing of your requests. And to get what benefit there may be you need to, more or less, pay for a server in every big city. IMHO, outside of gaming there's no real need for what fly.io does. For something like this to be useful I think the code…

This trick isn't just about geographic distribution - it's most commonly used for classic horizontal scaling, where you use multiple read-replicas to handle more traffic.
Post reply on HN