Heroku shouldn’t be sandbagging paying customers who have low-traffic apps
blog.3solarmasses.com
blog.3solarmasses.com
You are incorrect. We idle single-dyno apps that have not recently received requests. We do no caching, unless you are running an old bamboo app and are therefore going through varnish. See https://devcenter.heroku.com/articles/dynos#dyno-idling
If you don't like this behavior, that's something to complain about. I'm just stating facts to help explain why his assumptions are incorrect.
The greater underlying problem is there are some customers who only need one dyno (especially those of us who are running unicorn. My dyno can handle three times the number of requests) and we would rather spend a little extra on an upgraded database or some other addons.
Imagine how many free apps are created that are never used again. Should Heroku really devote resources to these apps? I think it's perfectly reasonable to idle them after a period of inactivity. If they didn't, they would need more resources and ultimately the customers would be paying for that. They aren't a charity, they are a business.
It's pretty simple, if you don't want your app to idle out after 1 hour of inactivity, buy a dyno for $35 p/month.
The issue is that there is no hour of inactivity because there is web monitoring/querying supposedly going on automatically. So there should be no idling.
Like I said, if Heroku did provide the resources for all these free apps (and there must be so many that aren't used) then that would be reflected in their pricing. I pay for Heroku and don't want to be paying more to compensate resources for their free apps.
Also, bgentry stated "We idle single-dyno apps that have not recently received requests. We do no caching." This also seems to contradict what is happening and adds to the confusion.
Why not just clarify what exactly is going on? It's completely reasonable to be handling this kind of situation however they are doing it, but it's not reasonable (IMHO) to repeat and support misleading/incorrect documentation.
This seems like a reasonable pricing model to me. And it seems reasonable to me that they don't document _exactly_ in what circumstances the free dyno might spin down on idle. Free is free.
If on the other hand even with the paid extra web dyno you were still getting ~10 second spin up times after idle, that would be something I'd get annoyed at too.
If you're willing to pay over $100/month on services you may or may not need just for the learning experience -- perhaps scale some of those back, and instead pay $35/month for the web dyno you do actually need to avoid the idle spin up time.
I do think it's true that heroku can end up being a lot more expensive than you initially expect for what you need, the extras can add up quick. This certainly can be frustrating. Even when you really are paying only for what you need, things can get expensive for a non-tiny app. But if you want to minimize your costs, you definitely want to avoid paying for add-ons you don't need.
He has purchased other addons and is complaining he isn't getting the benefit from this one. Of course not.
Yes, you are paying for a bunch of other services; but, well, those services aren't the actual web dyno that processes the actual request.
Perhaps they could phrase their offerings better, but my impression was that the 1 free dyno with idling is intended for development and testing, not for production use. Once you actually need to use it in production, you need to pay for a dyno.
So now I have 3 dynos (2 production, one staging) for $35/month, I can scale up or down at will, deployment is dirt simple, and I don't have to do the sysadmin crap myself.
It's an extreme bargain, IMO.
Now if the project takes off to the point where I need dozens of dynos all the time, that will be different, but ideally in that case I could hire a sysadmin. :-)
I'd say just pay them another $35 a month. Considering the miracles Heroku regularly performs as an ops team, it's worth it.
Yet you have a 507KB (!) image on your site's home page. Optimizing that would go a long way toward improving the end-user experience.
2. It matters to every user that loads the page, regardless of how much traffic you're getting.
3. As a side note, this info page is nearly 2MB on wire. Turn on gzip (like 700KB+ of JS/CSS and stuff) and figure out what else is taking up so much transfer.
This could be something as simple as them ignoring pings from pingdom when deciding to spin up workers, have you tried using curl to simulate hits? Heroku would probably be happy with you moving to linode, it suits what you want to do a lot more.
Re the image, if you're serious about learning about site optimisation, and dealing with load, yes it does matter, far more than your db until you reach much larger scale.
It's a pretty cheap way to have servers set up with 24/7 monitoring and technical support.
Setting up a vps and automating deployments is not very hard, it would be useful experience if he plans working on startups, and it would also be massively cheaper and could host tens of sites like his. If he wants to pay heroku to deal with all of that, he should accept that it will be costly, and reasses his priorities and direct resources where they are needed. heroku gives you the tools to do that - ditch crane db for example and other caching add ons, and buy dynos rather than trying to use the free dyno for a proper website.
But I wonder if that comparison "I think Heroku is a perfectly fine option until you reach the point where you could hire a full time dev ops" is actually one anyone makes in reality. A full time ops person is going to cost way more than $100 a month, quite a bit more than several thousand a month in fact. Are there really people who would go with heroku until they're paying $5 or $6k a month or more, and somewhere around there (that's a lot of heroku), say "Gee, _now_ we're paying enough (barely) to hire a fulltime person to manage the servers ourselves, let's switch everything to that."
Could you detail what I would not need to do when I'd chose Heroku? What "expertise" you are speaking of, apt-get?
I'm confused these days about cloud and how this would save me "full time dev ops". Could you elaborate?
One night, working for a CMS design agency, and running a launch for a new Rails app, I tried installing nodejs onto our dedicated server so Rails could compile the new coffeescript stuff we were running with.
Of course Node then tried to update NGINX or something (I'm a little fuzzy on the details, but this server had been around for a while) and then NGINX complained about something being misconfigured and wouldn't let us restart it, and so then we were stuck with 100+ rails apps sitting on this server, and we couldn't change the configuration for any of the apps, or launch this new app, and it's 11 PM, and I just want to drink a beer and go to bed, and the client's yelling, and
— so, I'm perfectly OK with not having 10 years of server management experience. Heroku just works. Almost 100% of the time. And every app's isolated.
I got into this business to ship products for customers, not figure out how to make dependencies of 3rd-party libraries on 4-year-old-server-builds play nice. If that's what you've gotta do, that's what you've gotta do, but I'm not really inclined to pick up 10 years of experience managing servers unless I have to.
My hypothesis is that everything interesting that happens to servers is not covered by Heroku.
I think you underestimate what it takes to run your own infrastructure. I'm not saying it's black-magic hard, but it does require a not-insignificant skill set for all but the simplest of setups.
Taking another of my hats, the CTO of a million-user business hat, I still don't know what TCO wise the cloud/Heroku brings to the table. I know about the fast scale up and scale down benefits, no 12 months contract, OPEX vs. CAPEX etc. but have not found any TCO cost calculation based on real tasks people need to do on rented servers vs. cloud.
The logs should show 'idling' when idling and also show the 'pings' from pingdom and/or new relic. Looking through that it'd give us all something concrete to discuss - because quite possibly this is just a bug with Heroku's dyno idling that could have simply been submitted as a support ticket.
I contacted support about this a while ago (was in a similar situation). Their response was "Use more than one web dyno". I didn't need more than one, but that was the only way they offered to allow my app to not "go to sleep".
I agree that Heroku could do a better job of explaining their offering, but I don't think they're doing anything wrong.
I see no problem with their support response, it was accurate.
What is the best way to host a bunch of low-traffic sites for less than $35 (I believe that is what it costs for the second dyno, required to keep your app from being spun down) each per month? The usual answer is "PHP", but I sometimes wonder if there'd be a market (and way to make money) for Heroku-like ease of deployment/management, billed based on resources (much like a VPS) rather than per application.
It hosts email, various domains, static, non-static, Python, Ruby, Postgres, MySQL ... and I don't pay a cent more for each of those services.
One of the sites I host on there has been Reddited and it didn't even break a sweat...
I'd venture that there are far more people using Heroku for its easy deployment and management than its ability to scale quickly and easily.
That's well and good but I wouldn't be so quick to pass off on dedicated. A simple 50-100 line fabric script that takes 30 minutes to write can manage your custom deployment for you. And guess what, your next project will be even easier to deploy because of that same script.
If the only reason to use Heroku or other of its kind is easy deployment - maybe we just need better deployment apps that can work seamlessly across servers.
Heroku certainly thought so. That's why they got a few dozen brilliant programmers into the same building and made it happen.
Of course, with a ~$5M/year burn rate, it's probably also why they charge money for their services.
(making up numbers here, but assume 30 developers at $150K => ~$4.5M so I would guess I'm laughably low)
But I am still weary about using them for anything serious. I thought they were just for bittorrent.
I use Linode for sites I actually care about.
As for actual hosting? They are fast, have plenty of banwidth, and I am able to saturate my home cable link (Comcast in Colorado) using my service located in their Canadian datacenter.
Ping times aren't that fantastic, but for most of what I serve up it isn't an issue that the connection took 50 ms to set up, rather than the 35 ms from a US based host (Although a lot of that comes down to the extremely poor routing choices that Level 3 seems to be making on my way to Canada.)
What I have noticed is that my European visitors are happier, from across the ocean to OVH's BHS datacenter is about 90 msec, whereas from there to my server at Softlayer (Dallas, TX) that easily goes up to 150 msec.
A few of my sites that are heavier load, or require more static assets that can easily be cached have Cloudflare thrown in front of the static asset part. So the web app/dynamic content is served from the server itself, and the static content is on a secondary domain that is set to Cloudflare.
Heroku is a great and easy service, but I find the add-on 'no lag for $35/month' which is what the dyno basically is to the poster, unacceptable. But if most commenters are willing to pay into the hype, go ahead.
Just go with Linode or appfog or something.
The cheapest Linode is $19.95/month, and that's just a bare VM. You have to do all the sysadmin stuff yourself. For $15/month more, Heroku takes care of all that for you. If your time is worth anything at all, maintaining your Linode is going to burn up more than $15/month.
Now, granted, for some use cases the Linode makes more sense (I have one of those, too, and have been happy with it and the company overall), but I don't think either company is screwing anybody over. Both are offering good value on their products, but those products are different. Linode gives maximum flexibility, but at the cost of full responsibility. Heroku gives maximum convenience, but at the cost of less flexibility.
I grant you that Heroku is a great service. Having a reasonably big site you'd need a system admin who costs $100/hour, Heroku saves on that too. I am not arguing against the technical convenience that it brings you. But I believe the policy of spin downs should depend more on if and how much you are paying, rather than if you are paying for a specific element of their service, in this case a dyno. It does not cost $15/month more to achieve what the poster wants, but $35/month.
" But I believe the policy of spin downs should depend more on if and how much you are paying, rather than if you are paying for a specific element of their service, in this case a dyno."
You're seriously arguing that if you buy several items from a company, they're then obligated to give you a completely different item for free?
The purpose of the dyno is not to prevent spin downs, it is a provision for background processes, think processing orders, updating information from external APIs every hour, etc.
Your comparison is obviously bogus as we are dealing with a service, not products. It is more like paying for a spotify premium account and still having to listen to ads. He is being treated like a free user, while he is paying for premium service.
I agree though that if you are hitting the damn thing every second it shouldn't go idle.
Forcing me to read in landscape.
http://www.imgur.com/x8wCC8U.png
The same day as a post about about contrast.
Btw. Heroku and App Engine apps start fast, compared to what ep.io (free) app start took, it was more like 20-30 seconds than 2-5 seconds.
That and fundamentally (as you noted about being optimistic) you're paying $100+ a month for an app that gets zero traffic. That seems to be the core issue.
Deleted comment
That being said, they aren't making this policy a secret. Not sure what you have to complain about after the fact.