Good news for those of you using our canned roles for mysql, postgres, or redis: we’ve significantly improved their interfaces in Scalr.

Our goal for these pages is to give the DBA a simple, powerful control panel for managing database infrastructure. This means exposing performance metrics, configuration details, administration links, and facilitating routine operations such as capacity resizing. See for yourself.

One page to rule them all.

We also wanted to give you a visual representation of your database tier, and make launching new instances easy right from there, since our interface to Mongo was so popular.

Launching slaves is easy!

We also integrated this new interface with our performance monitoring, so you can see the load on each server right where you make the decision to add capacity. If you want more info added here, simply let us know and we’ll comply.

Server stats, right were you need them

We’re actively improving this interface, so if you have improvements to suggest, now’s the time!

Cheers,
The Scalr “UIs are underrated” Team

DevOps attention! This is not a drill!

We’ve just released a new set of features that tremendously extend the flexibility and customizability of our management tools, along with corresponding UI improvements.

First, we’ve upgraded the parameters functionality that few of you used with a new system called global variables. This new system is a key-value storage that allows you to set, store, and retrieve arbitrary information for re-use in scripts, deployments, and any configuration management software that you use, such as Chef.

Global Variables let you set in Scalr values that you can set and retrieve in your scripts.

Second, we’ve upgraded our scripting functionality into a full fledged *drum roll* orchestration engine™ that gives you more control over script execution scope. For instance, you can now target specific roles, or even specific classes of roles (which we call behaviors). This makes bringing up clusters with internal dependencies easier than ever, allows you to extend and customize Scalr’s built-in automation, and facilitates the creation of your very own roles!

The orchestration engine lets you build new roles or extend existing ones

To go with this new and improved *drum roll* orchestration engine™, we’ve improved script execution logging, and you can now pinpoint a failed or successful execution down to the instance it was run on, so you can troubleshoot or investigate. Even better, we integrated it with the events list, so users can see what actions were taken (such as what scripts were executed) for each trigger (such as the HostUp event).

Errors can now be backtraced to their source for troubleshooting

Topped with a new user interface and speed improvements, this should make Scalr easier and more flexible than ever to serve your workloads big and small.

Cheers,

The Scalr “Orchestrate this!” Team

A few weeks ago, AWS made launching instances in a VPC the default for new accounts in the Sydney and Sao Paulo regions, and called this “EC2-VPC” (as opposed to “EC2-Classic”). EC2-VPC expands, as explained here, on EC2-Classic’s networking capabilities, making it more useful in the enterprise, as well as better suited to the more security-minded of us. This new default automatically places new instances launched in a VPC and public subnet.

Today we’re launching our first integration with Amazon VPC by supporting the EC2-VPC behavior. If you have such a VPC based account, all instances you launch from Scalr will automatically be placed in a VPC, in a single public subnet, and have a public IP address that it uses to access the Internet and hence Scalr. You’ll also be able to see VPC and subnet information from the details page.

This change is completely transparent to users –as most of the work is done behind the scenes by Amazon itself– so there’s nothing you need to do to take advantage of this. Simply wait for EC2-VPC to come to your region.

Cheers,
The Scalr “virtually private” Team

A while ago, we added a feature called “configuration presets”. These presets allowed you to define from within Scalr the configuration files for the services that you used, such as MySQL, Postgres, or Redis, and let Scalr handle the complexity of orchestrating file updates and service restarts.

There were a few limitations to this system, most notably that if you were unaware of this feature and made changes to a file such as my.cnf directly from the instance, Scalr would overwrite those changes (we considered this a good thing, but not everyone agrees).

So today we are releasing our improvements to our configuration file management system, making it more reliable, compatible with other management systems, and yes– realtime.

Here’s the workflow by which it works: when you click on the “Manage configuration” button from a Status page, Scalr will

1. load the configuration file from the current master server (in the case of a replicated database, and to make sure we don’t overwrite your changes),
2. let you edit or add any fields / lines and click ‘apply’,
3. test your changes with a handy tool called configtest so no faulty settings are pushed (Scalr will also show you any faulty settings),
4. if configtest isn’t supported, we restart the service with new config; if the service doesn’t restart, we rollback to your previous configuration and show you the error;
5. restart the service, if needed, and
6. push your changes to all nodes starting from the master, and finishing with the slaves.

Manage configuration directly from Scalr

Adding new values is dead easy.

Update was successfully applied on all two servers.

This new system has been updated for you to use with MySQL 5.5, Percona 5.5, Redis and PostgreSQL, and has very few (necessary for our baked-in automation) limitations, such as replication configuration. Apache, Nginx, and other are coming soon.

As usual, let us know what you think!

Cheers,
The Scalr “Realtime Hammertime” Team

Not that long ago, we redesigned the “admin” interface for managing environments, teams, users, and permissions. We didn’t stop there, and today we’re releasing a new interface for the role builder: our software that lets you create new roles for public and private clouds that don’t support sharing images.

Choose the cloud on which you want to create your role, then choose your operating system

It uses the same three-tier layout as the admin interface, wherein you start by selecting the cloud where you want to create the role. You then choose the region and operating system, followed by the software you want to install. Finally, you give the role a name, and click create.

Choose what software you want, and Scalr will bundle automation free of charge!

The more advanced Scalr reader will be pleased to know that roles can now be custom built using Chef, and you can find a variety of options in the Advanced section.

Customize roles with Chef

Happy role creation!

The Scalr “rock & role” Team