[danjac]

Let's say you have never deployed anything to production before, and you've worked through a tutorial in Rails or Django or whatever and just built your first web app, and it's 2018, what are your options?

There's the zoo of AWS. Maybe there's something there you can use - Lightsail came out I think in 2016 - but good luck trying to find it out of all the plethora of weirdly named services. Again, total beginner here, and AWS can be daunting even to experienced developers.

You can go with Linode or Digital Ocean. You would need to set up a VM with all the dependencies and make it secure. Oh and you'll need a database - should that sit on another VM? What about backup and restore? What about deployment? Sure, you can use Ansible, but that's yet another learning curve.

Render launched in 2019. Fly.io came out 2020. As far as I remember, there wasn't a competitor that offered the sheer convenience for the hobbyist beginner on the level of Heroku.

[post-it]

> You can go with Linode or Digital Ocean. You would need to set up a VM with all the dependencies and make it secure. Oh and you'll need a database - should that sit on another VM? What about backup and restore? What about deployment? Sure, you can use Ansible, but that's yet another learning curve.

An interesting perspective. I started using Linux as a kid, long before I started programming. When I wrote my first webapps, setting up a VM and database was the easy, familiar part. (I didn't really care about securing it.) It makes sense that if someone's first delve into any technical field is writing webapps, setting up a VM and database would be daunting.

[ornornor]

Well yeah the hard part in running your own VMs is security (and backups), if you don’t concern yourself with this then it isn’t super difficult to diy. But how long will it stay online?

[rtsil]

Ten years before that, I rented a cheap dedicated server and learned to use Webmin and Virtualmin. And it wasn't particularly complicated, Virtualmin gave you everything you needed with minimal configuration and you could find plenty of help online for the rest.

And it gave you a certain idea of how it worked, instead of operating on a black box.

[tmpz22]

> you've worked through a tutorial in Rails or Django or whatever

People underestimate the momentum of educational content. The Ruby on Rails tutorial book is a perfect example of guiding people into the Heroku walled garden - and at the time it was a reasonable decision that benefited the readers and (IMO) helped encourage them to go beyond starter-apps and actually put something in the wild.

[cooljacob204]

I used a digital ocean ubuntu droplet with haproxy and certbot back when I first started off. Used their Postgres service for the database and only opened port 443 and 80 to public traffic. Droplet backups for backups if the vm needed and deployments were a manual git pull.

Sure a little complicated but there are plenty of good tutorials out there.

I would say Heroku for a new dev is not actually ideal. It hides way too much of the inner workings and makes it harder to learn about web development. I think it's more appropriate for a startup which just wants a ci/cd pipeline and some redundancy without investing that much time into it.

[danjac]

Digital Ocean's Postgres service launched in 2019.

I mean sure, you can learn all the other bits and pieces and I have no doubt learning them is valuable, but for a novice who just wanted to get something out there - beyond a static website - Heroku was hard to beat. Sure, it got expensive fast, and that's when you should learn how to manage hosting on your own. But at that point you had more of an idea what you needed and why.

[govolckurself]

Why is "learn more about how to properly host something" never an option for people? And in 2018! Suck it up and learn how to secure a VM, folks, especially if you're turning tutorials into production services. Most of those issues don't just go away when someone builds yet another expensive abstraction on top of a server, I promise.

[alx__]

As someone who took this advice around 2016 and setup servers for clients' sites I was building, the lesson I would impart here is: DON'T DO THIS

Maybe do this for small side projects and people who don't care if the site goes down.

Nothing more fun than trying to figure out what your 2016 self did to set up that fucking server based on a half-baked tutorial that was the top Google hit. And now it's crashing, and you don't know what the fuck is wrong. And the client is frantically texting you asking when the site will be up again.

The curse of knowledge gets people to forget how fucking steep the learning curve can be when every Linux thing is new. Especially when you're trying to debug a problem and every StackOverflow answer has you chasing wrong paths.

2023 me would have no problem doing this now, but also why the fuck would I want to waste my time mucking about fixing dumb problems. There's no need to prove how awesome I am at doing DevOps. I'm 100% ok paying a premium to let that be someone else's problem. I would rather solve fun problems than doing endless maintenance tasks.

[govolckurself]

>I would rather solve fun problems than doing endless maintenance tasks.

Not everything in your career will be fun and exciting, and what you consider to be maintenance that you can ignore, some of us consider fundamentals that one ought to know to be considered a serious professional. Food for thought.

Edit: the real lesson is to avoid doing mission-critical, production work for customers without the requisite knowledge. This is hard to hear, but if people don't, they'll overestimate their abilities and get into trouble. It's fine to be junior, it's not fine to oversell your skills.

[danjac]

Again, standing in the shoes of a beginner, you don't know what you don't know.

Heroku offered a path to easy, relatively secure deployment of a database-driven web application. If your aim is to just get something up and running - an MVP - it was probably fine, until it got too expensive. Maybe then you could buckle down and learn the "right" way, or maybe your business took off and you could just keep paying Heroku. If you're running a one-person SAAS, you might not have the time to spend on learning devops, when you have to fix bugs and add features and deal with customer support and sales. Sure, you'll hit that pain point when Heroku no longer works for you, but as detailed in the original post, that pain point may be years off.