Yesterday’s release included a number of features that I’ve been itching to get into RightScale for a long time. This stuff is fresh off the press in alpha-release form so we’re hoping for your feedback so we can evolve it to suit your needs. Here are the highlights and some background on where we’re headed.
First off we’re adding RackSpace CloudServers to the set of clouds in RightScale and it’s available to everyone as of today! All you need to do is to get a CloudServers account and enter your credentials into RightScale. Please refer to our tutorial for the details. What we’re releasing today is full support for our ServerTemplate machinery which is the foundation for building cloud portable systems. The ServerTemplates are built using our new RightLink agent and support Chef cookbooks as well as our standard RightScripts (see below for more info on this). While we don’t have a RightImage available for RackSpace quite yet it turns out that we’ve implemented enough magic to make the “Ubuntu 8.10 (intrepid)” image provided by RackSpace work as if it were a RightImage.
Some of the features we’re missing for RackSpace are a full set of the core RightScale production ServerTemplates and the support for monitoring, alerts and automation, such as auto-scaling arrays. We’re working hard to release all this as soon as we can and that’s one reason the current RackSpace support is still labeled alpha.
The second major new feature is the RightLink agent which supports not only RightScripts but also Opscode’s Chef cookbooks. The RightLink agent connects each server with the RightScale core as well as other servers around it. Boot scripts and operational scripts are launched via RightLink and we’ll fully support direct server-to-server communication in a next release. RightLink uses Nanite for the communication, it includes the Chef-client for running cookbook recipes, and it can run RightScripts as well. We’ll be enhancing the whole communication infrastructure so servers can communicate with each other efficiently but in a secure and controlled manner, for example to enable application servers to register with load balancers and to locate the currently active database master.
I’m also very excited that we are now supporting the Chef server configuration system. When I started RightScale almost three years ago I wanted to include something like Chef but couldn’t get myself to pick among the available options. When I dug into Chef earlier this year and started talking to Jessie and Adam at Opscode it became clear to me that this is the right technology for configuring servers in the cloud. Chef cookbooks are the next level beyond OS distributions like RedHat or Ubuntu: a cookbook leverages the distro for getting the right bits onto the machine and then layers the operational know-how on top: how to configure everything and perform operational tasks. RightScale’s ServerTemplates then combine all the cookbooks needed on a server into a portable package and add the coordination between servers. After all, no server operates alone in the cloud…
A nice side-effect of using Chef is that we’ve been able to fully embrace git for developing cookbooks (svn is also supported). We publish our cookbooks on github where you can fork and change what we offer to suit your needs. The RightScale web site pulls metadata information about each cookbook directly from github or any accessible git repo and servers also get everything directly from git. This means that all of git’s (or svn’s) software development goodness (branching, merging, tracking, etc) is now fully integrated with RightScale ServerTemplates!
We still have to put together a getting started tutorial for Chef but we have published a sample ServerTemplate called “Rails all-in-one (EC2 Chef Alpha)”. It launches and comes up running the Rails Mephisto blogging app. You’ll notice that it’s a bit on the slow side to boot — we have a number of things to optimize — but it does pull from the public Opscode and RightScale cookbooks on github. Look into the Server Template under the Repos tab and you’ll see the definitions for the repositories.
But there’s more! We’ve started to add Flickr style machine tags to RightScale resources. A machine tag is a tag that follows a special triplet syntax of namespace:predicate=value and the purpose of machine tags is to allow anyone or any external application to attach metadata to RightScale resources. Right now tags are only available for Servers, Images, and EBS Snapshots. Rather than start attaching tags everywhere we preferred to start using tags ourselves for something concrete so we can ensure we have a good feature set. We’re using tags now for snapshots to control the rotation of backup snapshots and to organize snapshots of multi-volume stripes. We’ll soon use tags to encode the features provided by images, e.g. whether they’re RightImages, support RightLink, support the freezing of repositories, etc. But most importantly we’ll add API access to tags so you can attach your automation to tags. We’d love to hear from you what exactly we need to provide. But in the meantime you can at least add tags to servers and use that in the UI to filter the list of servers you see.
Amazon has been on a tear lately with few weeks going by without a new feature announcement. The most important news to come along in a long time has been the introduction of Virtual Private Clouds (VPC) and we’re pleased to support them in this release, which means that you can create subnets in your VPC and launch servers into them. We’re also now supporting the purchase of reserved instances straight from the RightScale dashboard, plus we’ll show what you’ve purchased.
Finally we’ve improved the speed of the site across the board specially for larger accounts with lots and lots of servers. We continue to appreciate feedback on anything that doesn’t work well or that we should enhance: use the feedback link on our site or email feedback@rightscale.com directly.
I hope you’ll enjoy the new features as much as we do — yes, we eat our own dog food and manage RightScale using RightScale!
This nomenclature turns out to be useful in teasing out the benefits of these various types of clouds. For public vs. private clouds the two main distinguishing factors are isolation and elasticity. In a private cloud it is easier to draw a hard boundary around the servers, the storage, and the network used by an organization’s cloud resources. This may have advantages from a security compliance and audit point of view. On the flip side, public clouds will tend to have more elasticity than private clouds because of the increased scale and ability to balance across more disparate types of uses. The elasticity is a very important cloud characteristic because it underlies a number of the end-user benefits.
The three main distinguishing benefits of internal vs. external clouds are about control, the nature of the costs and cloud locations. By outsourcing the cloud infrastructure to a service provider the typical cap-ex costs of computing infrastructure can be turned into variable costs that scale relative to the actual use of resources. As more and more service providers offer clouds across the globe it is also increasingly easy to place compute resources where they are needed, whether for latency reasons or for regulatory purposes. Internal clouds are bound to where the enterprise has or can summon physical resources.
Developers can launch dev servers in the cloud when they need them and shut them down again when they’re done. Test engineers can launch whole clusters for test runs and they go away automatically at the end of the run. Operations engineers can set up staging systems for short periods to engineer the roll out of the next release. Marketing support engineers can launch demo systems for events or important prospects, and in general the various business units are in more direct control of their compute resources. All these users are outside of central IT.
