Live data from Hacker News

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

holovaty.com

91–100 of 231 posts

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

#91

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…

My preference is to make a base ami that's configured with puppet and a couple core user/keys. I make this instance automatically hit our puppetmaster and use things like security_groups and user data to figure out what type of node it is. One of the things that puppet installs is a script to generate a new ami from the built instance, this script optionally deletes the puppet package.

Now you have an easy way to build your ami from the ground up, you only need to worry about core OS package enhancements on the base ami, and you can use your created AMI with autoscaling behind an ELB.

For VERY rapid changes - direct git access is optional (even on startup for current code pulls), but I tend to side with the Netflix guys and focus on an AMI as the minimum unit of deployment.

Check out asgard to make this easier (senseless self plug: I built an asgard ami this weekend - http://imperialwicket.com/netflix-asgard-ubuntu-1204-lts-ami...).

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

#92

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

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.

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

#93
post #31

Earlier quoted context omitted.

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.

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!

I really can't blame Heroku for spinning down non-paying instances that don't get a single hit in 6 hours.

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

#95
post #31

Earlier quoted context omitted.

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.

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!

I completely agree, but sometimes third party tools are better than baking in-house, especially single purpose services. App crash analytics for example, or performance trending tools like NewRelic.

But cron? That's just ridiculous.

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

#96
post #11
post #10

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

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

Be careful about the multi-AZ promise. One of the reasons we don't use RDS is because there is no multi-region failover/replication capability.

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

#97

Earlier quoted context omitted.

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.

"you get very little control over the environment" also seems spurious. You get parameter groups to control just about everything you can from a standalone mysql instance. logs or things that load from disk (LOAD DATA ...) are the only things you can't touch, but a small price to pay for automated backups, failover and scaling (both up AND down...)

Sorry if I wasn't specific enough.

In my opinion, you don't get enough control over the environment for what you're paying on a per hour basis. Automated backups? Great, they aren't that difficult to being with. Failover? Sure, within the same AZ, when you need to be doing it between datacenters. Scaling? I will grant that it scales up and down fast automagically.

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

#98

Earlier quoted context omitted.

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.

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.

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 :)

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

#99

Earlier quoted context omitted.

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

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…

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?

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

#100

Earlier quoted context omitted.

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.

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…

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

Post reply on HN