Let’s face it! From time to time, you woke up, grabbed your iPhone 4S and asked Siri: “What does my day look like?”. Then, the answer may have been: “Damned! There is a scalarizr update planned today. Don’t forget your stress pills”. For all the awesomeness that scalarizr brings to infrastructures, managing the agent has never been a walk in the park. Like every Rockstar, it had its whims and offered you tight choices. A Shakespearean dilemma: to update or not to update.

Buy one, get two

For instance, last Thursday, we released scalarizr version 0.7.226. We ran tests for various scenarios and farms types. Regrettably, scalarizr post-scripts deleted important runtime informations -sometimes leading to scalarizr’s crash. This kind of situation is exactly WHY the engineering team worked that hard to bring you today’s process update. Well, Scalr is thrilled to announce an era of seamless updates.

Like a Muffin, the revolution is built on three ingredients: the scone, the chocolate and the cream.

The scone

At first, a much more explicative interface has been shipped: on the server’s extended information window (Servers > View All > Options) you can display the current scalarizr status, updated details and informations on the new versions, check the last update errors, and update schedule info. Even better, you may also restart the scalarizr or upgrade it from this panel. This helps you to keep a record of the previous scalarizr updates and to know precisely what is under the hood.

Learn more

The chocolate

The chocolate makes the muffin’s taste: what a particularly true statement here!

You can now cook scalarizr’s updates up in whatever sauce you like. We implemented a double repo feature based on a simple principle: choice is better. If you are an “early-adopter” you should have the right to try the newest features. If you don’t like to dive in first, something proven must be at your disposal.

So, two drivers are actionnable:

• You can select a “stable” (or “prudent administrator”) or latest (or “go-getter”) repository
• The update’s frequency (for instance: not Saint Valentine’s day)

The repositories are completely isolated. Stable repo packages have been rock-solidly tested in real-life condition for at least one month. Unlike the newly introduced stocks of a famous social network, these won’t be downgraded after two days. ONLY the packages passing these hard tests will be marked as stable. You can sleep in peace.

The repository named “latest” straightforwardly contains the latest scalarizr version. It has been of course tested but may have been occasionally marked as non-stable. Theoretically, an issue is still possible, while actually rare. Therefore we recommend to use this repository for your stagging/development farms. If you do so, that’s ideal to test Scalr’s latest improvements at no risk.

The cream on the top

By default the auto-update-client will use the stable repository and check for new updates every hour. The frequency can be customized along with the repository settings. It has a classic cron job format without minute and month to define. Time intervals can take a value anywhere between one hour and one month.

Pimp your ride

Here are a few examples to illustrate those settings. For example if you let all the columns empty, that will keep the default choice: the cron job will be activated every hour. If you put 11 (or 23) under Hour the job will run everyday at 11AM (or 11PM). Eventually, you can choose 6,7 as the Day of the Week column to install potential updates only during the WE.

We hope that you will enjoy this major step towards a more personal Scalr (dare I say: “fun”?). As usual, we’re waiting for your feedback.

Enjoy!

The Scalr “Make a wish” team

Paul, our amazing Sales Engineer, has worked very hard these last days to write tutorials on the new documentation.

In case you missed them, here are some of them:

• How to install Magento with Scalr
• How to setup a Master-Master MySQL Replication in different regions
• How to install a WordPress Blog with Scalr
• How to install Apache Tomcat with Scalr and Chef

We are currently working on others:

• How to setup Varnish
• How to migrate to the Cloud

Which tutorials would you like to see on the documentation? Is there something in particular you struggle to install when you used Scalr for the first time? Your feedback would be really appreciated! If you want to contribute, you have our word: the most deserving tutorials editors will get a tee-shirt (or a hoodie).

The Paul Chapotet Fan Club

• EBS volumes provides block level storage volumes for use with Amazon EC2 instances. The data persists independently from the life of an instance. So when you terminate your database, the EBS volume attached to it will still be available and you could attach it to another instance. As a reminder, you can manage all your EBS volumes in Scalr going to Tools > Amazon Web Services > Amazon EC2 > Elastic Block Storage > Manage volumes
• Ephemeral devices are ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content, or for data that is replicated across a fleet of instances. The data persists only during the life of the associated Amazon EC2 instance.

You can learn more about storage on Amazon EC2 on our fresh new wiki.

To select your storage engine, click on your Redis or PostgreSQL role, and then on Database settings. Please note that you will not be able to change the storage settings once the farm has been launched (you’ll have to remove the role and then add it again). Ephemeral devices are available for Redis and Postgres databases only, but MySQL support should come soon.

In Storage Engine, you can select either "EBS Volumes" or "Ephemeral device"

• Data bundles are snapshots of the EBS volume containing the data (binary storage).
• Backups are snapshot of the EBS volume containing the data by running a database dump (object storage).

Realtime MySQL backup!

For the past two weeks we’ve worked on revamping the documentation site, this time on Confluence instead of DekiWiki, and I think we have a good foundation for future updates.

You can head on over to the new documentation site to take a look. We want this platform to become the ultimate knowledge resource on Scalr. Just let us know if you would like other tutorials to be added – this can be done. We’re waiting for your feedback.

Enjoy,
The Scalr “RTFM” team

The Ubuntu Cloud Summit was held this week in the Bay Area, and Scalr was in full attendance. Sebastian gave a well-received talk on Cloud trends, and the marketing team got Ubuntu stickers and feasted on M&Ms. Boy were they happy!

Meanwhile, the engineering team was hard at work–new Ubuntu roles were released, based on 12.04 aka Ubuntu Precise Pangolin. And this, barely a week after the official release.

Precise Pangolin

This much anticipated release is a Long Term Support release, aka LTS, meaning that it will continue to be supported for the next 5 years. This is ideal for servers, guaranteeing updates until 2017, long after the next American president’s mandate or World football cup in Rio.

Oh, and while we’re at it, let’s give a big shout out to Mark Shuttleworth, founder of Canonical, who paid us a visit in #SF last week. And thanks to the entire Canonical team and Ubuntu community for developing this awesome distro!

The Scalr Tux Team

We made this dashboard to address the following:

• Allow you to bring all the information that matters to you in one place
• Help onboard new users
• Keep users updated with new functionality, service announcements, etc.

We found that a widget-based dashboard addressed this best, despite how unoriginal it is. We made a half-dozen widgets to get started, including widgets that display costs to date for your farms, latest errors from logs, and a farm’s status.

To enable the beta, go to your account settings and enable the dashboard at https://my.scalr.net/#/core/settings

Most widgets can be added directly from the dashboard, but two of them are added from elsewhere: the Farm servers widget is added from the options drop-down menu of your farm, and the Graphic statistics is added from the Load statistics page.

My dashboard looks like this:

We hope you like this start, and welcome discussion of new features on the mailing list scalr-discuss.

To calculate these costs, we simply multiply the number of instance hours in each farm by the cost of the instance hour. We don’t keep an internal database of cloud costs though. We have a special secret that we’d like to share with you.

AWS has a json feed for their web services pricing.

Yep. You heard me.

We get the information directly from Amazon. In json. See for yourself below.

• On Demand Instances
• Reserved Light Utilization Linux
• Reserved Light Utilization Windows
• Reserved Medium Utilization Linux
• Reserved Medium Utilization Windows
• Reserved Heavy Utilization Linux
• Reserved Heavy Utilization Windows
• Data Transfer Pricing
• Cloud Watch Pricing
• Elastic IPs Pricing
• Elastic Load Balancer (ELB) Pricing

There’s even a python client for accessing the data!

Circling back to calculating the costs of each of your farms, we’ve found that for most users, EC2 instance-hour costs constitute over 80% of total expenditure. So if you assume that other costs (storage, bandwidth, ebs io) are evenly distributed, you can do a rule of three and determine costs of each application you are running.

Cheers,
The Scalr “Bean Counter” Team

But doing so presents a few challenges: first, creating many images make it harder to track down a particular one, and fill up storage space (or balloon storage costs). Second, versioning can be difficult and non-linear (which is why we add a timestamp to a role’s name when you create a snapshot). Third, rolling back to a previous version in an emergency can be delicate.

In today’s release, we’re addressing the third problem by making it possible to revert to a previous role in a few clicks. Now, under Farms -> Roles -> Options menu you’ll find the option to revert to the previous role, like below.

This will revert the role to the previous one (eg. to ‘my-base-1′ if your roles were named ‘my-base-0′, ‘my-base-1′, ‘my-base-2′) without losing any settings (scripts assigned to events,parameters, scaling options). Previously you’d have to edit a farm, remove the role, and add the previous one, which would have you lose the settings. Scalr won’t replace running servers though, this is left to you: only new servers will start using previous image.

With this new feature release, we’re acknowledging the alternative practice to using Chef or Puppet for configuration management, and will continue to make this process easier. We just need you to you keep sharing with us details on your way of working and how we can help.

Cheers,
The Scalr “Ok, have it your way” Team

We build Scalr to help you manage and automate your cloud infrastructure. Often times our roles, with their pre-packaged automation, do the trick. But sometimes you need something slightly–or entirely–different. That’s where the scripting engine comes in: making that easier.

The past few weeks a lot of pre-packaged automation has seen the light of day (we’ve been very productive) with MySQL Proxy, guest agent improvements, and a RabbitMQ role. So we thought we should balance it out with improvements to the scripting engine. Thus…

You can now associate scripts directly to roles.

What?! Yes, you heard me. You can now attach any script to any role, whether it’s in a farm or not. Previously you could only do so if the role was placed in a farm.

This makes it much easier to build and reuse your own automation. Want to create an auto-scaling, auto-recovering Cassandra role? Just combine some Chef / Puppet / custom scripts, hook them to Scalr events on to a base role and voilà! you got it. Want the Apache role to behave slightly different? Perhaps proxy traffic to Tomcat? Associate a script that adds the desired behavior to the role, and you’ll ensure that the modified behavior is available to all your farms.

What if I modify the upstream role? What happens to the ones in my farm?

Simple: any scripts added to the parent role are added to the child farmrole (a role added to a farm), creating a nice inheritance model.

Some other use cases are:

• Enforcing the presence of some software. Like a configuration tool we don’t have native support for (read: Puppet). Make a Puppet script to be run when server is online. Or perhaps a VPN, or a logging tool like the excellent Loggly.
• DRY, or Don’t Repeat Yourself. It can be immensely repetitive and error prone to manually update all the roles with updated scripts: no need for this anymore.
• Sharing roles made by your team members. Colleague just built a Varnish role? It’s now easier than ever to re-use it.

Take a look at the screenshot below to get an idea of what this looks like.

You can now add scripts to a parent role

To use this, simply go to Roles in the menu, and click on View All. Filter by owner, set to ‘Private’ (since you can only customize your account’s roles). Under options, you can then click ‘Edit’ on the role you want to add automation to. Click on the ‘Script’ tab–there you’ll be able to add scripts as you normally would a role in a farm.

The possibilities are endless for what you can do with this: open/close security ports when an instance initializes, install specific software, tailor a config file, create a root login/password access to FTP or que sais-je… It’s up to you to take the most of it. And of course, if you made something great and want to let the community know, you can shoot an email to genius@scalr.com.

Scripts that are inherited from the parent role appear greyed out when added to a farm, like below:

The greyed out scripts were inherited from the parent role

Cheers,
The Scalr “automate all the things!” team