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

Fly.io: The reclaimer of Heroku's magic

christine.website

Post reply on HN
Print view View original

181–190 of 320 posts

Re: Fly.io: The reclaimer of Heroku's magic

#181

Post by thorncorona »

burner556 wrote: post #172
nickjj wrote: post #57

Earlier quoted context omitted.

> Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary. Doesn't this take away a lot of the benefits of global distribution? For example if you pay Fly hundreds of dollars a month to distribute your small app in a few datacenters around the globe but your primary DB is in California then everyone from the EU…

Why are people tripping over $2/mo ? I don’t get this tight-ass mentality. It’s a rounding error.

why spend money when you don’t have to?

Re: Fly.io: The reclaimer of Heroku's magic

#182

Post by kevlened »

joseph wrote: post #122
tptacek wrote: post #28

Earlier quoted context omitted.

I'd love to do this, if for no other reason than I hate working with cron. What would you use it for? What would the ideal version of this feature look like for you? What kind of apps would you be more easily able to ship? Is it mostly so you wouldn't need to keep a single tiny running VM sitting around running cron?

I'd like to do any one-off job, not only scheduled ones; retrieving data and transforming or storing it, scraping a web page, running a database migration. My biggest annoyance with Fly is the assumption that everything is a long running application.

I'm not sure how Fly handles one-off tasks behind the scenes, but we're building task queues (w/ cron) as a first class citizen at https://tasker.sh

Re: Fly.io: The reclaimer of Heroku's magic

#183

Post by aledalgrande »

vlunkr wrote: post #126
Trasmatta wrote: post #114

Earlier quoted context omitted.

> I think people misconstrue the benefits of k8s to be related to reliability or similar. Ultimately it's about the API and the consistency and productivity it offers I think this is the first time I've heard somebody say one of the benefits of kubernetes was productivity.

Really? I think it's a pretty obvious benefit. If you bundle something into a container, you can probably run it in kubernetes. This uniformity makes it incredibly easy to deploy and scale new applications.

Yeah if you study over it instead of copy pasting stuff from the internet, I find k8s the best thing for my small projects. I only have to setup a simple dockerfile and helm chart and I can run a new service in my cluster on DO, for which they offer free control plane, and not be billed for a completely new app and have to setup all my deps and env vars in a clunky UI. I can setup scaling, ingress easily, the Datadog agent is going to pick it up automatically, I can have services communicating via private dns etc. etc.

I am not an ops guy.

Re: Fly.io: The reclaimer of Heroku's magic

#184

Post by ryantgtg »

mrkurt wrote: post #42
brundolf wrote: post #31

The only thing I don't like is their usage-based pricing. On Heroku I could pay $7 a month and know I'd never be charged more than that. I'm sure when you're scaling a service it's fine - maybe even better - to do it on a sliding scale. But for a fire-and-forget blog site, I don't want to have to worry about stuff like that.

This is a problem. And a bit of an own goal on our part. I hate services that don't put a price on things like bandwidth (because there's always a price!). So we priced bandwidth and made it transparent. You can put an app on Fly.io and server petabytes of data every month, if you want. We'll never complain that you're serving the wrong content type. But the reality is – having an unlimited bandwidth promise is perfe…

I might be in the minority here, but I don’t have the slightest clue what my monthly bandwidth currently is on heroku, and so I can’t estimate what Fly will cost.

Um, how do I find this out? Preferably historical usage.

Re: Fly.io: The reclaimer of Heroku's magic

#185

Post by daxfohl »

mrkurt wrote: post #179
daxfohl wrote: post #167

Earlier quoted context omitted.

And disclosure, I used to be on Azure Front Door team and was the lead for Azure Edge Zones development. I really wanted to do something like fly with that. But it turned out that too many people wanted too many different things. Some needed GPU (some Nvidia, some AMD), some FPGA, some general compute. Surprisingly few cared about Functions (our Lambda-like service), or even Web Apps (our Heroku). SQL Server was a bi…

This is part of why the PaaS take has worked so well for us. People who think they want edge have all kinds of different needs. When we realized that all full stack devs could benefit from something kind-of-like-edge it helped us do more focused work.

Yeah, I hope it works! Prior to MS I was the solo dev for Smilebooth (a photobooth company), and when I joined Edge Zones my north star to shrink the minimum footprint (I think it was three racks initially) so that you could load an edge zone host on like a Smilebooth console or something and manage photobooth fleets by deploying Web Apps directly to them. (I realized that was ridiculously far-fetched at the time and that there were probably better ways of achieving that outcome, but I certainly didn't foresee the minimum footprint growing so dramatically)!

And, like I said earlier, I hope to see what a real edge IaaS solution looks like too, if such a thing is even possible. Maybe the IaaS that would allow a build-your-own-CDN.

Re: Fly.io: The reclaimer of Heroku's magic

#186

Post by jamesgreenleaf »

sanjayio wrote: post #48
brundolf wrote: post #31

The only thing I don't like is their usage-based pricing. On Heroku I could pay $7 a month and know I'd never be charged more than that. I'm sure when you're scaling a service it's fine - maybe even better - to do it on a sliding scale. But for a fire-and-forget blog site, I don't want to have to worry about stuff like that.

Big concern of mine as well. They take your CC for usage, which is reasonable given bad actors, but then I can’t put a limit on my monthly charges.

I use privacy.com for things like this. Make as many CCs as you want with whatever limits you want.

Re: Fly.io: The reclaimer of Heroku's magic

#188

Post by snoman »

otterley wrote: post #130
vlunkr wrote: post #126

Earlier quoted context omitted.

Really? I think it's a pretty obvious benefit. If you bundle something into a container, you can probably run it in kubernetes. This uniformity makes it incredibly easy to deploy and scale new applications.

The same is true of ECS, but with a much simpler API, much tighter integration with load balancers, a no-charge control plane, and not having to upgrade every cluster every 3-6 months.

I’ve had 2 services running flawlessly in ecs for over a year (with load balancing) without having to touch them. Took me all of 15m to set them up. It’s quite good.

Re: Fly.io: The reclaimer of Heroku's magic

#189

Post by snoman »

teaearlgraycold wrote: post #128
iammiles wrote: post #120

Earlier quoted context omitted.

I strongly agree with your last paragraph. I used Heroku for my wedding website and I would 100% use it again on a project site. In about 15 minutes I was able to take my site from localhost to a custom domain with SSL with just a little more than a git push. I can't think of many solutions that are simpler than that.

Vercel and Github pages would be better IMO if it's a static site.

If it’s a static site then just dump it in an s3 bucket and be on your way.

Re: Fly.io: The reclaimer of Heroku's magic

#190

Post by anon3949494 »

jrockway wrote: post #110
anon3949494 wrote: post #86

Earlier quoted context omitted.

It's also trivial to serve read requests from a caching layer or via a CDN. At any sufficient scale, you're probably going to need a CDN anyway, whether your database is replicated or not. You don't want every read to hit your database.

I don't think this is that trivial. I've never seen it done correctly. It typically manifests itself as not being able to read your own writes, and I see this all the time (often from companies that have blog posts about how smart their caching algorithm is). For example, you add something to a list, then you're redirected to the list, and it's not there. Then you press refresh and it is. I guess that's acceptable be…

> It typically manifests itself as not being able to read your own writes

Multi-region databases with read replicas face the same issue

Post reply on HN