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

101–110 of 111 posts

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

#101

Post by simonw »

treis wrote: post #96
tptacek wrote: post #82

Earlier quoted context omitted.

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

80ms is the network latency not response times. That's the number fly.io can change and realistic best case is going from 10-15ish ms staying within a city vs 80ms going to a server on the other side of the US.

If all of your users are in the US you won't gain much from geographical distribution. Where this gets really interesting is when you have users all around the world.

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

#102

Post by mrkurt »

dx034 wrote: post #25
pw wrote: post #20

The end of this article raises the issue of whether Fly.io’s USP, deploying app servers close to your users, is useful for run of the mill web apps. And as much as I like Fly.io and the people associated with it, I’ve wondered this myself. It just seems like serving to US customers from any major US data center is generally fast enough. And I think this might even be true for the world of HTML-over-the-wire web stuff…

Not only that, having one location for a world-wide user base is usually enough. You can optimize much more through rendering speed, blocking requests etc than by being closer to your user. And even if your page becomes really popular, 3 locations (Europe, US, East Asia) are enough to be <200ms to any user in the world. And it keeps your setup and cost much lower.

This pretty much fits our definition of "deploy app servers close to your users".

One region works just fine for some apps. Some are worth going to three.

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

#103

Post by satyrnein »

chrismccord wrote: post #76
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…

It really is pretty cool stuff, and it may not be additional complexity for those who are already at the scale where they're dealing with CDNs and caching hot paths, as you say.

For the long tail of Rails/Django/Laravel apps sitting on Heroku or a pair of EC2s in Virginia, who are looking at SPAs with trepidation, I think the case is less obvious.

Sorry if the snark was excessive and thanks for your reply!

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

#104

Post by jjtheblunt »

Humphrey wrote: post #70
simonw wrote: post #65

Earlier quoted context omitted.

Companies start to get a lot more interested in this when their business truly goes global. Users in Australia have money to spend and get pretty poor performance from apps hosted in the USA due to speed of light issues. I've looked at implementing this in the past and always found it to be SO difficult that the benefit would not be worth the cost. Fly has changed that equation for me. It has moved this problem from…

Yeah, and I guess all my Australian hosted things are slow for you Americans who have even more money to spend

> who have even more money to spend

?

I'm guessing it's a joke about the government printing money, and the surrounding fiascos?

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

#105

Post by Mo3 »

tptacek wrote: post #95
Mo3 wrote: post #77

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.

Just so we're clear: our take right now is that if you want Redis, you should run Redis as an app. The Redis we provide "built in" to the platform is an artifact of an earlier iteration of Fly.io.

Yes - which unfortunately results in a single-instance, single-region Redis instance, as far as I understood.

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

#106

Post by tptacek »

Mo3 wrote: post #105
tptacek wrote: post #95

Earlier quoted context omitted.

Just so we're clear: our take right now is that if you want Redis, you should run Redis as an app. The Redis we provide "built in" to the platform is an artifact of an earlier iteration of Fly.io.

Yes - which unfortunately results in a single-instance, single-region Redis instance, as far as I understood.

Not sure I follow, sorry. If you want multi-region Redis, you can deploy multi-region Redis.

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

#107

Post by tlarkworthy »

aenis wrote: post #72
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 lan…

Yeah the load balancer bit sucks, I forgot about that. I use terraform for multi region deploys but yeah, the load balancer is a major cost.

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

#108

Post by alx__ »

dom__inic wrote: post #37

Unrelated to this topic, but I think you should apply this one line of CSS to your stylesheet - it improves your text aesthetics and readability :) html { -webkit-font-smoothing: "antialiased" }

First off, avoid changing that property. It doesn't improve things

10 years later, still relevant - https://usabilitypost.com/2012/11/05/stop-fixing-font-smooth...

Secondly, the issue may be the font being used. I don't recognize it, but probably not optimized for modern web screens. Or a "converted" typeface originally designed for print

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

#109

Post by ctvo »

tptacek wrote: post #86
ctvo wrote: post #68

Earlier quoted context omitted.

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…

That's an excellent guideline. I want to throw another example into the ring if folks are researching this space:

Planetscale does a good job at https://planetscale.com/blog

In particular "Generics can make your Go code slower"[1] which received deservedly a lot of attention here.

1 - https://planetscale.com/blog/generics-can-make-your-go-code-...

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

#110

Post by Mo3 »

tptacek wrote: post #106
Mo3 wrote: post #105

Earlier quoted context omitted.

Yes - which unfortunately results in a single-instance, single-region Redis instance, as far as I understood.

Not sure I follow, sorry. If you want multi-region Redis, you can deploy multi-region Redis.

Now I am not quite sure if I follow haha. Sorry.

The documentation states,

> "to get a Redis instance with persistent storage running in a single region."

Would I be correct to assume that I would have to take care of configuring the clustering?

I'm obviously aware I could deploy multiple Redis instances in different regions, but then I would end up with different Redis instances, no?

Post reply on HN