We've Moved!

Appoxy LLC has moved! We've moved the office to a beautiful 11th floor location on Nob Hill in San Francisco.


The Building:

Some of the office space:

We're excited. We're also right across from the Ritz Carlton so we can conduct meetings there and pretend that we're uniting nations or something.

Chad

CloudCache is Now Officially in our Development Arsenal

As you are probably aware if you're reading this blog, everyone here at Appoxy is a big Amazon Web Services fan boy/girl (we also spend a lot of our hard earned money at amazon.com, but that's not for this post). But Amazon is missing a few pieces of the infrastructure puzzle and one of those missing pieces is a caching service. Thankfully, there is CloudCache. We are now using it in two production projects and it has become a standard component in all our new development efforts.

A Little Background

The most commonly used caching software is memcached which is a very lightweight, high-performance, distributed, in-memory caching system. To use memcached, you run memcached daemons on servers that have some extra memory to spare. Then in your application when you want to put some data into the cache, the memcached client that your application is using will hash the key you are using to put your data against the list of servers. After choosing a server, it will send the request to that server to store the data. So the servers don't really need to know anything about the other servers around it, it just stores whatever you give it and it will return whatever you ask for. Very simple, very efficient. There are a few major drawbacks though:

1. Each client must know the entire list of memcached servers (if you add/remove a server, you have to update the server list on each client)
2. If you change the server list on the clients, you invalidate the entire cache because the key to server hashes will all change.
3. Memcached doesn't handle failover. If a server goes down it's just down and any attempt to put to or get from keys that hash to that server will fail.
4. You have to run and maintain all these memcached servers!

The last point is the biggest pain point in our eyes. It's the very reason we love using AWS, so we don't have to maintain anything. AWS frees us from requiring storage hardware (S3), queueing servers (SQS), and database servers (SimpleDB), but not caching.

Enter CloudCache by Quetzall, or as I like to call it...

Memcached On Demand

If Amazon were to make a caching service, CloudCache is what it would look like. It gives you everything memcached gives you (and more) and you barely need to lift a finger. Just sign up, get your access key, secret key, and a client library for your language of choice. In a couple of minutes, you have a whole farm of cache servers ready and waiting for you. And did I mention it's cheap? At only $0.05 per MB per month, it's almost the same as running an EC2 instance for a month and better yet, you pay only for what you use.

How to Rotate Your Ruby on Rails Log Files

Nobody wants a disk to fill up when you least expect it so here is a simple step by step for rotating your Phusion Passenger log files.

1. Create a file called /etc/logrotate.d/passenger

And put the following contents in it.

/home/myapp/log/*.log {
daily
missingok
rotate 30
compress
delaycompress
sharedscripts
postrotate
touch /home/myapp/tmp/restart.txt
endscript
}

Now your logs will get rotated daily with the previous day being compressed into it's own file. The compressed files will sit around for 30 days then be deleted. After the rotation is done, postrotate, it will touch /home/myapp/tmp/restart.txt to restart passenger.

2. Test it

Run: logrotate -f /etc/logrotate.d/passenger

After running, you should see an archived log file and a fresh new active one taking the original files place. Also, Passenger will restart so it can log to the new file.

Ruby Interface to AWS Elastic Load Balancing Service

The AWS group is hard at work. They responded to the market demand with a load balancing service called, true to form, Elastic Load Balancing.

It's really slick - but generating soap or rest commands from scratch isn't all that fun, so we upgraded our Appoxy-aws gem and added an interface to the ELB service.

Now, using Capistrano, we simply use one command:

cap appoxy:launch_instance

To launch an EC2 instance, provision the system, deploy our code, and (with the new ELB interface), automatically attach the server to our load balancer.... viola, more capacity, testing server, staging server, redundancy, you name it.

Central to this strategy is provisioning and deploying almost everything using Capistrano. Building a full AMI sounds nice, but rebuilding an AMI after a gem update isn't very efficient.

Here's appoxy-aws: http://github.com/appoxy/aws/tree/master

Also if you want our Ubunty Jaunty clean AMI with Ruby 1.9 search for: ami-51769738

Finally, thanks again to RightScale for building the RightAws libraries that made appoxy-aws possible.

Cheers,

Chad