Live data from Hacker News

Fly.io: The reclaimer of Heroku's magic

christine.website

221–230 of 320 posts

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

#221
post #42

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 don't want unlimited bandwidth (I mean, it'd be nice - but I realize it costs money) -- I want predictable pricing and spending caps for my personal projects.

If I can't have that, then I just can't take the risk of my site getting hammered (by attackers, getting linked on HN, whatever) and racking up some kind of bill I can't pay. I realize the chances of that are small but that's scary.

I realize that, obviously, "stay up at all costs" is what a business needs and that's where the money is. Fly.io won't get rich off of personal projects. But, I do think they serve to get developers onto the platform.

Your bandwidth allocations and rates seem very fair and generous, btw. I do really want to check out your platform.

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

#222
I could relate to the comment on Redis.

  The only things I can see missing are automated Redis hosting by the platform.
There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it.

If and when you get big enough you switch to a setup you bother about setting up and taking care of.

Am I making sense to anyone?

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

#223
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.

It's a temporary decision until we can build multi-tenant Postgres instances which will be perpetually free.

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

#224
post #100

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. For larger teams having a well defined API that delineates applications from infrastructure that doesn't require extreme specialist knowledge (it still requires some specialist knowledge but vastly less than direct manipulation of resources via something…

> 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.

We're running Nomad, but that's just a detail. The great thing for both development teams and the ops team is that the container orchestration starts working as a contract between the teams. This allows building more of a framework in which we can provide some initial starting point for standard tasks, like connections to infrastructure components, migrations in various languages, automated deployments, rollbacks and so on for teams out of the box. With this, product teams can go from an idea to deployed and running code very quickly and confidently.

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

#225

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. I've had a very real situation with DataDog: I've accidentally created a Synthetics test (and forgot about it) on a test account and incurred $5k+ bill at end of month. Zero notice or anything. I ended up swallowing the bill but will not be using them again since this is plain scary. Edit: funny thing - to add insult to injury, I've started to hear from their sales people on "my growth plans", even though I've…

Datadog is one of the worst offenders in this one. It's like they actually want to get you into that situation. Wanna see your prepaid capacity? Lol, email our support. Wanna use front-end monitoring? Here's an example with the defaults hidden. (Oh btw the defaults enable all the features and set the sampling to 100%) How do I turn on sampling? Don't worry, limitless tracing is the way, we'll figure out how to filter your traces. (Oh btw you'll still pay for ingestion, we're just omitting it here)

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

#226

Earlier quoted context omitted.

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.

[deleted]

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

#227
post #222

I could relate to the comment on Redis. The only things I can see missing are automated Redis hosting by the platform. There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it. If and when you get big eno…

Fly did have a built-in redis cache (albeit multi-tenant / shared) and for the life of me I can't figure out why they'd deprecate it (though, it still works): https://community.fly.io/t/debugging-a-failing-image-without... and https://community.fly.io/t/please-bring-redis-back/1563

If anything, I'd prefer they moved their PaaS more towards serverless and managed offerings than towards IaaS.

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

#228

The main thing I want is pipelines - review apps, staging apps, and promotion to production, all integrated closely with GitHub, along with a slack integration that lets me do all of it in a public chatroom. Until another service has all of this, we’re sticking with Heroku.

A coworker and I basically built review apps on top of hubot interactions with the Heroku API before review apps existed. It was probably the work of about two weeks to get right.

Yes, it’s automation you have to own, but it changed very little once it was done and provided phenomenal value. I wouldn’t let those features hold you back from exploring other options.

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

#229
post #222

I could relate to the comment on Redis. The only things I can see missing are automated Redis hosting by the platform. There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it. If and when you get big eno…

Perhaps just using an embedded DB would be better in your case? Something like Berkeley DB. Alternatively, just Dockerize it, although I assume it's too much upkeep.

While not as "Redis-y", there are some decent KV-ish managed databases out there:

- Firestore - Cloudflare Workers KV - DynamoDB - Bigtable

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

#230
post #222

I could relate to the comment on Redis. The only things I can see missing are automated Redis hosting by the platform. There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it. If and when you get big eno…

Fly did have a built-in redis cache (albeit multi-tenant / shared) and for the life of me I can't figure out why they'd deprecate it (though, it still works): https://community.fly.io/t/debugging-a-failing-image-without... and https://community.fly.io/t/please-bring-redis-back/1563 If anything, I'd prefer they moved their PaaS more towards serverless and managed offerings than towards IaaS.

On their forums they say they envision some other company handling Postgres too. Personally I would prefer they handle the databases, redis etc because that way the services you need can be provisioned right alongside your app servers otherwise it undermines the value of having edge servers near your users. Heroku could get away with 3rd parties being responsible for the database software because using AWS it was easy for other companies to be in the same region or zone.

https://community.fly.io/t/can-we-get-an-update-on-managed-d...

Post reply on HN