41–50 of 320 posts
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.
Just use a static hoster for a blog site (like netlify or even github pages).
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.
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 perfect for for a fire and forget blog site. We're not doing ourselves any favors with scary pricing for that kind of app.
After all the chatter this week, I've come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called "features" are exactly what we don't want or need. 1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. 2.…
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.
https://fly.io/docs/getting-started/multi-region-databases/
You do still need to consider the possibility of read replicas being behind the primary when designing your application. If your design considers that from day 1, I think it takes less away from solving your business problems.
Alternatively, you can also just ignore all the multi-region stuff and deploy to one place, as if it was old-school Heroku :-)
Earlier quoted context omitted.
I get the intention with Slack. I’ve never understood, except for the geek cred, pushing work into chat services. Github is open to the team too. I hear complaints about chat distractions and see engineers create those distractions. I’m at a loss why we want to do that to ourselves? Nevermind it’s one more pipeline for messages to lost in. It’s needless complexity and configuration too.
The main reason is to use a chat solution is as a unified ledger / single pane of glass. Silly as it is, there isn't really a better solution out there for "integrate all of my third-party deploy, CI, build, etc. status updates in real time, in one place." Sure, someone can click into GitHub, but if you use another service to deploy into, does GitHub pipe the status of that service into your dashboard? How about erro…
After all the chatter this week, I've come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called "features" are exactly what we don't want or need. 1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. 2.…
Being a small-scale Heroku user, I have a hard time deciding whether to stay with Heroku or move to render.com or fly.io. Before the latest incident, Heroku seemed to be frozen but stable. Now… I don't know. Are they even trying to bring back Github Connect? Fly.io seems cutting-edge but I feel I would not profit from their multi-region, close to the user infrastructure. So what are their tradeoffs? Render.com appear…
Render is more user-friendly and great for teams, but Fly.io is more flexible and has more advanced features
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…
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.
Earlier quoted context omitted.
Just use a static hoster for a blog site (like netlify or even github pages).
I've got a small amount of dynamic content
if something goes crazy and you end up using a wild amount of outbound data, it looks like the next jump up is only to $12
How mature is fly.io?
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.