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

Why I left Heroku, and notes on my new AWS setup

holovaty.com

Post reply on HN
Print view View original

61–70 of 231 posts

Re: Why I left Heroku, and notes on my new AWS setup

#61

Post by lesterbuck »

scottvdp wrote: post #2

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!

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?

Re: Why I left Heroku, and notes on my new AWS setup

#62

Post by pjungwir »

count wrote: post #59
bearwithclaws wrote: post #4

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

I pitched a book to No Starch and a few others, and they all said there wasn't enough demand...

I know Packt was looking for a Chef author a few months ago. I declined to work with them, but I'm working on an outline for a Chef/DevOps book to self-publish.

Re: Why I left Heroku, and notes on my new AWS setup

#63

Post by scottvdp »

memset wrote: post #57

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 slowl…

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.

Re: Why I left Heroku, and notes on my new AWS setup

#64

Post by tibbon »

arunoda wrote: post #42

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

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)

Re: Why I left Heroku, and notes on my new AWS setup

#66

Post by thruflo »

ceejayoz wrote: post #13
greghinch wrote: post #7

Earlier quoted context omitted.

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…

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.

Or enable availability monitoring with the (free) newrelic addon.

Re: Why I left Heroku, and notes on my new AWS setup

#67

Post by falcolas »

pjungwir wrote: post #44
jmgrosen wrote: post #36

Earlier quoted context omitted.

I'm not the OP, but the thing that's always scared me off from those types of services is that I think there would be high latency, where in a DB you really need low latency. Is that not true?

Since Heroku runs on EC2, as long as OP kept his servers in the same availability zone as the DB, latency shouldn't be any worse than running it himself. But yes, in general I'd be wary of a database far away from my app servers.

That can depend on whether you can hit the internal IPs, or just the external IPs. If you can only hit the external IPs, you're subject to greater network latency, plus data transfer fees.

Re: Why I left Heroku, and notes on my new AWS setup

#68

Post by scottvdp »

pjungwir wrote: post #60

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 scrip…

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.

Re: Why I left Heroku, and notes on my new AWS setup

#70

Post by spydum »

anon987 wrote: post #56
bearwithclaws wrote: post #4

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

AMI = ISO Elastic Load Balancer = software based load balancer or traffic director auto-scaling rules = if number of connections >50 or bandwidth > 100k or reponse time >10ms start a new instance and automatically update the load balancer so the new instance takes connections

Add in reasonable max-node count: automated processes that cost you money are dangerous if not governed. You don't want your provisioning tool spinning up endless amounts of nodes, all because some backend database has become slow (some new user pattern has emerged and is causing indexed queries to queue up), and all response times are getting trashed.
Post reply on HN