Fly.io: The reclaimer of Heroku's magic • Hacker News Board

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

#291

Post by newaccount74 » Mon, May 16, 2022, 4:28 PM UTC

manigandham wrote: post #211

EnKopVand wrote: post #69

Earlier quoted context omitted.

I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small…

This topic has been discussed many times. There's no easy solution to what happens after the cap is exceeded - should the vendor delete everything? - which is why so many of them don't bother. And for customers, it's far easier to negotiate billing disputes then to try and recover from an account deletion because of spending caps (and there have been plenty of examples of companies shutting down because of such a mis…

It's pretty simple: Ask people when signing up if they want to set a spending limit or not. If they do, return HTTP 500 as soon as the spending cap is reached. If it's for storage, return a quota exceeded error. Obviously the vendor shouldn't delete data, that would be stupid.

A lot of people try to get hobby users on a platform as a form of PR -- if you don't have spending caps, you are probably going to scare a lot of them away.

And I've never heard a company shutting down because they exceeded a limit -- I've only heard of people being surprised by unintended extremely high bills.

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

#292

Post by brunooliv » Mon, May 16, 2022, 4:32 PM UTC

How are rates for small apps? I've read the pricing table in the website and it seems pretty generous, so, for a small poc style app, is this limit enough?

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

#293

Post by newaccount74 » Mon, May 16, 2022, 4:33 PM UTC

manigandham wrote: post #263

xchaotic wrote: post #257

Earlier quoted context omitted.

Imo it’s really simple, actually. Stop the service and delete after the next billing cycle. Price that in for regular price of the service.

That's limited to free tiers that usually deactivate or delete if there's too much usage. Anything with production usage and pay-as-you-go pricing means data at rest still costs money - and requires deleting to avoid accruing new charges. Do you want your databases and volumes and object storage deleted when your app stops? And if this was offered then there would be a whole new class of mistakes leading to lost data…

The high charges are almost never storage costs, its almost always processing or bandwidth.

And storage costs are simple to predict -- as soon as you see the cap would be exceeded, stop accepting new data.

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

#294

Post by manigandham » Mon, May 16, 2022, 5:37 PM UTC

kasey_junk wrote: post #279

manigandham wrote: post #261

Earlier quoted context omitted.

It's basically the platform to build platforms like these (and some of them already run on it). K8S offers the same primitives and more, with progressive complexity as you need it. You can deploy a single container with a 1-line command or an entire PaaS subsystem. It's also more portable than any single platform and you can run it on a few VPS instances or your own bare metal. I've also found it far more reliable th…

I’d be very surprised if any edge compute systems run on (a single) K8s cluster. In nearly all cases you’d run at least a cluster per region. K8s also provides no functionality for per region routing or networking between clusters. That is to say, for most of what fly gives you there is no K8s equivalent.

None of them run on a single cluster globally. That's not supported or recommended by anyone. Some PaaS do use K8S as an underlying orchestrator for workloads, the same way Fly uses Hashicorp's Nomad, with multiple clusters per region.

Kubernetes does have federation/multi-cluster abilities, and global routing/load balancing is available from every CDN and cloud. It's more work to setup but not by that much.

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

#295

Post by jshen » Mon, May 16, 2022, 6:40 PM UTC

alskdjflaskjdhf wrote: post #210

jshen wrote: post #198

Earlier quoted context omitted.

Render has a free DB tier

Render's free DB tier isn't really usable when the data gets nuked after 90 days. Really strange decision IMO.

Good point. I haven’t used it because I use other free DB offerings. CockroachDB and cosmos DB both have free tiers.

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

#296

Post by cultofmetatron » Mon, May 16, 2022, 6:50 PM UTC

hthrowaway5 wrote: post #111

At one point (a very long time ago now) it was declared that Dogwood was the future and as a result Go would be the language of choice at Heroku and Erlang would be no more. Trouble is that Erlang ran all the important Cedar code (it might still today) and the Erlang engineers didn't particularly like the news that Erlang code was essentially deprecated so they left and nobody knew how to maintain the stack. This def…

I just don't understand all the fetishism for go. At its core, its a brutally pragmatist language optimized for engineers who barely understand closures while running reasonably fast.

need a garbage collected native compiled language?/

- ocaml fits the bill and provides better type checking

need a fast as possible system?

- rust is faster and has much better abstraction for type checking. unless you're writing a throwaway or a very short lambda function, rust is almost always a better choice here as handling errors and maintaining the code is going to be more important overtime and go is just now getting its generics story straight

need a networking application?

- elixir (and erlang) do this so much better. it has 30+ years of high reliability networking built in and its about as fast as go. additionally, fault tolerance and error handling is so much better. I have real parallelism out of the box and async primitives that make goroutines look like a joke.

additionally, all 3 (ocaml, rust and elixir) give you proper tools for handling error branches. go downgrades you back to c style which works but means your code is going to evolve into a god damn mess as there's no way to separate your error path from your happy path

Literally the only place I see go making sense are small scripts that need to be written asap and wont' need much long term maintenance. for everything else, go seems woefully inadequate.

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

#297

Post by ecnahc515 » Mon, May 16, 2022, 6:55 PM UTC

indigodaddy wrote: post #50

mrkurt wrote: post #36

Earlier quoted context omitted.

We are DigitalOcean circa 2015 mature. Good enough for some very large customers, good enough for many developers, not some place I'd run pacemaker infrastructure.

Does anyone run pacemaker on non-baremetal? Can you even? I’m aware you’re just using it as an analogy/example, but was just wondering..

FWIW, I'm pretty sure OP was referring to literal pacemakers, as in, the things that keep people's hearts beating.

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

#298

Post by sodality2 » Mon, May 16, 2022, 8:09 PM UTC

jen20 wrote: post #288

sodality2 wrote: post #278

Earlier quoted context omitted.

Contractually? I doubt it. But they have refunded many, many people on their forums after they report accidental charges. Whether they continue is a different story, but I feel safe using it and certain that I won't be overcharged. To be clear a bandwidth limit would be awesome! And the pricing may not be for everyone. However there is a large amount of leeway as evidenced by the community forum posts.

Good will does not feel like a good way to scale this. For a business that might be ok, but I’m highly unlikely to recommend to a business something I haven’t personally investigated, and I’m not writing cheques whose value is dependent on the good will of a startup. I don’t understand why cloud providers will not accommodate this basic “prepay to X and allow me to use the credit” model.

>I don’t understand why cloud providers will not accommodate this basic “prepay to X and allow me to use the credit” model.

They actually do:

> You can configure fly.io apps with a max monthly budget, we'll suspend them when they hit that budget, and then re-enable them at the beginning of the next month.

From their Launch HN: https://news.ycombinator.com/item?id=22616857

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

#299

Post by snark42 » Mon, May 16, 2022, 8:36 PM UTC

mrkurt wrote: post #143

the_duke wrote: post #123

Earlier quoted context omitted.

I'm actually very curious: why is bandwidth so much cheaper on more traditional VPS or dedicated server hosts like Hetzner ? This extends to their somewhat new-ish cloud product, where you get 20TB traffic included - even on a tiny instance. And it's 1 Euro per TB after that. [1] Do they just decide to not profit from bandwidth or are they doing something special that allows them to be so cheap? [1] https://docs.hetz…

There are three ways to manage bandwidth prices: 1. Put servers where bandwidth is cheap (not Sydney, for example) 2. Constrain throughput per server 3. Buy from cheap transit providers like Cogent Hetzner does all three. Bandwidth in the US/EU is very cheap. They meter total throughput on their services. And they use cheap providers. None of these are bad choices, just different than ours. Our product has multiple l…

You forgot play the peering game which can lead to substantially cheaper bandwidth when you connect to enough Tier1/2 ISPs. I think Hetzner does this some as well.

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

#300

Post by nickjj » Tue, May 17, 2022, 12:09 AM UTC

manmal wrote: post #234

nickjj wrote: post #89

Earlier quoted context omitted.

> You don’t need to route every write to primary though, but only those writes that have dependencies on other writes. Thanks, can you give an example of how that works? Did you write your own fork of Postgres or are you using a third party solution like BDR? Also do you have a few use cases where you'd want writes being dependent on another write? > 6-7 probably do the job quite well You could, let's call it 5. For…

> Thanks, can you give an example of how that works? I just noticed I formulated it wrong, my apologies. What I meant is that the replicating regions don’t need to wait for the primary writes to go through before they respond to clients. They will still be read-only Postgres replicas, and info could be shuttled to primary in a fire-and-forget manner, if that’s an option. Whenever an instance notices that it‘s not pri…

> Why would you need 5 web workers, would one running on primary not be ideal?

It's not ideal due to some frameworks using background jobs to handle pushing events through to your web UI, such as broadcasting changes over websockets with Hotwire Turbo.

The UI would update when that job completes and if you only have 1 worker then it's back to waiting 100-350ms to reach the primary worker to see UI changes based on your location which loses the appeal of global distribution. You might as well consider running everything on 1 DigitalOcean server for 15x less at this point and bypass the idea of global distribution if your goal was to reduce latency for your visitors.

> Crazy idea: Use SQLite (replicated with Litestream) instead of Redis and save 50 bucks

A number of web frameworks let you use Redis as a session, cache and job queue back-end with no alternatives (or having to make pretty big compromises to use a SQL DB as an alternative). Also, Rails depends on Redis for Action Cable, swapping that for SQLite isn't an option.