
Why I left Heroku, and notes on my new AWS setup - adrianh
http://www.holovaty.com/writing/aws-notes/
======
jcastro
We're working on solving these sorts of devops problems in Ubuntu with Juju:
<https://juju.ubuntu.com/>

As an alternative approach would be that a Juju charm (script) would handle
the initial deployment of a stock Ubuntu AMI and the customization in one step
(or with puppet/chef) and then allow you to add new instances based on scale
(though currently not automatic). When you have changes to your service you
update the charm and just `juju upgrade-charm`.

This would consolidate step 1, 5, and the "ongoing" into one tool and you'd
get a cloud-agnostic deployment (openstack cloud or bare-metal).

~~~
23david
FWIW, I tested juju a few months ago and found it to be buggy and unreliable.
Sometimes the instances would connect together correctly, and sometimes they
would fail inexplicably. Didn't seem ready for any kind of production use to
replace config mgmt tools.

~~~
mpdehaan2
If you are looking for another general purpose orchestrator, I'd suggest
taking a look at Ansible - <http://ansible.cc/>

Disclaimer: I am the primary author.

~~~
StavrosK
I have tried ansible and love it. I invested the time (a few hours) to get a
script working for my stack, and now I have a 70ish line script that will
provision a server or VM (with a shared code directory in the VM), from clean
installation to the codebase up and running in its production state, in one
command.

New project? I just copy the script, change a few variables (names and
packages it needs), and I get deployment for free.

~~~
23david
Sounds interesting. Any possibility that you could anonymize the script and
paste a link to a gist of it? would be interesting to see some real-world
Ansible examples.

~~~
StavrosK
Sure: <http://pastebin.com/KPrm3Zky>

It could use variables a bit more, I think, but there were a few bugs with
expanding them, so I didn't use them. I'll fix them later on, though.

~~~
23david
amazing. that example explains how it works better than 200 pages of
documentation :-)

thx!

~~~
StavrosK
You're welcome, examples are pretty useful for this sort of thing. Plus, after
you have a base to work off, it's trivial to extend.

I'll put this up in a post on my blog, maybe it'll help others as well.

------
deno
Yet another post about scalability/architecture that goes down under load.
There should be some rule for that.

<http://i.imgur.com/UEHzaOL.png>

EDIT: Back online, the site migrated to AWS is _not_ the blog.

~~~
adrianh
Heh -- my blog is still hosted on Heroku, and I forgot to up the dynos. Which
I suppose is a nice (and ironic) argument for doing the AWS auto-scaling
stuff!

The site I was writing about, soundslice.com, has not seen any blips.

~~~
psychometry
There's no need to increase dynos yourself. Just use the [Adept
Scale](<https://www.adeptscale.com/>) add-on.

------
bearwithclaws
_> The way we set up Soundslice is relatively simple. We made a custom AMI
with our code/dependencies, then set up an Elastic Load Balancer with auto-
scaling rules that instantiate app servers from that AMI based on load._

Doesn't sound that simple to me (as a complete sysadmin noob). Somebody should
write a book about this.

~~~
toomuchtodo
Would you be interested in a blog post about it? I'm a sysadmin/devops with 12
years in, and build stuff like this on a daily basis. I wouldn't mind sharing
how the sausage is made.

~~~
steveklabnik
Last week, I literally spun down an EC2 instance and signed up for Digital
Ocean because I couldn't figure out how the hell to make stuff work on EC2,
but have lots of VPS experience. As a dev and not a sysadmin, it's much easier
to go with what you know... but I want to learn.

~~~
skinnymuch
What's the difference between EC2 and a VPS for you? Do your VPSs already have
things installed or a GUI? I've used EC2 before as a single server, never
scaling. The main difference was installing things that are usually pre-
installed (like on Ubuntu's official desktop image). Is that it or is it more
about the scaling?

And thanks for the reference to Digital Ocean. Never heard of them before.
Seems great, might try using them :)

~~~
steveklabnik
I have no idea, just things don't work on EC2.

> Do your VPSs already have things installed or a GUI?

Nope. I prefer straight-up Arch linux. ssh in and go from there.

To add some concrete-ness to the mix, I was installing ejabberd. When it came
time to ping the server... no response. I did the exact same steps on my
Digital Ocean VPS and everything went fine. I had done whatever commands EC2
expects to open the right ports...

~~~
oz
For EC2 security groups you have to open access to both the correct ports
_and_ protocols. Ports are a concept at layer 4 of the OSI model, while ping,
or more correctly 'ICMP Echo Request', is lower down the TCP/IP stack at layer
3. So when configuring the security group, look for the option to choose
Protocols, then enable ICMP :)

~~~
steveklabnik
Thanks. This is exactly the kind of stuff that I could learn from said blog
post, and why I think "EC2 == VPS" is false.

The documentation I was following made no mention of this at all.

------
memset
This really resonates with me. I have been having identical issues with
Dotcloud, a Heroku competitor.

There's nothing worse than wondering if deploying your stupid one-character
typo fix will hang or leave the app in an incomplete state.

I myself am working on setting up salt stack for deployments. I like that all
of it is in python, and after a couple of days I've begun to make progress.

I am migrating things slowly: first cron jobs, then internal tools, and at
some point, our website. The only thing that really needs "scale" is our
frontend, and I don't yet know how I'll manage that, but you know, I guess it
is time to learn!

~~~
scottvdp
Huge fan of salt stack, and I may push Adrian in that direction. The changes
we made here were minimal in the way he deploys, and with so many architecture
changes behind the scenes, we decided less is more on that front.

~~~
bsaul
any link on the advantage of using saltstack for aws instead of AMIs ?

~~~
scott_w
Salt is more easily repeatable across heterogeneous environments.

For example, we're using Salt to manage our development, testing, staging and
production environments. We couldn't do this with AMIs, since the environments
are quite different.

It makes updating quite easy, as you don't need to create a new AMI, just push
your update to your release branch, then run state.highstate from your Master.

If you configuration changes, you update the master and then you can push that
change across all (or just one) of your environments.

------
yesimahuman
On my end I get a complete crash once a week when running with one dyno. The
official response for support I got was to upgrade to two dynos.

Apart from the PostgreSQL hosting, I'm not really happy with Heroku. Add to
the random deploy breakage I've experienced mid-launch (not to mention it's
slow as hell), I'm going to move back to my own servers.

~~~
greghinch
Heroku docs do say (and I'm afraid the link to it is escaping me) that if you
run only 1 dyno, it will shut down after something like 6 hours of inactivity.
So if no one hits your site for 6 hours, the next time someone does it has to
boot the dyno up again, which can take enough time for the request to time
out.

Not saying this is a great policy, just explaining in case you weren't sure.
When you go to 2 dynos they keep things up for you presumably because now
you're a paying customer.

~~~
ceejayoz
This can be mitigated by having cron hit your site every few hours. There are
some free cron services like <https://www.setcronjob.com/> that do this.

~~~
Fuzzwah
Welcome to the cloud, where you need to rely on a third party service to keep
your other third party service online. Of course, what happens when
setcronjob.com goes down.... well you then use pingdom to check that it is
up...... down the rabbit hole we go!

~~~
goldfeld
Welcome to the web, where you get an easy hosting service like Heroku without
paying a dime and then complain about how you need to put some effort to hack
the system so you can continue to pay nothing.

~~~
yesimahuman
Just to be clear: I am paying $70/mo for SSL and Postgres, so it's not that
I'm paying nothing. However, based on the minimal server requirements for my
app (most users are using our client-side Javascript tools), one dyno "should"
be enough.

------
boothead
If you think puppet/chef is too much complexity you might find saltstack worth
some attention. I haven't used it in real anger yet, but I've really liked
what I've seen so far. I see they've even got instructions specific to aws now
too [1]

Also worth mentioning cloud formation as well [2]. That might make the pain of
chef/puppet more of a worthwhile investment!

[1] <https://salt-cloud.readthedocs.org/en/latest/topics/aws.html>

[2] <http://aws.amazon.com/cloudformation/>

~~~
tomsthumb
Ansible is another alternative that is relatively simple.

~~~
gazarsgo
I've been using Ansible for a couple weeks now and it is awesome how simple it
is compared to Chef/Puppet (IMO)

------
zdrummond
Just my 2 cents... the problems described here seem to fall into the category
of "things didn't work 100% of the time".

I have some bad news for you; nothing I have ever used worked 100% of the
time. Doubly so on AWS. Just off the top of my head; just in the last week we
have seen 5% of AWS instance act so badly that we had to recycle them, and
that is just the easy to diagnose problems. Don't get me started on the IOPS
marketing BS that Amazon sells.

It's just the reality of a lot of moving parts and complex systems. From the
sound of it, the OP had very little _actual_ downtime, and had to make some
end-runs a couple times. Shrug, just life in a high-scale world IMHO.

The goal should not be to bounce around providers until you find the Garden of
Eden. The real goal should be to accept failure and build to tolerate it. Now
maybe it is easier to build fault-tolerance if you are closer to the metal...
BUT I would bet that Heroku has much better experience and tooling to detect
and resist faults then rolling your own.

------
scottvdp
Really loved working on this with you, and I'm excited to see what you come up
with now that you have a much better understanding of AWS. Congrats on the re-
launch!

~~~
lesterbuck
When engaging a super qualified expert like this, say in devops, what levels
of interaction are available? For example, is is possible to get the one hour
consult that points the way and mentions the land mines to avoid, with maybe
some template files, or is it only the complete package where the expert does
everything from soup to nuts? Is it cost effective for an early-stage venture
to use the rockstar for something like this? Would someone like this only
apply after product-market fit?

~~~
scottvdp
Well, it depends on the application. Most people think about scaling far too
early, and the same applies to configuration management. I am a fan of
shortcuts, early and often... worry about things when you have things to worry
about.

That being said, making some easy architecture choices early on can have an
enormous effect on your sanity. It is probably worth it to bring someone in to
hint you in the right direction after you have a prototype to show and have
already started to make choices. This is basically where I helped Adrian.

If your app is struggling under success, you are ideally in a better position
financially than most startups are at the beginning. This is when you bring
someone in for longer term engagements, or potentially when you hire someone
to work on this full time.

I think you are hitting on something that is really a need in the market right
now. When you don't need a consultant, and you need 30-90 minutes of "how do I
do this?" Q&A, it is hard to figure out who to talk to.

From my perspective, it is hard to find those engagements. I do a sad majority
of my time in the sales side of things. Recently, I spoke to some folks at
10xmanagement and Adrian pointed me to anyfu, both of which are approaching
this problem but in slightly different manners.

Lastly, you don't want the soup to nuts guy. This is your app, and if you
aren't deeply involved with what is going on with it, you are putting yourself
at a huge disadvantage post consulting engagement.

~~~
nasalgoat
I've often gone on Quora or Stack Exchange to answer questions about scaling
or stack design, but the questions (and answers) are often very simplistic, or
the questions are so specific that I'd need to spend hours answering.

If there was a place I could go to get some cash for my time answering these
questions, I'd certainly be more inclined to spend the time to do so
thoroughly.

Mentoring contractor start-up perhaps?

------
mjackson
From the OP:

> I changed the app to use cookie-based sessions, so that session data is
> stored in signed cookies rather than in memcache. This way, the web app
> servers don't need to share any state (other than the database). Plus it's
> faster for end users because the app doesn't have to hit memcache for
> session data.

The switch to using cookies for storing session data instead of memcache has
tradeoffs. Sure, you no longer need to ask memcache for the session data. But
you are also shipping a significantly larger cookie back and forth _on every
request_.

If you're storing a lot of data in your session, this could actually slow
things down in the long run. [1]

[1]: [http://yuiblog.com/blog/2007/03/01/performance-research-
part...](http://yuiblog.com/blog/2007/03/01/performance-research-part-3/)

~~~
adrianh
Definitely a great point. Fortunately my session cookies are _teeny_.

------
andrewgodwin
Sad to see the recommendation to use MySQL - in my experience RDS hasn't been
worth the effort - but I'm probably biased since I already invested the time
in automating PostgreSQL replication setup.

~~~
adrianh
Believe me, I am sad to stop using Postgres. What parts of RDS haven't been
worth the effort? I didn't have to make much effort, beyond rewriting my
Postgres triggers into MySQL syntax.

~~~
toomuchtodo
RDS is pretty expensive for what you get. You can't restore to a running
instance from snapshots, you get very little control over the environment, and
you can't replicate between geographic regions (only availability zones).

I know you said you're a two man shop, but in this case it may make more sense
to leverage other IaaS DB services instead of RDS.

~~~
riffraff
I am not sure what you mean by "You can't restore to a running instance from
snapshots" cause, well, I've done it a few times.

Could you expand a bit maybe?

~~~
toomuchtodo
My apologies. I should've said "to an existing instance."

[http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_R...](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html)

"You must create a DB snapshot before you can restore a DB instance from one.
When you restore the DB instance, you provide the name of the DB snapshot to
restore from, and then provide a name for the new DB instance that is created
from the restore. You cannot restore from a DB snapshot to an existing DB
instance; a new DB instance is created when you restore."

------
maxmcd
Two quick Heroku recommendations that wouldn't fix all (any?) of these issues,
but would at least make them more palatable.

1\. Change your default heroku error pages. From this:
<http://s3.amazonaws.com/heroku_pages/error.html> and this:
<http://s3.amazonaws.com/heroku_pages/maintenance.html> to something else (in
the app settings tab).

2\. Keep a staging instance up and running with a cloned database so that you
can avoid random heroku-created errors in production.

------
killion
I get a 500 when I go to the site. It seems like a bad omen for an article
about your hosting setup.

~~~
adrianh
Which site? My blog? The blog is still on Heroku, and it sounds like it was
overloaded for a while there. I just upped the number of dynos, so it should
be fine.

I don't have any indication that soundslice.com (which is the site I'm hosting
on AWS) was returning any 500s, but if it was, please let me know.

~~~
japhyr
I am curious how many dynos you end up using under traffic for a blog site.
Care to share?

Also, how many dynos did it take to handle the load on soundslice, when it was
on the front page of reddit?

~~~
adrianh
I don't have a definitive answer for the blog, to be honest. I just add four
more dynos (to bring it up to five total) and it seems to be fine. I figure
it's only for a few hours, so I can be sloppy about it without needing to
worry about huge costs. Wish I could be more scientific about it!

As for the number of dynos when Soundslice was on the Reddit homepage, I
_think_ was using 10 at that point, but, again, it was a totally non-
scientific thing. 10 did the job, but fewer dynos might have been just as
fine.

~~~
japhyr
Thank you for responding. That's exactly what I was looking for, a ballpark
figure for what can get you through a peak in traffic.

------
acomjean
AWS is great. We use it a work and I spun up extra server capacity for a once
a year open studios event.

That being said as someone who's been in the Unix world for a while figuring
out which AWS services to use is not obvious at all. It took me some time to
figure out the alphabet soup of sevices and I was familiar from work. I ended
up using "cloud formation" which builds you a server (LAMP or other) and
optional database/loadbalances configuration. Its was that or selecting a LAMP
ami (Amazon machine image). They have a lot of documentation but its hard to
get an overview of what everything is (S3, elastic storage....) Plus
configuring web server/ database servers for best performance can be non-
trivial.

I get better speeds from our organizations cheap "shared hosting", during low
loads. I was pretty sure the one week of very high loads would have crushed
the shared host, thus AWS was perfect.

------
waterside81
Switched from Rackspace to AWS - couldn't be happier. I think AMZN is really
far ahead of the competition and their pricing seems to be as good if not
better for many use cases.

------
pjungwir
The OP says he opted not to use Chef/Puppet and went with baked AMIs instead.
In my experience, Chef simply takes too long to build a machine. I use it to
ensure a repeatable, self-documented machine setup, but then if I'm on AWS I
snapshot an AMI for quick scaling. This also lets you more easily use Amazon
auto-scaling tools like Cloud Formation, which bring up new machines based on
an AMI. But having the Chef script is still great for knowing what's on your
box and having "source code" to change it.

One thing I'm curious about re the OP's process: he says he is using Fabric
for deploys. Does that mean every time he deploys new code he has to snapshot
a new AMI? In that case, why use Fabric at all? I'd be worried about auto-
deloying AMIs with outdated code.

Since EC2 instances are "disposable," one approach is to never "update" an
instance, but instead you release new code by simply launching fresh instances
with the latest code, then destroying the old ones.

~~~
scottvdp
The baked AMI comes up and pulls, so it doesn't need to be baked each time.

If you take the route you just mentioned, I highly recommend using Netflix's
Asgard (<https://github.com/Netflix/asgard>) and check out their recently
released Aminator (<https://github.com/Netflix/aminator>). Asgard specifically
makes AMI based deploys outrageously easy.

------
TheMagicHorsey
How come nobody thinks about Google's App Engine (and/or Compute Engine) in
these situations? Is it really that unbaked?

~~~
angkec
It's too expensive and has dangerous vendor lockin. I myself was burnt 2 years
ago and vowed never to return to that platform. Now we use combined Heroku and
AWS services. However I do miss GAE though, its deployment is smooth, their
auto scaling up is great. It's just that I don't want to be locked in any
more.

That being said, we still use GAE as a platform for fast prototypes, as a cron
service to keep our Heroku instances up + firing up an EC2 instance every
night to run a script for 5 minutes. So we only use GAE when there's minimal
risk of being locked in.

------
thejosh
What's the cost difference between Heroku and AWS for you?

~~~
adrianh
Ah, I should have mentioned this in the post. The price is going to end up
being basically the same. I could have done it even cheaper, but I'm paying
extra for multi-AZ stuff (i.e., making the database and load balancer
available in multiple availability zones, for failover protection).

~~~
masklinn
You should edit this in at the end.

edit: though you'd have to factor in the cost of bugging Scott when you're not
his friend.

------
anuraj
For discerned users who are ready to spend effort, AWS is definitely the way
to go. No restrictions, fire up your virtual machine, setup everything as you
like and optimize as you need - you have the control button.

------
gingerlime
This sounds pretty great. I haven't used Heroku, but have used Rackspace, AWS
and Linode.

What worries me the most with AWS, is that there's virtually no support. I
guess you can pay and get decent support, but on the low-end of the scale,
it's pretty thin or non-existent. Now, I don't hear of so many issues with AWS
that warrant contacting support about, and I don't face any issues myself, but
just the thought of something going strange and having nobody to talk to makes
me nervous.

In contrast, Linode does not have so many cool features, but their support is
there and very responsive.

~~~
ceejayoz
You can just bump up to AWS's $50 paid support as-needed for one month, if you
need to. They've been very responsive to us with the three cases we've opened
- roughly an hour to resolution each time.

~~~
gingerlime
Thanks. That makes more sense, and I guess a reasonable price if you consider
you don't need this every month.

According to <https://aws.amazon.com/premiumsupport/> \- the developer support
is within local business hours though...

I still wish this could have been factored into your hourly AWS costs rather
than as a monthly fee. Say, pay extra 10% for every EC2 instance-hour or
something and get it included (without the $100 minimum as in the business
support that is).

~~~
ceejayoz
It wouldn't be sustainable. The folks trying to build the next Amazon.com on a
t1.micro would be paying a buck a month and expecting the same level of
support Netflix gets.

~~~
gingerlime
Yep, you're right. I guess support is one of those aspects that can't be
measured per Gb, so there must be some kind of an entry cost. I do wonder how
Linode manages to keep this manageable for them though.

------
koa
Can you share approximately how long the process took you? Thinking of going
down that road with 2 small basic heroku rails apps 1 web, 1 worker, 1 small
postgres DB. very little traffic. Both apps already at ~$170/month on Heroku.
These are paid SaaS B2B apps, but they generate so little traffic but the way
heroku partitions their services or addons, this really should cost like
$30-40/month on a regular "hosting environment"

I know almost nothing from a unix sysadmin perspective, but would invest the
time if it is feasible.

~~~
adrianh
It took about four full days of work, spread out over a couple of weeks. It
would have taken me much longer had I not been helped by Scott (my friend
mentioned in the post).

I don't know the details of your app, but $170/month sounds high for that
server arrangement. If you set up a few auto-scaling Amazon micro instances,
it would give you more capacity and be cheaper. Of course, the tradeoff is
that you'd need to either learn how to do it or hire somebody. :-/ Good luck!

~~~
koa
2 apps, same profile SSL $20 postgres basic $9 1 free web dyno $0 1 additional
worker $36 Scheduler addon usage: $5

$70 for each app(Its actually ~$140.00) (approximately 100-200 business
customers might use the apps daily)

And of course, bad billing practices where they dont stop charging you for
addons you have stopped/remove and send invoices 1 month late so by the time
you notice, another round of billing as occurred incorrectly. Have resulted in
me paying $350 and $251) in the past 2 months.

Exact quote from Heroku customer support email, after overcharge of ~$300 in
past 2 months

"I'm sorry that the delay in receiving your invoices caused the charges to
continue for longer than you would have liked, however please keep in mind
that we offer your Current Usage details[ on your account page]"

Yeah, not happy with heroku at all. Even though i can better use my time
generating additional sales for the apps, Im so pissed, I plan to burn time
move and cancel ASAP...

------
mark_l_watson
I used to be a big fan of Heroku for a few customer's projects and for small
stuff (mostly free hosting) of my own. At least for my own projects, I decided
that for the monthly cost of a large VPS (I use RimuHosting) I can run 5 web
apps written in Clojure (I mention the language because this is an efficient
run time setup, once the JVMs warm up). I am giving up temporary scalability
for a lot more bang for the buck. I also like dealing with smaller companies
because you get great personal service.

~~~
rlander
Mark, thanks for sharing. Do you use an app server like immutant or does each
app run on a separate JVM instance?

------
arunoda
AWS OpsWorks is another reason to move to AWS. It is not good as Heroku yet!
But is it evolving...

~~~
tibbon
I had a great conversation the other day with one of the OpsWorks product
managers. Been using Opsworks for a new client and so far I'm loving it over
Rubber/Capistrano. Rubber was ok, but Opsworks wraps up the entire process
just enough (but leaves enough control)

------
rvanniekerk
Not sure how I feel about these "Being a sys-admin is hard, I'd rather not do
it" type posts. This is literally THE CORE OF YOUR COMPANY, your site not
working is inexcusable!

I think this is going to be an emerging problem for many startups these days.
Patterns of completely unstable products because "ops is hard LOL" followed by
a desperate attempt to hire actual sysadmins for their company and excuse
after excuse of how "awesome we are for growing so quickly!".

~~~
moreentropy
This. If you don't want to and/or are unable to properly operate your systems,
please stay on Heroko, AppEngine etc., otherwise this is a disaster waiting to
happen.

------
contingencies
Is anyone aware of an up to date comparison of the various orchestration
systems?

I have rolled my own which, being totally biased, I do believe is more full
featured than most of those mentioned in this thread, as well as more
redeployable/generic. (100% pluggable platforms, built to integrate tightly
with build services and developer environments, etc.). Limited internal
testing at this stage (1000s of VMs instantiated, across three cloud providers
(one internal), only two distinct OS deployment environments targeted thus
far).

However, it'd be great to have an overview of this area... it's certainly
exciting. I am beginning to feel like the DevOps batton has been passed from
large companies with massive infrastructure requirements back to the community
over this last year, as more developers are becoming aware of the pitfalls of
single provider cloud solutions and the rough edges and missing features of
existing multi-cloud deployment APIs. We can probably expect great things in
this area over the next 12 months.

------
nutmeg
When exactly do you bake a new AMI? On every Soundslice deploy?

~~~
adrianh
No, definitely not on every deploy! For a deploy, I just do a "git pull" on
all of the production boxes and restart the web server.

Baking a new AMI only happens when there are new underlying dependencies, like
a new package from apt-get or a new Python module from pip. In other words,
it's rare.

Hope that helps!

~~~
slig
Is there any reason for not letting pip update things automagically from your
`prod_requirements.txt` using a simple fabric `fab update_pip` when necessary?

~~~
adrianh
Yes, in fact that's what I do! The issue is I need to account for any new
servers that might spin up later (hence updating the AMI).

I could also change the AMI's "user data" to run pip when the instance loads,
but I'm not 100% confident it will always run without errors. I feel better
doing it manually and baking it into the AMI. Personal taste.

------
pramodliv1
I saw your video ([http://37signals.com/svn/posts/3446-adrian-holovaty-talks-
so...](http://37signals.com/svn/posts/3446-adrian-holovaty-talks-soundslice-
at-37signals)) on the 37signals blog where you mentioned that the server stuff
was boring. Now it just got interesting!

~~~
adrianh
Ha, I guess you're right! I must say it's become more interesting than I
expected.

------
DrNoob
I have always wanted to learn how to build stacks on AWS and use them with my
apps. Does anyone know of any good resources out there for this, definitely
for a noob like myself? Perhaps a codeacademy-like site or user-friendly book?

------
pseut
The notes are nice, but this seems like a highly relevant detail: "I'm lucky
to be friends with Scott VanDenPlas, who was director of dev ops for the Obama
reelection tech team"

~~~
Fuzzwah
At least a bit of the knowledge has now been shared via this article.

------
pbiggar
My company does automatic setup too (<https://circleci.com>). However, we went
in a different direction than Heroku, and allow people to nail down the exact
version of their platform they want to use (for example, our users use over 30
different Ruby versions). We haven't needed the same flexibility for DBs and
libraries, but I imagine that will come.

------
tlrobinson
I love Heroku: git deployment, the "dyno" abstraction, Procfiles, buildpacks,
putting configuration in environment variables (all the 12 Factor App stuff:
<http://www.12factor.net/>).

Is there an open source implementation of Heroku (close to 100% compatible,
not just similar ideas) that runs on your own cloud?

~~~
druiid
Clone of Heroku? None I'm aware of. A bring-your-own PaaS? Many. I work with
Cloudify myself: <http://www.cloudifysource.org/>

Nice things: It integrates with Chef/Puppet, allows built-in auto-scaling so
it's cloud independent... has recipes for many applications and services ready
to go: <https://github.com/CloudifySource/cloudify-recipes>

Drawbacks in my mind are that it's based off of Groovy which may or may not be
helpful to some people. The other thing is that it doesn't have a direct
method to do source/application deployment so you kind of have to roll your
own via 'Custom Commands'+Groovy.

~~~
natis
You can also launch many of the popular frameworks such as MongoDB, Play
Frameowrks etc online:
<http://www.cloudifysource.org/cloudifyRecipeCatalog.html>

------
macspoofing
I haven't seen a very good reason to go with Heroku over AWS in any relevant
scenario. It seems like you're paying more for less.

------
stox
Just wait until AWS East goes down. Not if, just when. But Heroku is in AWS
East, too. I am so happy to have gotten out of AWS.

------
Myrmornis
This doesn't put me off heroku very much. Seems a pretty meager list of
complaints.

------
ksajadi
you can use Cloud 66 to deploy your apps from Heroku right to your own servers
with little hassle and no need to do much sys admin work.

------
abimaelmartell
well, that escalated quickly

------
kmasters
AWS, is simply amazing infrastructure automation. Learning how to use it, even
if your not a sysadmin, is going to be a part of your job as an engineer at
some point in the future.

How many times has your boss or your organization said "we want xyz", but we
cant hire admins and we have no hardware?

Every time someone hits that brick wall, AWS is right there. Although I rarely
use the retail side of Amazon.com, I think AWS is a stroke of genius whose
full impact wont be felt for a few more years.

------
camus
very interesting , thanks !

