I know almost nothing from a unix sysadmin perspective, but would invest the time if it is feasible.
Why I left Heroku, and notes on my new AWS setup
21–30 of 231 posts
Re: Why I left Heroku, and notes on my new AWS setup
#22> 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...
Re: Why I left Heroku, and notes on my new AWS setup
#23If 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…
Re: Why I left Heroku, and notes on my new AWS setup
#24What 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.
Re: Why I left Heroku, and notes on my new AWS setup
#25> 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.
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.
Re: Why I left Heroku, and notes on my new AWS setup
#26Earlier quoted context omitted.
Hehe, yeah, that sentence doesn't sound particularly simple. :-) Check out the code snippets I linked to from that blog post. It's pretty easy, I promise -- the tricky thing is just figuring out the various APIs.
I apparently need to get back to that book.
Re: Why I left Heroku, and notes on my new AWS setup
#27If 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…
Re: Why I left Heroku, and notes on my new AWS setup
#28From 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 l…
Re: Why I left Heroku, and notes on my new AWS setup
#29This 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 so…