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

261–270 of 320 posts

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

#261

Post by manigandham »

nik736 wrote: post #254
manigandham wrote: post #248

Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deploys leading to stuck and unreachable instances or other networking issues. It's probably exacerbated by the new user growth but the slick deploy workflow can't override having an app that works. Render and others are interesting but K8S is still fundamentally better considering al…

What exactly makes K8s better?

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 than all these PaaS services that have their own issues with no visibility.

K8S experience is also more valuable and useful in future projects and there are plenty of nice DX tooling to make deploys easy if that's the blocker.

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

#262

Post by m12k »

ditsuke wrote: post #163
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…

Sorry I couldn't find a reference, what is dogwood?

Second paragraph in the article

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

#263

Post by manigandham »

xchaotic wrote: post #257
manigandham wrote: post #211

Earlier quoted context omitted.

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…

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. Like I said, billing is easier to negotiate than deleted accounts.

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

#265

Post by flurdy »

ryantgtg wrote: post #184
mrkurt wrote: post #42

Earlier quoted context omitted.

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.

I only found out my bandwidth after putting cloudflare infront of my apps as they email a monthly bandwidth saved report.

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

#266

Post by nickjj »

nicoburns wrote: post #251
nickjj wrote: post #124

Earlier quoted context omitted.

Does Fly let you run multiple commands in separate Docker images? That's usually the pattern on how to run a web app + worker with Docker, as opposed to creating an init system in Docker and running (2) processes in 1 container (this goes against best practices). The Fly docs only mention the approach of using an init system inside of your image and also tries to talk you into running a separate VM[0] to keep your we…

Not sure how Ruby works, but can you not run the workers and the web server in the same process? In our Node.js apps, this is as simple as importing a function and calling it.

Most of the popular background workers in Ruby run as a separate process (Sidekiq, Resque, GoodJob). The same goes for using Celery with Python. I'm not sure about PHP but Laravel's docs mention running a separate command for the worker so I'm guessing that's also a 2nd process.

It's common to separate them due to either language limitations or to let you individually scale your workers vs your web apps since in a lot of cases you might be doing a lot of computationally intensive work in the workers and need more of them vs your web apps. Not just more in number of replicas but potentially a different class of compute resources too. Your wep apps might be humming along with a consistent memory / CPU usage but your workers might need double or triple the memory and better cpus.

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

#267

Post by imtringued »

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 very easy to solve this problem. Just let people set a cap on the things with usage billing:

"I want to cap the amount of data I store to 50GB and the amount of traffic I serve to 1000GB"

Of course there is an obvious problem with this, the pricing structure would become transparent and you don't want that as a cloud provider. You want your customer to just pay his bills and not even know why it costs this much.

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

#268

Post by jpgvm »

joseph wrote: post #136
mrkurt wrote: post #15

Earlier quoted context omitted.

We've been kicking around ideas for managing files on volumes. This is a common problem – it's actually more difficult than you'd expect because "securitah". Once your volume is mounted in one of your VMs, we can't run tools outside the VM to let you manage the file system. On something like k8s with vanilla Docker, we could. But no one should run multitenant Docker. It's not really an excuse, just a reason it's taki…

> We've been kicking around ideas for managing files on volumes. This is a common problem – it's actually more difficult than you'd expect because "securitah". Once your volume is mounted in one of your VMs, we can't run tools outside the VM to let you manage the file system. On something like k8s with vanilla Docker, we could. But no one should run multitenant Docker. Was there a reason for not using something simil…

They do that already AFAICT by using Firecracker.

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

#269

Post by nickjj »

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.

It's not the $2/mo at face value. For me it's the idea of them pushing to make paying for SSL certificates the norm again after Let's Encrypt has put in a huge amount of effort to change that field. Not that there's anything wrong with charging for things but charging for a free service rubs me in a weird way, especially since they're using Let's Encrypt.

Using the rounding error logic, how do you feel about companies adding $1.99 "convenience fees" or "administrative fees"?

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

#270

Post by weird-eye-issue »

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…

Do you hate Cloudflare?
Post reply on HN