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

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

Time Zone settings to be reset

On Wednesday Oct 19 at 12.00 GMT we will update the code responsible for time zone management in Scalr. After this update, all previous log, instance launch, and event timestamps will appear in an incorrect (but consistent) time zone.

By now, you are probably  thinking "why on earth are they doing this?". One of the problems you've probably encountered (we have!) using Scalr is that timestamps from different sources use different timezones. Instance launch time might use local time, but logs collected might be remote (thus depending on the server's location). This makes it difficult to troubleshoot problems.

With this update, we're converting every timestamp to a single local timezone, and the UI will be in charge of converting it to the timezone of your choice.

We expect this to be completed in the next 5-7 days.

RDS for Postgres

We are pleased to announce the general availability of a new Postgres role.

When it comes to MySQL vs Postgres, you’ll find another holy war between quasi-religious fanatics of both technologies, similar to what you’d find between Windows and Linux. Or to the layman, Snickers vs Mars.

Postgres now auto-scales on Scalr

That said, there are notable technical differences between both databases.

WHY POSTGRES
First, Postgres lets you perform DDL changes (a.k.a. schemas, or if you are more familiar with Excel, changes to column names and spreadsheet names) as transactions. This means that either the schema change is successfully and entirely done or else it rolls back to its previous state. This wiki goes more in depth on the process.

Why is this important? When you have a large database (or worse—lots of large ones in a replicated + sharded cluster), then the probability of a failure that requires tedious manual repair increases to threat level why’s-the-rum-gone. Running migrations as transactions means that if there’s a failure, you can simply run the migration again. MySQL 5.6 still doesn’t support this.

Postgres also allows you to create indexes (to speed up queries on the indexed column) without write-locking the table (which prevents you from writing new data but still lets you read from it).

Here’s a good comparison of MySQL and Postgres from Quora and a blog post on why Heroku chose Postgres.

POSTGRES BY SCALR
This Scalr Role comes with the same automatic backups and recovery that you get with RDS (but on Postgres), only with added auto-scaling (which RDS lacks). Here are a few screenshots:

Configure postgres backups from here

This Postgres role doesn’t support Configuration Presets yet, so if you need them soon, let us know at suggestions@scalr.com.

Like all database roles, the options menu contains a status page.

Postgres status

This status page allows you to check on the databases’ replication status, last backup (a dump), and last data bundle (binary snapshot).

Easily check Postgres operational status

HOW TO GET STARTED
We’ve prepared a few images for you (but not on every infrastructure cloud). If you can’t find one that suits you (maybe you want to deploy on Rackspace, maybe you want another OS), you can use the Role Builder. Find the Role Builder under Roles in the top menu and use our Chef recipes to create some automatically for you.

Deploy Postgres in any cloud with the Role Builder

Redis Redux

I for one welcome our new NoSQL overlords!

At Scalr, we’ve been following Redis for some time, loving its data model (a key-value store with a bit more structure than memcached), its speed (it’s a bloody fast in-memory database), and have been planning on using it internally to complement our usage of MySQL.

WHY YOU SHOULD USE REDIS
Redis is great for the following web use cases (taken from my friend Todd’s excellent blog at HighScalability, more details here):

• Latest items in a Craigslist or eBay clone
• Leaderboards or Digg & Reddit style voting sites
• Counters and Rate Limiting like number of API calls per client per month
• Stats tracking, like unique pageviews
• Pub/Sub, like Amazon SNS (topic-based message filtering, although content-based filtering can be achieved in your app)
• Message queues, like Amazon SQS
• Caching html fragments, like you would do with memcached

HOW REDIS WORKS
Persistence. As an in-memory database, Redis holds the whole dataset in RAM. Since RAM is volatile (a power down or crash results in total loss of all memory data), Redis offers two persistence models: Snapshotting (a semi-persistent durability mode where the dataset is asynchronously transferred from memory to disk from time to time), and Append-only (a file or journal that is written as operations modifying the dataset in memory are processed, which allows Redis to rewrite the append-only file in the background in order to avoid an indefinite growth of the journal).

Scaling. Scaling Redis can be done through replication (read scaling) and sharding (write scaling). Pretty much the same as MySQL.

Replication. For those of you thinking about read scaling or data redundancy, Redis supports master-slave replication. Data from any Redis server can replicate to any number of slaves; a slave may even be a master to another slave, for example (aka cascading replication, or a single-rooted replication tree). Worthy of note is that Redis slaves are writable, permitting intentional and unintentional inconsistency between instances.
Sound good? Well we have good news for you then! Redis is now available as its own automatically replicated, automatically backed up, automatically persisted, and automatically monitored role in Scalr.

Sharding. Sharding with Redis isn’t done on the (Redis) server side, but rather on the client side, next to your code running on your web server, with a client library that performs consistent hashing. That is, every request’s key is hashed, and the hash determines where to find or put some data. The hashing needs to be consistent, so the same key always gets hashed to the same location. More on consistent hashing.

SCREENSHOTS

Redis status: replication, backups, and more

Redis settings: backup schedule, persistence method, storage engine, and more

Check Redis' status from the Options menu

Create a Redis role (image) on any cloud with the Role Builder

**Special thanks to VMware for sponsoring development of this great project.**

Remember that secret project? Introducing…

We cryptically announced a private beta recently, and now we’re ready to spill the beans!

As you know, we have a great API (if we say so ourselves) but it isn't terribly practical for performing routine operations.

So we created a handy command line tool that lets you better interact with the Scalr API and deploy code more easily.

Um, so what?

You can do more cool stuff. Let the possibilities begin:

1. Create a dev server farm, and let your developers tie it to their code repository. They push code to the repo from the command line using git or svn, then from the repo to the servers using the new tool.

2. Same as above, but add some continuous integration into the mix with Jenkins. Here's what your workflow would look like:

a. Create a fork or a new branch in repository, checkout code from it
b. Code a new feature
c. Merge new code in your fork or branch
d. Use our new tools to push code from your fork or branch to your dev server farm
e. Use Jenkins to run tests
f. Repeat steps b.-e. until tests pass
g. Commit to main branch

3. Go totally hardcore and deploy directly to production systems. If things break and tests don't pass, keep pushing new code quickly until they do. Alternatively, roll back to a previous revision just as easily.

4. Practice your bash-fu and use the command line tools from inside your instances to retrieve information about your other farms, like getting the IP addresses for all your web servers so you can configure your varnish reverse proxy with them.

5. Pipe grep with logs obtained with the tool to quickly find some data.

6. Stuff we haven't thought of.

This lacks polish, but it’s a start.

We'd like to better integrate code repos to Apache vhosts and DNS to avoid tying code in a repo to a directory. Instead, you could point it to a domain and the vhosts and directory are taken care of. For example, tying repo X to (sub)domain beta.example.com, creates a vhost for beta.example.com on all web servers in farm Y.

Surely your mind races with the endless possibilities of such a powerful tool, so we'll finish off with a single link to help you get started.

Installation and Getting Started

We hope you enjoy this great new tool.

Cheers,
The Scalr Command-line Team