Create copies of your setups with farm cloning

What’s that? You want *another* new feature? OK!

Scalr now allows you to clone your farms with the same roles and settings. This is one of my favorite features because it’s a great example of the operational agility that Scalr affords you.

You know how object-oriented programming allowed us to avoid repeating ourselves in our code (aka DRY, or Don’t Repeat Yourself)? In the same vein, this object-oriented model can also be applied to sets of machines, or clusters—known as server farms in Scalr. Define a model, or blueprint, for some infrastructure, and you can instantiate it into real infrastructure to run your application. And then you can use that same model to deploy your application in China, Italy, or the Great Nation of Kazakhstan, which allows you to avoid repeating yourself.

The model can even be applied to software configuration (i.e. what’s on the machine? WordPress? Postgres? Redis?) as well as the passwords, endpoints, and security configuration of each. Software like Chef and Puppet fill this role and allow you to do this through code.

Following this model, you can now clone your farms to create a copy. Here’s how:

On the Farm View page, select Options > Clone. This will create a copy of your Scalr configuration (note: no data is cloned yet), including all scaling settings, scripting settings, etc. In addition, new EBS volumes, ELB, and Elastic IPs will turn up as if you had just created a new farm.

From your farm's options, select 'Clone'

What’s next? You tell us! One thing that might be useful is cloning the farm’s data too, by creating snapshots of the volumes used in the origin farm. Although you can’t do this from Amazon to Rackspace (because the images are incompatible), it might still be useful to do this between regions of a cloud.

This is a first step towards FarmTemplates: farms that you can create, clone, and share with others, for WordPress, Drupal, and other popular software.

Let’s look at three immediate use cases:

1. You can test new features or a new upgrade before going live.
Want to test the effect of MySQL 5.6 instead of 5.1? Create a clone in your dev environment, modify the clone to update MySQL to 5.6, and test it. If it works, you’re safe to repeat on your production environment. If not, you can solve the problem without taking the site down—or better yet, without your manager yelling at you.
2. Create backup with some fancy copy-paste.
Deploy your farm clone to another datacenter, so that if the first goes down you can still operate.
3. Create copies for your clients
If you repeatedly create farms for your clients, internal development groups, or more, then you can create a master farm and clone it instead of repeating yourself.

We think the new cloning feature will find a special place in your heart, especially because it’ll help you save time (and your ass). You’ll never have to repeat yourself again! Yourself again!