"What is the difference between WebSphere CloudBurst and IBM CloudBurst?" After the IBM Pulse 2010 event this week, I'm hearing this question in my sleep. It came from both our customers and other IBMers, and it's not hard to understand the confusion caused by the name similarity. Let's take a shot at clearing up any confusion around the two separate offerings and explain the complementary value WebSphere CloudBurst can provide IBM CloudBurst.

Both IBM CloudBurst and WebSphere CloudBurst provide capabilities to enable private, or on-premise, clouds. The main differences between the products are the degree to which they are purpose-built and the form in which they are delivered. First off, the IBM CloudBurst solution form factor consists of three primary elements: service management software, hardware, and IBM services. The software portion of the package provides general purpose (very important distinction) provisioning, workflow, and management capabilities for the services that make up your cloud. These services could consist of WebSphere software or any other software that you can package into a virtual image format. The hardware is the actual compute resource for your on-premise cloud, and the IBM services portion of the package provide a fastpath to get started with your cloud implementation.

On the other hand, WebSphere CloudBurst is a cloud management hardware appliance that delivers function to create, deploy, and manage virtualized WebSphere application environments in an on-premise cloud. WebSphere CloudBurst is purpose-built for WebSphere environments meaning that a lot of the things users would have to script with general purpose cloud provisioning solutions (creating clusters, federating nodes into a cell, applying fixes, etc.), are automatically handled by the appliance and virtual images with which it ships. Also, it is important to note that WebSphere CloudBurst works on a "bring your own cloud" model. The virtualized WebSphere application environments do not run on the appliance, but instead they are deployed to a shared pool of resources to which the appliance is configured to communicate.

While we are talking about two offerings that have the noted differences above, I should also point out the how and why of the integration of these two offerings. The WebSphere CloudBurst Appliance can be leveraged from within the IBM CloudBurst solution to handle the provisioning of WebSphere middleware environments in your data center. From the included Tivoli Service Automation Manager interfaces in the IBM CloudBurst solution, you can discover and deploy WebSphere CloudBurst patterns that exist on an appliance in your data center. WebSphere CloudBurst will deploy the patterns to the set of hardware resource provided by the IBM CloudBurst solution. Why would you want to integrate the two? If a large portion of your data center provisioning involves WebSphere middleware environments, WebSphere CloudBurst provides quick time to value and low cost of ownership. The WebSphere know-how is baked into the appliance and the virtual images it ships meaning that you don't need to develop and maintain what would be a rather large set of configuration scripts for the WebSphere environments running in your cloud.

I hope this clears the air a bit about not only the difference in IBM CloudBurst and WebSphere CloudBurst, but also about how and why these two can be integrated. I will never answer everyone's question in a simple blog post, so if I didn't address yours please leave a comment or reach out to me on Twitter @damrhein.

One of the new features that debuted in WebSphere CloudBurst 1.1 is the ability to resize the disks in a virtual image during the extend and capture (image customization) process. If you remember, the virtual images that exist in the WebSphere CloudBurst catalog are made of multiple virtual disks. In WebSphere CloudBurst 1.0 a default size was used for the virtual disks and this could not be changed, even during the image extension process. To be quite honest we got quite a bit of feedback about this, and so with version 1.1 while default sizes are still provided, you can specify the eventual size of each of the virtual disks during the image extension process.

As an example, consider the WebSphere Application Server Hypervisor Edition virtual image. This image contains four virtual disks: one for the WebSphere Application Server binaries, one for the WebSphere Application Server profiles, one for the IBM HTTP Server, and one for the operating system. The default size of each of these disks in the 7.0.0.7 version of the image is 6GB, 2GB, 1GB, and 12GB respectively, for a total of roughly 21GB. While that may be fine for some, what happens if you are going to be installing various other third-party software packages in the image? You may need more disk space for the operating system's virtual disk. Perhaps your WebSphere applications produce log files of considerable size. In that case you may want to increase the default size of the WebSphere Application Server profiles disk space.

Those scenarios and more are exactly why the resizing capability was added. When you extend the WebSphere Application Server Hypervisor Edition 7.0.0.7 virtual image in WebSphere CloudBurst 1.1, you will be presented the option to resize one or more of the virtual disks:

In the case above the default operating system disk size is bumped up to 16GB from the default 12GB size. Also note that in addition to changing the disk size, you can specify the number of network interfaces for your custom image.

Obviously, when you increase the size of the disks within the virtual image you are also increasing the storage requirements for that image when it is deployed to a hypervisor. Keep this in mind when you are calculating the upper bound capacity of your cloud. If you want to see more about how this feature works, check out this video.

A while back I co-authored an article along with Chris Ahl from Tivoli and Ken Klingensmith from WebSphere Technical Sales about the customization of virtual images in WebSphere CloudBurst. In the article we approached image customization as a means to enable IBM Tivoli Monitoring for the operating system within virtual machines dispensed by WebSphere CloudBurst. Today I posted a short demonstration that discusses and shows this particular integration scenario. If you are interested, but haven't had time to read the article, you may want to watch the video first as it should give you a good overview of the process and results.

Talk of Tivoli reminds me that IBM Pulse 2010 is just around the corner. I'll be going to discuss WebSphere CloudBurst and how it can be paired with software from IBM Tivoli for high-value integration scenarios. In the session I'll be talking about the Tivoli Monitoring integration as well as other key points such as our integration with Tivoli Service Automation Manager, IBM CloudBurst, and more. The best part about the session is that I will be co-presenting alongside a WebSphere CloudBurst customer that will dole out practical advice for using WebSphere CloudBurst within the enterprise. Join us on Tuesday February 23rd from 3:30 - 4:30 in Conference Center 306.

Remember, any time you have questions about WebSphere CloudBurst please pass them along. You can leave comments on this blog, or you can reach me at my new Twitter location @damrhein.

The ability to package custom maintenance packages and upload them as emergency fixes is perhaps a lesser known feature of WebSphere CloudBurst, but nevertheless something that's been around since the product's initial release. This is a powerful feature that allows you to build your own fix packages that you can then apply the same way you would use WebSphere CloudBurst to apply a PAK file or fixpack shipped by IBM.

Since IBM is delivering fixes and updates to all of the contents within WebSphere Application Server Hypervisor Edition virtual images (including the OS and IBM software components), you may wonder why you would even want to create your own maintenance packages. One reason would be if you switched out the SUSE Linux operating system shipped with the VMware ESX based images in favor of your own Red Hat operating system. In that case you would be responsible for maintenance to the operating system, and custom maintenance packages would be of interest to you. Another scenario where these custom maintenance packages come in handy would be if you created your own customized images that include non-shipped third-party software in addition to the software shipped in the images. If at some point you have the need to fix or update this software in a running virtual machine, custom maintenance packages provide you the vehicle with which to do just that.

What do these custom maintenance packages look like? In short, they are simply archives or ZIP files. The contents of the archive are largely decided by you, but there is one piece of metadata that is necessary if you want to use WebSphere CloudBurst to apply the maintenance. A file called service.xml is inserted into the root of the archive and tells WebSphere CloudBurst critical information about the custom fix archive. Here's an example of a service.xml file:

Most notably, this metadata tells WebSphere CloudBurst what module or script to invoke to apply the maintenance (Command, this executable is supplied by you), what image versions the fix is applicable to (ImagePrereqs), and the location of the working directory on the virtual machine (Location). In addition to the service.xml file and the executable, you can package up anything else, such as product binaries, which are needed to successfully apply the fix/upgrade/maintenance.

If you haven't noticed, this is an extremely flexible mechanism and can be used for just about anything. I should point out that you can only apply a given fix once per virtual machine, so it's not good for something that you want to run repeatedly against a given machine (check out user-initiated script packages instead). Also, there is a 512MB size limit on the archives. Keep these restrictions in mind when you are deciding how to use custom maintenance packages. If you are interested in learning a bit more about custom maintenance packages or other maintenance techniques, check out this article I co-authored along with Xiao Xing Liang from the IBM SOA Design Center in the China Development Lab.

When it comes to managing users and user groups within WebSphere CloudBurst, you can choose to manage all aspects of those resources within the appliance. Mainly this means that you can define and store user information (including login passwords) within the appliance, and you can define and maintain user groups and their associated membership list on the appliance. While you can do this and be sure that your information is extremely secure, you may instead want to integrate with an existing LDAP server that has some of this user and user group data. WebSphere CloudBurst certainly allows you to integrate with LDAP servers, but what does that mean for you?

For starters, when you integrate WebSphere CloudBurst with an LDAP server and enable the LDAP authentication feature, you no longer specify password information when defining users of the appliance. When users login, the password they specify will be authenticated against information stored in the LDAP server. Naturally, if you add a new WebSphere CloudBurst user with LDAP authentication enabled, that user must be defined in the LDAP server. Otherwise, WebSphere CloudBurst will prevent you from adding the user because it has no way to authenticate that person.

From a user groups standpoint, integrating with LDAP means you can no longer modify user group membership. User membership in groups is determined by information in the LDAP server. As a result, the same rule concerning adding new users applies when adding new user groups: You cannot define new user groups that do not exist in the LDAP server.

If you want to take a look at what LDAP integration looks like with WebSphere CloudBurst, I put together a short video. Let me know what you think.