The Official Scalr blog software to auto-scale the world's websites

Server usage statistics

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.

Cron Jobs 2.0

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

Please, sir, may I have some more?

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.

Environments are now free!

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!

You bet your PaaS it’s open!

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

Two-factor authentication now available for plans IPO and higher

Scalr users on the IPO plan (40 instances) and higher can now enable two-factor authentication for additional security.

As your organization grows, so does the risk of a weak or lost password compromising your infrastructure. To avoid that, you can now enable two-factor authentication so that a lost password in itself doesn't compromise your account.

Here's how it works: you use the Google Authenticator app to obtain a code, which you then use with your regular password to log in. Simple, yet secure!

Here's what it looks like:

Enable two-factor authentication to login to Scalr

Two-factor authentication is only available to our higher tier plans, since the utility of this more secure login often comes with larger deployments and organizations—although you can always get it by upgrading regardless of the number of instances you have.

Cheers,
The Scalr Security team

Clarifications on the price change

Confused abut our new pricing model change? Take a gander at the following frequently asked questions:

Why should I upgrade?
For service and functionality optimized for the size of your operations. New functionality will be available only to customers on the new plans.

Upgrading now will give you the ability to create multiple users, organize them into teams, and manage permissions granted to the aforementioned users and teams. You will also be able to purchase additional environments, which help you manage client accounts under a central account and isolate development and production servers into their own cloud accounts.

Most importantly, the new plans allow Scalr to better tailor further functionality for those who need it most. For example: Chef is a great configuration management tool, but it only starts shining when you manage over 20 nodes. So Chef support will be available to the IPO plan (for customers using over 20 servers) and higher. Likewise, RAID support for network volumes, master-master replication for databases, and advanced db tooling will be available for those on the VC plan.

How much is it to upgrade?
Simply put, you only pay for what you need. Count the number of instances that Scalr manages for you, and pick a plan from our pricing page that accommodates that.

Selecting a plan among several in Scalr

When does the new pricing take effect?
The new pricing plans opened last Thursday.

Do I have to upgrade?
No. All current customers are grandfathered into their existing paid plans. You don't need to change anything to use Scalr as you did before.

What if I don’t upgrade?
We will sob and smear mashed potatoes on our emaciated bodies and ululate.

Oh, and you will miss out on new features and everyone else will be so much cooler than you.

Is this model final or is it still being shaped?  
It is already shaped like a fine voluptuous vixen, with each tier more attractive (and with more features) than the next.

What is the difference between emergency support and premium support?
Emergency support will provide a faster-than-normal response time in an emergency. Premium support is for general operations support above and beyond the normal call of duty.

Does auto-scaling conflict with a plan’s instance limit?
No, the plans allow for auto-scaling when you experience temporary spikes in number of instances. So even if you’re normally limited to 10 instances on the Angel plan, you can still scale to 11 instances from a temporary high load.

So the server limits are not hard-imposed? For example, on an occasional extreme peak the system would go a couple of instances over the limit?
You said it, brother.

Change your subscription, credit card, and other information on the billing portal

Important Updates to Scalr Pricing Model

Dear Cloudsters,

In order to, well, scale with the number of servers needed, Scalr will soon change its pricing model from the current flat rate plan. But don’t arm yourselves with pitchforks and brandish your torches just yet: all paid users will be grandfathered into their existing plans for as long as you want.

In Scalr’s humble beginnings, most clients had between 1 and 10 servers. A flat rate made sense for everyone. Today, however, our largest clients run hundreds of servers. We’re serving a wide range of clients who have different needs, so we want to offer the best fitting plan catered to your operation. In following the Dharmesh test for SaaS startups and aligning our interests with yours, Scalr will charge more for those who get more from our service.

For most paid users, though, you will see little to no change in your current monthly rate. Here’s what you can expect:

• 40% of our paid users will see no cost increase in switching to the new model.
• 20% of our paid users will see an estimated $50/month increase.
• The remaining paid users will see a cost increase proportional to the amount of instances they run.

Starting soon, everyone can upgrade in app through the billing section. Users with free plans must upgrade to a paid plan within 90 days to retain their access to the Scalr service. Unfortunately, we can no longer absorb the cost of offering free support.

(Of course, you can always run Scalr yourself using the open-source code. Community support is available from #scalr on irc and through the scalr-discuss mailing list.)

And just to sweeten the deal, we’re ready to roll out new features for all users who upgrade to the new plan. Drum roll, please!

• Users: add as many users as you want and set their permissions
• Teams: corral your own team into different logical groups
• Environments: consolidate your clients into a single account or isolate Dev from Prod

Scalr will continue to prioritize new functionality for those who upgrade, and with our new tiered system, we can make available the features you need most. Thanks to the new pricing model, Scalr will be better equipped to funnel our resources appropriately and accommodate all users’ separate needs.

Cheers,
The Scalr Team

Boot faster! Faster!!

A while ago some complained about the time it took to bring up large amounts of instances in Scalr. While never a problem for scaling web apps (incremental scaling), it was for bringing up data crunching farms, crawlers, and any kind of asynchronous task.

We looked into what optimizations we could do to help you with that, and found quite a few.

The Scalarizr initialization and messaging phases have been reduced from a couple minutes per instance to less than 10 seconds for a whole farm. In some tests we ran, we had 50 instances send HostUp within 7 minutes of starting a farm with min_instances = 100, which includes API call, provisioning, and OS boot. For instances that need EBS volumes, boot and initialization take longer because of the AWS requirements, but you should still see about a 50% speed increase (33% time to HostUp decrease) in those cases.

I hope you enjoy this effort!

Cheers,
The Scalr "Make it faster! Faster!!!"  team