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

161–170 of 320 posts

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

#161

Post by hota_mazi »

mrkurt wrote: post #157
augstein wrote: post #154

Earlier quoted context omitted.

Does that mean if my webapps get DOSed or something like that, and I can‘t react very quickly, I could face a bill potentially in the thousands of dollars? Currently considering switching from Heroku, but fixed pricing is a must. I‘d rather they shut down my apps temporality in case something is out of control, then get broke ;-) Any other recommendations besides fly.io?

No, we don't bill people for traffic from attacks. We also waive fees from big, legitimate bursts. The intent of our bandwidth pricing is to allow high usage, sustained bandwidth workloads. It's not to sneak one over on you.

How about large traffic from a legitimate spike (e.g. front page of reddit or HN)?

You have enumerated a lot of alternatives so far (prepaying, waiving attack costs) but you still haven't addressed the number one scenario that everybody has been asking about, and which was the reason why Heroku was such a hit: do you offer a flat fee which, if exceeded, simply shuts down the app until the next billing cycle?

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

#162

Post by nl »

EqNoteqp wrote: post #21
taylorlapeyre wrote: post #14

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.

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.

I'd never, ever go back to working without chat.

We've switched to Discord (because reasons. Slack is much better for work though) and I rewrote a bunch of Slack hooks to get Dicord notifications.

> I hear complaints about chat distractions and see engineers create those distractions.

People will complain no matter what.

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

#163

Post by ditsuke »

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?

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

#164

Post by mrkurt »

hota_mazi wrote: post #161
mrkurt wrote: post #157

Earlier quoted context omitted.

No, we don't bill people for traffic from attacks. We also waive fees from big, legitimate bursts. The intent of our bandwidth pricing is to allow high usage, sustained bandwidth workloads. It's not to sneak one over on you.

How about large traffic from a legitimate spike (e.g. front page of reddit or HN)? You have enumerated a lot of alternatives so far (prepaying, waiving attack costs) but you still haven't addressed the number one scenario that everybody has been asking about, and which was the reason why Heroku was such a hit: do you offer a flat fee which, if exceeded, simply shuts down the app until the next billing cycle?

"We also waive fees from big, legitimate bursts."

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

#165

Post by xena »

Mo3 wrote: post #139
skrtskrt wrote: post #49

Earlier quoted context omitted.

DigitalOcean App Platform has a $5/month flat rate for dynamic stuff on top of two static sites hosted for free... 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

Depends on what you would consider a "wild amount". Their app platforms' bandwidth pricing is pretty painful at 0.10$/GB. With these prices and considering the app platform lacks functionality like multi-regional droplets or VPC integration, they are a subpar choice even compared to Firebase or Amplify.

Author of the post here. Fun fact: if I paid that for how much traffic I'm getting, this post would cost me $5 for being on the front page of hacker news for a few hours.

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

#166

Post by xena »

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?

The next phase after Cedar. It was mostly a "Go 2" style mythical benchmark that they compromised on for private spaces but was never really able to meet.

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

#167

Post by daxfohl »

daxfohl wrote: post #155
mrkurt wrote: post #151

Earlier quoted context omitted.

This is pretty much what I believe. This isn't HN frontpage worthy, but one of the things I'm most excited about is people running production CockroachDB clusters on Fly.io. It is still a little more difficult to use the underlying infrastructure than it should be, but we're getting close.

Neat, I'd say that is absolutely HN frontpage worthy!

And disclosure, I used to be on Azure Front Door team and was the lead for Azure Edge Zones development. I really wanted to do something like fly with that. But it turned out that too many people wanted too many different things. Some needed GPU (some Nvidia, some AMD), some FPGA, some general compute. Surprisingly few cared about Functions (our Lambda-like service), or even Web Apps (our Heroku). SQL Server was a big request; CosmosDB was not. Remote Desktop was another big one. They also wanted availability zones within the edge zone itself. And even if latency was tolerable to the nearest region, we had to put almost all our infra services local too because everything needed to continue working if there's a network outage. And the extra annoying thing that shouldn't have to be annoying -- everybody wanted ipv4.

So it ended up hardly making sense to deploy anything less than like 80 racks per site, at which point it's basically a small region minus a few small pieces.

Then there's just the risk that the people who wanted whatever special GPU or SSD combination would quit wanting them and they'd just sit there unused indefinitely after that. Or stockouts when demand rose due to a conference or whatever that would tarnish the brand. And of course nobody wanted to pay more than like 10% markup. They were more amenable to long term contracts though. It was just hard to figure out the right use case and make it profitable.

Seemed like what customers really wanted out of them were nearby replacements for pieces of their own datacenter. It was exactly the opposite direction of where I was hoping things would go, which was something between fly and cloudflare workers. Not sure what they're doing now; I left about 18 months ago.

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

#168

Post by zoomzoom »

taylorlapeyre wrote: post #14

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.

We’re super early but if all of that running on top of your own cloud using tools like cloud run or fargate sounds interesting, check out www.withcoherence.com (I’m a cofounder).

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

#169

Post by tootie »

quickthrower2 wrote: post #160

Fly.io is a reclaimer. Also see: Vercel, Digital Ocean, Dokku, Netlify, Firebase, Engine Yard, OpenShift, Appfleet, Github Pages, Render, AWS Amplify. Heroku made it easier to deploy, but now it feels a tad bit bit more frictional than other services, including fly.io and these mentioned above. It is probably a bit outdated in that regard.

We use a tool called squash.io. It's geared more for instant QA environment than production workloads, but it has the advantage of being super simple. It just listens for feature branch commits and grabs the docker-compose file and runs it. Funny enough, before we signed up we also considered Heroku since we had a relationship with Salesforce and I was familiar with their product. After an intro call, they never followed up. Guess that was a sign.

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

#170

Post by tnzk »

brundolf wrote: post #41
natly wrote: post #38

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

Most of static site hosts nowadays provide (serverless) functions for you to do something on server side.
Post reply on HN