Over a year ago, Amazon Web Services built their nifty Popup Loft in San Francisco. Since then they’ve hosted a ton of cool events, including a very regular series of all day, hands on labs. The labs are free, everything is provided, even lunch. There’s one critical issue (for most people): getting time off work to go to the lab is hard! Fortunately for me (and several others in the class) I’m between jobs, so I have time to attend and get all educated.

Once you get to a certain number of servers (virtual, physical, or cloud), you need some manner of centrally managing the machines. Something that will let you install packages and configure them all in some standard way, so you don’t have repeat these steps a hundred times yourself. In my experience, the pay off was less during the initial setup phase (because you’re generally only setting up 1 or 2 machines at a time) and more in the “we need to change something that affects all the machine” phase. Regardless of what phase, Puppet does a great job of helping you out. The last company I worked for did not have much in the way of central management so I started to learn Puppet and deployed it.

Recently, I was asked to enable mod_rewrite for Apache on our webservers, which are controlled by the sexy puppet master server. I did a quick google to see if anyone had any recipes published. On the puppet wiki there is a recipe for Apache on Etch, but their module portion installs Apache modules. In the case of mod_rewrite it comes with Apache2 so it doesn’t need to be as complicated as they suggest.

At the office I’ve been working to move our operations infrastructure into Puppet. Since I’m fairly new to puppetizing, I’ve been spending a lot of time with puppet. During one of my recent trial runs, I got the following (cryptic) error message: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type What. The. Hell?

This morning I received an email from Amazon Web Services announcing the release of Amazon ElastiCache. In Amazon’s own words “ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud.” At first glance, that sounds very handy to have. After all, Amazon already has DB backends, instances for application front ends, load balancers and remote file storage, really the only part left for a large application is cache. The best part about Amazon ElastiCache, and a very smart thing to do overall, is that it is running Memcache (or at least is Memcached compatible). So I start out very enthused by this prospect, but by the time I get to the pricing section… I’m very underwhelmed.