This is Part Two of our release series. A couple weeks ago, we announced a lot of goodies and we’re going to talk about some new stuff today.
It has been a R.A.C.E. to the finish line this sprint, but we have some exciting news! RightScale’s current ServerTemplate release showcases the entire PHP 3-tier stack across the Rackspace Cloud, Amazon’s Elastic Compute Cloud, Cloud.com’s CloudStack and Eucalyptus Systems (hence R.A.C.E). These new HAProxy Load Balancer, PHP App Server and Database Manager for MySQL 5.1 ServerTemplates are available now in the MultiCloud MarketPlace.
Underneath all these templates, we’re releasing a new CentOS 5.6 MultiCloud Image with RightLink 5.7 for all EC2 regions, Rackspace Cloud Servers, Cloud.com’s CloudStack and Eucalyptus Systems. For a complete list of ServerTemplates and MultiCloud Images we released, check out our latest release notes.
People often talk about developing for the cloud and associated challenges. But what about building platforms on which other people develop their apps in the cloud? It is very challenging building for the “general use case”, but it is even more important when you build for generality that it works well. A lot of time and effort goes into designing and building our ServerTemplates. During development, and especially before release, we conduct extensive manual and automated testing cycles where we put our templates through the wringer. Below is a sample test matrix that represents our checklist for one ServerTemplate.
Notice that we test this one ServerTemplate across 2 separate images in 7 clouds each. Considering that we released 9 ServerTemplates last week, this makes for quite a few permutations. Of course, we also find bugs and have to retest rapidly.
Luckily we have help with a home-grown automation tool that we call Virtual Monkey. The monkey uses the RightScale API to create deployments with servers to test, launches them, runs tests against them, collects the results, shuts everything down, and cleans up. In most cases the tests include entire 3-tier application deployments so we can test the interactions between the servers and ensure things work end-to-end. All in all we launch hundreds of servers a day in various clouds to test these ServerTemplates and make sure they work before we let them loose in the wild.
Not all clouds are created equal…
If you’ve done anything on multiple clouds, you’ll appreciate the behind-the-scenes presented above. When launching hundreds of servers and developing infrastructure-as-a-service agnostic solutions, small nuances can be big blockers towards expected end-user functionality on the solution. From security groups on Amazon versus iptables management on Rackspace to volume snapshot API response differences in Eucalyptus and CloudStack, the ServerTemplate needs to be aware and abstract away differences. Do our customers really care about these differences? Of course not. They just expect one solution to work on one cloud type just as well as it works on another cloud type. You may have noticed that we utilized Chef for many of our recently released ServerTemplates. Chef allows us to abstract the business logic away from the details of the cloud, making it easier to propagate the same solution to as many clouds as we can get our hands on.
Wait, each cloud has different profiles for instance types!
But Chef isn’t the only innovation that we use. We also have to support many ‘by design’ cloud architecture differences. For example, pre-defined instance types. Instance types in Amazon, while being the same across all regions within Amazon, do not align well to flavors in Rackspace. Plus, in private clouds, you can either use the default instance types or custom configure to what your application demands. How then does a specific ServerTemplate correctly configure a new instance for optimal performance? Seems like that’s (yet another) real prerequisite for proper application setup.
In the specific case of MySQL, our ServerTemplate will auto-tune configuration parameters including innodb_additional_mem_pool_size and table_cache. The tuning is based off of an instance’s available memory. Of course this can be overridden on a per-server basis. This mechanism extends well to our PHP App and Load Balancer ServerTemplates where you override parameter defaults specified in apache2.conf and haproxy_http.