Fly.io, Porter, Render, Google Cloud Run, DO Droplets and probably a bunch I'm forgetting.
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.
Made up reasons... to support the ponzi scheme of devops to increase salaries
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.
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.
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.
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.
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
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.
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.
> 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.
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.
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.
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.
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).