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

301–310 of 320 posts

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

#301

Post by brundolf »

sodality2 wrote: post #298
jen20 wrote: post #288

Earlier quoted context omitted.

Good will does not feel like a good way to scale this. For a business that might be ok, but I’m highly unlikely to recommend to a business something I haven’t personally investigated, and I’m not writing cheques whose value is dependent on the good will of a startup. I don’t understand why cloud providers will not accommodate this basic “prepay to X and allow me to use the credit” model.

>I don’t understand why cloud providers will not accommodate this basic “prepay to X and allow me to use the credit” model. They actually do: > You can configure fly.io apps with a max monthly budget, we'll suspend them when they hit that budget, and then re-enable them at the beginning of the next month. From their Launch HN: https://news.ycombinator.com/item?id=22616857

According to this they got rid of the feature at some point: https://news.ycombinator.com/item?id=31391451

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

#302

Post by throwaway892238 »

tptacek wrote: post #149
throwaway892238 wrote: post #147

Earlier quoted context omitted.

It's interesting that their bash init uses fg %1 . That may return only on the first process changing state, rather than either process exiting. It should probably use this instead: #!/usr/bin/env bash /app/server & /app/server -bar & wait -f -n -p app ; rc=$? printf "%s: Application '%s' exited: status '%i'\n" "$0" "$app" "$rc" exit $rc

That looks a million times better than the horrible hack I wrote. Do you want credit for it when I fix the doc?

Only if it's credited to either "IPBH" or "Some Bash-loving troll on Hacker News" (ninja edit, sry)

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

#303

Post by Andys »

cultofmetatron wrote: post #296
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…

I just don't understand all the fetishism for go. At its core, its a brutally pragmatist language optimized for engineers who barely understand closures while running reasonably fast. need a garbage collected native compiled language?/ - ocaml fits the bill and provides better type checking need a fast as possible system? - rust is faster and has much better abstraction for type checking. unless you're writing a thro…

Rust probably didn't exist when this decision was made.

Out of the box from day one, Go is great at writing HTTP services including proxies, which is a large part of what Heroku needed. Ocaml is harder to use and not a popular choice for such things. Go has easy to follow docs and tonnes of useful contemporary libraries. Go is especially easy to pick up for anyone with older C experience.

I've found Go excellent for the long term, when you come back to something that hasn't been touched for years have passed, it compiles and run quickly and easily. I wouldn't have thought it was any good until I actually used it for something.

Also, concurrency in Go is braindead easy, there are multiple choices of "worker pool" libraries and queue/messaging choices. You don't even have to know about channels to do work across cores.

EDIT: Having said that, if you already had Erlang and an experienced team, you wouldn't ditch that for Go. Why do companies do this? Is there some famous historical case where keeping and growing a highly experienced team has backfired?

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

#304

Post by tptacek »

throwaway892238 wrote: post #302
tptacek wrote: post #149

Earlier quoted context omitted.

That looks a million times better than the horrible hack I wrote. Do you want credit for it when I fix the doc?

Only if it's credited to either "IPBH" or "Some Bash-loving troll on Hacker News" (ninja edit, sry)

Done!

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

#305

Post by manigandham »

newaccount74 wrote: post #293
manigandham wrote: post #263

Earlier quoted context omitted.

That's limited to free tiers that usually deactivate or delete if there's too much usage. Anything with production usage and pay-as-you-go pricing means data at rest still costs money - and requires deleting to avoid accruing new charges. Do you want your databases and volumes and object storage deleted when your app stops? And if this was offered then there would be a whole new class of mistakes leading to lost data…

The high charges are almost never storage costs, its almost always processing or bandwidth. And storage costs are simple to predict -- as soon as you see the cap would be exceeded, stop accepting new data.

Overages are overages, whether its 1 penny or thousands of dollars. Data also still costs money per time and can be unpredictable.

This kind of pacing and billing buffer is an immense amount of complexity at scale for very little benefit (even if an individual user might like it).

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

#306

Post by joriskok1 »

jshen wrote: post #196
franciscop wrote: post #156

Earlier quoted context omitted.

This is the reason I use Heroku and would never on a personal level use some of the bigger solutions, or apparently Fly.io. As an individual and despite being generally careful, I just cannot have a tiny risk of having a $100k+ accidental bill. I'd rather my project goes down if there's a DDOS attack, or if I made a typo and created an infinite loop. If I take some of my hobby projects to the "next level", it'd be de…

Have you looked at render? Been using it for my hobby sites and am very happy with it.

I also really like render, very easy to use.

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

#307

Post by newaccount74 »

manigandham wrote: post #305
newaccount74 wrote: post #293

Earlier quoted context omitted.

The high charges are almost never storage costs, its almost always processing or bandwidth. And storage costs are simple to predict -- as soon as you see the cap would be exceeded, stop accepting new data.

Overages are overages, whether its 1 penny or thousands of dollars. Data also still costs money per time and can be unpredictable. This kind of pacing and billing buffer is an immense amount of complexity at scale for very little benefit (even if an individual user might like it).

Can be unpredictable? How would data storage costs increase if you stopped accepting new data?

SaaS companies manage to pull of ridiculously complicated things, but coming up with a billing scheme that does fuck over the customer is asking too much?

The simple truth is that usage based pricing is designed to be unpredictable, and surprising customers with high bills is probably considered a feature, not a bug.

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

#308

Post by atraac »

Andys wrote: post #303
cultofmetatron wrote: post #296

Earlier quoted context omitted.

I just don't understand all the fetishism for go. At its core, its a brutally pragmatist language optimized for engineers who barely understand closures while running reasonably fast. need a garbage collected native compiled language?/ - ocaml fits the bill and provides better type checking need a fast as possible system? - rust is faster and has much better abstraction for type checking. unless you're writing a thro…

Rust probably didn't exist when this decision was made. Out of the box from day one, Go is great at writing HTTP services including proxies, which is a large part of what Heroku needed. Ocaml is harder to use and not a popular choice for such things. Go has easy to follow docs and tonnes of useful contemporary libraries. Go is especially easy to pick up for anyone with older C experience. I've found Go excellent for…

> Having said that, if you already had Erlang and an experienced team, you wouldn't ditch that for Go. Why do companies do this?

You don't get promoted until you do the new shiny thing. This seems to be especially prominent in Google and the likes. Big companies do not give out bonuses/promotions for those who quietly sit and work with existing, proven stack, maintaining it and fixing bugs. Shiny new things get noticed.

It might also be caused by staffing issues? Erlang/Elixir to this day are pretty niche stacks. It's much easier to find Go developers(or developers willing to switch to Go), than Erlang.

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

#309

Post by ignoramous »

cxr wrote: post #102
ignoramous wrote: post #81

Earlier quoted context omitted.

Fly.io isn't as much cutting-edge as it is a rethink on what devex on Cloud should look like. It is a fantastic offering that despite its shortcomings is really a delight to use. I use it for toy projects (mostly stateless, or state stored elsewhere but not on Fly.io), but there are plenty who run pretty serious workloads. Give it a spin! You'd be surprised how butter-smooth all that cutting-edge is.

> [...] despite its shortcomings [...] What do you see as some of its shortcomings? Do e.g. semi-broken docs (or other instances of unclear/uncertain messaging) factor into your impression?

Docs, oh god yes. They're the anti-Stripe in this regard.

And hard-to-debug deploy-time (and sometimes runtime / uptime) issues are a major sticking point. It is hard to know what or who's at fault without asking for it in the forums, since you can't stackoverflow much.

Their support (granted it's free) is a bit of a hit and a miss; while it isn't clear what really is on their roadmap (or important) and what isn't (even though, they are more than transparent than other providers I've interacted with).

These are but pains that come with adopting a nascent ecosystem, I suppose. I still persist with Fly because it is still simpler to build certain apps on it than on any other BigCloud (bar Cloudflare).

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

#310

Post by manigandham »

newaccount74 wrote: post #307
manigandham wrote: post #305

Earlier quoted context omitted.

Overages are overages, whether its 1 penny or thousands of dollars. Data also still costs money per time and can be unpredictable. This kind of pacing and billing buffer is an immense amount of complexity at scale for very little benefit (even if an individual user might like it).

Can be unpredictable? How would data storage costs increase if you stopped accepting new data? SaaS companies manage to pull of ridiculously complicated things, but coming up with a billing scheme that does fuck over the customer is asking too much? The simple truth is that usage based pricing is designed to be unpredictable, and surprising customers with high bills is probably considered a feature, not a bug.

Data (and all resources) cost money per time. You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges.

The billing scheme is very transparent and friendly by being pay-as-you-go. It doesn't "fuck over the customer".

Your entire complaint isn't about the pricing scheme but about an additional feature to stop billing at some point - which I've explained is not easy to calculate precisely because charges accrue on time and adding even more complexity for calculations and potential for mistakes is not worth it for the many reasons I outlined previously.

> "The simple truth"

You keep repeating that word. There is nothing simple about this. Let's end this here.

Post reply on HN