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

141–150 of 231 posts

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

#141

Post by druiid »

jcastro wrote: post #104

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…

I would really love to recommend Juju. I used it for a good couple months attempting to get even just a working Openstack deployment. The trouble is that for the bare-metal functionality you guys mean it to be paired with MaaS. Unfortunately the community I found to exist around this combination was basically zero.

Even a simple question went unanswered the couple times I posted it. Eventually I gave up and just went back to Puppet+Openstack modules for the configuration I was working on at the time.

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

#142

Post by jcastro »

23david wrote: post #122
jcastro wrote: post #104

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…

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.

1.10 (what's in 13.04) is much more reliable now if you want to give it a shot, here's a PPA: https://launchpad.net/~juju/+archive/devel

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

#143

Post by adrianh »

japhyr wrote: post #114
adrianh wrote: post #107

Earlier quoted context omitted.

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.

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?

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.

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

#144

Post by druiid »

tlrobinson wrote: post #139

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?

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.

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

#145

Post by japhyr »

adrianh wrote: post #143
japhyr wrote: post #114

Earlier quoted context omitted.

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?

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…

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.

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

#146

Post by rbc »

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…

I'm a fan of CFEngine and use it for the things that many use Puppet or Chef to do. I think the key advantage of some kind of system domain specific language, is it helps document how things are configured. The only way to figure out what's going on in AMIs is mounting their file systems and running diffs to see what changed AMI, to AMI. Having a large number of AMI's can also be a problem in the respect that they proliferate, particularly when you deploy new applications, based on old applications, but slightly different.

On the other hand, if you are using auto-scaling, Chef/Puppet/CFEngine may not be able to finish their work in time if they have to do a lot of work. You have to strike the right balance between what needs to be in the AMI (provisioning) and automation (post-install).

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

#147

Post by psychometry »

adrianh wrote: post #109
deno wrote: post #83

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.

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.

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

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

#148

Post by tjbiddle »

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.

It's actually a lot simpler than it sounds:

- Create a new EC2 instance (Literally click "Launch instance" and select Ubuntu. - Login and install any dependencies (sudo apt-get update && sudo apt-get my list of awesome packages i need installed) - Go back to the EC2 dashboard and click "Create AMI" which is just imaging the server. - I can't attest to the ease of ELB and auto-scaling rules as I haven't used them, but I would assume it's fairly straight forward - and there is a ton of resources on AWS to help you out :-)

Have fun!

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

#149

Post by adrianh »

slig wrote: post #135
adrianh wrote: post #108

Earlier quoted context omitted.

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!

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?

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.

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

#150

Post by jcampbell1 »

skinnymuch wrote: post #98
steveklabnik wrote: post #40

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…

> What's the difference between EC2 and a VPS for you?

For me it that restarting an EC2 instance deletes all the local storage. I have had good success just getting a big ass VPS, and running the database locally, and pushing text backups to S3. It is trivial to manage, and in the real world, downtime is more likely to be caused by configuration wonkiness than hardware failures.

You also have to have a huge amount of traffic to overwhelm a 24core / 96GB ram server. Why not put off the managing the complexity until you really are doing 10M page views per day?

Post reply on HN