Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heroku Isn't for Idiots

rdegges.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Heroku Isn't for Idiots

#51

Post by dasil003 »

wisty wrote: post #50
rapind wrote: post #44

Earlier quoted context omitted.

There are definitely reasons that you would want to be on your own managed metal infrastructure, but let's not exaggerate so much and say that it's only use is for blogs and experimental projects. Why do people have to always be so extreme to try and make a point? There are a ton of real sites that never see more than a couple hundred thousand visitors a month. E-commerce sites, mobile APIs, SAAS apps, etc. I've used…

So Heroku is good for higher margin sites. You couldn't run Facebook, because the value of each customer is marginal, and they are expensive customers. You could host a B2B app no problem, because they are paying (high margin) customers, and will probably not use too many resources.

No platform could run Facebook. There is a certain scale where you have to do it yourself because no one else has done it that way before.

Re: Heroku Isn't for Idiots

#52

Post by jordanthoms »

pbiggar wrote: post #5

I love this post, and hope it keeps coming up. Some day, developers will learn that even though they could do it as well as Heroku, given enough time and effort, it's just a lot cheaper not to! This comes up all the time with my company. We make hosted Continous Integration ( https://circleci.com ), and often hear "can't I just set up Jenkins?". And the answer is the same, "you could, but ...". Run it on EC2, where y…

Hey, BTW the join using github button at the bottom of the page doesn't work (links to undefined), the one at the top does. Probably want to fix that :)

Re: Heroku Isn't for Idiots

#53

Post by jeremyjh »

wmf wrote: post #27
jeremyjh wrote: post #22

"Each instance (Heroku calls them dynos), has: 512MB of RAM, 1GB of swap. Total = 1.5GB RAM. 4 CPU cores (Intel Xeon X5550 @ 2.67GHz)." That is very interesting. So you get 200% of the CPU from a c1.medium but only 1/6 that memory? For 1/8 the price that Amazon charges? Maybe this is a the new math I keep hearing about.

I would guess that Heroku runs ~29 dynos per m1.xlarge, so each dyno gets a minimum of ~1/7th of a core or ~366 MHz. Just because you can see 4 cores doesn't mean you can use them.

Yes, I know that. The OP doesn't seem to know that. This is a problem, because the piece he is responding to in a large part is concerned with the meager resources provided by a single Dyno.

Re: Heroku Isn't for Idiots

#54

Post by calinet6 »

pbiggar wrote: post #5

I love this post, and hope it keeps coming up. Some day, developers will learn that even though they could do it as well as Heroku, given enough time and effort, it's just a lot cheaper not to! This comes up all the time with my company. We make hosted Continous Integration ( https://circleci.com ), and often hear "can't I just set up Jenkins?". And the answer is the same, "you could, but ...". Run it on EC2, where y…

Good to know Circle is running on Heroku. At least now we'll know why our CI isn't up when there's another lightning storm in North Carolina.

Heroku does make a lot of sense: it's an abstraction. You're using a system designed to do a lot of the heavy lifting so you don't have to deal with those details, and for many startups and small operations, it's a great value proposition.

But you have to admit that it is only a value proposition; and fundamentally a tradeoff. The truth is, especially from the perspective of a seasoned operations manager, all of the things above are just not that hard, nor are any of the complaints outlined in the OP article.

The more layers you put between you and your infrastructure, the harder it will be to control your availability. When EBS's start failing and you have no idea why and Amazon only shows a green dot on their status page with a cryptic message like "minor availability issues experienced in certain availability zones; investigating." Now that is hard.

Cloning a server and keeping a mirrored backup in another data center if you really need the availability? On hardware you have full control over? Not that hard. http://whoownsmyavailability.com/

Re: Heroku Isn't for Idiots

#55

Post by batista »

heretohelp wrote: post #48
benologist wrote: post #30

Earlier quoted context omitted.

Here's my pretty graph for serving ~500,000 requests per minute on Heroku: https://api.playtomic.com/load.html Savings aren't exclusively because of Heroku, I also switched the underlying architecture during that migration from C# / ASP.NET to NodeJS which is exceptionally well suited to what I'm doing there. Previously: Dedicated servers, ~$1600 a month 8x dedicated servers at ~$200 each, each running 3 to 5 instanc…

Your app isn't "serving" anything up, it's an event API. 100% different use-case than what I was talking about.

You keep using that word "serving". I don't think it means what you thing it means. Parent is spot on.

Re: Heroku Isn't for Idiots

#56

Post by pbiggar »

jordanthoms wrote: post #52
pbiggar wrote: post #5

I love this post, and hope it keeps coming up. Some day, developers will learn that even though they could do it as well as Heroku, given enough time and effort, it's just a lot cheaper not to! This comes up all the time with my company. We make hosted Continous Integration ( https://circleci.com ), and often hear "can't I just set up Jenkins?". And the answer is the same, "you could, but ...". Run it on EC2, where y…

Hey, BTW the join using github button at the bottom of the page doesn't work (links to undefined), the one at the top does. Probably want to fix that :)

Cool, thanks!

Re: Heroku Isn't for Idiots

#57

Post by batista »

MattRogish wrote: post #36
aaronblohowiak wrote: post #6

Earlier quoted context omitted.

... except heroku doesn't do multi-region, which is where things start getting tricky. They make the easy immediate, but haven't really tackled the hard (yet.)

We use heroku, and every now and again that terrifies us. I'm not sure which will come first: Heroku going multi-region, or us having an outage due to another AWS problem and switching providers. :fingers crossed:

>or us having an outage due to another AWS problem and switching providers.

Why, because the other providers (or a roll-your-own solution) will not have outages?

Or because the customers cannot tolerate even the more or less half a day of outage per year AWS has?

Even critical businesses like banking have work stoppages far more often than that for tons of reasons, in both the physical world and the digital/networked one.

Re: Heroku Isn't for Idiots

#58

Post by heretohelp »

batista wrote: post #55
heretohelp wrote: post #48

Earlier quoted context omitted.

Your app isn't "serving" anything up, it's an event API. 100% different use-case than what I was talking about.

You keep using that word "serving". I don't think it means what you thing it means. Parent is spot on.

>The persistence scaling story for Heroku seems pretty questionable to me.

I said this and was talking exclusively about this. Read my original comment.

Re: Heroku Isn't for Idiots

#59

Post by TehNrd »

benologist wrote: post #24

I also save significant time and money using Heroku and it's awesome being able to scale up and down automatically using HireFireApp. Most of this article rings true with my experience however some of it doesn't feel that valid for me having a high volume NodeJS app, not to mention the entire "Let's talk about bad ideas" section is just lame. 1) If your app crashes it takes ages to restart dynos "automatically", ther…

Can you shed some light on how you are using HireFireApp with node.js? I thought this was only good for Rails/rack frameworks.

Maybe I misunderstood and your main app is rails with some of the other functionality in node.

Re: Heroku Isn't for Idiots

#60

Post by benologist »

TehNrd wrote: post #59
benologist wrote: post #24

I also save significant time and money using Heroku and it's awesome being able to scale up and down automatically using HireFireApp. Most of this article rings true with my experience however some of it doesn't feel that valid for me having a high volume NodeJS app, not to mention the entire "Let's talk about bad ideas" section is just lame. 1) If your app crashes it takes ages to restart dynos "automatically", ther…

Can you shed some light on how you are using HireFireApp with node.js? I thought this was only good for Rails/rack frameworks. Maybe I misunderstood and your main app is rails with some of the other functionality in node.

I couldn't get it to work initially, it just would not recognize my app at all and I couldn't add it.

I sent an email and got sent to this new link (not sure if it's launched) which I believe covers the entire Cedar stack rather than anything particular to NodeJS, it pings a provided URL.

http://manager.hirefireapp.com/

Post reply on HN