Cloud control systems tame the ether
- — 03 July, 2009 03:56
Signifying a formless haze of computing power and storage that is somewhere "out there," computerdom's current buzzword is as difficult to get one's arms around as a real cloud. A seemingly limitless pool of processors and memory and disk space, and you just scoop out what you need. Sounds great, doesn't it?
Of course, it's not that simple. You don't just grab a handful of virtual computers and toss them after your data. They have to be configured. If you need an n-tier system, you'll have to assemble the virtual networking components to tie them all together. In short, managing a herd of virtual systems in the cloud is no less difficult than managing a herd of physical computers.
The four products in this roundup are designed to simplify the life of a cloud-based virtual-machine wrangler. To varying degrees, and in varying environments, each provides tools for creating, deploying, and managing collections of cloud-machines.
The products are the AppLogic platform from 3tera, the Elastic Computing Platform (ECP) from Enomaly, the Infrastructure and Middleware on Demand (IMOD) system from Kaavo, and RightScale, from the company of the same name. The 3tera and Enomaly offerings are tools for building your own private or hosted clouds. The Kaavo system works with third-party cloud services such as Amazon EC2. And RightScale works with both private clouds and third-party cloud services.
The 3tera AppLogic system is its own cloud. That is, you do not run it on a third-party cloud provider such as Amazon EC2; you run it on hardware hosted by 3tera, or you provide the hardware and 3tera builds the cloud. AppLogic is referred to as a "meta-operating system." At its heart, it is Red Hat Linux running a specially configured Xen hypervisor. More precisely, it is a cluster of interconnected systems running Red Hat Linux, Xen, and the AppLogic orchestration system.
AppLogic can run on a remarkably spare piece of hardware. Minimum requirements are a 1GHz processor, 512MB of RAM, and 80GB of disk storage. Of course, this is the barest of beginnings; a single backbone of an AppLogic system can consist of up to 128 machines, and backbones can be combined to form overall networks of thousands of machines. Assuming you don't have the space in your basement for your own AppLogic system, 3tera already has datacenters in North America, South America, Europe, Japan, and Singapore. (Quantities and locations are changing; you should check 3tera's Web site for the latest details.)
Though AppLogic's core is Linux, it can host virtual machines running Linux, Solaris, and Windows Server 2003. But the fundamental building block of a multitier AppLogic system is not simply a guest operating system; it is the duo of virtual machine (running the guest operating system) and application -- such as Apache or MySQL. This combination is called an "appliance," and it is a unique feature of AppLogic that, in an appliance, the application takes precedence over the containing OS. You create a cloud application by wiring together applications, and the fact that each application is running in its own OS is merely incidental.
This is a powerful paradigm, because it insulates you from the details of a particular OS; the OS is merely a container, a runtime environment for the application. Configuring and tuning the application are what counts, and this focus on application construction becomes apparent when you step inside AppLogic's management console.
[ Cloud computing offerings differ in depth, breadth, style, and fine print. See Cloud versus cloud: A guided tour of Amazon, Google, AppNexus, and GoGrid. ]
Log onto AppLogic's management console, and you are presented with the tool's Dashboard, where in-flight instances are displayed, accompanied by each instance's basic usage statistics: CPU, disk, and memory. Click the Applications tab, and you're shown a list of your account's applications; the list includes the application's state (stopped or running), a description, and associated CPU, memory, and bandwidth resources. Finally, the Support tab is a jumping-off point for 3tera's documentation, release notes, and support forum.
All the action is on the Applications tab. Select an application and the AppLogic editor opens. The application is represented as a network of nodes on a canvas. Each node is an appliance, populated with input and output connection points called "terminals." If you want, say, a Tomcat appliance to send database queries to a MySQL appliance, you drag and drop each onto the canvas, then drag a connection line from the output terminal of the former to the input terminal of the latter. It's a lot like wiring circuit components. An "appliance palette" waits to the side, from which you can drag new appliances onto the canvas and wire into your application. Right-click on an appliance, and you can configure its property values and attributes.
To actually configure or tweak the internals of an appliance, you log onto it. (Remember, an appliance is an OS running an application.) A secure shell window opens, from which you can execute Linux commands to your heart's desire.
The glue that cements appliances into applications is ADL, the Application Description Language. ADL is very much like XML, but less repetitive and devoid of brackets. It is used to describe all the components (appliances) that comprise an application, as well the structure of the appliances themselves. A complete description of the language is available on 3tera's AppLogic wiki.
3tera's version of cloud services is a "virtual private datacenter" (VPDC), executing on hardware hosted by 3tera itself. Pricing for a VPDC depends on a mixture of factors -- CPU, RAM, and storage requirements. Or, if you already have hardware in place and want to construct your own AppLogic installation, you can purchase an Enterprise AppLogic License. In either case, you should contact 3tera for details.
Enomaly's Elastic Computing Platform (ECP) is not a tool for deploying to existing clouds such as Amazon Web Services. Like AppLogic, Enomaly ECP is a tool for building your own clouds. It is erected on a set of open source virtualization applications and APIs. You can construct your own cluster of systems, install ECP, and use its UI to manage the configuration, storage, and deployment of virtual machines. At its core is Enomalism, a virtual-machine management system written in Python that uses MySQL as back-end storage.
The ECP user interface is a console that operates the mechanics of the tool's underlying system, which is, in turn, undergirded by the open source libvirt virtualization API. libvirt is a C toolkit that allows applications to communicate with the Linux kernel's virtualization capabilities, and thereby control hypervisors running on the system. The hypervisor is the virtualization software that allows a computer to host one or more OSes -- each in its own virtual environment. Currently, libvirt supports Xen, QEMU, KVM, VirtualBox, and others. (For more information, see libvirt.org.)
Currently, there are three versions of ECP: the free, community edition (which I tested); the Enterprise edition; and the new Cloud Service Provider edition, which adds usage accounting and billing integration to the user interface. Check the Enomaly Web site for details of the editions' differences.
ECP's management console is arranged along the same lines as the other consoles in the roundup. It is browser-based, with tabs for each of the major functions. The console opens to the obligatory Dashboard, which is really a transaction monitoring page. All operations performed in the console are transactions. They can be issued asynchronously, and some may take minutes to complete, so the Dashboard lets you monitor their progress.
The Virtual Infrastructure tab leads to three control areas. First, the Infrastructure control provides a navigation pane for all the clusters in your cloud. Select a cluster, and you can view all its assigned virtual machines. Buttons across the top let you start, stop, pause, or delete a virtual machine within the cluster.
Next, the Virtual Network Manager control panel assists in creating and managing virtual networks within your clusters. (This control is not in the community version; it was in a testbed system that Enomaly gave me temporary access to.)
Finally, the Elastic Valet is a control panel for provisioning machines. You select a target cluster for the machine, and specify launch parameters. The Elastic Valet will determine which physical machine in the cluster is the best destination to "park" the virtual machine -- hence the tool's name.
[ Application development has taken to the skies. See the InfoWorld Test Center reviews, "Windows Azure Services Platform gives wings to .NET" and "Google's high-flying cloud for Python code." ]
Another important component of the ECP control panel is the Repository, which is a storage management system for OS images and plug-ins for the Enomaly system itself. (The latter is typically supplied as Python eggs.) The Repository recognizes both local and "remote" machine images. Remote images are available from Enomaly's central servers; you can select a remote image and have it downloaded to your local system. At the time of this writing, there were about 10 images, including Red Hat, Ubuntu, CentOS, and others.
Hard-code developers will enjoy the Enomalism API selection from the Admin tab. This provides a list of the REST-style APIs that Enomalism supports. Select an API, and you're provided with a structured definition of the parameters and data types for that API.
ECP is simply not there yet. Or, if it is, it hides the fact behind its meager documentation. Though I was able to install and run the community edition on Ubuntu, whenever I got something to work, I could never be certain whether I had done the right thing or had simply stumbled into a solution. More importantly, ECP appears to be lacking in tools that assist in the configuration of machine instances. That is, it has nothing analogous to RightScale's RightScripts or Kaavo's system definition file. For now, it appears to be good for managing virtual machines in a cluster of networked hardware, but provides little support for applications on those virtual machines. Hopefully, this capability will appear in a future release.
Kaavo's Infrastructure and Middleware on Demand (IMOD) seeks not only to abstract the individual servers running on cloud-based system, but -- as much as possible -- to erase the boundaries between tiers. That is, with IMOD, you can work with a multitier application as though it were a monolithic application, without losing the ability to fine-tune constituent parts.
All the information needed to deploy an application is gathered into a single file, called the system definition file. Crack the file open, and you'll find what looks like a description of a state machine. The IMOD engine executes this file, booting the different tiers of an application in proper order. The file can also specify corrective action to be taken if a tier somehow fails to boot. Each tier specified in the system definition file consists of one or more servers. When you configure a particular tier, you specify the number of servers on that tier, and IMOD lets you manage them as though they were a single system.
The system definition file contains two major sections. One defines the static artifacts of an application (tiers, servers). The other is a flow control section that specifies the actions that the IMOD engine is to perform when the application is being launched. These actions are defined in the form of Velocity templates -- Velocity being a scripting technology that allows you to embed Java classes in a script file, so you can create scripts that are not only descriptive, but executable as well. It is this "descriptive executability" that permits IMOD to roll everything it needs to know about a system into a single file.
IMOD's user interface is a three-tabbed control panel. Foremost on the list is the N-Tier tab, where you can view available templates and systems (the latter being the configured and executable form of the former). Select a system, and you can view it either in graphical, "run-time" form, or as a text-only XML file (the system definition file mentioned above). You can also open a tree view of the system, which shows the state of each of its Amazon Machine Images (running/terminated), its instance identifier, firewall rules, and more. Click the "start system button," and the selected system is deployed and launched in accordance with the system definition file.
Kaavo provides a number of prebuilt templates that you can use to jump-start your own applications. These include a variety of JIRA configurations (JIRA is a popular issue-tracking system), a MySQL cluster system, a template for the PHP-based collaborative project management system phpCollab, and more.
Other entries on the control panel include the Profile tab, where you can configure your account. This tab also includes billing and user management. From the Accounting tab, you can review your service usage over a selectable time range.
IMOD's system definition file is a two-edged sword. On the one hand, it keeps everything in one place, and that bookkeeping advantage should not be underrated. Also, if something goes wrong, you pretty much know where to look. On the other hand, it's one more language's syntax you have to learn. Because it depends on Velocity, an understanding of Java is a definite advantage. Nevertheless, Kaavo's documentation is good enough that even new users can find their way around with few bruised noses.
If you want to go it on your own, Kaavo has a self-serve plan that begins with a 30-day free trial. After that, you pay a fixed monthly fee for a fixed number of CPU hours. Exceed the available hours, and you fall into a pay-as-you-go scheme for any additional time. Users who need guidance will want the Enterprise Solution, which provides 24/7 support and training; contact Kaavo for pricing. Currently, Kaavo supports only Amazon's EC2, but expects to add support for other cloud providers in the near future.
RightScale takes a non-intuitive approach to preparing and managing cloud-based systems. Rather than preconfigure a machine image, the RightScale methodology is to launch a "bare" image and have that instance configure itself by executing pre-installed scripts. Such scripts are called RightScripts, and they are the essential ingredients of a RightScale-powered cloud system.
A RightScript can be written in any of the well-known scripting languages: shell script, Python, Perl, or Ruby, to name a few. The language is unimportant. What is important is the fact that RightScripts can include parameters, and those parameters can be programmatically filled in by the RightScale system at runtime. RightScripts are therefore reusable, so a RightScript that installs MySQL, for example, can work on any cloud server that needs a MySQL installation.
There are three types of RightScripts, each designed to run at a specific point in a machine image's lifetime. Boot RightScripts execute just after the machine image is booted. Operational RightScripts execute once the image is running. And a decommission RightScript will execute just prior to the image being shut down. RightScripts can be used for just about any operation imaginable, but typically they install, configure, and start applications on the machine image they occupy.
To be accurate, RightScale images aren't completely barren. First, RightScale images include a small piece of software that, at boot time, contacts the RightScale system and basically asks: "I just booted, what am I supposed to do?" The RightScale system then begins feeding the image whatever RightScripts it is configured to use. And, of course, the necessary scripting languages are pre-installed on RightScale images. For example, RightScale pre-installs Ruby; I was told by a RightScale engineer that they use Ruby "extensively." These modifications convert a basic machine image into a "RightImage."
Ultimately, a RightScript will end up as part of a ServerTemplate. A ServerTemplate is a base server image, associated with the RightScripts that configure the server to do its assigned work. For example, an Ubuntu-based MySQL ServerTemplate would consist of an Ubuntu machine image and all the RightScripts needed to install, configure, and launch MySQL. RightScale provides a number of prebuilt, application-specific ServerTemplates. To create your own, you merely clone a copy of the original, add or modify the associated RightScripts, and save the result in your local repository.
You control your RightScale-based systems via a Web-based management console. You begin at the Dashboard, from which you can view currently defined deployments -- a deployment being a collection of machine instances, typically working together for a single purpose. For example, an Apache Web server, Tomcat application server, and MySQL database server, combined to provide a shopping cart application, could be saved as your custom-built Shopping Cart Deployment.
Down the tool chain is the Management screen, for creating and configuring servers, arrays of servers (for those times when the number of servers must grow or shrink based on changing workloads), and deployments. Select a deployment from the list, and you can configure its internals, or launch it and monitor its status.
The console also has tools for managing important Amazon Web Services cloud resources such as SSH keys, security groups, and machine images. RightScale's console excels at context-sensitive help, as well as comprehensive onscreen documentation (that can be turned off, once you've become expert at the system).
RightScale offers five different editions, ranging from the free Developer's Edition to the feature-rich Enterprise Edition. Of course, the free edition includes no support and lacks add-ons available with the paid editions. The feature combinations of the various editions are extensive enough that you need a matrix to comprehend it all; such a matrix can be found on RightScale's Web site.
In the clouds
When it comes to cloud tools, one certainly cannot complain about the assortment. If you've already settled on Amazon EC2 as your cloud provider, then head on over to RightScale or Kaavo. If you'd prefer to build a cloud system yourself, check out 3tera or Enomaly.
The name of the game is the reduction of complexity. Configuring, launching, and monitoring a multitier cloud-based application is a process of many steps. There are OSes to choose, applications to install, connections to establish, security permissions to worry about, and on and on. And launching a multitiered system is an essentially asynchronous process; if something goes wrong, it is not altogether easy to figure out where the problem is. Each tool here tried to make that easier; each succeeds on different fronts to different degrees.
3tera's AppLogic excels at representing an n-tier system as a collection of interoperating applications, rather than a collection of interoperating virtual OSes running applications. Abstracting out the OS is a powerfully simplifying force.
Kaavo's user interface is well laid out and easy to navigate. It is impossible to get lost with Kaavo, and it's easy to figure out where in the UI you need to go to perform a particular task.
[ Stay on top of cloud developments from an IT professional's perspective in whurley's Cloud Computing blog. ]
RightScale's approach is finer-grained -- focusing on individual machine instances -- and more demanding of the cloud architect, but its abundance of pre-written RightScripts, in-line help, and copious examples goes a long way to lowering the learning curve. In addition, RightScale's RightGrid feature provides a prebuilt grid architecture for lashing together clusters of virtual machines in a "producer-consumer" structure, making it easy to build large-scale processing systems without getting bogged down in the details.
Finally, I can only recommend Enomaly's ECP for the technically savvy. The engineers at Enomaly were extremely helpful in answering questions, and I applaud any system based on open source technology. I would heavily encourage involvement in Enomaly's community edition. But the lack of substantial documentation and missing application configuration capabilities leaves me reluctant to advocate ECP for production deployment. A new release is expected this summer, and perhaps the added features will erase my doubts.
Cloud management systems
Platforms: Private and hosted AppLogic clouds
Pros and cons:
+Graphical "wiring" of applications is easy to work with.
+Lots of pre-built applications.
+Application-centric view of system.
-ADL requires a modest learning curve.
-Built on proprietary AppLogic runtime system.
Bottom line: 3Tera's graphical user interface captures your application's architecture in an easy-to-manage form. Its treatment of components as appliances also simplifies system construction. But it locks you into 3Tera's AppLogic environment.
Platforms: Private and hosted ECP clouds
Pros and cons:
+Built on open source technology.
+Freeware version available.
+Runs a variety of virtual machines.
-Documentation is seriously lacking.
-No visible tools for managing applications on target OSes.
Bottom line: You can't argue with Enomaly's price tag: free is as good as it gets. And you are not tied to any proprietary software or cloud infrastructures. But Enomaly has a way to go before deployment is as simple as with the other tools.
Platforms: Cloud service providers including Amazon EC2
Pros and cons:
+Excellent control panel UI.
+Graphical view of application is easy to manipulate.
+Lots of pre-built appliances.
-Currently only supports EC2.
-Some configuration steps not readily apparent.
Bottom line: Kaavo's bundling of an application's descriptive and executable information into a single System Definition file unclutters application management, and allows for easy transfer of an application from one installation to another. However, it does require study of the underlying XML and Velocity syntax.
Release: April 21, 2009
Platforms: Private clouds and cloud service providers including Amazon EC2
Pros and cons:
+Free version available.
+Large selection of RightScripts and machine images.
-Machine-centric view, rather than application-centric view.
-RightScripts require understanding of scripting language.
Bottom line: Where some of the other tools abstract the underlying structures of a cloud-based application, RightScripts require you to develop at the level of those structures directly. This produces some significant starting friction. Nevertheless, once mastered, RightScripts are phenomenally flexible and powerful.
Rick Grehan is contributing editor of the InfoWorld Test Center.