
Goodbye Heroku - bcardarella
http://reefpoints.dockyard.com/2014/06/23/goodbye-heroku.html
======
joshpadnick
I was always weary of Heroku because it's exactly what @hunvreus said: a
black-box. Very appealing when you're strapped for resources in the beginning,
but increasingly frustrating as you scale. Case in point:
[http://rapgenius.com/James-somers-herokus-ugly-secret-
annota...](http://rapgenius.com/James-somers-herokus-ugly-secret-annotated)

That being said, it seems like the model itself is not flawed, just the
execution. I've met many developers, especially in the Node community, who
fundamentally believe they as software engineers should not have to spend any
time learning devops.

My position is that a good software engineer today should be familiar with the
full stack from frontend (SPA, javascript, html, css) to backend (sql, basic
db admin, db design) and devops. Obviously, you can't become an expert in
everything, but the knowledge level required to become "proficient" in these
areas seems pretty achievable if you're well-versed in software engineering
fundamentals.

FWIW, it took me about 4 weeks to get a "startup-ready" fully open source
3-tier stack running in EC2 with full automation using Chef (which is a whole
other topic) plus continuous deployment using Jenkins. Ultimately, we'll pay
more for EC2 per month upfront, and I had to absorb the upfront time hit, but
now that we're setup, it's extremely easy to tweak things, and we have
complete transparency.

~~~
pswenson
you mind sharing your chef recipes? did you use chef to automate jenkins too?
there are too few good chef examples on the web....

~~~
joshpadnick
@pswenson, I used Chef to automate setting up the server with Jenkins. This
included automated security updates, awscli tools, nodejs, and even hubot so
that we can trigger builds from HipChat (we still need to write a custom hubot
listener to handle that, though).

I also took advantage of AWS IAM roles so that the server is pre-authenticated
for certain S3 buckets.

PM me at josh dot padnick at gmail /period/ com with some background on what
you're trying to do and I'll see what I can share. For many reasons, I can't
make our Chef code repo public, but maybe I can share some code samples.

Edit: Regarding Chef, for more info you might check out
[http://www.slideshare.net/JoshPadnick/introduction-to-
chef-a...](http://www.slideshare.net/JoshPadnick/introduction-to-chef-
automate-your-infrastructure-by-modeling-it-in-code).

As far as online examples, yeah, the learning curve does kind of suck. Also,
if you're starting from scratch, SaltStack may very well be a superior
technology (don't know enough about it). I think the key with Chef is to learn
how to read the docs, using the application-cookbook pattern (where you never
touch the cookbooks you download online and instead customize them by
"wrapping" them with your own custom-defined cookbooks.

It's also helpful to use very thinly designed roles, and define special
cookbooks as your actual roles. This way you can version-control them.

I basically learned by reading the same material in multiple places,
especially in books on Safari Books Online, and IRC was also a huge help b/c
the community was VERY helpful.

I think Chef is a classic case of where the technology is somewhat inelegant
and perhaps bloated, but a mature community is there and it's battle-tested so
once you suffer the pain of ramp-up you get a huge benefit.

HTH

------
diziet
If our company was hosted on Heroku instead of AWS, we would have to shut
down. Want a 50gb redis? $4k/mo. MongoHQ's largest heroku instance is 150gb at
$2700 / month? We'll need at least 50. Want 300 workers? That's $20k / mo for
less quality servers.

Heroku is great for working on your own project or if your data scale is
small. Otherwise, the cost is just too high.

~~~
matdes
At that point, don't you have enough scale, money, and need to actually hire
an ops person?

~~~
joevandyk
The size of your data and the number of processes you run have nothing to do
with your available cash for hiring people.

~~~
andy_ppp
The amount of money you have to grow your business is directly proportional to
the cost overheads of running your app minus the revenue it generates. We are
assuming that the larger your internet service is the more money you will
make.

Of course that has yet to be empirically proved.

~~~
nemothekid
A service that processes tweets from the firehose in realtime. Assuming you
decide to process everything day 1, thats a case where the overhead from
running your app could greatly outweigh the revenue it generates.

~~~
matdes
I mean, I guess? I would question that business and processing model heavily,
though. Most sustainable business models show growing from some kind of
smaller MVP to a larger full-featured application.

Significant overhead costs to go from nothing to steady-state instantaneously
would be enough to scare me.

------
hadoukenio
> When our customers email us during our vacation pissed off that we are not
> around and we have nothing to show to them to prove that this is Heroku's
> fault and not ours

Here's a tip. You are a black box. Your customers don't care if it's your
fault, Heroku's fault, the power grids fault or a meteorite's fault. They just
care that their service is up. If anyone from you all the way down to the
silicon breaks, its your problem. Not Intel, not RealTek, not Western Digital,
not ComCast.

Stop playing the blame game.

~~~
cwyers
And that's what he's saying; Heroku's problems are his problems, but Heroku
doesn't provide him a lever to solve their problems. So he's moving to
somewhere else, where he has more visibility over the problems and can better
communicate with his customers what the timetable is for repair.

~~~
rhizome
The whole rationale of outsourced hosting is to have someone else take care of
things, so it's a little comical to see the complaints when the pendulum
swings the other way. What do people expect?

------
hunvreus
Heroku is a great way to get started fast without having to worry about
anything related to operations. That being said, you're effectively
outsourcing your entire ops/DevOps to a third party. You don't set the rules,
you don't get to argue about the best scaling strategy, and overall your
infrastructure is pretty much a black-box.

I've seen a fair amount of people who loved Heroku for ramping up apps only to
feel trapped once they started scaling their service. PaaS definitely has its
use case, but I wouldn't recommend it for anything beyond prototyping.

In fact (shameless plug), this is why I've been working on devo.ps, to lower
the barriers of entries to managing your own servers (on AWS, Rackspace,
Digital Ocean, Linode...) using tools familiar to developers (Git + YAML).

@bcardarella happy to add you to our beta testers; we'd love to get feedback
from a heavy Heroku user. Email is in my profile.

If there are other Heroku users affected, drop me a line and I'll see if we
can help you get set up on your own infrastructure with devo.ps.

~~~
morenoh149
no blog updates since '13 tsk tsk. I was excited.

~~~
hunvreus
We've been busy building stuff and talking with users. We actually have the
new landing page and a couple blog posts coming out this week.

------
sync
So how do you scale out to multiple droplets on Digital Ocean? Set up your own
HAProxy instance?

What do you do when one of your droplets disappears or crashes?

Where do you host your database?

Not quizzing, real questions from someone also looking to drop heroku.

~~~
opendais
I'd suggest using Linode over Digital Ocean.

They already are the same price/performance [roughly, unless you are buying
DO's $5 nodes]. They also have stuff like load balancers built out and are
reasonably reliable [although only at the datacenter level, they don't have
multi-DC load balancers]:

[https://www.linode.com/nodebalancers](https://www.linode.com/nodebalancers)

~~~
bcardarella
I am a big Linode fan and I hadn't realized they price-matched DO. Thank you
for the info.

~~~
rwg
Be warned that Linode's status page is also borderline useless. Their website
and web-based management interface (and API, according to customers on their
IRC channel) were throwing 500 Internal Server Errors for >2 hours the other
night, and their status page never had any mention of it.

~~~
jebblue
In 4 year it's always worked for me.

edit: years _

------
alrs
Deployment and maintenance should not happen in the middle of the night. We've
known this for years.

You design your systems to degrade gracefully, hopefully transparently.
Screwing up your engineers' sleep schedules is a terrible idea, so you deploy
during the day when people are awake, clear-headed, and on the clock.

I'll take a 1PM outage over a 1AM outage any day. If that's bad for business,
business should pay for the engineering time to build a more resilient system.

~~~
general_failure
This is not how businesses are run. No sane person running a business will
take a 1PM outage over 1AM. The whole point of heroku is that you are relying
on them to do a lot of the infrastructure systems because you are low on
manpower. The resilient system will be built over time and is being worked
upon. But to put the blame on heroku's customer for the outage is nonsensical.

People do night shifts in so many industries. There's nothing wrong with that,
it's just part of the job. My building security guard does a night shift and
what he does is way more important and needs more attention than an engineer.
Unless you think we should not have security guards in the night.

~~~
alrs
No one with half a backbone should be willing to do scheduled work all day and
then during any portion of the night.

You need to build a resilient system, and that's gonna cost you. It's a lot
less fun than adding features, which is why business people tend to put it off
and instead manipulate the tech people into working crazy hours.

The 24/7 web culture is dying. Adjust your business plan accordingly.

~~~
scott_w
You don't have to. You can take the prior or following day off after the
overnight work.

~~~
alrs
I was never presented this option by any of my previous employers.

~~~
scott_w
That sucks. Whilst we're able to do most work during the 9-5, there's the odd
time I'll come in at 5 or the IT manager works a Saturday because we have to
take down key infrastructure to work on it.

If your working environment is good, it's pretty easy to just say "I'll take
tomorrow off and come in to do it on Saturday" without feeling like you're
getting taken advantage of.

------
lucisferre
Heroku does have it's problems but if I'm being honest I don't have the time
to spend using anything else right now. Perhaps when I hit a larger
scale/stage I'll reconsider that, but at this stage there really isn't
anything better.

------
m0th87
We're working on switching from Heroku to EC2. To my knowledge there isn't a
lot of documentation out there on this process - we're just looking for code
snippets to figure out how to build AMIs, deploy, etc. It's a slow and error-
prone process. Anyone know of good resources to make this migration?

~~~
parasubvert
I'd suggest looking at AWS OpsWorks, which is probably closest to what you're
used to.

[http://www.stefanwrobel.com/heroku-to-
opsworks](http://www.stefanwrobel.com/heroku-to-opsworks)

[http://artsy.github.io/blog/2013/08/27/introduction-to-
aws-o...](http://artsy.github.io/blog/2013/08/27/introduction-to-aws-
opsworks/)

~~~
anko
I second this. I got up and running on opsworks in about 3 days without any
AWS or Chef experience (I use puppet on our other providers).

------
meritt
All these companies leaving Heroku and other PaaS providers is definitely a
blessing for the thousands of unemployed devops & sysadmins out there.

~~~
lucisferre
I can't say I meet all that many who are unemployed. Maybe that's just me.

~~~
meritt
Our last engineering job req we received about 10 sysadmin applicants almost
all of which started with a "I know I'm not an exact fit but..." sort of line.
Maybe it was just an oddity.

~~~
incision
_> 'Maybe it was just an oddity.'_

I think there's a reason, but it's not outright unemployment - yet.

On the enterprise side what I'm seeing are traditional sysadmin positions
being eaten up by aggressive VARs and software vendors. They all have XaaS
plays now and they're targeting their existing customers first.

The pitch is literally...

 _" Hey, I can save you $350K/yr. Just fire your ________ team and use our
PaaS. We'll perform the migration for free."_

Assuming the organization doesn't want to pursue their own internal or lower-
level external service it leaves the sysadmins to either somehow make the leap
to administering a provider system or diversify into other roles where they
don't exactly fit.

------
parasubvert
"Buildpacks are just terrible."

Elaborate please? CF uses a variant of them, and they're ultimately just a
simple three-script harness to build and run your app.

There are pros/cons vs. dockerfiles , chef/puppet/ansible, or just doing a
Netflix style Aminator, I suppose, but "terrible" seems exagerrated.

~~~
bcardarella
Customization. Ever try to add a command-line tool to a buildpack? I don't
understand why we cannot make use of apt as the EC2 instances that Heroku uses
are just Ubuntu AMIs.

~~~
latchkey
It's a pain, but it isn't the end of the world or a disaster. I distribut some
CLI tools with a NodeJS app I wrote. Here's the docs:
[https://github.com/lookfirst/convert/wiki/Compile](https://github.com/lookfirst/convert/wiki/Compile)

------
drovido
I am not a Heroku customer and maybe there is more substance to his complaints
but I didn't see anything in the post that would cause him to want to leave
his hosting provider with guns blazing like this. Reduce their prices because
their service providers have reduced their rates? Seriously which company you
know does that? Do we even know what arrangement Heroku has with amazon? Isn't
it possible that as a large customer their rates are already discounted. On
the subject of downtime he didn't actually say that his application was down
as a result of the maintenance in this instance or any other.

------
nonane
What are the alternatives to Heroku? I'm looking for something that makes it
easy to deploy and launch services. [http://deis.io](http://deis.io) looks
promising but it isn't production ready yet.

~~~
king_magic
I literally just discovered Dokku
([https://github.com/progrium/dokku](https://github.com/progrium/dokku))
yesterday - a "Docker powered mini-Heroku in around 100 lines of Bash". You
can roll your own PaaS infrastructure on your own VMs.

It took a few hours, but I was able to get my Heroku-based Rails app up and
running on a Dokku droplet (to be fair, the most time-consuming part was
getting the SSH keys right and figuring out that I needed a domain name -
e.g., couldn't just set it up with a droplet's IP address - at least not with
the DigitalOcean tutorial's instructions:
[https://www.digitalocean.com/community/tutorials/how-to-
use-...](https://www.digitalocean.com/community/tutorials/how-to-use-the-
digitalocean-dokku-application)).

~~~
mattgreenrocks
Dokku is cool, but it is very basic. Deployed apps don't have any sort of
restart protection, for instance.

~~~
king_magic
It looks like it's possible with a Dokku plugin
([https://github.com/statianzo/dokku-
supervisord](https://github.com/statianzo/dokku-supervisord)). But agreed,
definitely basic - but I think it has a ton of potential.

------
rodrigoavie
I work at an Brazilian mobile ad network running on Amazon AWS and our traffic
is really intense. There are 13 developers in total in the team and none of
them are DevOPS, which make me conclude that most often than not, you don't
need a person specialized into server maintenance and infrastructure.

Like some people said before, Heroku is great for prototyping but just not a
good deal in the long run. Too expensive, way to risky/unreliable for serious
stuff

------
michaelbuckbee
Heroku's defining characteristic has always been that it radically reduces the
sysadmin surface area of my app stack to something I can reasonably handle.
So, while things like Dokku, etc. are really interesting they don't seem to be
actually expanding the number of app-stack layers that I'd need to know to
properly secure and maintain a server. Am I missing something?

------
mr_than
I'm still in the startup phase, and the time saving of Heroku has been
fantastic. I'm ever mindful of these types of stories and the scaling cost
though.

I've not seen it mentioned so far: RedHat has OpenShift
([https://www.openshift.com/](https://www.openshift.com/)) out now, v3 will
see Docker support too. With only a quick play, it seems to be a mix of Heroku
and dedicated host.

On sysadmins: talking to a guy who managed AWS nodes for a popular iOS game
you've probably played, he made the comment that it was great to have a new
team member onboard now, dedicated to looking after all the VMs. I figure he's
rediscovered sysadmins, just using different kit.

The risk I see with managing your own Dokku, etc is handling
issues/maintaining uptime if it's not your only job/skill. When another
HeartBleed comes along, can you react quickly and competently enough?

------
nathan_f77
I really like Deis so far. Can't wait for the Docker / CoreOS / Deis ecosystem
to become more mature.

------
slb350
I'm a devops engineer and I never really saw the draw of Heroku or EY after
you scale out to a certain size. EC2 is extremely easy to work with and
there's tons of documentation out there. Once you setup your CI & CD, write
your cookbooks and capistrano (or whatever), it's nearly hands off.

~~~
andy_ppp
Heroku is the dreamweaver of devops... but you know developers often don't
have the time to spend 2 months+ learning how to do it right (hence your job
title :-D). And for my small app I'll wager that Heroku has infinitely better
uptime than I would manage!

------
Jweb_Guru
Personally, I really fell out of love with Heroku when reading their
justification for not providing VPC compatibility.
[https://discussion.heroku.com/t/deploy-failure-from-
heroku-e...](https://discussion.heroku.com/t/deploy-failure-from-heroku-
ec2-security-group-change/324)

In short, Heroku thinks that firewalls encourage people to be lazy about
security, and leaves people crippled if the firewall is exposed. Due to this
philosophical difference, they would rather force everyone to rely on SSL for
all secure communication, and leave every machine accessible to the internet,
including (for example) your database server.

------
cellis
Easy. Just use deis [1]. Or CoreOS [2], if you're more hardcore. In any case,
with the advent of Docker and 12-factor -- not to mention openstack [3] --
Heroku is a commodity or fast approaching it, and will soon face pricing
pressure.

[1] [http://deis.io](http://deis.io) [2]
[http://coreos.com](http://coreos.com) [3]
[http://openstack.org](http://openstack.org)

------
_bpo
The idea that maintenance should not be done during the day is a bit
antiquarian. Scheduled maintenance should take place during their company's
workday when they have as many people as possible available, feeling awake,
well-rested and not distracted by the things they might prefer to do with
their evenings and weekends off work.

Of course, scheduled _downtime_ should be done in off-hours, but modern
services like Heroku don't have scheduled downtime.

~~~
ryanbrunner
I agree with this argument, but there's plenty of work hours in the day, and 2
PM Eastern is just about the worst one to pick. We try to start scheduled
maintenance around 8 AM - that way we have fully refreshed devs ready to
address any problems, and if something does go wrong, it's a relatively low-
traffic time for our application.

~~~
_bpo
The reality is that there is no good time for a large-scale platform to go
down. I'd speculate that 8am PDT would be worse for Heroku, as their business
seems largely split between the US and Europe, so downtime then would upset
everyone... but that's just speculation.

You can't build a company of developers selling products to developers while
fleeing the working hours of developers.

------
grrrando
If Heroku simply re-sold AWS, people wouldn't use them. The argument that
AWS's falling prices should be passed on to customer's is logical only if
you're ignoring that Heroku is using the savings to build and increase the
performance of their platform.

It's really the complete opposite case, I think. For the value (time is
money!) they offer, it's amazing they haven't increased their prices as they
scale.

------
AdrianRossouw
We're actually busy doing a similar move.

fwiw, here's some resources i collected around docker.

[http://wayfinder.co/pathways/53619274d95a741100e7f203/docker...](http://wayfinder.co/pathways/53619274d95a741100e7f203/docker-
based-paas-wip)

It's a few weeks old, but of those the one that came closest to our needs was
Deis.

------
akh
Sound similar to why we said goodbye to Heroku as well:
[http://blog.planforcloud.com/2013/03/from-paas-to-iaas-
how-w...](http://blog.planforcloud.com/2013/03/from-paas-to-iaas-how-we-
migrated-off.html)

------
boboohaze
Bit surprised no one mentioning Cloudfoundry in the comments. It's pretty much
opensource Heroku solution, run it againts AWS and it's almost exactly heroku,
and with all the tooling around it quite easy to setup.

------
marcoms
Not sure, but is something like Divshot a viable replacement for Heroku - they
both seem to be doing the same thing: developer webapp hosting, but there's
probably a difference somewhere.

~~~
josegonzalez
Seems like it's only for static sites? So if you mean someone's jekyll blog,
sure, it's a viable replacement for Heroku. But then, so is Github Pages.

------
Lamlon
I do not believe Brian has a strong understanding of what it actually takes to
do ops work.

1) Downtime.

This is such a huge fallacy, if you think doing this yourself means no
downtimes think again. If you had a top notch ops team you are still going to
have outages in the middle of the business day. This team of ops guys you
hire, guess what? They are not going to be deploying at 1am every day, that is
not sustainable. They are going to deploy in the middle of the day, and guess
what, they will make a mistake. And guess who notices outages first most
times? Customers.

Heroku's uptime is typically in the 99.9%'s, I don't think you can do the same
with one ops guy, maybe you will get lucky, however it is more likely that you
won't.

5) Buildpacks

Build packs are an AMAZING abstraction. Just think about how you would solve
the following without buildpacks:

5.1) Install libgeos on all the hosts running a specific application?

5.2) Create and scale new worker instances on demand?

5.3) How do you setup logging for all these servers?

5.4) Health checks for these services (tcp, http)

5.5) Alerting and automatic failover

* pssh? That will work fine until you spin up a second server and forget all the incatations to get your software up and running. * Puppet? I am sorry but Puppet, chef and their ilk are horrible, who knows what state any machine is ever in at any point in time. humans will inevitably forget to ensure absent, or make an assumption about state in puppet land. Nevermind the slow feedback loop in puppet land. Oh hey you want to change all the servers running X to now run Y instead, good luck with that. * Mesos? Mesos is the best open source scheduler out there, Marathon makes it easy to deploy to and there are scripts to run easily on ec2. However if you want to install native dependencies (libgeos etc) you will still need to do one of the above things. * Docker? Docker is an amazing way to package your app up and ship it to run on Mesos, however how do you package docker apps and ship them? Guess what? Buildpacks.

Now consider this on Heroku (5.1) Add the [https://github.com/ddollar/heroku-
buildpack-multi](https://github.com/ddollar/heroku-buildpack-multi) (5.2)
Change your procfile (5.3) There are plugin's for that

Oh hey you can also write your own language, write a buildpack for it, and
deploy it to production without ever having to get an ops person anywhere to
setup a server for you. I am sorry but that is nothing short of amazing.

2 and 4)

I agree 100%, it sucks to feel powerless and have no insight as to when things
will be resolved, however if you work in any decent size org ops things will
go down, and you will also have to wait to see any resolution. I agree it
feels better to see people working busily in your office because you can see
the sense of urgency. I

3) Pricing:

In regards to pricing: yes Heroku is very expensive. However for small and
medium teams it is much cheaper than hiring an ops person. You also get an
economy of scale when you use Heroku; Think of all the things heroku takes
care of for you: automatic failover on hardware/software(segfaults)/vm issues.
Disks filling up on some host (it is embarrassing how many times I have seen
something as simple as this cause issues). Agility; You need to switch MRI out
for JRuby or rubinius, no problem, just update your ruby "version" in your
Gemfile. The Heroku platform is superior in almost every way for running small
to medium size applications then any in house cooked alternative.

I am very familiar with the alternatives out there, I have contributed to
dokku's buildpack repo
[https://github.com/progrium/buildstep](https://github.com/progrium/buildstep),
and have patched docker.

There is no good behind the firewall/on my vm/hardware alternative for heroku
atm. People are making progress but you won't really get anything as full
featured as heroku.

Best of luck to you Brian.

~~~
eropple
_> Puppet? I am sorry but Puppet, chef and their ilk are horrible, who knows
what state any machine is ever in at any point in time._

I _always_ know what's on my servers all the time; I build immutable servers
and throw away the old. And I'm not particularly knowledgeable or skilled at
this; I just use a little good sense. I mean, your problems with devops may
actually exist, but this is silly.

~~~
Lamlon
Sure, but the feedback loop is still slow, also adding support for a new app
is much more time consuming, I would much rather have an api call and a git
push and get back to delivering value.

~~~
eropple
You may rather have that, but then _it breaks_ or _it doesn 't scale_ and
you're up the creek. Which is why people pay people like me.

At Localytics, adding a new Play 2.x (our current standard) app into our new
deployment infrastructure takes one command and about 120 seconds. The only
part for which a developer needs devops input is the first production deploy,
which require a signoff and some (automated, but privileged) IAM
permissioning. Adding a new app on a framework we haven't incorporated yet
(Rails is probably next) would take a few days, but needs only be done once
for all developers at the company. And we know it works with our entire
ecosystem.

You might have had bad experiences in the past, but you're extrapolating from
them to the state of the world. It's not what you think.

------
delta-clu
Hi guys, we're actually working on bare-metal PaaS, and we're a couple of
weeks away from launching a beta.

------
fortunajs
what's funny, I read it and didn't go to heroku's website - now all the ads I
see are from them

------
braydenjw
I'm wary about a lot of these SASS/PASS/IASS services. The "don't put all your
eggs in one basket" cliche comes to mind.

------
steven_yue
Thank god you finally realized that :)

------
calgaryeng
s/mainteance/maintenance/

------
sunseb
Why don't you use a dedicated server ?

[http://www.kimsufi.com/en/](http://www.kimsufi.com/en/)

It's not that complicated... And it is far cheaper !

------
brianmcdonough
Heroku support options have always worked to shelter their employees from
customers and as has been pointed out, despite the steep decline in costs,
their prices have not changed. It's a shame because they were a trendsetter,
but they are quickly being surpassed by players like DO, Linode and Poppup.

~~~
therealmocker
Poppup?

~~~
ephemeralgomi
The company that $parent is the founder of. Which, if you google for, you
discover that their page is titled "Blog Logo" and contains no content. Check
back in a week or so, I guess.

~~~
brianmcdonough
A frivolous addition with no facts to check. Admitted. Give it twelve weeks.
The point is that Heroku can do better. No offense meant to sales force or
it's employees, just honest feedback based in real experiences.

------
zaqokm
> It has been heavily reported that AWS has cut their pricing quite a bit over
> the past few years. Yet, how many times has Heroku reduced its price?

This is the bit which confuses me. It is easy to think that there should be
correlation between Heroku pricing and AWS pricing.

However just because AWS drops their pricing does not mean the capex for
Heroku is dropping.

~~~
bdcravens
Even if there is a capex drop, Heroku's focus is simplicity. 5 or 10 cents an
hour is part of the value prop; it may be hard to translate a 55.4 to 49.8
cent/hour drop for an AWS instance into their pricing model and not lose that
simplicity.

~~~
zaqokm
> and not lose that simplicity.

Very interesting point

