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.
Fly.io: The reclaimer of Heroku's magic
31–40 of 320 posts
Re: Fly.io: The reclaimer of Heroku's magic
#32Earlier quoted context omitted.
Why do you need to SFTP into a disk?
I was moving a Ghost blog from Render. Ghost is notorious for having a difficult time with hosting assets in S3, so it uses disks. I needed to move the Ghost assets directory for all the posts. This was a ten minute thing in Render. SOL in Fly.
Can you not ssh into a fly instance and then pull?
Re: Fly.io: The reclaimer of Heroku's magic
#33My experience with Fly.io has not been a good one.
If I could sum it up, it would be that the dev ux needs a lot of work, and it seems like they are mostly focused on the fundamentals of the platform first.
Following their guide you get postgres not spinning up and linking to your app correctly and you have to nuke your entire app.
The billing UI is weird and feels cobbled together.
I don't feel secure using Fly right now. But again, they are doing cutting edge shit and are probably focused on the underlying bedrock of the platform. They can always circle back to polish the dev ux.
Right now we're on Render.com and it does absolutely everything we want with wonderful dev ux.
In my mind it's a race: can fly catch up to render's UX before render can catch up to flys global mesh load balancing? We'll see who wins.
Re: Fly.io: The reclaimer of Heroku's magic
#34i'm running https://wikinewsfeed.org on fly.io
very satisfied so far and would definitely deploy there next time!
the killer feature i like the most is automatic prometheus metrics collection
one thing i don't really like about fly.io is the fact that they charge money for free Let's Encrypt SSL certs
Re: Fly.io: The reclaimer of Heroku's magic
#35Earlier quoted context omitted.
I was moving a Ghost blog from Render. Ghost is notorious for having a difficult time with hosting assets in S3, so it uses disks. I needed to move the Ghost assets directory for all the posts. This was a ten minute thing in Render. SOL in Fly.
Can you not ssh into a fly instance and then pull?
No. Flyctl SSH does not allow this functionality.
Re: Fly.io: The reclaimer of Heroku's magic
#36How 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.
Re: Fly.io: The reclaimer of Heroku's magic
#37After 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. File persistence is fine but not typically necessary. S3 works just fine.
It's easy to forget that most companies are a handful of people or just solo devs. At the same time, most money comes from the enterprise, so products that reach sufficient traction tend to shift their focus to serving the needs of these larger clients.
I'm really glad Heroku froze when it did. Markets always demand growth at all costs, and I find it incredibly refreshing that Heroku ended up staying in its lane. IMO it was and remains the best PaaS for indie devs and small teams.
Re: Fly.io: The reclaimer of Heroku's magic
#38The 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).
Re: Fly.io: The reclaimer of Heroku's magic
#39The 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.
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 error logs and alerting, do they go there? If there's a customer incident, does the trust site status show up as well?
On Slack and other chat solutions, it's possible to set up a #operations style single-pane-of-glass channel with deploy notifications, error alerting, and customer communication platforms all pushing to the same place. If an incident occurs, engineers, product, support, etc. can all collaborate around what's going on in real-time without needing to ask "hey has someone updated the trust site yet?" or click into 10 different tabs.
It's honestly pretty good when it works well and really bad and noisy when it doesn't, but it has a place.
Non-engineering are usually in Slack too, which really helps when support, product, or the field need quick answers to easy questions like "has this commit been deployed yet today?"
Re: Fly.io: The reclaimer of Heroku's magic
#40The 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).
what if they want to use a CMS?