Scalarium Update: Load Based Auto Scaling, New Cloud List View, Selective Deployments

2010/12/14

To noone's surprise, we've been quite busy adding new features to Scalarium over the last couple of weeks, some of which we already snuck into the live version. Most noteworthy of these features is load-based auto-scaling. We already collect a good amount of metrics from your instances, so why not put them to good use and mix them with the elasticity of EC2, right? Fret no more, we got you covered. In your cloud overview you'll find a new tab for each role.

The basic idea is that you define thresholds for CPU or memory usage and load average. The metrics are averaged across all instances in that specific role, so we'll not just start a new instance for you when one maxes out, but when the average of all instances cross a certain boundary.

Anyhoo, you're greeted with a screen where you can define thresholds for scaling up and down. We define some defaults for you, which make sense in our experience, but you're obviously welcome to provide your own. Apart from value threshold you can define timeframe which should be considered when measuring.

The idea is to not just blindly start instances when CPU usage goes up for a spike that only lasts a minute or two, but instead to measure over a slightly longer period of time, we default to 15 minutes, that'll give a good idea if your instances were just handling a short burst or have significantly increased their workload in general.

You can define how many servers should be booted once the threshold is reached. Don't forget to add some instances for load based auto scaling though, otherwise your threshold will be met but there are no instances for us too boot up for you. You can do so through the usual "Add Instance" workflow, but this time selecting the new tab "Load based instance." Your new instances will show up in the cloud overview like you're used to, but sport a new icon to distinguish them from the others.

Hey, did you notice we're telling you how much your shiny new instance will cost for an hour, a day and a month? Quite handy, huh? I'm not going to go into all the glory details on load based auto scaling, we have an entire section dedicated to it in our knowledge base. Go check it out!

Next on the list of new features is a new list view for your clouds. When you visit your cloud pages now, you'll notice that each role tab bar has a set of new icons in it, showing a box view and a list view.

So far, when you had a whole bunch of instances in a particular role, the traditional box view could become a bit too much on the eyes, it was easy to loose sight of the details of all the instances in it, especially when it comes to the monitoring metrics. We hear you. You should click on the list view icon right now to see what we've come up with, or you can look at this pretty screenshot for a glimpse.

Shiny, eh? Instances are sorted by datacenter, and you get a nice overview on their basic details, internal and external IP addresses, controls to start, stop and reboot them, and to launch the SSH console too. Most noteworthy though are the monitoring statistics. In the list view we'll switched to showing you raw numbers representing the last known values. To instantly give you an idea of which instances are close to their maximum CPU, memory usage and load average. The list obviously includes all of your time and load based auto scaling instances too. Of course we keep your selection persistent as a preference, so that you don't need to switch to the list view again when you're coming back to a cloud's page.

Last but not least we added a feature that allows you to be more selective about which instances a deployment should go to. When you go about and deploy an application, you already saw a list of instances sorted by their role, demarking which instances a deployment would go out to. That list is now interactive and can be used to select or deselected single instances or entire roles and exclude them from a deployment. Quite handy if you need to do a deployment only on your app servers or even just the web server, because e.g. only static files have been updated since your last deployment. It can speed up a deployment quite considerably and avoid unneeded overhead on servers you don't want to touch.

To top it off we threw in a bunch of performance improvements on the cloud pages and for loading deployment logs. That's it for today, let us know how things work for you. Happy holidays! We know we'll be busy adding more awesome to Scalarium for you.