As a low-value user experimenting with Heroku (and very impressed with their setup), but potentially interested in moving higher value services there, this is one thing which worries me - their billing is really vague and retrospective, and they require a credit card even for free service if you use any addons - there should be an area where you can set up billing alerts for certain thresholds, and an option to set a threshold (right down to $0) for an app where service will be cut off rather than continuing to bill. That would provide peace of mind which I currently don't have about their services. I'm sure having this would also free up their support as quite a few people seem to go over limits by mistake.
A little experimental app could easily start to overrun limits without the user knowing and run up a huge bill, and this is the only thing about their service which I found unsettling - it gives the impression they're happy to trick you into paying more than you wanted, which I'm sure is not the intended one.
It's a crime to make this comparison with the glaring omission of Engine Yard Cloud which fits smack dab in the middle of these two options.
With Engine Yard you get a proven, scalable, and supported Rails stack, except you retain complete control over it. You have a dashboard and support desk, but you also have root access and the AWS keys. There is complete transparency in what you are charged, and you can run anything you want, just add a chef recipe, you don't have to be nickled and dimed by an add-on or external service just because you need a different piece of software.
Heroku is great if it fits your use case, but if it doesn't then there's no reason you have to go completely vanilla EC2.
The original article was a commentary on Heroku with a short conclusion which included a comparison to the authors experience with AWS. Your comment reads like an ad for a third service which isn't at all related to the original article. If the piece was a general analysis of the PaaS market, maybe it would seem relavent, but to this particular topic it seem tangental. I can't down vote you but I can understand why someone would.
Okay but it's weird to jump straight to AWS when the exact complaints are the strengths of a parallel platform on the same cloud provider. It would be like if someone were saying they were leaving Windows for OS X because Windows is not open source, and totally ignored the existence of Linux. I'd say commenters would be within their rights to bring up the elephant in the room without being accused of shilling.
"I assumed there would be an additional step needed to opt-in before being billed"
Why would you assume this? I explicitly remember using the beta databases for free with the understanding that with the continued usage of those products outside of the beta period, I'd be charged.
I understand your point about not assuming, but I generally get negative feelings about companies that don't communicate clearly when they make decisions for me that cost me money. I think that is the authors primary gripe.
> notice will be provided to all beta users prior to GA release
The only notice I received was in the email newsletter (which I didn't read). It seems reasonable to expect a specific notice based on the language in the blog post.
Try an opensource PaaS like Cloudfoundry. You can use cloudfoundry with bosh to spin multiple ec2 instance and deploy across all of them and you can scale up and down as you want.
I am not affiliated with Cloudfoundry and earn no money from them neither do i have any formal relationship with Vmware. I am bullish on cloudfoundry and use bosh multi-instance and multi-cloud deploy. You can see how cloudfoundry works by testing the commercial version on cloudfoundry.com and the opensource community based articles on cloudfoundry.org.
You can run Java, Ruby, Node, Python, PhP tec and comes preinstalled Postgresql, Mysql, Mongodb, Redis, Rabbitmq.
I was pleasantly surprised with their customer support, but unfortunately they still miss a few features (not being able to run ssh commands on the server is one) that prevent me from using AppFog for anything serious for now. I'm keeping a close eye on them.
This is not a review. To call it that and for this to make it to the front page is a disgrace. This is a blog-rant about a billing dispute with Heroku.
I've had fewer platform errors on EC2 than with Heroku (although many of Heroku's outages were directly caused by AWS failures). So it seems Amazon does a somewhat better job at eliminating most of the need for customer service.
What the new interface appears to do is that it forces users to RTFM. Probably the first step every user in a self-serve system should do before opening a ticket.
After you have searched for the info, then probably you should open a ticket.
Now, if you have premium support. That is a whole new story.
Heroku as a highly abstracted PAAS built over AWS should definitely make it easier for beginners. AWS is there if you need to hit the metal any time. Also the cost of Heroku abstraction is the flexibility you sacrifice in order to get things off the ground faster. You also lose out on new services introduced on AWS regularly or have to wait till similar functionality is available on Heroku.
Tickets are most definitely openable by all, but yes, it is true that the link to open a new ticket is a little buried within the new help site.
As for current invoices amount, the old dashboard used to show you your current usage. I'm not sure when this got lost, but the new dashboard doesn't have it.
I can pretty much guarantee that Heroku are fully aware of both of these problems and acting on them…
Agree with OP. Heroku really needs to add a billing status screen. If you host a free app it's confusing when they will start charging you for usage and how much it will be. You can look at past invoices which shows your how many dyno hours you used, but as far as I can tell there is no place to view this information for the current month until your bill arrives.
I had a very similar issue as well with Heroku. Their support option is buried away in the site. I had a few questions about billing that weren't clear.
When I did find it their customer service was just nasty. "He doesn't have time..." after the fact I was willing to spend a couple hundred dollars doing business with them. He told The irony here is heroku is owned by salesforce....
A coworker set 'tenancy' on EC2 to dedicated not understanding that it meant an extra $10 a hour charge!! The bill came in at a few thousand dollars that month. He contacted AWS and said it was set accidentally. AWS actually refunded the charges. From what i have heard, heroku doesn't do similar refunds, maybe AWS doesn't refund heroku charges.
> [...] believing they would remain free until their general release in August. Heroku’s blog post indicated they would notify users prior to billing them.
OP then proceeds to cite the email which verifies just that:
"We will also begin billing for the paid plans as of August 1st"
Regarding opt-in, he has already supplied his payment info as an existing customer.
Since OP expected this, and did not check in August, I can't help but feel this rant is a bit unmerited. Blaming Heroku is not entirely justified here.
The email was a newsletter which contained many announcements unrelated to the impending charges. I felt they should have made the notice much more prominent and so I'm alerting other Heroku customers to be more vigilant.
While I haven't yet had to open a ticket through the new interface yet, in the past I've received rapid, competent direct answers from Heroku staff, both as a 'free tier' and then (very modest) paid-level user.
So these knocks against Heroku don't ring true for me. I even have to wonder if the author overlooked pointers/responses/notices (as with his opt-in-before-billing-begins assumption).
I love Heroku and use it for everything, but I'd seriously reconsider AWS for some of my bigger apps if I could just get Elastic Beanstalk for Rack apps. Frankly, I'm shocked that this hasn't been released yet.
I'm an apps guy, not devops, and definitely not ops. I can manage an AWS deployment if I have to, but it's not on my top ten list of activities that I consider to be fun.
A little experimental app could easily start to overrun limits without the user knowing and run up a huge bill, and this is the only thing about their service which I found unsettling - it gives the impression they're happy to trick you into paying more than you wanted, which I'm sure is not the intended one.