I believe that Heroku under the Salesforce's management is a different product that a lot of developers are used to.
It's now in a Cash cow stage: https://en.wikipedia.org/wiki/Cash_cow. Salesforce is trying to extract as much revenue as possible from the company they bought. And guess what - the real margins doesn't come from SMBs and individuals - they come from larger companies with large contracts.
Heroku is no longer building a product for ordinary developer's side-project, or for SMBs or early-stage startups. They are building a product for larger accounts paying 25k+/month.
Customers that are expecting the old Heroku experience just need to look somewhere else. There are a lot of alternatives (such as render.com and many others). But the truth is, none of them is as good as Heroku. Luckily, these PaaS alternatives are getting better as we speak.
There are also different alternatives, such as https://stacktape.com (disclaimer: I'm a founder). For example, Stacktape offers PaaS-like experience directly within your own AWS account. It offers developer-friendly experience, and allows developers to deploy their apps entirely on their own, while at the same time offering the full power and flexibility of AWS.
I have my startup with them and pay them a hefty bill. I had my personal websites on a second account (that should have been a free plan - one deploy every three years, next to zero traffic), and they deleted them and continue to bill me.
I've had multiple customer service interactions asking them to stop billing me and they're nothing short of rude and unhelpful. "We've told you the dozens of steps to take to get us to stop billing you" kind of responses from their top CS head. (Paraphrasing that quote, though I'm sure "we told you" is verbatim).
I think I tripped their janky system up when I started scaling one of my personal projects into a startup. I converted my personal account into my business account and moved my personal websites into a new account. This totally botched their system. The thing that gets me is how unhelpful they've been in dealing with the matter. It's not like any of this is my fault.
As soon as I get bandwidth to take my startup elsewhere, I'm gone and I'm never looking back. It's amateur hour over at Netlify. They're downright unpleasant to deal with.
I'm warning everyone I know to avoid them.
Netlify has weird defaults for everything. It caches almost nothing by default. I had to create a Netlify headers file to tell them that actually yes I would like my CSS, JS, and fonts cached.
Absolutely absurd I had to do that. Even for font files. Because as we all know, the font files change so often that we should never cache them /s
All manner of dumb things like this. Really the only thing keeping me on Netlify is that it has for handling built in. That and fear of changing DNS settings (I use Google domains).
I was thinking about using their identity and access plug-in to build out member access only pages. Would Render have this capability? Or any other non-code recommendations?
edit: and no, they did not stop charging me for youtube TV. I actually had to get a new card number for my credit card for them to stop.
There's one thing that somewhat surprised me though: this line:
> "In 2018 Heroku was pretty much the only option for a newbie like me to get started with web-development"
Was it? Really? I mean, I'm not saying the author did anything wrong in choosing Heroku at the time (after all, who could have known back then what a dumpster fire Heroku would turn out to be), and the commercial success Heroku achieved before going down the gutter shows that it must have had some good reasons going for it, at least on paper before the users are confronted with problems that make them judge the situation differently…
… but I don't really get where that "pretty much the only option" vibe would come from. Maybe It's just me having completely different selection criteria, but from my perspective, there were lots of other options to "get started with web-development" and Heroku was just one among many. I don't see at all by what measure Heroku would have seemed like "pretty much the only option"?
I'm sure the author knew this, but I wanted to iterate it in case anyone misunderstood.
Yet-another-infrastructure-group nailed it in their graphic about "what your infrastructure says about you?"... "Heroku => "You are either negotiating the pricing or deplatforming" https://www.yaig.dev/
BTW, I’m not 100% sure it’ll work: if Heroku updates that zombie dyno’s environment variables, it may still have access to the new credentials :/ (My Redis instance is also a Heroku add-on)
If the configuration only read once during startup, the celery process won't use the new configuration unless it's restarted, right?
That horror when you delete code but it's still running, you're just so confused...
I've forgotten how I resolved it, but man it was a pain to diagnose.
I was so annoyed by the pain of configuring Celery I stopped my project and wrote my own job queuing system.
Job and message queues are ridiculously over complicated - including the one I wrote. For trivial usage, job queuing should be zero config.
RQ or Huey are otherwise fine for anything more complicated. I've rarely run into a situation where Celery is better, but teams just use it because it's the "default".
nowadays, if i need to connect to rabbitmq directly, i just use pika/aio-pika, which are lower level, but a LOT more reliable and lightweight.
Free PHP webhosts have been around for 15+ years
But I guess having salesforce buying them out pretty much stalled their progress, and over time leading them to where they are today.
Anyway this is why we're building something to continue to innovate in this space, there is a lot to do. https://instellar.app
It allows the average developer (me) to spin up docker containers behind HTTPS subdomains together with postgres and other popular services from nothing within less than half an hour.
https://lifehacker.com/showhopping-finds-upcoming-shows-arou...
Anyway, nice to meet you! I enjoyed your write up.
I can't remember exactly what we did but I think we just kept deploying over and over again until the old one finally went away.
Once auth is required for the celery processes, the old zombie wont have access. And if this occurs again OP could revoke access etc.
I haven't heavily used Celery anymore for the past few years, but I remember trying to setup a HA Celery Beat schedule process with Kubernetes in 2019 and hitting this exact same issue! There was an alternative scheduler[1] storing its state in Redis instead of a local file, after a few fixes it was working pretty well: multiple beat processes running concurrently and not firing twice a scheduled task.
Don't know if that still works though.
It is truly mind blowing on how many people keep falling for one of the oldest trick in IT : vendor lock-in.
===
No more vendor lock In 2018 Heroku was pretty much the only option for a newbie like me to get started with web-development. The landscape is very different now with providers like Render, Railway, and more
Moving to another vendor while making it easy to move between vendors doesn't get you locked in.
How, exactly? What happened in 2018 that somehow made it impossible to just host a website?
The real self-hosted solution is running your server off a solar powered yacht in international waters while transmitting and receiving all data via worldwide shortwave radio. Fire any customers not willing to invest in a SW-Ethernet adapter.
My god I wish I could short Heroku stock.
Then add Postgres for another $95. Or if you're cheap like me, you self-host that in your $24 droplet and pay nothing extra.
And then they want you to pay for Crons....instead of just running a cronjob on your dedicated compute?
What is this world coming to?
If you are working on a team and you want everyone to be able to spin up a copy of the production infrastruction for each pull request then PaaS is the way to go. If you just have some random one-off production environment and you are happy to either manage the state of a HDD or a k8s cluster yourself (which comes down to will more so than skill) then DO is the way to go.
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.
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.
And it gave you a certain idea of how it worked, instead of operating on a black box.
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.
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.
I, like you, hate blanket statements. Perhaps I should I’ve emphasized a newbie like me in that sentence? I really knew next to nothing about how web development, and specifically serving your site from a server, works.
I still have some smaller projects running on Heroku. Was running a mid-scale one that we shut down for unrelated business reasons. It's been fine.
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.
Looks like k8s yaml.
> If you are working on a team and you want everyone to be able to spin up a copy of the production infrastruction for each pull request then PaaS is the way to go.
But I get that with k8s + docker too. Everything's containerized. Just run the config, it even brings up the cron jobs.
> or a k8s cluster yourself (which comes down to will more so than skill) then DO is the way to go.
Yeah...that's the rub. Takes a few weeks to learn. Worth the time cost to save the $ cost and vendor lock in IMO.
As I said, there’s more of a issue of wanting to maintain your infra than knowing how to.
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.
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.
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.
Is that really a thing, with HNers of all people? You just use your registrar's/nameserver operator's web tool to point your DNS name to a new IP. Transferring your DNS to a new registrar might be a bit more involved but is guaranteed to be also possible by domain market regulation. Or maybe it is a problem of cache invalidation and/or lack of control over exact timing of DNS switchover? Or, idk, possibly Google-owned TLDs like .dev require Google Domains as registrar? Or does Google Domains (or GoDaddy or other big registrar) make transferring your domain difficult in a dark pattern way? Doubt it though, if even changing pointed to IPs appears difficult, which however shouldn't be something a registrar would have an interest in making difficult.
You want it to be hitless. Unfortunately DNS can take days to fully propagate and you may not see mistakes until it's too late to fix them. This can cause horrifying outages.
HNers should be respectful of DNS changes and plan accordingly.
Now I have to go check and see if it's not caching our fonts. Geez, I just assumed...
> fear of changing DNS settings
I recently had to migrate DNS to Cloudflare to stop a 40,000 QPS DDoS attack. DNS migration was slow, but painless. As long as you plan accordingly and set up the new destination in advance, it should be fine. Hosting DNS at a DNS provider will give you extra flexibility in the future.
I use google domains for dns too, just with netlify as the host.
I did exactly what you suggested, even leaving extra time (a full weekend!) for the DNS changes to propagate. What happened?
Turns out local authorities don't all respect DNS TTL settings and we had a major outage. I had to on-the-fly learn how to configure iptables to act as a proxy for the new server.
The "proxy" was still receiving requests 2 weeks later.
Even if you don’t need HA it’s still worth it for a small team for ease of deploy.
The vast majority of startup web apps don't need anything more than a decent MVC framework (seriously, just use the web as designed) and a fast database. Keep a warm spare of your application running if a box goes down and you need to cut over or something. No, it's not sexy. No, they probably won't invite you to speak at Re:Invent. But your shit will work and it'll be cheap and FAST.
I've seen way too many basic CRUD apps, written by developers who mean well, needlessly overcomplicated in the name of things like "scalability" and "reliability". And guess what? They were some of the least scalable, least reliable applications. I'm talking applications where low double-digit requests per second for basic web pages caused the entire thing to shit itself.
So no, you don't actually need your own mini cloud provider to run a solid service. You just need to know what the hell you're doing.
Docker's interface might seem simple, but it adds an entirely new layer of complexity, with semantics only superficially understood by the vast majority of its users, and nobody ever seems to talk about Docker's negatives. A good rule of thumb might be: if you can't accurately explain how Docker works under the hood, or if you don't understand the OS components Docker itself uses, you shouldn't use it.