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

111–120 of 320 posts

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

#111

Post by hthrowaway5 »

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 definitely wasn't the only problem we had but it was a big one.

What do fellow Herokai think? Was Dogwood a fool's errand? Or did we just not get enough staff to build it properly?

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

#112

Post by neojebfkekeej »

nosvince wrote: post #106
treeman79 wrote: post #95

Earlier quoted context omitted.

Most of the time. If heroku is having downtime. Then Amazon is having downtime. Then half the internet is down. Let customers know Amazon is down. Sit back and relax.

Wow, that's a horrible way of thinking about the user experience. And honestly, I'm not surprised. That's why companies that really care about the user experience will always steal market share from those that don't.

It’s actually small companies that care about user experience that will often make these trade-offs. Less time managing multi-cloud deployments means more time spent building our core product and talking to users.

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

#114

Post by Trasmatta »

jpgvm wrote: post #100
closeparen wrote: post #91

Earlier quoted context omitted.

Hot take: if people spent half the energy doing multi-region that they today spend screwing around with Kubernetes, they’d be a hell of a lot more reliable.

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.

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

#115

Post by kbrisso »

Using Fly.io it was pretty easy to to spin up an app.. I wish it used Docker Up/Compose files though. I'm not a Docker expert but being able to use those files seems like it would be easier to deploy apps. Please correct my ignorance if this isn't so.

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

#116

Post by [deleted] »

sanjayio wrote: post #56
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.

Where would you feel comfortable running pacemaker infra? Half-joking here.

[deleted]

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

#117

Post by ceejayoz »

brundolf wrote: post #83
mrkurt wrote: post #76

Earlier quoted context omitted.

We actually launched with that feature: https://news.ycombinator.com/item?id=22616857 No one took us up on it. What we found is that the majority of people want their stuff to stay up, and the right UX for "shut it down so you don't get billed" is not obvious. We ended up implementing prepayment instead. If you sign up and buy $25 in credit, we'll just suspend your apps when the credit runs out. Bandwidth is weird be…

I can't speak for your whole market, but I know for me the pre-loading flow sounds really clunky because I'd have to go and manually add funds each month (right?) It's understandable if your usage data showed the fee-capping feature just wasn't popular enough to be worth maintaining, though that would surprise me based on this thread (but possibly HN just isn't representative of the whole market)

I’d be happy with a “refill if under $10 up to $x/month”. If they can cut off when you’re out of credit they can presumably do it for other criteria, too.

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

#118

Post by [deleted] »

nosvince wrote: post #106
treeman79 wrote: post #95

Earlier quoted context omitted.

Most of the time. If heroku is having downtime. Then Amazon is having downtime. Then half the internet is down. Let customers know Amazon is down. Sit back and relax.

Wow, that's a horrible way of thinking about the user experience. And honestly, I'm not surprised. That's why companies that really care about the user experience will always steal market share from those that don't.

[deleted]

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

#119

Post by antod »

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

I did run some VRRP or CARP stuff (forget the specific tool/protocol - but that's kinda like pacemaker right?) in an immature OpenStack cloud once that didn't have a good LBaaS yet. It was a semi supported hack documented by the provider.

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

#120

Post by iammiles »

anon3949494 wrote: post #37

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

I strongly agree with your last paragraph. I used Heroku for my wedding website and I would 100% use it again on a project site.

In about 15 minutes I was able to take my site from localhost to a custom domain with SSL with just a little more than a git push. I can't think of many solutions that are simpler than that.

Post reply on HN