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

71–80 of 111 posts

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

#71

Post by snowwrestler »

tut-urut-utut wrote: post #22
telotortium wrote: post #4

Earlier quoted context omitted.

For better or worse, fly.io has as a principal tptacek, who's at the top of the HN leaderboard and so has built up a lot of goodwill here.

This actually makes me wonder if people here generally pay attention, who posted what? Does that influence actual upvote status? I never look at the person name when replying or voting, only the content. For example, I remembered this tptacek not because I remembered his posts, but because they get frequently mentioned in other people posts.

A lot of people on HN do pay attention to who is posting.

This is why Cloudflare is generally beloved here as well: the principles show up in the comments whenever it’s mentioned.

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

#72

Post by aenis »

tlarkworthy wrote: post #2

Cloud Run is an alternative to fly.io that scales to zero so it can be much cheaper but with added cold starts.

But, to get a cloud run based setup:

- you need an elb - and this is not cheap (if you have an efficient backend, the elb will dwarf compute costs) - no persistent volumes, and you are encouraged to use gcs or firestore - each region requires a new deployment. No big deal but certainly not super easy to automate, esp. given the need to run behind an ELB (which you need on gcp to have a WAF) - google sdks for some languages suck big time. Most of python sdk is not async friendly, unbelievable as it seems.

I do use cloud run for projects big and small, and rather like it, but its hardly a competitor to fly.io imho.

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

#73

Post by simonw »

simonw wrote: post #66
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…

There's another, more sophisticated trick that works for some databases: tracking a global transaction counter of some sort, persisting that in a cookie when a user makes a write and redirecting the user to the lead database if the replica they are talking to hasn't made it to that point yet. Chris McCord describes how Elixir does that with PostgreSQL here: https://news.ycombinator.com/item?id=31434094 Wikipedia impl…

Actually the way Wikipedia works is slightly different: they don't redirect to a lead database, they instead call this MySQL function to wait on the replica for it to catch up:

    SELECT WAIT_FOR_EXECUTED_GTID_SET($gtidArg, $timeout)
https://github.com/wikimedia/mediawiki/blob/434c333d9b2be817...

I wonder if there's a PostgreSQL equivalent of this?

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

#74

Post by aenis »

bobnamob wrote: post #15
tlarkworthy wrote: post #2

Cloud Run is an alternative to fly.io that scales to zero so it can be much cheaper but with added cold starts.

Isn’t the whole appeal of fly that they’re geolocated near your users, reducing latency so you can use fancy serverside rendering stacks like Phoenix? Cold start latency kinda ruins that no?

Latency on cloud run is not an issue, in my experience (been using it around 4 years now, on a fairly large scale).

Its generally fast as is, and if you want to pre-allocate a minimum # of instances, cold starts are less of a problem (basically only if you are suddenly stampeded by a spike in traffic). But the whole smart routing and localized storage concepts are left for you to implement. You can have a bunch of cloud run services behind an ELB that does geo-proximity based routing but firestore is region-bound, and cloud spanner can be very expensive. Not saying there are no workarounds but it seems to me fly.io offers a much lower cost of entry here.

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

#75

Post by treis »

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 would need to be running on the user's network. That would drop server ping to sub 1 ms and open up a whole lot of interesting possibilities. But I don't see what changing server ping from 80 ms to 15ms gets me.

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

#76

Post by chrismccord »

satyrnein wrote: post #54

Tired of SPA complexity? Try server side rendering, now with websockets, globally distributed nodes, read replicas, and eventual consistency! All of this tech sounds cool, but like the author, I'm unsure when it's called for.

To tame the snark from the quoted comment, I think it's worth breaking down.

Current SPA trends are about deploying your app separate from the backend, often CDN-style close to the user (because speed of light matters). Most apps at scale use caching for reads on hot-code paths, so now we have "eventual consistency" in the mix.

Elixir is distributed out of the box, so while "global distribution" sounds fanciful, it's literally baked into the Virtual Machine, Fly simply gives us a private ipv6 network across the globe. All Elixir sees is a cluster of hosts that it can connect to, and it's off to the races.

What I'm getting at is all this snark actually describes most application folks build today at any scale, and we build distributed apps with Elixir because it's a distributed platform.

> All of this tech sounds cool, but like the author, I'm unsure when it's called for.

Imagine if you could write your dynamic UI with realtime updates, and you didn't have to bootstrap JSON apis, or GraphQL schemas for it. Imagine doing `PubSub.broadcast(room, "new_message", ...)` and it gets sent globally to all your instances – with no external dependency. Want to show some activity on the page when something happens on the cluster? Broadcast the event, then write 3 lines of code to update your UI. Imagine writing "naive" template code that renders some markup, but what falls out is smaller payloads on the wire than your carefully typed and specified GraphQL schemas that require serialization rules for all your objects. Imagine doing away with all that and gaining all the benefits of payload size.

If that sounds interesting, Phoenix + LiveView would be called for any time you wanted a dynamic UI or realtime updates and bonus points if you care about writing less code and killing layers of abstraction. Fly would be called for for the same reason folks use CDN's today, to serve resources of the app close to the user, except we just serve the app there instead.

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

#77

Post by Mo3 »

Fly.io, as sorry as I am to say, does not come close to the functionality Heroku offers yet.

Redis instances are single-region single-replica, for example.

On another note, as soon as they offer serverless functions and solid redundant Redis + SQL I'll be thinking about moving some of our production services over there for a test run.

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

#78

Post by mbesto »

telotortium wrote: post #4
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?

For better or worse, fly.io has as a principal tptacek, who's at the top of the HN leaderboard and so has built up a lot of goodwill here.

And to be fair, Fly's blog content is very good for this audience (which is largely the result of tptacek).

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

#79

Post by alexmuro »

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?

I think the perspective of this article is a very healthy and productive one and I found it particularly useful.

Assessing if attending on the shoulders of the new Giants who stand up every few years is a difficult problem that I'm interested in and I appreciate the amount of context given here considering different use cases.

Post reply on HN