Hacker News Reader

Comment by emilsedgh | Hacker News Reader

I think Heroku's aggressive pricing is the main driver behind making them obsolete. I honestly cannot believe Salesforce is so short-sighted with Heroku. Their approach is "Milk it as much as we can until everyone just abandons it for cheaper solutions/clones".

Had they become more competitive in terms of pricing, a large, large chunk of companies would've used them rather than moving to solutions like Kube, etc, or a bunch of Heroku clones which are now taking off as it's being considered a "Sinking Ship".

Just see this:

https://blog.porter.run/why-companies-move-off-heroku/

The reasons they are suggesting [that companies leave Heroku for] (besides the costs) are a bunch of non-reasons and small nuisances. The main reason is the cost, and the cost issue will become bigger and bigger of an issue as competing solutions get cheaper and cheaper, until Heroku is completely sunk and abandoned.

We are still using Heroku and I really hope they would fix the pricing before we bite the bullet and just spend a couple of weeks moving to a cheaper alternative. There's no vendor lock in on 12 Factor Apps you see.

View on HN

Former employee, and you're wrong: pricing had nothing to do with it.

In 2017 we went under a feature freeze and no new features were allowed to be worked on. Anyone can look at the Heroku Changelog to verify this yourself (of course features that were in progress still rolled out over some of 2018). We had tons of attrition (without backfill) and even a layoff afterwards. Heroku is probably 1/3 of what it was at its peak around 2014.

SFDC gave up on us because we wanted to build a developer platform and they wanted us to build an enterprise platform. We sucked at enterprise features so they gave us the axe.

I appreciate you letting us know what happened exactly. This just confirms the basis of my previous comment that this is exactly SalesForce's strategy regarding Heroku: Milk it until it dies.

So the biggest Heroku clone I can think of is Google's App Engine, and it's complicated for no reason. The most comical example is storing/accessing secrets. What should be something like `heroku config set MYSECRET=foo` is instead an entire tutorial on setting up a separate key management system and configuring GAE to use it, which cutting every corner still took me at least 2 hours.

It's like this all the way. Postgres is one click on Heroku, a miniature ordeal on GAE. Yeah I can handle it, but why. Maybe I don't have the patience and there's some light at the end of the tunnel. I thought maybe that light was gRPC, but turns out App Engine ironically can't run gRPC services.

My former employer, a large lumbering fortune 500 trying to play in the agile pool, made extensive use of those specific features...

Secrets should not be on the command line, they get logged to history. Instead should be prompted for like a password.

Only tangentially related, but if you prefix the command with a space, it doesn't get recorded to history.

    $ cd
    
    $ echo "one"
    one
    
    $  echo "two"
    two
    
    $ echo "three"
    three
    
    $ history | tail -3
    10089  cd
    10090  echo "one"
    10091  echo "three"

When you remember to do it, that is.

That is the default on many Linuxes' bashes but it's not universal and you can turn it on or off using HISTCONTROL: https://www.gnu.org/software/bash/manual/html_node/Bash-Vari...

Meanwhile, `ps` etc will still show the secret. Just do it the right way.

I was never sure about this. Sure, they're more expensive than competitors but for a lot of uses they worked out cheaper than the alternatives in almost every circumstance.

We were able to support _hundreds_ of applications, scale up at a moment's notice (applications were _very_ spiky traffic) and we didn't need a single member of infrastructure staff. We had engineers with _some_ backend-heavy knowledge, but nobody who could really get in to the guts of an infrastructure problem.

We charged Heroku out at cost to customers on top of our daily rate and it's barely a rounding error except for the largest of projects.

Don't get me wrong, the overall issue is that Heroku just isn't actively maintained anymore and that's going to put off new customers (as it should), but for those heavily invested in the platform right now, cost is not a factor that will be pushing them away.

While companies move off Heroku because of the pricing, there's still a huge addressable market there given that the Heroku ecosystem (including all its addons) is much more extensive than other similar services. The OP discusses this (that's what the "magic" is all about). Plenty of folks would be willing to pay the Heroku premium if new features were being actively developed, the addon ecosystem was continuing to expand (and addons were kept up-to-date), and the general reliability of the platform wasn't being questioned.

But are there any good alternatives to heroku that have a similar approach (i.e. not spinning your own VM) ?

Fly.io, Porter, Render, Google Cloud Run, DO Droplets and probably a bunch I'm forgetting.

The magic of heroku was everything just worked from a git push, no need to fuck around with Docker and fly.toml files.

Launching laravel app on heroku is magic, git push and done. On render and fly.io? Man I hope you don't suck at Docker cause it took me forever.

Exactly. Every HN thread that mentions Heroku always has people responding with the same half dozen Heroku competitors. In reality, none of them are comparable. If I have to touch Docker at all then it’s not comparable to Heroku. If I have to configure a service at all. It’s not comparable. If I have to do anything other than click a button to add a database, make that database HA, and make backups automated, then it’s not comparable. If I have to manually manage things like environment variables (for managed services) instead of the system just doing it for me, then it’s not comparable. If I have to deal with complicated role policies, and access management instead of just saying who can and cannot push, then it’s not comparable. If it takes more than clicking a drop down to resize a service, then it’s not comparable. If I have to go to a third party website to add something like monitoring or logging from that third party, then it’s not comparable.

You're sort of describing the overall conundrum of the PaaSs starting about 10 years ago. A lot of especially individual developers liked them because, as you say, they were mostly drop-dead simple. The problem is that individual developers mostly don't pay and enterprise app development for good (and bad) reasons has a whole bunch of other requirements which has led a lot of the industry to adopt mostly Kubernetes based container platforms. Which are a lot more powerful and flexible but are also a lot more complex that the original PaaSs envisioned.

> reasons has a whole bunch of other requirements which has led a lot of the industry to adopt mostly Kubernetes

Made up reasons... to support the ponzi scheme of devops to increase salaries

Or maybe because there are applications out there that are bigger and more complex than your typical side-project o SaaS with a thousand users that you deploy in Heroku.

They're only complex because developers want to make them complex. It's not a demand from the user.

> They're only complex because developers want to make them complex.

I get your frustration but have to disagree; solutions like k8s exists because users, (often internal users mind you), expect things like rollouts of features several times a day, horizontal scalability etc.

I know there's a mantra on HN of let's go back to how things were in '95 and in some ways I'd love that but it just doesn't seem possible. You have to remember most devs just want to get their tickets done, they don't want to make anything complex if they can avoid it.

That being said if there's certain trends, (hardly set by your average developer), you have to go with at least some of it if you want to remain 'marketable' unfortunately.

I worked at a company that served 3 million MAU, deployed 30 times a day with PHP and a 4 TB Mysql database. Most of these tools are for companies like Twitter and Google. 99.9% of companies will never need them. The problems are made up, end of story.

I appreciate anecdotes as much as the next person but you're not responding to what I actually wrote; I am simply saying that it is not in the hands of most developers to use/not use these tools. They get no choice. Therefore blaming them is misplaced.

Most developers also don't think they're working at the next Google. There's a different group within many software companies that likes to think so, usually not your ICs.

    Most developers also don't think they're working 
    at the next Google. There's a different group within 
    many software companies that likes to think so, usually 
    not your ICs.

In the past ten years, I've worked at three companies with dozens of developers.

I don't know if they "think they're working at the next Google", but I would say they have close to literally no conception of "performance" that doesn't mean "scaling out" to hilariously overcomplicated architectures that serve mainly to pump metric tons of money into AWS' coffers.

I worked at a company that thought you needed a Redis cluster because Performance Reasons. And they paid AWS handsomely for that belief.

What were we storing in Redis, you ask? Literally kilobytes of ephemeral data (cached values, etc).

A cluster. For kilobytes.

Obviously most examples aren't that nutty, but this kind of thinking has poisoned a whole generation of developers. It's not their money, so who cares about the AWS bill? Fuck hunting for missing indexes in the database, they just spin up a new server. It makes them look better to management because they're "getting things done" and management isn't tech-savvy enough to know otherwise.

And these aren't morons. These are talented people who are also kicking legitimate butt in many cases.

Agree. to this day none of them match heroku's magical DX... which makes it more mind-boggling that SalesForce seems to be really intent on just throwing it away.

Render.com seems to be the closest. It's gotten a lot closer in the past two years. And is basically trying to be more or less a clone of heroku, with a few minor update tweaks for how the world has changed (while heroku has not).

Maybe it'll reach it before heroku fully implodes -- although it's hard because so much of heroku is also the ecosystem, that so many third-parties are adding value to heroku too, from add-ons, to just writing documentation for how to integrate their thing with heroku, to external non-approved "add-ons". (If the hirefire.io developer is reading this... hirefire for render?)

Fly.io is also really interesting -- for trying to do something different than heroku, actually much more sophisticated/interesting than heroku, but the trade-off is that it's not really as management-free as heroku, it has seemed to me. (I don't want to write a Dockerfile, nope). But maybe it'll get closer too.

I agree wholeheartedly to all this and honestly, Heroku has been the gold standard I loved for years, and because of the decline had started building my own alternative with the rest...

Biggest differentiator with me and the rest? They focus on "look you can git push to deploy, we're just like Heroku!" while I am all about this DevEx.

So like parent OP said about what is comparable is my goals too.

I hope my product and vision of being "What if we rebuilt Heroku on today's tools with the DevEx?"

You can learn more and sign up for beta at https://primcloud.com

(Render founder) agreed and great feedback. We're working hard to get there.

I'm personally happy to mess around with docker for an hour once if it lets me save 50%+ on running it.

It's true that Heroku has a better experience, but that doesn't matter if the NRE for making it work on a cheaper platform is recouped after barely a month. I think the fact that these services are able to be successful despite having a worse experience shows how uncompetitive Heroku's pricing is.

Heroku requires a Heroku.yml, no? Seems pretty comparable to me.

It used to not to. Before the heroku.yml file it did most of the things with either auto detection of build packs and implicit procfile generation. You could git push a vanilla rails app and it would just work. It was magical before then.

Still is. I don't use a `heroku.yml`. That appears to be an alternate available path, I don't know how many heroku customers use it.

It doesn't, no. I don't even know what that is (well a quick look at the documentation: it's about Docker, which is not needed for Heroku).

All it requires is a Procfile, which can contain a single line telling how to start your server and that you can extend to add other process types. It's not even needed for simple apps.

Genuine question, is a Procfile really that preferable to a Dockerfile with equivalent functionality?

> cmd: python helloworld.py

doesn't seem massively less complicated than

FROM alpine CMD ["python", "helloworld.py"]

FWIW, I've never used heroku in production so maybe it's more about the constraints of heroku than the number of words, but it just doesn't seem like a huge deal to me.

I'm familiar with docker but certainly not an expert, so this is surprising to me. Is it really possible to have a single line dockerfile?

The smallest one I've used was probably a screen full, due to updating packages, setting up bundler paths, etc. A production dockerfile is much larger with non-root user shenanigans, etc.

But to answer your question about Heroku, a Procfile is much smaller and more constrained in scope than a Dockerfile.

> I'm familiar with docker but certainly not an expert, so this is surprising to me. Is it really possible to have a single line dockerfile?

Not single line, but two lines, sure. Though you're at the mercy of your upstream image and how it configures things. Though I guess that's also true of buildpacks.

Plenty of my Dockerfiles are no more than a couple lines.

Heroku was still nicer in most ways of course, at least in my opinion.

Since I've never used Docker, I can't answer.

A Procfile works well with what you'd want to do on Heroku: run a webserver, and maybe run some other worker process. It's a single line per process, equivalent to what you run locally.

You are correct about Laravel apps, but there's some nuance here. The Heroku magic only worked for Rails in the early days. We (Fly.io) have a similar experience for Phoenix, Rails and Remix apps. We don't have magic for Laravel yet (soon: https://fly.io/jobs/laravel-specialist/).

Docker images are a way for people to run anything they want on Fly.io. You probably won't need them on one of our happy path frameworks.

(I work at Render) You don't need to use Docker to run your app on Render. Just a build command or script which can do anything (e.g. `npm build`) unlike buildpacks which force you into a specific way of doing things.

If you've tried Render without Docker and it still took you forever, that's a bug we'd love to fix if you can email me (in profile).

For anyone reading, none of these are comparable to Heroku. Yes, it’s a server in the cloud that can host your app. Heroku does much much more than that. I never want to think about DevOps or infrastructure. Like literally ever. I want to click a button and have everything work. That’s the power of Heroku. I don’t see any other product that does this 100% of the time like Heroku does.

I think Render is close to this?

Cloud run has been nice, but I really wish I could get a shell in a container in the same environment as my app. The “jobs” feature they’re launching seem like it will help for some use cases of this but having a shell for debugging is something I miss.

DO App Platform would be the competition, Droplets are just bare VMs

That experience is pretty much exactly what Cloud Foundry offers. There are companies offering CF as a service, so very like Heroku, although they're a bit hard to find, because they all rebrand it and roll it into some larger awful cloud offering of their own.

Possibly the most clearly and simply CF-based is from Swisscom:

https://www.swisscom.ch/en/business/enterprise/offer/cloud/c...

Even there, i see no links to getting started docs, or pricing.

Im doing a project in Vercel (NextJS ) and Firebase and once you get used to the recent Firebase api changes (they are fine but makes searching for answers harder) it is a fairly ok MVPing solution. You can go a long way for $0

You can get really close by using the one click Dokku deploy on DigitalOcean. Technically it is your own VM, but in practice you just set your git remote to that IP and use it like you would a Heroku instance. It even supports the Heroku build packs!

But then I have to run a server.

Very minimally, sure. You also save a whole pile of money.

The point of Heroku is that I don't have to run a server.

The blog post we're all commenting describes the point of heroku as to lowering the barrier to entry for deployment. It's about the number of things that you don't have to think about. As a sibling comment says in Google App Engine you also don't have to run a server, but it's much more complicated to use (I ran a startup on it for a while).

> The blog post we're all commenting

Was written by the person you are responding to.

https://appharbor.com for .NET (though not many recent signs of life).

Scalingo is mostly a clone with some twists

https://scalingo.com/

Contrarily, I think there are many heroku customers who would be happy to keep paying for it if they just kept actively investing in it. Maintaining it and delivering new features necessary to keep up with the changing environment. But, they are not.

How much do they charge?

Heroku's pricing model is absurdly complicated. [0] But for anything nonfree, you're probably going to end up at over $100/mo, even if just by accident.

To compare it to one of their current competitors, render [1], for something with all the same features as gave me that $100/mo figure, you're looking at about $15/mo.

[0] https://www.heroku.com/pricing

[1] https://render.com/pricing

And if we look at some European cloud providers' prices, it becomes painfully obvious that any such services (even incl. Render) built on top of major US cloud providers are excruciatingly overpriced - the markups can be as large as 5x for equivalent compute: https://www.hetzner.com/cloud

This combined with something like Doku gives one a sense of what could be possible.

The thing is that Hetzner is unfortunately still missing some of the low hanging fruit cloud services.

I'm building a product that intends to bridge that gap[0] -- but I think it should be done in a way that works for any provider. There are so many other smaller providers out there with decent prices, but that are completely missing the services.

It's been getting better recently though! Aiven also just raised a bunch of money, so maybe we'll see a decoupling of services from the same to multiple clouds as they expand as well.

[0]: https://nimbusws.com

Please stop suggesting Hetzner for every random problem in existence.

I've been a happy Hetzner customer for years, BUT

1) They are cheap because they are comparable to a discount supermarket chain

2) They are not a cloud platform

2.1) They offer none of the advanced features available on modern cloud platforms

2.2) It would be almost impossible to build a PaaS like Heroku on Hetzner infrastructure

3) The latency to anywhere outside Europe is pretty bad (regarding EU data centers) and their network is not the best (regarding the whole network)

4) The cheap dedicated server offerings are consumer hardware (and possibly thus are the hosts for the cloud services), and the more expensive server hardware offerings are not necessarily cheaper than other options

5) They have consistent issues with their virtual/cloud offerings that are not remediable due to the aforementioned lack of advanced PaaS functionality

There is much more going on behind the scenes of a platform like Heroku than a single dokku instance on a budget host. You are comparing single apples to a global distribution chain of bananas.

I use hetzner personally (the OP article is hosted there) and I can't agree more. It's incomparable. You can get the first 90% of Heroku sure, but not any of the other 90% of reliability.

Besides reliability, the moment you need to scale up, you wish you were on Heroku or a real PaaS. Although their pricing model is unacceptable and there’s many better options by now.

We too use some Hetzner servers at work for infrequently accessed databases that have no need to be highly available. We recently migrated non-production logging to a Hetzner dedicated with 8TB of HDD. Almost unbeatable price.

Choose the right tool for the job. I have nothing against Hetzner, but I’ve been seeing them mentioned dozens of times in unsuitable contexts by now.

Thanks for the insights :-)

To put that in context, I've been a (mostly happy) architect on all three major clouds for several years. The thing that "triggered" me to explore alternative options is GCP's continuing pricing increases across the board, and it's extremely bad pricing model for indie projects (that used to NOT be the case).

One thing to realize though is all of this is VERY relative - reliability etc. CAN be achieved by using proper primitives (Kubernetes etc.), but that comes at the cost of additional setup. That does however has its upsides too, meaning that these days pretty much everything under the sun can be done via K8s on bare metal, and migrated later somewhere else with relative ease.

I haven't found GCP to be particularly expensive (besides for some subservices) - for indie projects, Firebase is top notch and, depending on your use case free or almost free -

I've always held the opinion that the markup on GCP, AWS, etc, is more than remediated by the savings in manpower requirement and cost of maintaining your own infrastructure.

Don't get me wrong, I love playing with self-hosted k8s for non-production, but when it comes to production, there's no real room for mistakes, downtime, constant maintenance and whatsoever.

If I had the time, or we had a dedicated SRE, sure - that might be a good path forward - but only if there is the chance of outgrowing the cost/profit ratio at some point. Unfortunately, what we provide at work is not a public offering, yet at the same time its being used by institutional money and has to have phenomenal availability and stability - I'd be hard pressed to sign off on a move to anything else in that case..

Yep, I like serverless offerings too (although some services, like Firestore, still leave much to be desired).

The problem is, big enterprise is "all in" on K8s and that becomes hard to reason about because when I tell them "use all of the optimizations available via GKE" they bark that that "ties them to GCP". But then when I wear another hat (as I did above) and suggest the opposite, folks in the other camp say we shouldn't rely on self- or semi-self-managed options. It seems there's no "win" here :-)

Also, to put in context what I meant above re recent price increases on GCP:

1) Per-cluster fee when it used to be free. This hurts hobbyist projects in particular (and yes, I know about the free tier for one zonal cluster, but that's not enough for playing around with one prod and one dev cluster env...).

2) Regional VM to multi-regional bucket traffic when it used to be free. This one is a huge degradation - used to be one of the selling points for Google's "Global Network", and there appears to be no excuse for it other than money-making, as Corey[0] famously mentioned. This hurts us in particular because we process so much data that this matters - right now, our (already exorbitant) cloud bill is a time bomb that is expected to go up on the scale of 50% or some such. Yeah :-)

Despite charging a lot even for internal traffic, AWS never increased pricing for any of their products, as far as I know (indeed, they decrease it over time..). That says something about GCP's reputation - it's a problem unique to Google Cloud, afaik. It breaks the fundamental trust in the platform.

[0] https://www.lastweekinaws.com/blog/google-cloud-alters-the-d...

While 100$ is a lot of money, it is not so much in business environment, I mean even a cheap software developer costs probably more than 5000$ (full cost calculation) per month. But complicated pricing is a big no-no. I mean everytime you find you need a slightly different plan going again through the purchase department?

I think Heroku just got a dead zone in pricing. It's too expensive for a single developer (for comfort at least), but any 'proper' company, even with only a couple of full-time developers, can afford the overhead to set things up in AWS.

Disagree on a small company having time to setup AWS. I work in a 2 man team, and that would be about the last thing on our priority list. We spend ~$500/month on Heroku and while that’s a lot more than it would be elsewhere, it’s also non-issue. Heroku’s main problems are:

1. There are now comparable competitors that are cheaper.

2. They seem to have stopped maintaining it properly which is gradually leading a loss of trust.

My data point in contrast to your suggestion is a company with more than a dozen developers, and a loose idea of "let's migrate from Heroku to AWS without planning much or actually educating our developers on how to use AWS to be as productive as they were in Heroku"; more than a year later, there was definitely some success to speak of, but there was a lot of realization that some of our systems were just fine on Heroku, and that we didn't have the DevOps talent to help us manage AWS better than Heroku was already helping us.

Suffice to say a “cheap” developer costs way more than $6k/year

The 100 was per month so the 6k is also per month. But let me ask: if no time is specified, is salary alway considered per year?

Depends on your locale. In the US, yes. Many parts of Europe (all?), no.

Thought it said $500 when I first read it. Must have misread

If you have a purchase department, you likely are on an entreprise plan, for which the purchase department is in direct contact with a Salesforce account executive, and that becomes a non-issue. The purchase department negotiate directly Salesforce based on projected usage, with periodic re-evaluation.

Reply on news.ycombinator.com