Now that Amazon’s Identity and Access Management (IAM) is more widely known, and you can use your IAM credentials to login to the AWS Console, you might be wondering how to really leverage the IAM offering.

One really good use for IAM is allowing access for specific users to specific S3 buckets. This is what the IAM policy would look like.

{
  "Statement": [
    {
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::bucket_name_here"
    },
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::bucket_name_here/*"
    }
  ]
}

This contains three simple IAM statements.

1. The s3:ListAllMyBuckets for the entirety of S3 (arn:aws:s3:::*)
2. Full control of the specified bucket (bucket_name_here, in this case)
3. Ful control of the contents of the specified bucket

Sadly, there is no way to limit a user to which buckets are listed, instead you have to let them see all buckets which is accomplished by the first statement.

The second and third statement gives the user full control of the bucket itself, and it’s contents respectively. Assign this policy directly to a user, or a group that the user belongs to, and you’re all set!

When Amazon announced it’s Authoritative DNS service, cheekily named Route 53 a few things popped into my head immediately. First, this should be a much easier way to get the effects of Dynamic DNS which we were currently leveraging DNS Made Easy for. Secondly, I wonder how much of a performance boost using it might provide.

Amazon’s entire model for providing services through AWS is predicated on the idea of distributing load. They have several availability zones for computing and storage, they have a Content Delivery Network (CDN) which will deliver your static web content to users at blazing speeds because it’s coming from a data center as close to them as possible.

So why wouldn’t that persist to their new DNS offering?

Turns out I wasn’t the only one wondering this. Brant recently revealed some performance and stability findings in a blog post about Route 53.

How does it improve speed?

With the increasing focus on the speed of websites, everything is getting optimized. Image sizes, whitespace in your CSS and JS files, the number of additional files you load, etc. Each of these techniques strips a millisecond or two off of the time it takes your browser to find and download all of the components which make up the page you’re looking at.

But there is another facet of browsing the web which takes time, the DNS lookup. See, your browser has no idea which server to send the request for “www.google.com” to, since servers are identified not by their domain or hostnames, but by their IP address. DNS is used to translate the hostname you enter into your browser, into an IP address which can be used to actually locate the server.

Of course, this lookup takes time, and if you have lots of components on your page, perhaps even some from other servers, this time could add up.

Google launched a recursive DNS service for this some time back. By using the recursive (think “cached”) servers you could drastically improve your DNS lookup times which is demonstrated quite well in this FAQ for the service.

The downside of course is that you only get the benefit if you change your computers network settings to use the Google DNS servers, and since the DNS data is cached it can lag behind when changes are made to the authoritative DNS records.

On the other hand, if you use Route 53 as the authority for your DNS records, every internet user will benefit from the performance boost of making a DNS request to a much closer (and faster) DNS server. Sweet!

I’ve been making use of Amazon Web Services (AWS) quite a lot lately. In order to really enjoy the benefits of Cloud Computing (automation, agility, etc) I’ve had to use a number of tools to interact with AWS on my behalf.

All of these external tools ask for the same thing to enable them to make AWS API calls, your AWS Access Key ID, and your AWS Secret Access Key. Common practice is usually to just hand over the main set of these credentials, but there is a better (more secure) way, using Amazon Identity and Access Management (IAM).

What is IAM?

In September 2010, amidst very little fanfare (as is the Amazon way) Amazon released their Identity and Access Management offering. To this day, the IAM is still technically in Beta, but it is stable tested offering.

As of this writing, you can only interact with the IAM via the API. Amazon also makes a nice set of command line tools available which work equally well in Windows or *nix (including mac OSX) environments.

IAM is a set of tools which allow you to create user groups with defined security policies, as well as unique AWS users with their own credentials who can be assigned to those groups.

This is an extraordinarily powerful tool for managing your use of AWS. No longer is every request to AWS made as your super user account, but you can assign particular users their own credentials to more easily control and audit what they’re doing in your AWS environment.

This concept extends to services and tools you might use to manage your AWS environment as well. Rather than handing over your super user credentials, you can create a unique key and secret pair for each management tool you use, effectively isolating that service.

Now it’s true that you can already create many sets of credentials, and invalidate old ones using the Security Credentials link off of your account management in AWS, but these are all still super user credentials. They still have the same level of access (full control) and any audit information for objects created by those keys show up as the super user.

With IAM you can restrict a set of credentials using an AWS policy, to only the specific AWS API calls you want to allow that user to make, and the objects they create or interact with get audit data showing their username. This makes it possible to know who (or which service) did what to objects inside your AWS environment.

Do you use a tool like S3 Fox to manage the contents of your S3 buckets? You can create a unique user and policy which allows access only to S3 calls, or even narrow it to a particular bucket, or filenames!

So, how exactly do you do that? To best explain it, I’m going to walk through the steps necessary to create a new group and user, and then use those new credentials with RightScale my favorite tool for automating AWS.

Prerequisites

Before we get started, you’ll need to go ahead and download the IAM Command Line Toolkit (IAM CLI) and add the bin directory to your PATH environment variable. Once you’ve done that, you’re ready to follow the steps below.

Creating a Service Account

The first thing we’ll want to do is create a security policy which we will apply to the service account. Since RightScale helps to manage nearly every aspect of the AWS, the policy document is going to be quite simple, and will grant full access to all services.

Don’t be too intimidated by the creating policies for more restrictive cases though, the Policy Generator makes it easy.

So lets write out our full control policy somewhere to disk so that we can use it later.

{
  "Statement": [
    {
      "Action": "*",
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

/tmp/fullcontrol_iam_policy.json

With that out of the way, lets create a new IAM user group named RightScaleDash and upload our new policy file using the IAM CLI tools.

$ iam-groupcreate -g RightScaleDash
$ iam-groupuploadpolicy -g RightScaleDash -p FullControl -f /tmp/fullcontrol_iam_policy.json

Then, we create a new user named rsdash and assign the new user to the RightScaleDash group. Note the -k parameter, this instructs the IAM CLI tools to create a new AWS key and secret pair.

$ iam-usercreate -u rsdash -g RightScaleDash -k

Some things like signing your custom Amazon Machine Images (AMI’s) require an x.509 certificate, and RightScale has a place for entering this type of “credential” as well, so we’ll create a self signed one for this example.

$ openssl genrsa -out iam.key 1024
$ openssl req -new -key iam.key -out iam.csr
$ openssl x509 -req -in iam.csr -signkey iam.key -out iam.pem
$ iam-useraddcert -u rsdash -f iam.pem

That’s really all there is to creating your service account. Once you’ve set things up you aren’t locked in to your choices either. At any time you can go back and add or remove security policies using the IAM CLI.

So now that we’ve set up our new user, let’s configure RightScale to use it.

RightScale Configuration

These steps are very easy, I’m going to describe how you would change the credentials for an existing RightScale account since adding your credentials for the first time is handled by the RightScale setup wizard.

Once you’ve logged in, hover over the Clouds menu, then under AWS Global click the Credentials link.

On the next page, click Edit then enter the newly created credentials into the appropriate fields.

That’s it, you’ve just configured your RightScale account to use it’s very own AWS credentials!

If you’re looking to start a blog to promote your business, or boost your presence on the internet, you’ve probably heard of WordPress.

You may also have heard about the benefits of hosting your own instance of WordPress, but you’re intimidated by the idea of setting up and maintaining your own server, or trusting your business to a shared hosting solution.

What if I told you that I’ve got a solution that’ll let you run your WordPress blog, on your very own server, with automated backups and disaster recover, completely free?

Wait wait! I know it sounds too good to be true, but don’t leave just yet, hear me out…

Amazon AWS Free Tier

First, let me be straight with you. When I say “free” I’m referring to the free tier of Amazon’s virtual computing and storage platform AWS.

This free tier allows you to run their smallest instance free for one year. In practice you actually end up paying them a very small sum (around $0.12 average for me thus far) each month for transfer costs to run a low to medium traffic blog.

After your first year of free usage has expried, it’ll start to cost around $15 per month to keep using the same size instance.

Managed by RightScale

You may be looking at AWS and thinking that setting up your own server, and keeping it running and backed up would be a daunting task, and it can be. That’s where RightScale comes into the picture.

RightScale offers a Free Developer Edition that gives you access to their shared library of ServerTemplates.

In that library is one little gem that I published, expressly for the purpose of running a server that hosts my blog, a few sites for other domains I own, as well as all of the email traffic for my various domains.

In fact, you’re reading this right now from a server running from this ServerTemplate.

Full Disclosure

Before I give you the skinny on how to start using these tools to host a WordPress blog on your own virtual server, a few warnings are in order.

I am using Opscode Chef to configure the server. Chef support is currently in Beta on RightScale, meaning that they do not recommend you use it to configure and manage “Production” servers.

It also means that there can be some hiccups when you’re launching and configuring a server with this ServerTemplate.

So, don’t be surprised if the first time you launch your server, it doesn’t work. Try launching a second time.

Lastly, I can’t take any responsibility for any loss of self esteem, data, productivity, or sanity. You have been warned.

That said, I’m using this server to run the very blog you’re reading, and I haven’t had any significant glitches yet. RightScale is working as we speak to improve their support for Chef and things will only get better from here.

Haven’t scared you off yet? Okay, good.. Here we go..

20 Minute Quickstart

The RightScale management tool, and this ServerTemplate offer all sorts of cool functionality which we can explore later, but if you’re in a hurry to get started here’s all you need to know.

1. Go sign up for an AWS Account
2. Sign up for a RightScale Free Developer Edition
3. Enter your AWS credentials into the RightScale dashboard using these directions
4. Browse to my All-In-One ServerTemplate and click “Import”



5. Click “Add to Deployment”



6. Pick the AWS Cloud closest to you and click “OK”
7. Change the “Instance Type” dropdown to “t1.micro”, and select the “default” Security Group from the dropdown. You can also provide you server a name, then click “Add”



8. Click the “Play” button, provide inputs for the Database Administrator password, Postfix DB password, and EBS volume size, then click “Save and Launch”




And now.. We wait.. Until the instance is up and running..

9. Click on the server’s nickname, then navigate to the “Scripts” tab
10. Run the “rjg_utils::aio_ebs_volume_enable_continuous_backup” operational script to make sure your server is backed up daily
11. Run the “app_wordpress::deploy” operational script to setup WordPress for your domain



12. Navigate to your websites URL (we used http://ec2.ryangeyer.com in this example) and setup your WordPress preferences



13. Start Blogging!

What’s Next?

That’s really all there is to it. As I mentioned the ServerTemplate does a number of other cool things, which you can read about in it’s description.

The best part is that because this ServerTemplate is what I use for my own blog and email hosting duties, you can be sure that I’ll keep it up to date, secure, and be adding features fairly regularly.

Drop me a note

If you followed these directions, or if you’re using this ServerTemplate, or if you’re having trouble, by all means drop me a note in the comments here.

I’ll be happy to answer any questions I can, and I’d love to get a sense for how many people are out there running servers based on this template, it’ll keep me motivated to publish more stuff in the public ServerTemplate library!

For the past few weeks I have been getting down and dirty writing Chef recipes for use in RightScale.

With Chef support still in beta on RightScale, and me being a complete Chef newbie it’s I’m still on the front side of the learning curve.

If you’re just getting started with Chef for RightScale, you might benefit from this quick start and some of the lessons I learned while getting started.

Mise en place

While you could just open up Notepad or TextEdit and start writing your Chef recipes, there are a few resources that will make the experience much more enjoyable.

Install Chef

The first thing you’re going to want to do is install the Chef Ruby Gem. This will add all of the libraries and binaries for Chef.

While we’re writing our recipes for use with RightScale we won’t need to worry about using the Chef Server, Chef Solo, or Chef Client, so don’t bother configuring any of those.

I’m developing on a Mac and the only suitable installation method seems to be using Ruby Gems to install. This mechanism should also work for most Linux and Debian machines which already have Ruby installed.

sudo gem install chef

Be sure that you run this as root, or with sudo or Chef will get installed at ~/.gem and won’t be in your $PATH or consequently accessible to other users.

Sharpen your knives

Now that you have all of the Chef goodies installed, you’ll have a binary named “knife”. The knife is a utility which we’ll be using as we develop our cookbooks and recipes which you’ll see later.

First though, we need to configure knife. Since we’ll only be using knife to act locally on our recipes and cookbooks we don’t need to give it legit values for a Chef server, but we do need to complete the configuration step to satisfy knife and prevent it from crashing when we use it.

To create a simple configuration file for knife, just run knife config, and accept all of the defaults.

knife configure
No knife configuration file found
Where should I put the config file? [~/.chef/knife.rb]
Please enter the chef server URL: [http://localhost:4000]
Please enter an existing username or clientname for the API: [rgeyer]
Please enter the validation clientname: [chef-validator]
Please enter the location of the validation key: [/etc/chef/validation.pem]
Please enter the path to a chef repository (or leave blank):
WARN: *****
WARN:
WARN: You must place your client key in:
WARN:   /Users/rgeyer/.chef/rgeyer.pem
WARN: Before running commands with Knife!
WARN:
WARN: *****
WARN:
WARN: You must place your validation key in:
WARN:   /etc/chef/validation.pem
WARN: Before generating instance data with Knife!
WARN:
WARN: *****
WARN: Configuration file written to /Users/rgeyer/.chef/knife.rb

You’re safe to ignore the warnings since they only pertain to actually connecting to a Chef server, which we won’t be doing.

That’s it for installing and configuring Chef if you’re using it with RightScale!

Prepare your pantry

Once you get going with Chef you’re going to need to store your cookbooks somewhere for RightScale to find them and run them.

RightScale will use svn or git repositories, as well as simply downloading a tar or zip file, but my personal preference is to use a git repository.

The quickest and easiest way to get started with git is to head over to github and sign up for a free account.

Once you’re setup, go ahead and create the repository we’ll be using for our Chef cookbooks, and note the SSH URL to your new repository. It should look something like git@github.com:<github_username>/<repo_name>.git. Write it down or keep the browser window open so you can reference it later.

Heat things up

Now that you’ve got your mise en place it’s time to get cooking for RightScale with Chef.

Create your repo

The first step is to get the file structure of your Chef repository setup. You could just take a look at an existing repository like the opscode cookbooks, or RightScale’s public repository and replicate it manually, but there is a better way.

Clone the OpsCode repo

OpsCode, (the folks behind Chef) have conveniently provided a public github repository that represents the skeleton of a fully operational Chef repository. You can clone this repository to get you started.

git clone git://github.com/opscode/chef-repo.git

Once you’ve cloned the skeleton repository, you’ll want to configure git to use the new github repository we created earlier. Here’s where you’ll use the SSH URL I told you to take note of. Substitute that URL where you find <ssh_url> below.

cd chef-repo/
git remote rename origin opscode-github
git remote add origin <ssh_url>
git remote rm opscode-github
git push origin master

Create cookbook

With the repository skeleton all ready, we’re going to want to create our first cookbook and add a recipe to it.

Creating a cookbook is our first chance to use our freshly sharpened knife, like so.

knife cookbook create my-first-cookbook -o cookbooks/

This should create a nice new cookbook skeleton directory at <path_to_your_repo>/cookbooks/my-first-cookbook.

With that done, let’s put our first recipe in the cookbook. Using your favorite IDE, create and save a file named helloworld.rb inside the new cookbook directory.

helloworld.rb

log "Hello World"

With the recipe created, we need to add it to our metadata file so that Chef and RightScale can know it’s there. Here’s a copy of our default metadata.rb file. The highlighted line is added to define the recipe we’ve added.

metadata.rb

maintainer       "YOUR_COMPANY_NAME"
maintainer_email "YOUR_EMAIL"
license          "All rights reserved"
description      "Installs/Configures my-first-cookbook"
long_description IO.read(File.join(File.dirname(__FILE__), 'README.rdoc'))
version          "0.0.1"
recipe "my-first-cookbook::helloworld", "My first recipe, prints Hello World to the RightScale dashboard"

We only have one more step before we’re ready to commit our new cookbook and recipe to our new git repository.

RightScale reads the metadata to determine which recipes are available in the repository, and which inputs are available for those recipes. The file that RightScale evaluates though is a json file named metadata.json.

The contents of metadata.json are effectively the same as metadata.rb, but take heart, you only need maintain the metadata.rb file, then convert it using another Chef command. To generate metadata.json from metadata.rb just run the following command.

rake metadata

You can run this command either right at the root of your repository, or inside each cookbook. If you run it from the root directory of your repository, it will convert all the metadata files in all of the cookbooks.

Now we’re ready to commit our repository and try out our new cookbook.

git add cookbooks/
git commit -am "Added my-first-cookbook and helloworld recipe"
git push

RightScale Configuration

I’m going to assume that you already have some familiarity with the RightScale dashboard, and creating things like ServerTemplates and RightScripts.

What I’m going to cover here are steps are necessary to start using Chef with your ServerTemplates.

Tell RightScale about your Repo

The first thing you need to start using your cookbooks in RightScale is to tell the RightScale dashboard where to find your repo. To do that, you need to create a new RepoPath in the designer.

When you’re adding the RepoPath, for the URL field, supply the “Git Read-Only URL” for your repository, and make sure to specify the path to your cookbooks as cookbooks.

Add your RepoPath to a ServerTemplate

Now that you’ve added your repo to the RightScale dashboard, you need to add that RepoPath to a ServerTemplate. To do that, open the ServerTemplate you want to run Chef cookbooks on, and click the edit pencil on the Repos tab.

Then select the RepoPath we just made, and click OK.

Add a recipe to your ServerTemplate

Our very last step is to add our helloworld recipe to a our ServerTemplate so that we can run it on one of our instances. Go back to the Scripts tab, and in the script category of your choosing, click Add Recipe and select the helloworld recipe.

From an instance running with the ServerTemplate we just modified, we can run the recipe, and see “Hello World” appear in the RightScale dashboard.

Tips & Tricks

As stated before, Chef support in RightScale is still in Beta. Because of this there are some gotchas to watch out for.

Sanity Check Recipe

If there are any syntax errors or anything else amiss in your repository, you’ll find that not just the cookbook or recipe which you’re working on is failing, but absolutely every recipe in your repo (or any other repo that’s part of your RepoPath) will fail with this super informative error message.

*ERROR> Chef process failed with return code 1

Of course, you can also get that error message if you have some other problem in the recipe you’re working on.

Because of this I find it useful to keep a “smoke test” recipe in my repo, and assigned to the operational scripts on my ServerTemplate when I’m doing Chef development. This recipe should be something simple that you know will always succeed, assuming that everything else is in order.

The helloworld recipe that we created in this exercise is actually a perfect choice for this purpose.

Taste Test

So there it is, everything you need to know to get started using Chef on RightScale condensed from my few weeks of experience. I hope it helps you get started configuring your server instances with Chef, which brings a whole new dimension of power and flexibility to the RightScale ServerTemplates.

I’m excited to see how Chef support progresses and makes it to production status.

If you’re hungry for more info, check out some of the early documentation available about using Chef in RightScale here.

One of RightScale’s key differentiators from other cloud management platforms is the concept of the ServerTemplate.

A ServerTemplate is like a blueprint of the server you want to launch in the cloud. It defines things like what software and services will be installed and configured, what will be ready when the server boots, and what can be run periodically for maintenance during the lifetime of that server instance.

ServerTemplates offer a great deal of power, and abstract a lot of the cloud specific dependencies but there’s room for improvement.

Optional Boot Scripts

One of the cool aspects of ServerTemplates is that you can specify a set of scripts which will be run on your new server instance the moment it boots up.

These bootscripts can be customized by inputs that you provide for each instance of the server template, allowing you to customize the exact details of your server instance.

Once you’ve selected the inputs that will produce the desired server instance, you just press a button to launch and the server starts up with exactly the configuration that you specified.

Tweaked with metadata

The problem though, is that sometimes you might create a ServerTemplate which could be used in more than one configuration. A great example is my Tomcat All-In-One template. This template is designed to run every service necessary for various Grails applications.

However, depending on the actual instance I’m trying to start I won’t need certain services, or I may need to configure some services differently for different purposes.

To accomplish this sort of functionality using the existing ServerTemplate functionality, I use optional input parameters for the scripts that control the outcome of those scripts. The input LDAP_ENABLED determines if an OpenLDAP server is installed on boot or not, and the value of DB_SOURCE determines which scripts are used for setting up the database.

Configure it later

Another strategy is to only launch the common services at boot, and allow the user to initialize other services after startup using operational scripts. I use this strategy on my Dev Team All-in-One ServerTemplate.

A better mouse trap

Neither of these approaches are particularly elegant though. In the case of the optional inputs, you have to specify a lot more metadata for a server instance before you launch it, and it may not be immediately obvious that the consequence of setting a certain input is that a service you depend upon won’t be installed or configured.

When you force the user to install the services they need after the server is booted, a lot of the convenience and agility afforded by ServerTemplates is lost.

A better solution to the problem is to allow scripts which are added to the boot section of a ServerTemplate to be flagged as optional. This would mean that when a user clicks the “launch” button for their server instance, they would be prompted not only for the inputs necessary to start the instance, but they would also be asked to select which optional boot scripts should run.

In this model, the optional boot scripts should probably also be able to define dependencies. For instance, an optional script for continuously backing up an LDAP server may be dependent upon an optional boot script used to install that LDAP server in the first place

Darryl Eaton eluded to the coming availability of optional boot scripts in his presentation at CloudExpo 2010 in Santa Clara, and I am anxious to see how it’s implemented. As a RightScale Ambassador I’m hoping to get a sneak peek of this as soon as it becomes available, and I’ll be sure to share my experience.

Script Packs

Another feature that I think ServerTemplates are missing is the ability to group sets of scripts together into packs, then allow many instances of those packs to be assigned to a server instance with discret sets of inputs for each pack.

What exactly do I mean by that?

All of the existing ServerTemplates that you find in the library make the assumption that a particular server instance is only running one of any given service or application.

Take a look at all of the MySQL Database templates, they all operate under the assumption that you are running only one database.

The application servers? Yup, those assume you’re only running a single application on each server instance.

Now, in production for high traffic applications and services which demand easy and rapid scalability, that’s exactly how your servers should be configured. But what about lower traffic applications?

Take a small development team running an all-in-one server with a few applications running on it for smoke testing or experimentation. Or a smallish business or social media personality who wants to host a website or two.

In both of the above cases a single m1.small EC2 instance could easily handle the load of even a few hundred users on a couple applications or services.

In fact I am exactly that sort of user. I currently have six small WordPress sites, and an email server all running on a single Linode VPS with just over 700MB of memory. A single t1.micro instance running on Amazon could easily accomodate my needs, and with RightScale I can monitor and manage it a lot more effectively.

To that end I’m working on a ServerTemplate to run these services in a t1.micro instance with Ubuntu 10.10, stay tuned for details on that.

The workaround

One of the challenges I face is having a set of scripts which I want to do the same operations on each of my six sites.

Things like a script to install WordPress to the proper directory, a script to update WordPress in the proper directory, scripts to backup or restore the database, scripts to backup or restore the files under htdocs, etc.

The best way I’ve found to add these scripts to my ServerTemplate and allow them to act on all of these sites individually, is to include them all in the operational scripts section of the template. Then when I launch my instance I leave the inputs for those scripts blank, requiring me to enter inputs which target a particular site when I run the script.

Obviously, this is error prone. What if I mis-type the path to the site directory and accidentally install WordPress in the wrong directory? Or maybe I am planning a wordpress upgrade and I backup a sites database, then update a different site that hasn’t been backed up because I provided the wrong inputs to the script.

Tightening things up

With a script pack I could group together all of the scripts that run against my various applications (database backup, htdocs backup, wordpress installation & updates, etc) into a pack and define (and save) the inputs for each distinct instance. Being able to label each pack would be a nice touch too.

There could be a www.nslms.com pack which performs those operational tasks only on the assets specific to that site.

And a tasforwp.ryangeyer.com pack which performed those operational tasks only on the assets specific to that site.

A www.ryangeyer.com pack…. You get the idea.

Imagine adding one (or many) of these packs to the boot phase of a ServerTemplate. You could setup several websites to be launched as soon as your server instance is ready, or restore all of them from a current backup. This could be useful for scaling your server horizontally to a bigger instance.

If you combine optional boot scripts and script packs, you could do some really cool stuff. You might take a clone of your existing multiple site instance, and using optional boot scripts, only launch one of the sites on a new instance, allowing vertical scaling. Powerful stuff indeed!

What would you like to see?

These are the improvements I would love to see added to ServerTemplates to improve my ability to manage servers in the cloud, but what do you think?

Would these improvements appeal to you?

What else would help you create better, faster, smarter ServerTemplates?

Feel free to speak your mind in the comments!

Whether you are a small development company with a tight budget, or an established enterprise with some trepidation about wading into the murky waters of cloud computing, RightScale just made it easier to empowering your development and test teams with cloud computing.

In late September RightScale announced a Development and Test solution pack. This solution pack is a suite of tools, best practices, and professional services that helps deliver the agility promised by the cloud to your development and test phases.

CM Crossroads interviewed RightScale’s CEO Michael Crandell about the new offering and has recently made the interview available.

If you want to know more after watching the interview, checkout the RightScale Dev and Test Solution Pack landing page for more info.

It’s now the end of my first full week back at work since I attended the 2010 Cloud Expo and RightScale User Conference, and I’m still feeling the motivation and enthusiasm I picked up there.

You see, a few weeks before the conference, RightScale announced a contest for the best ServerTemplate published to their public library. Three winners would be announced at the RightScale User Conference and be thanked for their contribution with a shiny new iPad. I couldn’t resist submitting my own work for a chance to win.

If you follow me on Twitter you already saw this.

rjgeyer I won the "Most Useful" category of the #rightscale ServerTemplate showdown! Stiff competition, so I'm stoked. Cool!!

On November 3, 2010 6:10 pm via TweetDeck

Yup, I won a shiny new iPad for my OpenLDAP ServerTemplate in the “Most Useful” category of the competition. What’s more my blog post about the ServerTemplate showdown made it into the opening slides for the day!

That pretty well set the tone, and I felt like a Rockstar for the rest of the day. All of the RightScale staff knew my name, and many of the other attendees chatted with me about how we’re using the Amazon and Rightscale, and how I built my ServerTemplate.

Groupies lined up to get my autograph and get their picture taken with me, and I had a few room keys slipped into my pockets.

Okay, maybe that last part was an exaggeration but I definitely felt like “somebody” that day.

On top of that, this has created a nice little buzz within my department and the company at large and it’s motivating them to take a more serious look at how we can leverage cloud computing for our IT needs.

And if all of that wasn’t enough I’ve also been accepted as a RightScale ambassador which gives me early access to betas and the attention of the product development folks to share our needs and use cases.

But I have a juicy confession…

My dirty little secret

All of this happened not because I am particularly charismatic, or because I extended some special effort to produce something amazing then market the crap out of it in social media. No, this all happened because I was just doing my job.

The OpenLDAP ServerTemplate was one I’d already created to meet the needs of our application development, and the possibility of winning an iPad (and a little notoriety) was all the motivation I needed to polish it a bit and share it with the community.

This all serves to strengthen a point which I picked up on at Cloudexpo and I think it will become a serious marketing trend for cloud computing. Making IT the “Hero”.

rjgeyer I love the subtext of "Making IT the hero (again)" at #cloudexpo Let users serve themselves from a well controlled & audited system

On November 3, 2010 5:01 pm via TweetDeck

In a lot of organizations, the IT folks are viewed as little more than an obstacle to getting things done, like the roadie who spends more time smoking behind the van than he does setting up the stage.

The experience of acquiring IT resources usually goes like this.

Request resources by following an often rigorous process…

Wait an extraordinarily long time to get the resources, usually so long that your project suffers…

Once you get the resources you need you’re bound by what seems like an endless list of apparently burdensome and unreasonable restrictions in the name of “security”…

Not an attractive scenario for the IT “customers” but it’s just as bad for the IT team. You see it’s not that the poor IT team does not want to move quickly, and provide the resources, but they also want to must sure that the users are protected and that they will be able to weather a security and compliance audit.

Sign your own record deal

Using the cloud computing paradigms though, IT can have a whole portfolio of ready to run servers and IT infrastructure. All of those images and templates are already pre-configured with all of the companies regulatory requirements, security best practices, and ready to interface with the rest of the IT infrastructure.

All the user has to do is log in and configure the environment they need for their particular business purpose all of the automation magic makes the resources available almost instantly!

That is really the beauty of cloud computing (if you’re doing it right). You can improve IT efficiency and agility, while maintaining or even improving your system of checks and balances, and you can make your users happy to use the system you’ve put in place. Now everyone wins!

Of course the very best news for IT guys is, you can sit back and enjoy the perks of rockstar status just by doing your job. In fact, by leveraging the promise of agility that cloud computing offers, you’re job will actually become much easier, and you still get to party like a rockstar.

As I was clearing out my RSS reader a few days back, I stopped to read a post on the Flickr dev blog about the “new” 640px image size. In the article they lament that they wished they had made “Large” copies of all uploaded images because it would make generating the new 640px size easier.

This got me thinking, what if they did want to convert every image ever uploaded to this new size and cache it? How would they do it? How much would it cost? The more I thought about it, the more curious I became, so I launched a little research project to see what I could find out, and to show how I would work through the problem.

Approach

How to resize?

I tried searching to find out exactly how Flickr is resizing their images, but it is apparently a well kept secret. There was a fair amount of speculation that they use Lanczos resampling, and my own research suggested it was a strong choice for quality resizing, so I chose to use it for the purposes of this experiment.

I wrote a very quick PHP script that uses ImageMagick with the Lanczos “filter” to do the work. This resizer was built with this particular experiment in mind, but it is fairly flexible. If you POST an image, and a value “largestDimInPx” it will resize the image and send it back as the response to the HTTP POST, thus the “RESTFul” name. The resizer also accepts an array of parameters which it sends back in the HTTP header. So if you were actually taking on a mass resizing project like we’re proposing, you can pass the unique ID of the photo in your system and get it back when the resize is complete.

You can find the code for it over on my GitHub.

Just how many images we talkin’?

Another carefully guarded secret it seems, is the total number of images that Flickr is currently hosting. I did a lot of searching and tried a few naughty tricks to see if I could get the API or website to tell me, but it was to no avail.

Some previous “official” numbers were as high as 6 billion images. So for the purposes of my test I assumed that they had 10 billion images that they wanted to resize to this new 640px image size.

CPU Cycles – Pick your poison

I have to assume that Flickr has a pretty impressive infrastructure built out, and that they have a huge amount of processing power at their disposal. Still, to accomplish something like this it’s unlikely that they’d reallocate existing resources. The task is too monumental to just have a couple servers work at it.

I also have to assume that they’re carefully optimizing their servers so that they don’t have to build and maintain more than necessary. So that begs the question, how do you get the processing horsepower necessary to convert all of these images?

Since I’ve recently been engrossed in creating and refining reusable RightScale ServerTemplates for our own servers in the AWS cloud, my thoughts for a solution instantly gravitated toward launching a bunch of servers in the cloud for this purpose then terminating them when the task was done. What I didn’t know is if this made more sense than, say, buying a bunch of servers and configuring them to do the same task.

In order to do some tests, I created ServerTemplate which can be launched on AWS using RightScale that will immediately be able to start resizing images posted to it using my aforementioned PHP resizer.

The experiment

What I learned in short was… This is a HUGE undertaking! I also found that while any approach would probably be cost prohibitive, performing this resizing task using on-demand servers in the cloud is still the cheapest route by far.

Assumptions

First, some of the assertions for this exercise.

• The server(s) performing the resize task will be of the m1.large type from AWS
• Flickr has 10 billion images to convert
• Those images are (on average 12MP and about 4MB
• The images are being resized so that the largest dimension is 640px

You’ll also find that as I describe the results, and the costs they represent, I conveniently exclude data transfer from my numbers. This is actually intentional. My goal is to compare just CPU time.

Yes, bandwidth has a tangible cost when you use it in the cloud. But the same is true for a bare metal server doing the same task, not to mention the networking hardware which must be acquired, configured, and maintained. So for the purposes of this experiment, only the cost of CPU cycles is really being examined.

Findings

With my new m1.large instance launched in the AWS cloud, and exposing the resizer service, I did a few tests to get a feel for just how long it would take to do all of this resizing. What I found out pretty quickly was that the actual task of resizing the image actually only took around 1 second, sometimes less! It should come as no surprise that the real time consumer in the process was I/O bandwidth.

Over my home cable connection (measures at 3.5Mbps up and 11.83Mbps down), using Firefox to post and FireBug to measure, it took an average of 12 seconds to complete the process of posting the image and receiving the response. If I removed the overhead of Firefox and simply used a bash script and cURL, that dropped considerably to 8 seconds.

In an effort to get a “best case scenario” measurement, I copied the file to be resized onto the AWS instance, and ran the same cURL command locally. On what can be effectively called “infinite” bandwidth, the process of posting, resizing, and fetching the result took about 2 seconds.

The tortoise and the hare

One very tangible benefit to using the cloud for this purpose though is the time to market for such a huge task. You can imagine that if Flickr did decide to go ahead with this, they wouldn’t really want to announce that they’ve started but that the process will take many months, or even years. Assuming again that the per image resize time is 2 seconds, it would take one server just over 633 years to convert all of the images. Something tells me that wouldn’t exactly go over well.

Say that they wanted to convert all of the images in one week, at 2 seconds per image for 10B images, it would require just over 33,000 servers to convert that many images in the cloud. What’s more is that it would take effectively “no time” to deploy that many servers, use them for a week, then terminate them. Try rolling out that many real, bare metal servers in that timeframe!

What’s it gonna cost?

You might look at those results and think that these times are fairly reasonable. However, if you take these figures and start multiplying them by ludicrously large numbers (like 10 billion for example), those reasonable numbers start to look very unreasonable.

Using these results, and (as I stated before) only accounting for CPU time, it would cost approximately $1.9M for Flickr to convert all of their images in the cloud. That is assuming that they’re connecting to the servers with effectively infinite bandwidth, ensuring that the upload and download transfer times for the image were less than 1 second (combined!). Seems like a lot of money, but then it’s a lot of images!

Compare that though, to building out a farm of bare metal servers to do the same task. We’ve already established that we’d need a little over 33,000 servers to be able to convert all of the images in a week. If we just take the lowest configuration Dell rack mounted server, the R-415 at a retail price of $4531, it would cost just over $149M, just for the hardware. Worse still, the Dell doesn’t actually have as much processing horsepower as an AWS m1.large does, so you’d probably significantly effect the time per image.

Conclusion

At the end of the day, any approach for converting all of those images would be cost prohibitive, and I’m betting Flickr won’t be taking on this project. Still, if I had to accomplish this task for real, I think I’ve demonstrated fairly convincingly that doing it in the cloud with on demand computing power is totally the way to go.

I’m not a mathematician or a statistician, and I did paint this topic with very broad strokes. You can check my work with the simple Google Spreadsheet I created to track my results. If this were an actual task, I’d be a bit more precise, but I wanted to show the differences between the approaches, without getting into too much minutia.

That said, discussion about factors I may have missed are welcome, I think you’ll find that the delta in price for just the CPU horsepower between the cloud and a bare metal solution more than absorb any real differences I may have excluded.

RightScale is definitely doing the whole “social media thing” right. They’re active on Twitter and Facebook. The CEO blogs, they have a community forum and the very nature of their product encourages users to interact and share with one another. Clearly they’ve ticked all of the big social media checkboxes, but their latest announcement is sheer evil genius!

How to motivate your users to add value

RightScale is holding a contest for the best Server Template submitted to the community. They’ve also dangled the most trendy carrot available (a shiny new iPad) as the grand prize for winners in three categories. This is social media 101. Get the users involved, and motivate them to generate great content that drives interest and brings you even more users who will in turn create great content. Plus, because it’s a contest it gives users more incentive to share their best work with the community, rather than just the left overs.

What’s really cool about this contest besides encouraging users to share their best work, is that it may also motivate them to really put the finishing touches on the templates and scripts which they may have already written. In fact, that’s exactly the effect it had on me when I read about the contest.

My ServerTemplate submissions

When we first started using RightScale to build out an infrastructure for our SaaS application at work, there were a few things we needed.

First, our application was going to use LDAP for authentication. We needed a decentralized database for our users since we plan to have many different applications and websites that a user can access with the same credentials.

We were also leveraging the paid RightScale ServerTemplates Tomcat6 FrontEnd, Tomcat6 Application, and MySQL 5.1 to build out our production deployment environment. But we needed to be able to run all of these services on a single box for development, staging, and QA purposes.

OpenLDAP ServerTemplate

Thinking that an LDAP directory would be a pretty common requirement for infrastructure in the cloud I went searching the RightScale Library for a ServerTemplate I could use out of the box, or modify a bit for our purposes. Instead I was a bit shocked to find that there wasn’t anything out there, which is why I built my OpenLDAP Directory ServerTemplate.

This is a ServerTemplate that we’re currently using for our production environment to authenticate users, and it has some pretty cool features. It allows you to easily setup a “Provider” and “Consumer” pair of servers, and allows you to easily promote the “Consumer” server in the case of a failure. It also backs up the database daily to a file in an S3 storage bucket of your choice.

Tomcat6 All-in-One ServerTemplate

This ServerTemplate is a utility template that comes in handy if, like us, you’re using the RightScript ServerTemplates mentioned earlier to host a Java application. It combines all of the roles (Front End, Application Server, Database Server, and my own OpenLDAP server) into a single instance.

This allows you to setup parallel environments that are nearly identical to your production environment for the purposes of development, testing, or troubleshooting an issue in production. We’re running one of these that our continuous integration deploys to nightly for demo and smoke testing purposes.

One of the coolest features of this template is the ability to fire up a utility server which will exactly mirror your production environment. This is done by grabbing the latest EBS volume snapshots your production server is creating for backups, then using those snapshots to attach new EBS volumes to your utility server. This effectively duplicates the production database, allowing you to work with it in isolation. This is great for staging a significant upgrade which might effect the database schema, you can bring up a “throw away” server instance, test and troubleshoot your upgrade, allowing you complete confidence that your upgrade will go off without a hitch in production!

One more for the road

I do have one other ServerTemplate that I’m putting some finishing touches on. It’s based on a collection of RightScripts and configuration stuff that I’ve compiled for our own development team server. It provides services like git, svn, Teamcity, and artifactory. I’m hoping to be able to submit it before the October 29th deadline.

So, for motivating me to step up my game and share my best work my thanks go to RightScale. Ohh and, you’re welcome for the value add, I just hope it’s worthy of an iPad!