

Thank You Heroku, or "How To Eliminate Sysadminning" - thedob
http://blog.dougpetkanics.com/thank-you-heroku-or-how-to-eliminate-sysadmin

======
blantonl
_Heroku never goes down, and it eliminates the need to pay a sysadmin (or the
time value of sysadminning yourself)._

Those are two bold, scary statements.

~~~
thedob
You're definitely correct about the first statement. It should be revised to
"Heroku has a strong history of very little downtime."

Regarding the second though, I truly believe that the cost + time savings are
tremendous from using their platform vs administering your own early on in a
startup product lifecycle.

~~~
moe
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 just described then clearly
you don't have him yet, nor someone who told you what slippery slope you're
about to tie yourself to.

If you have the admin guy then he will find you a cost effective platform to
start out with quite effortlessly. Which might be heroku in some cases, but is
usually just a bunch of rented or virtual servers that he sets up over a
weekend. In the latter case it might actually cost a few bucks more initially
than the "heroku free plan" - but he'll explain to you in kind words why he
thinks it's worth that in the midterm. And he'll probably be right.

If you don't have him, then heroku can't save you. Heroku will run your stuff
for a while just until things get interesting and worthwhile load starts to
build. 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.

At that point all you can hope for is that you're already profitable enough to
afford not only that guy you skipped on initially, but rather his bigger,
hairy brother, which is the only kind generally willing [and able] to take on
"search & rescue" gigs. For an adequate sum.

At this point your friendly "pay-later" route has turned into a nasty "pay
10-20x _now_ " roadblock. In an "Insert coin to continue" sort of way.

This is not about what heroku can or can not do. This is about what kind of
skills you need on the team for a web-startup. Don't skip on the admin. Or
rather, don't skip on at least one guy who has been doing the admin thing on a
real live app for a bit and also during some not-so-good times.

~~~
donw
I'm a sysadmin-turned-startup-founder, so there's my bias right there, plain
for all to see.

With that, this is really, really good advice.

In sysadmin-land, all my pain comes from software that was never written with
management in mind. Assumptions like 'all TCP ports are open, all the time,
between all servers', 'we can put things wherever we want in the filesystem',
and 'the server should be configured just like my local workstation' make
upgrades and deployment a nightmare, and are nominally difficult to change in
a codebase with more than a few iterations underneath it.

Oh, and my other favorite pet peeves: Applications that provide no easy way to
verify whether or not they are, in fact, up or down, and having debugging
information dumped into the logs marked as errors, rather than as debug
messages.

Keep in mind that these won't bite you in the ass initially, when you're only
on a single server, or on a small, tightly controlled cluster of boxes.
They'll torpedo you when you need to scale up, and you'll get a second shot in
the boilers if you ever need meet any number of regulatory standards for
various industries (PCI, HIPAA, etc.).

Fixing these early-on is _easy_ , and you can enforce scaling-and-deployment
friendly coding practices through automated unit testing and CI. Won't even
really cost your coding team any extra time. Fixing them down the road, after
you've got a few thousand live customers and a big pile of codebase to dig
around in, is... difficult, at best.

~~~
_pius
_In sysadmin-land, all my pain comes from software that was never written with
management in mind. Assumptions like 'all TCP ports are open, all the time,
between all servers', 'we can put things wherever we want in the filesystem'
..._

One good thing about Heroku, though, is that you essentially _have_ to do a
lot of these things properly from the beginning because they enforce a shared
nothing, tiered architecture. For instance, you can't write to the filesystem,
you can't set up some poorly secured e-mail server, you can't have arbitrary
daemons running. In general, every process that isn't core to the web stack
_must_ be executed in a completely different tier.

Obviously you can still shoot yourself in the foot with poorly written SQL and
other things, but a lot of the "sys-admin" type mistakes are avoided by
enforcing best practices when you start with Heroku.

------
brown9-2
Not related to the content of the article, but does anyone else get annoyed
with sites that put some sort of onclick/mousedown handler on their links,
presumably to track outbound clicks or something related?

This overrides the middle-click behavior of my browser to open the link in a
new tab. I'm trying to open your outbound link in a new tab so I can continue
to read your content AND later read the page being linked to; the analytics
being surreptiously added to every link overrides and prevents this.

~~~
pmiller2
Can't this be done in a non-obtrusive way? Not every site that uses analytics
has this type of annoying behavior, so I'm left wondering what additional
value they get by overriding onclick.

------
mark_l_watson
Heroku is great, no doubt about that. My only issue is the 'guilt factor':
almost all of my use of Heroku has been for free (my cookingspace.com web site
that I use to monitor my diet because I take blood thinners; test deploying
prototypes; used it to write 3 articles about Heroku for DevX).

I have had poor results getting customers to use Heroku. I tried twice, and
both times the extra cost over running your own EC2 instances convinced my
customers to eventually spend much more money having me set up custom
infrastructure - not a good decision unless you expect to have a very high
volume site (I hope they are not reading this :-)

~~~
Periodic
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.

~~~
mark_l_watson
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
Heroku must have customers with large user bases, the sweet spot seems to be
for moderately sized web portals that you sometimes need to scale up on
demand.

~~~
blasdel
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.

~~~
mark_l_watson
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.

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

------
dasil003
I'm intrigued by Heroku (and EY Cloud), but the thing that really freaks me
out is how they charge for every little extra thing. I love the idea of a
turnkey solution for Rails deployment and cloud scalability, but for me
personally I don't think I would do a startup on it because the value
proposition is squeezed from both sides.

On the low-end I can get a VPS for $10-$20 month and get a Rails app up and
running for a significant number of users with just that modest outlay. I can
install SSL and any software I want and have a predictable amount of resources
to play with. Yes, there is some sysadmining overhead, but setting up Nginx w/
passenger is like an hour of work once you've been through it a couple times,
and similarly a lot of the add-ons that Heroku charges a monthly fee for are
just a small one-time time investment. When I'm trying to bootstrap something
really small the last thing I want is ramping up a significant recurring cash
costs just to run some open source software that is really not hard enough to
setup or maintain to justify recurring costs.

On the high-end when I'm using a lot of server resources, I'm paying a growing
premium for a given amount of resources. Now don't get me wrong, it's nice to
be able to magically adjust for traffic spikes, but if I have a consistently
high amount of traffic, once again I'm paying a high recurring cost for actual
resources that are a fraction of the cost, _especially_ if I need any add-ons
which are not inherently resource-intensive—maybe I'm actually just paying for
SaaS of essentially open-source components. Actually I have this problem with
EC2 and S3 in general to some extent, though much less so than with Heroku
because the markup is lower and I've still got a large degree of control.

The benefit of Heroku is that they maintain an up-to-date and well-tuned Rails
stack w/ add-ons on top of EC2. There is definitely value there. But in all
cases there is this downside of overhead and flexibility. The clincher for me
is that ultimately Heroku may end up not supporting something I need that
would be trivial open-source stuff on any UNIX VPS. At that point I will need
to migrate off of Heroku and all those supposed sysadmin costs hit me full in
the face all at once rather than being amortized over the life of the project.
Maybe I'm just turning into a cranky old man (at 31!), but VPS or dedicated
servers still seem like a better value considering all risk factors. If I had
VC money and was trying to ramp something up really fast I might reconsider.

~~~
hopeless
Even though I had a VPS configured and running for almost a year (i.e., all
the upfront sysadmin setup done) I was stressing about what I hadn't done, or
more precisely what I didn't know I needed to do. Forgetting to update the OS,
check if the machine had been compromised, check the load/mem/disk space etc.
Just a hundred little worries floating around inside my head.

So I moved to Heroku to focus purely on the app. It's wrong to say they change
for "every little thing"... most addons are free. But yes, hourly cron,
background workers, unlimited bundles etc are charged for.

I'll always recommend to anyone that they check out Heroku because I think
it's a real time saver _if_ your app fits within their constraints. During
development you'll usually save money and then the costs will scale
(hopefully) with your income after launch

~~~
jhancock
For me, not owning my own server as a serial entrepreneur is like a graphics
design consultant not owning a mac. Or a mechanic without four extra cars in
his backyard.

I'm sure Heoku is a great deal if you don't have the sysadmin skills. My
skills are just good enough and I manage my own box. I bought it 5 years
ago..4 cores, 8 GBs, 73GB RAID-1...for $5000. I pay $105/month to host it.

This is at least the equivalent in horsepower of what you get from Heroku for
$500+ a month (that's being generous). So in a few years, I'm ahead of the
curve: $11,300 vs $30,000. Add in the fact that I paid down $5000 in advance
as a capital investment and I'm still ahead. You could do this today for under
$3000 capital investment and have an even more capable box.

Sure there's risk I'll have a hardware failure (I did have 3 years 24 hours on
site warranty, but that's still potential downtime and headaches). But there
is also risk that over the course of that time you will want to run things on
your server you did not anticipate when you started. It certainly was the case
for me. e.g. I started my app in rails then switched to merb. Now I run a
second site on the same server with mongodb and solr.

Bottom line, if you have moderate linux skills and know your going to be in
"some business" that requires you have a server, buy your own. If not, Heorku
seems a fine choice for some.

~~~
hachiya
Thanks for this comparison.

Can you recommend the company that you colocate/lease-to-own with?

~~~
jhancock
<http://m5hosting.com>. They're in a solid data center in San Diego. I started
with them for two reasons: 1- they knew FreeBSD (I use ubuntu now but wanted
someone who could hands on cover me in a pinch with FreeBSD at the time). 2 -
I was in Shanghai at the time and needed good bandwidth from the U.S. That
data center has better routing than most.

m5hosting is bigger than when I started with them but they are still a
"medium-sized" company. They seem to be solid and whenever I have a support
request they are on it quickly...about half the time I get a response from the
owner.

I generally follow the rule of picking business partners that are "right-
sized" for me as a customer. For many services I don't want a company so big
that I'm not worth their time after the sale...especially when it comes to
server support.

I have never been to the data center and never seen my own server. I bought it
on ebay and had it shipped to them ;).

------
ericd
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>

~~~
mahmud
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.

------
freetard
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.

~~~
xal
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

~~~
qeorge
This doesn't sound right to me. Do you perhaps mean PCI Level 1 compliance
(which requires on site data center audits and thus cannot be provided by any
cloud host)?

For instance, what about Heroku/EC2 prohibits me from using Authorize.net as
my payment processor, provided I never store card data?

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

~~~
jon_dahl
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 you want CPU-by-the-hour, go with EC2. If you want to host a Rails app, go
with Heroku.

~~~
jon_dahl
Edit: this guy shouldn't be downvoted. He asked an honest question (what's the
difference between Heroku and AWS) - unless I'm missing something, he isn't
trolling. No need to vote him down.

------
kilian
Is there something like heroku for django apps? :)

~~~
fizx
Is GAE not that?

~~~
jokull
No. There are a number of some pretty serious restrictions. I would _love_
something like Heroku for WSGI applications. Ian Bicking is working on
something similar, not as high level with his Silver Lining project.
<http://bitbucket.org/ianb/silverlining/>

~~~
njl
A couple of months ago I explored building a Django-friendly Heroku clone. I
white-boarded out the architecture, estimated how much work would be needed
for all the pieces, and built a spreadsheet revenue model. It's an interesting
and attractive business, but I'm only one man and my C skills are rusty
(really, really rusty). I couldn't get myself to a point where I could deliver
a product for at least a year, and I want to be ramen profitable before that.

My current focus is to look at the plethora of excellent SaaS applications
that help provide the whole Rails ecosystem, then turn around and do the same
for Django, with an eye towards expanding to handle other Python frameworks,
and then into the Java space.

~~~
rcoder
I think you could get well into the "people are paying money for this service"
stage of a hosted Django hosting platform without ever having to touch C.
Python is fast enough to do most of the systems-level programming you'd need
for such a beast, especially since so much of the standard library (socket,
struct, asyncore, subprocess) sits directly on top of the fast POSIX syscalls
you'd be invoking to do the same work in C anyway.

Going down to the metal may help squeeze the last 10-20% out of your hardware,
but the the really interesting and challenging work in coming up with a
scalable hosting platform is elsewhere: security, monitoring, process
spawning/reaping, deployment, et. al. If working in Python gives you a time-
to-market advantage, then go for it. You can hire a C hacker when you have
enough business to make the improvement in your hardware utilization
efficiency pay off.

~~~
njl
Well, some effort needs to go into some plugins for nginx and varnish. nginx
needs to route incoming requests to the right varnish, and some custom cache
invalidation stuff should happen on varnish as well.

Other than that? Lots and lots of python, of course ;) I'm only one guy, and
there are three or four big moving parts that need to be written. Something to
build eggs and push them, something to monitor and manage processes on
individual servers, something to dispatch requests to the appropriate servers,
and something to monitor and manage the database servers.

Even pulling back and looking at a minimum viable product, I'm still doing
most of that work, just far simpler versions. Succinctly, it's too big for me
to tackle on my own in the next six months.

~~~
jokull
I'd do without eggs and provide common Python libraries that need compiling on
the server (lxml, Crypto etc.). You'd then simply accept Python code over the
live for deployments. You'd also want to handle rollback, schema migration,
key-value services and a DB per instance, some sort of dumping/loading of
data. If you stick with certain django conventions (namely settings-as-a-
module and apps/libs on PYTHONPATH) you could get away with a really sweet and
simple deployment procedure. A pretty smart client to handle all this is a lot
of work too. Have a look at Silver Lining. Just got EC2 working on my fork ;)

------
jackowayed
I like Heroku, but it seems overpriced for most situations.

In particular, I think it's an issue that there's no decrease in cost for
dynos (though I be for extremely large sites there's special pricing). Because
of this and because you get a freebie, dyno pricing is actually a little
progressive (ie. your average cost/dyno increases as you get more dynos).

If you have 2 dynos, you're paying for one at ~$36/month, so your average cost
per dyno is $18. If you have 11 dynos, you're paying for 10 for a total of
$360/month, which is an average of $32.73/dyno-month.

------
yumraj
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?

~~~
bjhess
Each app is a separate instance. I have 5 apps there for free. The benefit of
my knack for creating unsuccessful side projects. :)

In any case, pricing is separate for each Ruby app you wish to run. You could
run one under Blossom and the other under Koi, no problem.

------
squidsoup
I've been considering using Heroku for my one-man side project , simply
because I do not have the time to attend to both development and system
administration. I'm aware that it's more expensive, but when your time is
precious, I suspect it will be well worth the extra investment.

------
rebelvc
Add php support pretty please

~~~
_pius
Why would one need this for PHP? Isn't PHP already pretty much upload and go?

~~~
detst
You would want it for the same reason you would want it for any other
language.

"upload and go" is a convenience feature of Heroku, not it's reason for
existence. It does make it easier to deploy Ruby apps but, again, it's not the
reason it exists.

~~~
papachito
What is the reason for it then? Scaling? But you still have to work on those
nasty sql queries. Too bad it doesn't support any nosql database.

