Oh my, this one sure was overdue.

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. Sorry for the url, it’s a Confluence OnDemand limitation. We’re working to get that down to a nicer docs.scalr.com, but wanted to share this with you as soon as possible.

Enjoy,
The Scalr “RTFM” team

This week, Scalr’s newsfeed was full of Linux.

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

Good news for all you Scalr users! The Scalr dashboard has entered a public beta.

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.

Scalr recently introduced server usage statistics, a tool which breaks down your AWS costs by application or farm, type of server, and more.

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

A lot of you guys use images to version your roles, taking snapshots of a server when it’s in the state you want. It’s quick, it’s easy, and no mental calisthenics are required to understand it or explain it to your colleagues.

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