Yesterday's release of the RightScale platform introduced two new features that I'm really excited about: the ServerTemplate Library and the use of Machine Tags on servers.
We've had sophisticated sharing of ServerTemplates in RightScale for over a year now allowing certain users to share ServerTemplates, RightScripts and other design artifacts with other RightScale users. This enables us to publish free ServerTemplates to all our users and premium ones to our customers, and it also lets ISVs on our platform publish ServerTemplates for free or for pay to their users and customers. In addition, each of the design artifacts is versioned such that users who have launched servers with a ServerTemplate last year can still launch new servers with exactly the same version of that ServerTemplate.
A result of all this publishing, sharing, and versioning is that there's a lot to choose from - so much that drop-down menus have become unwieldy, and this is where the new library comes into play. In the past, when adding a server to a deployment, you had to find the correct ServerTemplate from the list of all available templates in the RightScale system. Now this has become a two-step process where you first import the ServerTemplates of interest from the library into your account, then only the imported templates are shown in all the drop-down selection menus. Separating the library import/export step also allows us to significantly upgrade the experience of browsing all the design artifacts in the library over the coming releases.
We introduced Flickr style machine tags recently, and we're expanding their use with this release. One of the really exciting new features is that servers now have tags, and we've integrated the tags with the routing of messages between servers, with Chef (via the RightLink agents) and with the UI. All this is still in alpha but it's starting to take shape. Our first real use case is the registration of application servers with load balancers. When a load balancer comes up and is ready for operation, it adds a "loadbalancer:lb=www" tag to say "I'm a load balancer for the www vhost." When an app server starts up, it requests all servers in the deployment with a "loadbalancer:lb=www" tag to run a Chef recipe that adds the app server to the load balancer rotation. This way, the app server doesn't need to know which or how many load balancers there are. The tag matching, communication, and running of the Chef recipe are all done by the RightLink agents.
To let new load balancers come up when app servers are already running we can do the same tag-location in reverse: app servers announce "loadbalancer:app=www" to say "I'm an app server serving vhost www" and load balancers on startup can add all app servers to their config by querying for all servers with that tag. For overall resiliency it's a good idea for load balancers to requery the set of app servers and to update their configs accordingly. This catches race conditions as well as issues where portions of the app servers may be temporarily invisible due to network partitions. The theme here is eventual consistency, and we're still evaluating what the best primitives are to support high availability.
You may wonder why the examples above use such long tags. That's really where machine tags come in. The "loadbalancer:" prefix helps isolate the tags to coordinate the load balancer registration from other tags. Think of "loadbalancer" as being the name of the application or feature that uses these tags, e.g. the load balancer registration. The "lb=www" and "app=www" tag predicate and value can be used to support multiple vhosts. So a load balancer could announce "loadbalancer:lb=www" and "loadbalancer:lb=api" to indicate that it's load balancing the www and api vhosts. And an API app server then would only query for the "lb=api" tag and it would only announce the "app=api" counterpart.
While all this is happening among the servers, the RightScale UI provides access to all the tags, so one can see the servers announce the various tags and one can even intervene and manually modify these tags. We might provide a "don't touch" notion for some tags, but right now it's more important to us to be able to expose all this machinery. As an ops guy, there are few things I loathe more than hidden automation that I can't inspect and override when I need to.
Of course there's more in the new release than just these two features: more support for Rackspace (monitoring in particular), improved support for Chef, support for new AWS features, and more.