5 ms·

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

langsoul-com 4y ago
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.
- ryanSrich 4y ago
  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.
  - ghaff 4y ago
    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.
    - dham 4y ago
      > 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
      - darkwater 4y ago
        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.
        dham 4y ago
        They're only complex because developers want to make them complex. It's not a demand from the user.
        Matl 4y ago
        > 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.
        dham 4y ago
        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.
  - jrochkind1 4y ago
    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.
    - joshmanders 4y ago
      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 https://primcloud.com
  - anurag 4y ago
    (Render founder) agreed and great feedback. We're working hard to get there.
- ATsch 4y ago
  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.
- nicoburns 4y ago
  Heroku requires a Heroku.yml, no? Seems pretty comparable to me.
  - xena 4y ago
    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.
    - jrochkind1 4y ago
      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.
  - Fradow 4y ago
    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.
    - yunwal 4y ago
      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.
      - ek750 4y ago
        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.
- mrkurt 4y ago
  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/ 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.
- anurag 4y ago
  (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).
ryanSrich 4y ago
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.
- iviv 4y ago
  I think Render is close to this?
bpicolo 4y ago
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.
skrtskrt 4y ago
DO App Platform would be the competition, Droplets are just bare VMs

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.

ryanSrich 4y ago
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.
- ghaff 4y ago
  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.
  - dham 4y ago
    > 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
    - darkwater 4y ago
      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.
      - dham 4y ago
        They're only complex because developers want to make them complex. It's not a demand from the user.
        Matl 4y ago
        > 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.
        dham 4y ago
        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.
- jrochkind1 4y ago
  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.
  - joshmanders 4y ago
    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 https://primcloud.com
- anurag 4y ago
  (Render founder) agreed and great feedback. We're working hard to get there.
ATsch 4y ago
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.
nicoburns 4y ago
Heroku requires a Heroku.yml, no? Seems pretty comparable to me.
- xena 4y ago
  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.
  - jrochkind1 4y ago
    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.
- Fradow 4y ago
  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.
  - yunwal 4y ago
    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.
    - ek750 4y ago
      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.
mrkurt 4y ago
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/ 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.
anurag 4y ago
(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).

ryanSrich 4y ago

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.

iviv 4y ago
I think Render is close to this?

bpicolo 4y ago

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.

skrtskrt 4y ago

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