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

Thank You Heroku, or "How To Eliminate Sysadminning"

blog.dougpetkanics.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#31

Post by blasdel »

mark_l_watson wrote: post #15
Periodic wrote: post #9

Earlier quoted context omitted.

Costs that are represented in obvious dollar amounts with alternatives that have lower obvious dollar amounts tend to go over poorly with clients. The nebulous cost of more developer and admin time is something they can carefully ignore in their cost calculations.

I agree. Also, I suspect that if a deployed app is rarely accessed, then there is some spin up time to load a slug. Both customers noticed this effect that the first page load usually seemed slow to them. Same thing on AppEngine (a 'loading request' can take a while). Bottom line is that people dream that their web app will attract millions of users, and they want to plan for outstanding success. While I am sure that…

That would be a despicable thing for Heroku to do: you're paying them for capacity by the dyno-hour, but they don't keep all of them resident while they're paid for?

App Engine is the opposite: you're paying for the usage, so they spin up/down as much capacity as necessary to satisfy the volume you're willing to pay for.

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#32

Post by mahmud »

ericd wrote: post #20

A bit off topic, but JumpPost (the site launched on Heroku that this article refers to) looks an awful lot like you ripped RentHop's design. You guys thinking about changing that anytime soon? http://www.renthop.com/list http://jumppost.com/apartments

Down to the arrow in the logo. That's what happens when you market research team = your development team = your design team. Contamination.

Guys, let X/N people do the design, while (N-X)/N go around looking at your competitors' websites for "inspiration". What you wanna do is copy business plans, target markets and monetiziation strategies. Not goddamn pixel and element positions.

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#33

Post by mark_l_watson »

blasdel wrote: post #31
mark_l_watson wrote: post #15

Earlier quoted context omitted.

I agree. Also, I suspect that if a deployed app is rarely accessed, then there is some spin up time to load a slug. Both customers noticed this effect that the first page load usually seemed slow to them. Same thing on AppEngine (a 'loading request' can take a while). Bottom line is that people dream that their web app will attract millions of users, and they want to plan for outstanding success. While I am sure that…

That would be a despicable thing for Heroku to do: you're paying them for capacity by the dyno-hour, but they don't keep all of them resident while they're paid for? App Engine is the opposite: you're paying for the usage, so they spin up/down as much capacity as necessary to satisfy the volume you're willing to pay for.

You might be right that Heroku always keeps all of your dynos "spinning." If they do spin them down for the two less expensive shared cluster options, that seems OK, at least for my understanding of their service options. My customers used (for a while) the cheaper shared cluster options.

If you are paying more for the dedicated cluster options, then I agree with you that they should not be spun down.

Certainly, it is OK for them to spin down the free option dynos if they don't get HTTP requests for some reasonable time period.

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#34

Post by davepeck »

fizx wrote: post #7
kilian wrote: post #6

Is there something like heroku for django apps? :)

Is GAE not that?

It is, but with some pretty big caveats. You can't use Django's models on GAE, and a lot of what people think of as "Django" is built on top of Django models (admin, users, and sessions are the top three.)

The app-engine-patch team has essentially forked Django and made it work on top of GAE models. However, there are some disadvantages, including a huge perf hit on cold requests. I tend to avoid AEP.

I'm currently of the opinion that trying to get "all of Django" running on GAE is square-peg/round-hole. You still get a lot of mileage from the bits of Django you _can_ use on GAE, and it's modular enough that it is possible to build new GAE-specific session, etc. objects. I have several OSS repositories on GitHub that could serve as a decent Django + GAE template if you're interested.

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#35

Post by blantonl »

hammertime wrote: post #19
moe wrote: post #17

Earlier quoted context omitted.

In a perfect world heroku would be the ideal "pay later" option. I.e. you start out with them and once you outgrow their platform you simply hire the sysadmin then , and make him transplant the beautifully clean rails app onto your own infrastructure. Except... reality is harsh and ugly. You want the guy with the sysadmin foo on your team from as early as possible. Because if your thinking goes along the lines you ju…

That's the point where the sum of your mistakes brings it to its knees. Due to basic mistakes usually. Related to simple things like file descriptor limits, stuff about TCP connections, or a basic understanding of how disk i/o works and how to craft the SQL to make it not hurt so much. What if you are not a making these mistakes, how is Heroku (or another service like it) going to bring you to a harsh and ugly realit…

What if you are not a making these mistakes, how is Heroku (or another service like it) going to bring you to a harsh and ugly reality?

Well, if you are running a startup from scratch - you ARE making these "mistakes" because you certainly aren't focused on the minutia of performance tuning and significant scalability concerns.

Most startups at this point are still trying to get the aircraft off the ground - much less thinking about switching on the auto-pilot for cruise.

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#36

Post by xal »

freetard wrote: post #10

I tried installing spree the other day, a rails shopping app, and I gave up after entering gem dependency hell and the no local file policy. Went faster on my own server with nginx+passenger.

You cannot be PCI DSS compliant on Heroku unless you only use paypal express or google checkout for your payment backend. Be mindful of that before you commit to something like spree. I recommend Shopify instead :D

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#37

Post by xal »

jon_dahl wrote: post #26
nextpulse wrote: post #21

Anyone have experience with this vs amazon AWS? (amazon seems to be cheaper)

They're very different things. EC2 is bare Linux; you install apache/passenger/REE/memcached/postgres/etc/etc/etc. If you want to scale past one server, you're on your own there. You take care of backups, security, system monitoring, etc. Heroku is a platform that abstracts you from these things. You just push out your app, tweak a dial or two on your Settings page, and they take care of everything else for you. If y…

In fact, Heroku is build entirely on top of EC2

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#38

Post by jackowayed »

yumraj wrote: post #18

I'm seriously considering Heroku, for my test/learning projects, and am willing to pay a little. Blossom and Koi are good for me. But one thing that is making me think about VPS instead of Heroku is the ability to run multiple apps from one VPS unless I really need the power. Does Koi allow you to run multiple Rails apps/websites per Koi, or is it 1 per Koi?

I'm pretty sure you can't share any of them.

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#39

Post by hopeless »

mark_l_watson wrote: post #33
blasdel wrote: post #31

Earlier quoted context omitted.

That would be a despicable thing for Heroku to do: you're paying them for capacity by the dyno-hour, but they don't keep all of them resident while they're paid for? App Engine is the opposite: you're paying for the usage, so they spin up/down as much capacity as necessary to satisfy the volume you're willing to pay for.

You might be right that Heroku always keeps all of your dynos "spinning." If they do spin them down for the two less expensive shared cluster options, that seems OK, at least for my understanding of their service options. My customers used (for a while) the cheaper shared cluster options. If you are paying more for the dedicated cluster options, then I agree with you that they should not be spun down. Certainly, it i…

That's exactly what they do: spin down inactive free app. Anything which is paid for will never be spun down

Re: Thank You Heroku, or "How To Eliminate Sysadminning"

#40

Post by hopeless »

blasdel wrote: post #30
freetard wrote: post #10

I tried installing spree the other day, a rails shopping app, and I gave up after entering gem dependency hell and the no local file policy. Went faster on my own server with nginx+passenger.

Though they just fucked it up in the betas by depending on rubygems-1.3.6, it's not so hard to get it running on Heroku. You run the rake tasks to copy the public directories from extensions to the root one locally before pushing, you pre-cache the generated CSS (not a problem in the betas, they eliminated sass), and setup asset image uploads to go to S3. The real problem with hosting Spree on Heroku is having to spe…

The SSL thing is really annoying and expensive but I think there's sufficient demand/pressure that Heroku will find a better alternative... possibly with the help of Amazon.
Post reply on HN