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!

We are delighted to announce public support for MongoDB in true Scalr fashion: self-managed, automatically scaled, and easily configurable.

Mongo takes its name from the adjective “humongous,” and it’s a NoSQL database designed for scalability and developer agility. Big names like foursquare, Intuit, and Shutterfly (among others) all use Mongo.

Up until now, our users had to create their own Mongo roles, scale them manually, and write their own scripts to manage clusters of Mongo instances. You had to dig into the Mongo docs to figure out whether to add a replica set or a new shard, dig deeper to find out how to do so, and even deeper to find out the best way of doing it. And that doesn’t even cover the complexity of scaling down.

Check mongo status from your farm's options

Scalr feels your pain, and that’s why we’re rolling out this new automated role for Mongo. Need more write capacity? Click to add a new shard. Need more read capacity? Click to add a new replica set. Want a backup? Click to create a data bundle. Backups, replication, and configuration are all managed for you.

Add shards and replica sets with ease!

While you’re playing around with Mongo, we’d love to hear feedback from our users. Email us at suggestions@scalr.com to let us know how the process works for you. In the meantime, we’re working on adding configuration presets for it.

Ready to get this party sharded? Start by creating a new farm at https://my.scalr.net/#/farms/build and adding Mongo found under the database category.

Whip out yer plastic—Scalr can now accept credit card payments.

After an arduous, tedious, and laborious process, Scalr beat the first PCI DSS boss and leveled up to a level 1 PCI compliant company. Next up: saving the princess.

We’re making changes to the way we manage domains for you. File this one under www.awesome.com (keyword: “just for you”).

First, we simplified endpoint formats. Endpoints, for MySQL, are the hostnames to which you connect your application. The database endpoint is usually the most important. Here are a few examples of the new format.

• int.master.mysql.farm-hash.scalr-dns.net
• int.slave.redis.farm-hash.scalr-dns.net
• ext.master.postgresql.farm-hash.scalr-dns.net
• ext.server-index.farm-role-id.farm-hash.scalr-dns.net

The format breaks down like so:

• int|ext determines if the associated ip address is externally available (to the public internet) or not
• master|slave determines whether the endpoint links to either the single master server or one of the many slave servers. If you leave it out, the endpoint will be both.
• mysql|redis|postgresql [optional] determines the role if a database
• farm-role-id [optional] determines the role if not one of the above
• server-index [optional] points to the server’s index in the farm. For example [3] for the 4th instance launched of that role, in that farm.
• farm-hash determines the farm
• and scalr-dns.net is our new domain to handle / offer this service.

We also changed the average TTL, or time-to-live. This is the amount of time a computer caches DNS records before requesting them again. We noticed that TTLs of 90 seconds were often a little too long (many of our users reduce them to 60 seconds or even 30 seconds). Therefore, we reduced the average TTL to 20 seconds.

We’re also able to update records faster. Instead of waiting for our scheduled job to run (which it does every minute), the records under this new system are updated as soon as your infrastructure changes. This removes the lag during which the endpoints point to the wrong address.

To start using the new system, you can find the endpoints by clicking on Extended information under Options for any farm.

You can find more information about a server or farm here

You’ll find something like:

Connect your app to your db with these endpoints

We hope you enjoy!

Ever wondered how much a particular farm of yours costs? Amazon might bill you $4,720 for the month, but how much of that came from bobs_farm versus pats_farm? This is especially important if you manage your client’s farms and need to bill them (and apply a markup!).

Scalr makes it all possible. Starting today, you can find “Usage statistics” under Options for any farm:

Usage statistics can be found under options for each farm

This will take you to the following view:

See application and farm costs from this interface

If you can’t possibly wait to unwrap this package, check out the view here. Purdy, ain’t it?

This new page also allows you to track the farm’s expenditures over time, so you can see how well your infrastructure scales with your business.

And before you ask—yes, you can download this into Excel or any other spreadsheet. The export is done as a CSV file and can be found to the right of the grid:

Click here to download the stats as a csv file

We’re taking in requests—like API access, we know—to make this more useful to you. If you have other suggestions, shoot us an email at suggestions@scalr.com.

We heard you wanted a pony for your birthday, so we got you the next best thing: a new and improved scheduler. Trust us on this one.

We introduced the original scheduler some time ago to make it more convenient to run cron jobs reliably across a cluster and to avoid the problematic oh-but-the-machine-that-was-supposed-to run-the-cron-job-crashed situation.

So we did some tinkering. We ported the schedule to our new JavaScript engine, like the rest of Scalr (in fact it was the last piece that we needed to port over). This means that it’s faster and completely JavaScript- and JSON-driven, which opens the door for future API access. Furthermore, we rewrote the backend execution code to handle more edge cases.

So maybe you can’t braid its mane or paint its hooves, but you can start using it right away. If you had tasks running in the previous scheduler, they will continue to run in read-only view, and you’ll have the option of migrating them to the new one (the button says, not-so surprisingly, "Migrate all my tasks to new scheduler").

We want to avoid any issues with timezones and unexpected duplicate task runs, so we're not automatically migrating tasks set on the previous scheduler to the new one. We know when we shouldn’t horse around.

The new, awesom-er, scheduler

Tally-ho,
The Scalr “clock-is-ticking” team

Permissions, permissions

Today we’re rolling out permissions at Scalr. You can now create users for everyone in your team and restrict that pesky intern’s privileges so he can’t log into servers and mess things up. You can even show off to a client that awesome architecture you built—with read-only access. Or partition your developers and system admins so they stop warring over the cubicles. Nerf guns hurt, you guys.

Here’s how to set up permissions: you add users, create their logins and passwords to access Scalr, and assign them to teams. Each team is associated with a specific environment. The team owner can then set permissions (through permission groups) to each team user individually, to allow Bob to terminate servers and Pat to launch new ones.

Create teams and users from the top menu

Just like you wouldn’t share your toothbrush with just anyone, you shouldn’t give full Scalr access to everyone in your organization. Starting with plans IPO and higher, you get to do just that. This allows you to maintain the sanctity of your toothbrush.

What’s next? We’re going to tweak and improve the UI while you play around with the new permissions feature. Remember, you’ll need to upgrade to the new plans (if you haven’t already) to use this feature.

Grant your users partial access to components

You can learn more by reading our thorough reference manual.

As many of our clients have pointed out, it doesn't make sense to charge for additional environments, especially when Scalr asks you to choose a plan based on a number of managed instances. Therefore, all environments are free—effective immediately. Have at it!

Scalr environments are now free

For those that need a refresher, an environment is a set of cloud infrastructure keys used together to create farms. For example, if your production environment contains some Rackspace and some AWS keys, then you can create a farm that includes instances from both providers: if one goes offline, your traffic goes to the remaining one.

Multiple environments allow you to isolate farms entirely. This can be useful to make sure your Dev environment doesn't screw up your Production one. You can even set up an environment for each one of your clients so that billing, farms, and access are all separate.

Try it out, and let us know what you think!

Scalr now supports VMware’s open source PaaS, Cloud Foundry!

Platforms-as-a-Service, a.k.a PaaS, have been all the rage in 2011. Does the startup Heroku ring a bell? It should: our friends Adam Wiggins and James Lindenbaum took the tech world by storm with Heroku.

Since then, a number of competing platforms have also grown in popularity (such as the Google App Engine, DotCloud, EngineYard, OpenShift, and Joyent, among others).

And now with Scalr you can easily run and operate your own Cloud Foundry cluster. Simply add the Cloud Foundry role to a farm and launch.

A production-ready Cloud Foundry deployment

Cloud Foundry on Scalr is available in two flavors.

The all-in-one flavor is a role that includes all CF core components but does not scale. This is ideal for test runs, trials, and evaluations. What’s more, it’s cheap to run on a public cloud since it runs on a single server.

The component flavor is composed of three roles, for each of Cloud Foundry’s core components: the router, the DEA, and the CCHM (with nats, cloud_controller, health_manager). Both the router and DEA auto-scale, but the CCHM is limited to a single node.

A load balancer forwards traffic to nodes of a Cloud Foundry cluster

Got you excited? Nerd it up and read more about it here, or you can create your own account and get your hands dirty.

There are some limitations: this hasn't been integrated into Chef yet (although the CF team is hard at work on preparing cookbooks for it), so this doesn't work with our Role Builder. However, we pre-made some  images for you on EC2 using Ubuntu 10.04 64bit on the hosted Scalr service, so you don’t have to build them, and can get started in seconds.

What’s next? We don’t have any service bindings yet, but we have full scaling support for MongoDB, Redis, and MySQL, so as soon as we do, managing your CF cluster for your applications will be dead simple.

Complement your Cloud Foundry deployment with scalable, self-managed db services

Hey everyone,

We're pleased to announce a new stable release of Scalr available for download. Scalr's dependencies are still hard to install, but Scalr itself is easy.

You can request the source from http://scalr.net/features/open-source/

Why do we have a request form you ask? We want to be able to track downloads, as well as ask a few questions to find out what the community is doing with the source code. It also helps us find out if there are feature holes in our hosted offering. Finally, it'll help our sales offer software support.

Cheers,
Sebastian