Live data from Hacker News

Fly.io: The reclaimer of Heroku's magic

christine.website

201–210 of 320 posts

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

#201

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…

Have seen similar transitions in different companies, and while I can't say anything about Heroku, it is often not the target technology or architecture that matters.

For instance I've seen PHP -> nodejs transition while moving to micrservices, and while the ideas made sense on paper:

- It didn't come from the engineers at large. Most weren't phased by the prospect and the main engine for the change was the top architects and the engineering management.

- target architecture and language were very popular, and easy to hire. Incidentally salaries would be cheaper for same level of experience engineers.

Predictidbly a ton of the existing engineers left and new blood came in, and it was mostly according to plan from what I gathered. Some of the "old folks" stayed at a premium once they were the only ones left with enough knowledge, but they got relagated in side "experts" roles and the product as a whole saw a big change in philosophy (I think mentally what was seen as the "core" also became "legacy" in everyone's mind as engineers moved away)

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

#203
post #143

Earlier quoted context omitted.

I'm actually very curious: why is bandwidth so much cheaper on more traditional VPS or dedicated server hosts like Hetzner ? This extends to their somewhat new-ish cloud product, where you get 20TB traffic included - even on a tiny instance. And it's 1 Euro per TB after that. [1] Do they just decide to not profit from bandwidth or are they doing something special that allows them to be so cheap? [1] https://docs.hetz…

There are three ways to manage bandwidth prices: 1. Put servers where bandwidth is cheap (not Sydney, for example) 2. Constrain throughput per server 3. Buy from cheap transit providers like Cogent Hetzner does all three. Bandwidth in the US/EU is very cheap. They meter total throughput on their services. And they use cheap providers. None of these are bad choices, just different than ours. Our product has multiple l…

The chennai pricing in incredibly steep. It's weird that bandwidth prices for end-users in India is among the cheapest (if not the cheapest) in the world but enterprise customers are paying so much.

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

#206

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…

I think that it’s a very complicated answer to this question, .

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

#208

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

We’re not “froze”. The last week has been exhausting fud.

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

#209

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…

Have seen similar transitions in different companies, and while I can't say anything about Heroku, it is often not the target technology or architecture that matters. For instance I've seen PHP -> nodejs transition while moving to micrservices, and while the ideas made sense on paper: - It didn't come from the engineers at large. Most weren't phased by the prospect and the main engine for the change was the top archi…

This is pretty common in corporates too. Shiny new project gets all the attention, funding and management focus. The poor guys left to deal with the day to day crap get screwed over then leave. If they leave too soon its an emergency, if they stay too long they get laid off.

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

#210
post #198

The one thing I'm really missing after looking at a number of hosts (Fly and Render being top of list otherwise) is a free database tier. For a toy app, 10k db rows (across all tables) from Heroku was enough to get the app running and have a public URL to share, and I miss those days. I'm working on a fresh Rails7 toy app to try out some new features, and my current thinking is to use sqlite, and add an initializer e…

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.
Post reply on HN