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.
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'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.
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.
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.
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'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.
(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).
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.
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.
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.
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.
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.
