April 4, 2012 | Written by: Neil Weightman
Share this post:
For this blog entry, I want to look at the user experience of cloud-based development and test facilities.
IBM has an internal system, called the DST (Development and Support Team) CIO (Chief Information Officer) Dev & Test Cloud. This is an internal implementation of an IBM product named the Smart Business Development and Test Cloud. Fortunately, my fellow thoughtsoncloud.com blogger, Chris Dotson (@crdotson on Twitter), is a Manager of this service and was able to set me up with an account.
I received an email from a colleague of Chris with the details of how to connect to the Tivoli Self-Service Station, provided by Tivoli Service Automation Manager. The Dev & Test Cloud also has documentation provided through a very useful wiki.
A link in the email brought me through to the login screen for the service. Because this is an internal system, I was able to log in using my IBM intranet credentials.
The home page for Tivoli Service Automation Manager is a rich web application, based on Dojo, which you can use to view the current status of your requests and projects and to create new requests.
I decided to experiment with creating several test servers, deploying a simple web application to them and setting up a web server to distribute the load between my test servers. For this purpose, I really needed four servers: one to run my deployment manager for the WebSphere Application Server cell, two to run the application servers, and one to run the web server with the WebSphere plug-in. Looking through the wiki, I decided to use the provided VMware image named “Linux_RHEL5_x86-64_WebStack,” which promised pre-installed Red Hat Enterprise Linux Server 5.5 x86 64-bit, IBM HTTP Server 22.214.171.124, WebSphere Application Server 126.96.36.199, and also IBM WebSphere MQ and IBM DB2 9.5, which I didn’t really need for my purposes.
By clicking Request a New Service on the Tivoli Service Automation Manager home page, a new panel opened, with available options to start a range of processes, including the one I needed, Create Project with VMware Servers. I selected this option and found myself on the next panel where I could choose the details of the servers I wanted in my project. As you can see in the figure, from this panel you can select your preferred image from a wide range of options and install optional software (where available). The available images included various “flavors” of Windows and Linux, and different combinations of pre-installed software. At the bottom of the panel you can configure the number of servers, the number of CPUs per server, and the amount of memory and disk space required. I selected my four servers and left everything else at the default values.
I clicked OK and sat back to await the outcome:
- 13 minutes later I received an email confirming my request and telling me that my “Maximo Service Request” had been accepted.
- 21 minutes later still, another email confirmed the creation of my servers and provided all the details to connect to the servers.
- 34 minutes after clicking OK, I had the login details for my four servers!
The next step was to connect to one of my servers and see what I had ended up with. I didn’t have access to a graphical user interface for the servers, so I fired up PuTTY and entered the supplied IP address for one of the VMs. After logging in as root, I ran the WebSphere serverStatus utility to see whether anything had been set up for me. As you can see in the figure, a default stand-alone server profile had been created and the server was already up and running.
I wanted to test my little application in a single server before moving into the federated, load-balanced environment. I connected to the server’s admin console from my browser and installed my application with no difficulties. Security was disabled on the AppSrv01 profile, so I didn’t have to worry about finding the login details for the administrator ID for the server before connecting.
To begin the configuration of my test cell, I selected one of my four servers, logged in using PuTTY, and stopped the existing server, because I wasn’t planning to use the stand-alone server on this virtual machine. Using the manageprofiles command-line tool, I created a new deployment manager profile named CloudManager. The manageprofiles tool completed the profile creation in just 37 seconds and I was able to start the deployment manager—in just 14 seconds. In spite of the fact that I had reserved only 0.2 physical CPUs for each virtual machine, the performance—at least as far as carrying out admin tasks were concerned—was certainly acceptable so far.
I used the Add Managed Node feature in the deployment manager admin console to federate the existing servers into the cell. Adding each node took only 20 seconds. From this point on, carrying out my testing was only a matter of using the normal WebSphere Application Server administration features to create my cluster, create an unmanaged node to contain the web server, update the virtual host configuration, and deploy my application.
I found it very easy to set up and use the Dev & Test Cloud. Starting with only an application that I wanted to test, I was in a position to start configuring my servers and installing the application in less than an hour. The fact that all the software I was using came with web-based graphical interfaces meant that I could easily complete the management operations from my laptop at home, while the command-line interface was available for other operations.
After provisioning, the server configurations can easily be changed by using the Tivoli Service Automation Manager interface. Clicking on a link to Manage Projects, a panel opens, where you can do just that; it shows information about all the projects in my team (called “ZZDEMO”). Selecting a specific project—in this case my own—displays information about the servers within that project and allows you to make changes to their configuration. You can use the toolbar in the panel allows you to (left to right): refresh the servers view, create a server image (save the current state), restore a server from a previously saved image, modify the server’s configuration (changing the CPU, disk and memory allocation), delete, start, stop or restart a server, change the server password, and install additional software. If additional servers are required, a service request can be created from the home page of Tivoli Service Automation Manager to do this.
There are several downsides to using cloud-based systems for this kind of work, of course. Given the limitations of what can be done over an Internet connection, installing additional software yourself is probably impractical, because of the time taken to transfer the relevant files. This leaves you reliant on the support staff running the cloud infrastructure, and requesting additional services from them would likely incur additional costs. Also, I’m no Linux guru, so I did find carrying out some tasks using only a command-line interface something of a chore, although I know some people would delight in the chance. [Edit: When I asked Chris Dotson to review this post, he pointed out that I could have executed VNCserver on the provisioned machines to allow me to use the operating system’s graphical interface.]
Overall, however, the experience of using cloud-provisioned servers for testing applications has been very positive. The test servers are very quick to provision and perform well. It was great to be able to set up a cell using separate virtual machines without finding my system grinding to a halt because of the resources required.