Dyno redundancy and DNS CNAMEs to protect the rest of the platform if YOU get DDOSed looks to me like things their customers have to do to compensate for shortcomings of the platform.
That's of course totally ok. What I dislike is how it's being sold as a feature or simple precaution.
Why should I pay double because they have to restart my vm? Why can't they bring up a new one and then kill my current one? Why are they talking about isolating DDOSed customers instead of protecting them?
Again, I can see these issues, but don't sell the workaround as a feature
I'm a PM at Heroku. The dyno redundancy check has nothing to do with protecting the platform. It is a best practice for production apps to have redundancy at the web server level. This protects your app from downtime should underlying servers fail, or if the web server process were to crash. N+1 redundancy for the win.
Also, it does not cost customers double because the first dyno is free with each app.
re: DNS CNAMEs, thanks for the feedback! I've updated the relevant section:
> This ensures that in the event of an infrastructure-level issue, core components can be replaced without requiring you to make changes to your apps.
You are right, it's not about protecting the platform from an app being DDOSed - that example was far too specific. It's about ensuring that an app is configured take full advantage of the flexibility and redundancy that our infrastructure is designed to provide.
Setting DNS CNAMEs to a Heroku-provided name make sense. They might make underlying infrastructure changes; that's why you're using them instead of rolling your own on a VPS.
Having more than one worker also seems sensible.
The article stresses that these checks are all optional. You don't have to pay double for anything if you don't want to.
I beg to differ. They are definitely releasing a lot of features lately, but I feel that their core product is degrading. There has been a lot of bugs lately with Heroku.
To list a few, right when the whole debacle regarding concurrency started, they had a bug with their scheduler which wouldn't terminate processes. What ended up happening was that customers got billed for processing time they didn't use. Heroku fixed the billing issue after they were told of this issue. There was also a minor security issue where you could grant applications access to heroku via oauth, but you couldn't reject it. Not a huge deal, but it would be nice to revoke apps instead of leaving them out in the limbo. I could probably name off a few more issues I've been having with Heroku, but my point is, I'd rather they spend more time fixing the current issues instead of spinning off new features.
For starters, I'd love my support request to actually get responded to. To this day (one month later), the support request is still opened. The issue was fixed, however those who were affected received a canned respond. I'm sure thousands of paying customers would not have been aware they were over charged.
"We discovered that your February invoice # was not calculated correctly beacuse of an issue with our usage data system. We have not charged your credit card while we've been investigating and repairing the issue. We will run automatic transactions within the next two business days to collect on your February charges. You can see your corrected invoice on the dashboard:
https://dashboard.heroku.com/account
We apologize for the inconvenience this has caused."
Hey Ricky, we've definitely had some billing related issues recently. We've just finished the initial stages of moving onto a new system which should help clear up the cause of the issues like the one you mention in your last post. Sorry about the delays. If you email me at chris [at] heroku [dot] com and I'll make sure you're taken care of.
they had a bug with their scheduler which wouldn't terminate processes. What ended up happening was that customers got billed for processing time they didn't use. Heroku fixed the billing issue after they were told of this issue.
Is there something about our response here that you were unhappy with? Yes, we had a bug. No, we didn't notice it until we were told about it. But we fixed the bug as soon as we could and refunded affected customers. Obviously it would have been better if the bug was never introduced, but I'm not sure what aspects of our response you'd like to see improved.
edit:
I can only assume that the downvote was because this may have come across as an attack on you. On the contrary, I was merely trying to figure out exactly what part of this experience you were unhappy about. Everything you mentioned in your first post sounded like we had done everything we could have done, and yet you sounded unhappy.
Thank you for giving us more info on your experience so we can try to improve on those areas. I'd encourage you to reach out to Chris so we can figure out what happened with your support ticket.
For one of my apps it says that I'm not using a production ready database. I'm using Amazon RDS. How well will the DB add-ons integrate with this check?
This is correct. If there are no Heroku Postgres DBs, the test is skipped. If there are any, the test only passes if there is at least 1 production-tier database.
That's of course totally ok. What I dislike is how it's being sold as a feature or simple precaution.
Why should I pay double because they have to restart my vm? Why can't they bring up a new one and then kill my current one? Why are they talking about isolating DDOSed customers instead of protecting them?
Again, I can see these issues, but don't sell the workaround as a feature