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

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

Take the blue pill

Hi there!

Once again, Scalr Cloud Management delivers. This time, we show you what we have under the hood that makes your application harder, better, faster.

Great news for all of you stats junkies: you can now visualize resource usage on your servers via the load statistics page found under options for your farms. Like The Oracle pictured above, you can listen to it to get insight into your infrastructure’s load. A few use cases come to mind:

• Testing. Clone your farm, run an ApacheBench script and see the load graphs increase
• Resource cleanup. Spot underutilized servers with the compare mode
• Spotting outliers. Detect possible memory leaks and overloaded servers, or simply check that your load balancing is properly done.
• Application rollouts. Roll out a new version of your application, and compare 1.0 with 2.0, or staging with production.
• Optimizing. Identify the gating resource in your application, and change instance types from high-cpu to high-memory.

You can view network, CPU, memory, and load average for individual servers, as well as averages for all servers of a role, and all servers of a farm.

Better yet, the compare mode shows a vertical view (sorry guys, no Pinterest “Pin Button” for this yet) of all instances of any particular farm/role. If you check the farm checkbox you will average them and detect outliers and lame ducks. No country for old lagging servers.

While we’re in a monitoring state-of-mind, and until we release our monitoring & alerts feature, you can use the Event & Notifications found under the Options menu of your farms.

This feature lets you select a farm-related event and be notified each time it occurs. Want to receive an email every time an instance goes down? When a new database master comes online? Just enter your email address and select these two events. That’s it! Each time one of these events happens in the selected farm, you will receive an email! Isn’t that cool!? Hum… OK let me try again. Each time something happens in your farm, your sysadmin will receive an email!

Enjoy!

Cheers,
The Scalr “Let me plot that for you” Team

Do you speak CAPTCHA -these tiny anti-bot services? Did you know that you can actually be very creative with them? Take a look at CAPTCHAart.com if you don’t believe me. Today’s blog post will explain Scalr’s latest move to increase security. Don’t forget that the best way to make your infrastructure secure is to make your password hard to guess (but easy to remember).

You Shall Not Pass!

To protect you and your infrastructure against vilains and hackers, a CAPTCHA now shows up after three failed attempts to log in Scalr. Sorry to all of today’s Captain Hooks–you should look at other SaaS to play with brute force.

VIP Room

The second security feature turns Scalr into a very selective club: only verified members can access. Go to your profile settings and add approved originating IPs to the IP list to create a whitelist of permitted inbound connections. Leave it blank, and anyone with the login and password can access your account.

Recommended reading (by Scalr)

How CAPTCHA will change the world

The Economist on password security (with tips)

In Alice in Wonderland, the white Rabbit is a allegory for curiosity. Alice follows her instinct and dives into the hole. That’s exactly what I felt starting this blog post. The subject of an Open Source Message Broker available as a Role in Scalr was not exactly the funniest way to spend a monday morning. Or was it? Let’s try to make it cool.

Why a Message Queue?

What do “Message Queue” and “RabbitMQ” stand for? RabbitMQ is a message oriented middleware (or a message queuing system) aka a Post system. Like any Post system, its original idea is pretty simple: it delivers and accepts messages. In short, it’s like going to the post office: when you pay the stamp, you are sure that Mr. Postman will deliver the message from the Post office to the Post box. Keeping the metaphor, RabbitMQ is the Post box, Mr. Postman and the Post office at the same time.

Why Rabbit?

Plenty of open-source message tools are available on the web -Apache ActiveMQ, Apache Qpid, or JBoss. We decided to support RabbitMQ as this one is easy to use, robust, runs on major operating systems and supports most developer platforms.

So our engineering team worked hard and offer you this brand-new RabbitMQ role.

Getting started on Scalr integration

The RabbitMQ role works with RabbitMQ server v 2.7.0 and newer. The system is available as a pre-made role on EC2 (x32 and x64) in the role builder (Roles > Role builder). When configuring the role, please note the tab labelled RabbitMQ settings on the left.

The ratio bro, the ratio

The rest is obvious: we support both RAM and Disk nodes. The cool thing is that you can configure the Disk nodes / RAM nodes ratio. Setting it to 30% with 4 nodes means that 1 instances will be dedicated to the disk and 3 to the ram (hum…that’s a rough ratio, but you get the point). Yet, sorry but this role won’t be scalable.

Like Louis XVI in 1789, I can already see the people brandishing sticks and pitchforks, bringing their anger to the streets and yelling at Scalr’s windows: SCALABLE, SCALABLE, SCALABLE!

Let me give you some explanations to cool down the pressure and cheer you up:

• RabbitMQ does support queue replication, BUT, since Scalr has no easy way to know which nodes actually contain a message queue, it cannot terminate them safely (auto downscaling). But you can scale up manually of course.
• No snapshotting feature hasn’t been implemented. As snapshots can contain already delivered messages if a RabbitMQ server is restored from these, messages will be delivered twice. This could break your application and you don’t want this to happen (oh noes).
• Moreover, horizontal scaling doesn’t make much sense for a message queue service. It’s a very rare use case. In fact, when you need a larger capacity of messaging server you can just use a larger instance.

In addition, the RabbitMQ role won’t support snapshots and backups, but smile, baby, smile. Again, we believe that this is not a very frequent situation -given that messages are supposed to be delivered realtime not being stocked on a messaging system.

You might also wonder what happens when an instance is terminated. In the case of DISK nodes, the basic configuration will be saved. In the case of RAM nodes, all information (queues and messages) will be lost. That is why we offer the possibility to set in advance which nodes your cluster should use. Just keep in mind Captain Obvious’ theorem, RAM = speed while disk = reliability.

Scalr will provide a few DNS endpoints:

• *-rabbitmq = will point to all rabbitmq nodes
• *-rabbitmq-ram – will point only to RAM nodes
• *-rabbitmq-disk – will point only to disk nodes
• * – ext or int

Recommended reading (by Scalr)

• http://en.wikipedia.org/wiki/RabbitMQ
• http://msdn.microsoft.com/en-us/library/aa480411.aspx
• http://en.wikipedia.org/wiki/Message_broker
• http://wiki.scalr.net/Reference_Guide/Roles/RabbitMQ

Scalr started in 2008 as a simple tool to automate scaling, and has been on a mission since to facilitate IT operations, by automating all sorts of activities. What we didn’t realize is that this work was actually the bread and butter of our beloved friend sysadmins, who have been kicking it back so much lately that companies are wondering why they should still keep them on payroll.

To preserve the apparent usefulness of sysadmins while still giving them time to watch cat videos on youtube, play Civ V, and play laser tag across the office, Scalr is proud to introduce a new service: “Failure as a Feature”.

For a nominal fee, you can now cause a sudden malfunction on your web servers, load balancer, or database, which you will fight bravely using your deep knowledge of Linux architectures, to show your manager how vital you are to the company’s success.

Simply click on “Provoke disaster” under Tools in the top menu, and Scalr will randomly choose a disaster scenario based on your pricing plan. Customers on plans IPO and higher are entitled to one hour of downtime free of charge per month, and a special referral plan is available to get bonus downtime when you refer your friends.

Scalr takes "Failure as a Feature" to a new level

We trust this new feature will guarantee you keep receiving a paycheck every month for the years to come. We have set up a special email address to collect your success stories, and share with the rest of the community. You may find it at dev-null@scalr.com.

Cheers,
The Scalr “Master of Disaster” team

Scalr is open-source cloud management software for public and private infrastructure (AWS, Rackspace, Cloudstack…)