Hacker News new | ask | show | jobs
by yesdocs 1599 days ago
Heroku is crap. You can’t deploy without dropping requests, it’s tools are lame and any serious monitoring costs you big $. ‘It just works’ is a layman’s response to the fact that it really doesn’t.
4 comments

I wouldn't call it crap. It certainly has limitations, but for many projects those are an acceptable tradeoff for lower friction. For many projects those limitations cost less than not launching the project at all.

Heroku definitely has a ton more competition these days though. Containerization has really encroached on their main value proposition. Fly.io, AWS ECS and Fargate, Managed Kubernetes, even just Docker on a VPS mostly don't require much more effort than Heroku.

It absolutely has its limitations, but you can certainly enable rollover to prevent dropping requests [1]

Note that the default was chosen in a world where it wasn't natural that 2 versions of an app could be running side-by-side harmoniously, e.g. due to database evolution.

[1] https://devcenter.heroku.com/articles/preboot

For starting new projects it does 'just work'. Super simple to set up and maintain.

Yes, it might not work as well when you start to get more traffic, but for getting setup I have no complaints (aside from this downtime!).

I'd be interested to hear recommendations on what a heroku user should try instead? (particularly for rails/postgres stack, but in general also).
Netlify or Amplify if you want simpler. Managed k8s (e.g. AWS EKS + Postgres RDS) will quite soon be worth it if you need more power than Heroku.
What are some of the limitations of managed k8s? For a lot of scenarios, it really seems like it could be an ideal set of tradeoffs in terms of who manages what and being able to still maintain some shred of platform agnosticism.
The controlplane costs ~$45USD/year to run but so far my experience with it has been super positive. They support new releases quickly and if you're using managed node groups you can do blue/green version upgrades.

The main tradeoff for using EKS is the built-in CNI is limited by the number of virtual IPs you can assign to a given node type's network adapters. If you are running a bunch of small workloads you end up with very under-utilized compute and if you're using autoscaling that results in a lot of churn. We replaced it with weave-cni which has it's own set of headaches in regards to pod access to the control plane but it does allow us to run a basically unlimited number of small workloads on somewhat beefy instances. We set it up using spot pricing and the costs have been very low.

Okay, thanks! My primary interest is for spot instance CI workers, so yeah, the deployment side is a non-issue and having a sane story for auto-scaling many small short-term workloads is exactly my scenario.