This week is a busy week getting ready for IMPACT next week. I'm looking forward to the conference, and I thought I would share a few things on my agenda. Naturally, my agenda includes the sessions I am running:
10:15 AM - 11:30 AM
TDC-2973A Meet the Experts and Demo: WebSphere Cloudburst Appliance
Come and meet the experts responsible for the WebSphere Cloudburst Appliance, and see a demo of its functionality in this informal setting.
1:30 PM - 4:30 PM
TDC-1369A Lab: Working with the WebSphere CloudBurst Appliance
Come and work hands on with the WebSphere CloudBurst Appliance to create your own WebSphere application environments in a cloud. The lab will guide you through using WebSphere CloudBurst to create and deploy WebSphere virtual systems in a private cloud. Youll learn how to create custom WebSphere and DB2 topologies by extending virtual images, creating patterns, and using scripts. You'll get a chance to work with the easy to use Web 2.0 user interface. Youll be amazed at the ease of use WebSphere CloudBurst brings to configuring, deploying, and running WebSphere environments in a private cloud.
1:30 PM - 2:45 PM
TAD-1370A Simplifying Development using Rational Tools with WebSphere CloudBurst Appliance
Are you looking to really simplify your WebSphere development and test environments - including never needing to install or configure WebSphere again? If so, come hear about how you can use the IBM WebSphere CloudBurst Appliance along with Rational tools like the Rational Automation Framework for WebSphere and Rational Software Architect to create a dynamic development and test cloud. With the integration of WebSphere CloudBurst and selected Rational tools, you worry about the application development, while WebSphere CloudBurst worries about the WebSphere infrastructure and your cloud resources. Come to this combination of presentation and demo to see how easy development and testing can be.
In addition to these, there are some other exciting WebSphere CloudBurst sessions on tap:
3:45 PM - 5:00 PM
TDC-2498A WebSphere CloudBurst Appliance at Lowe's
Lowe's is evaluating WebSphere CloudBurst Appliance (WCA) as a tool for managing their X86 and PowerVM environments in a cloud fashion. Come to hear how Lowes believes WCA fits into an enterprise companys cloud strategy. This session will discuss the work done at Lowes so far and the use cases planned for WCA at Lowe's. Attendees can understand how WCA is delivering value in an adopter's environment.
5:15 PM - 6:30 PM
TDC-1368A Introduction to WebSphere CloudBurst Appliance
The WebSphere CloudBurst Appliance delivers capabilities to create, monitor, and maintain private WebSphere clouds. It provides you the capability to quickly and simply create, deploy, and maintain virtualized WebSphere application environments running on a heterogeneous, shared pool of resources that make up your cloud. In this session, we will provide an overview of the WebSphere CloudBurst Appliance features and benefits and demonstrate the latest capabilities.
1:30 PM - 2:45 PM
TDC-1758A Building Private Clouds with WebSphere CloudBurst Appliance
Come join us as we discuss how the WebSphere development and test organization built a large private cloud from the ground up using WebSphere CloudBurst Appliance. We have lowered the entry requirement to get a meaningful WebSphere Application Server development environment (days down to minutes), saved costs by improving hardware utilization while simplifying our management of physical resources and topologies. We will discuss best practices for adhering to security requirements, creating reusable automation scripts for your applications and configurations and maintaining your cloud. Allow us to share our experience in using WebSphere CloudBurst Appliance to create our automated regression infrastructure, and to provide up-to-date deployments to our test team.
4:45 PM - 6:00 PM
TDC-1946A BSkyB's Experiences using the WebSphere CloudBurst Appliance V1.1
At Impact 2009, IBM announced the launch of the WebSphere CloudBurst Appliance. BSkyB witnessed this launch and were very keen to understand the device's potential. This presentation details their experiences to date, and their vision for incorporating the appliance into their organization. Details will include bringing the device in house, setting up the cloud, and doing deployments. BSkyB will also discuss the customisation process, and how they used the extend / capture and scripting capabilities to add content including WebSphere Process Server. The presenters will share their lessons learned as they continue their journey using WebSphere CloudBurst for agile environment provisioning and simplified WebSphere Administration.
10:15 AM - 11:30 AM
TDC-2063A Panel: WebSphere CloudBurst Appliance Customers Describe their Experiences
A panel of several customers who have adopted WebSphere CloudBurst Appliance will discuss their experiences with the product, and answer questions related to their experiences.
9:00 AM - 10:15 AM
TDC-1884A Using WebSphere CloudBurst Appliance in a PowerVM Environment
This session will discuss the concepts and issues associated with implementing the WebSphere CloudBurst Appliance (WCA) in a PowerVM environment. The components of the implementation including VMControl, IBM System Director, HMC, NIM. and WebSphere CloudBurst will be explained, along with their relationships and functions. This in-depth session will also provide best practices from early adopter deployments and performance experiences.
1:30 PM - 2:45 PM
TBR-2491A Customizing a Private Cloud for WebSphere Process Server Applications
Every enterprise has a unique set of standards when it comes to the applications that are deployed and the qualities of service that are required for those applications. Come to this session to learn some of the best practices around pattern customization and maintenance of the images in the WebSphere CloudBurst Appliance for your specific requirements. We will use the creation of a WebSphere Process Server double gold topology pattern to show these best practices. This session will also cover the practices involved with maintaining these patterns.
As you can see there is going to be quite a bit of activity around WebSphere CloudBurst at IBM IMPACT 2010. The lists above is not all encompassing either. Visit the IBM Impact site for more information. If you are registered to attend, be sure to visit the agenda builder website for the conference.
May is almost here and that means that IBM IMPACT is right around the corner. Just like years past, IMPACT 2010 will be a great chance to get valuable education and insight into IBM WebSphere software and software from across the IBM software family. If you want to hear how IBM software is leading the march toward a smarter planet, register now.
IMPACT 2010 will be a great chance to hear the WebSphere cloud computing story. There will be multiple sessions on the WebSphere CloudBurst Appliance. These include customer-led sessions, internal adoption stories, overviews, and much more. I'll be there running a hands-on lab and delivering a session that discusses integration between WebSphere CloudBurst and IBM Rational tools. Of course, there is more to WebSphere and cloud computing than WebSphere CloudBurst. We have several other sessions that will detail all of IBM WebSphere's work in the cloud.
If you are interested, I put together a short video discussing some of the sessions on tap for WebSphere and cloud computing at IMPACT 2010. I'd also encourage you to check out the social media site for IBM IMPACT 2010. On that site, you will find tweets, videos, and blogs about the conference. Don't forget to sign up, and I hope to see you in Las Vegas!
-- Dustin Amrhein
When I talk to users familiar with both WebSphere CloudBurst and the IBM Systems Director VMControl offering, there is sometimes a bit of confusion. It is not surprising. Both WebSphere CloudBurst and IBM Systems Director VMControl allow users to create and manage virtualized environments. That leads us to an oft-asked question: What is the difference between WebSphere CloudBurst and IBM Systems Director VMControl?
The simple answer is that the difference in the two offerings is the degree to which they are purpose-built. IBM Systems Director VMControl equips users with broadly applicable capabilities to create and manage environments consisting of virtual machines. These capabilities extend to PowerVM, z/VM, VMware, and Microsoft Hyper-V hypervisor platforms. IBM Systems Director VMControl is not necessarily knowledgeable about the software running in the virtual machine, but it does allow the user to manage that asset effectively.
Compare and contrast that with the capabilities provided by WebSphere CloudBurst. The appliance also enables users to create and manage environments consisting of virtual machines. The difference is that WebSphere CloudBurst is purpose-built to provide you with the ability to create, deploy, and manage virtualized WebSphere environments quickly and easily.
What does that mean? Well, on one hand it means that WebSphere CloudBurst does not treat the virtual machines it creates like a black box. In fact, it knows quite a bit about the software running inside those machines, and provides users with out-of-the-box configuration and administration capabilities for said software. WebSphere CloudBurst knows how to interact with the software in the virtual machines to do things like federate WebSphere nodes into a cell, create application server clusters, configure environments for optimal performance, apply fixes and upgrades, and more. The best part is you do not need to supply any of your own scripts to do this. In short, the appliance ships with WebSphere intelligence.
Beyond this WebSphere intelligence, WebSphere CloudBurst enables users to create customized WebSphere environments (from the operating system up) and codify those customized environments in the form of patterns. These patterns, which represent your very own WebSphere application environments, enable you to deploy your applications rapidly, repeatedly and with extremely consistent results. In addition, the appliance allows you to define varying roles for users, each of those mapping to traditional data center responsibilities (i.e. customizing the operating system, building application infrastructure, carrying out middleware customizations, etc.). Again, WebSphere CloudBurst was purpose-built with WebSphere environments in mind.
It is not all about comparing and contrasting WebSphere CloudBurst and IBM Systems Director VMControl. In the case that you are using WebSphere CloudBurst to create and manage virtualized WebSphere environments on top of the PowerVM hypervisor platform, IBM Systems Director VMControl is actually a required component. In this scenario, the two offerings are complementary. WebSphere CloudBurst communicates with IBM Systems Director VMControl in order to create and configure the virtualized WebSphere environment requested by the user. This image below depicts how the two products work in conjunction in a PowerVM environment.
I hope this helps to shed light on how WebSphere CloudBurst compares to, contrasts with, and complements IBM Systems Director VMControl. Feel free to reach out to me on the blog or on Twitter (@damrhein) with any questions I did not answer here.
Yesterday, I had the opportunity to present WebSphere CloudBurst during the IBM Cloud computing for developers virtual event. I provided a brief overview of the appliance along with a demonstration, and then tackled some questions from the 150+ attendees in the audience.
All of the questions were good ones, and I wish I had time to address them all during the session (I will be answering all questions and posting them online soon). However, one of the questions stood out to me because of its relevance to how IBM uses WebSphere CloudBurst in their own labs. Paraphrasing, the question was "Can you share hardware resources (hypervisor hosts) between WebSphere CloudBurst and other components in your data center?"
Very good question. The answer is, of course, yes you can. I don't want to sugarcoat it because it does require thought and planning. Ideally, when WebSphere CloudBurst is using a hypervisor host, the appliance is the only thing acting on that host. However, when WebSphere CloudBurst is not using that host, then you can absolutely repurpose it for use by other components in your data center.
Our WebSphere Test Organization uses WebSphere CloudBurst to aid in their testing of our WebSphere middleware products. The capability to provision hypervisor hosts in and out of the WebSphere CloudBurst cloud is of critical importance to them. Like many organizations, they are resource constrained and must get the most out of their IT investment. They use the Tivoli Provisioning Manager to provision VMware ESX hosts for use by WebSphere CloudBurst, and then they use the WebSphere CloudBurst CLI to define those hypervisors to the appliance and do verification testing of the new resource. This allows them to easily expand and contract the amount of shared infrastructure utilized by WebSphere CloudBurst at any one time, and it means components do not have to statically lock down resources. I have a lot more information to come about our WebSphere Test Organization and their use of WebSphere CloudBurst, but I thought I would give everyone a peek at the kinds of things they do everyday with the appliance.
If you are interested in what I presented yesterday to the attendees of IBM's Cloud computing for developers event, you can check out their developerWorks Group page. In the Activities section, you will find the charts, demonstration, and a playback if you prefer to listen to the session. As always, I appreciate your feedback and questions.
The 1.1.1 version of WebSphere CloudBurst is now available on the IBM support site, and you can read a bit about it here. I have not blogged about each and every point release of WebSphere CloudBurst here, but this particular one is significant. The 1.1.1 release adds support for IBM's z/VM hypervisor platform as a deployment target.
Quite simply this means that you can now create virtualized WebSphere application environments on the z/VM platform using WebSphere CloudBurst. This starts by first defining target hypervisors, instances of Linux Master Systems, that WebSphere CloudBurst can communicate with to setup virtual machines on z/VM. Coupled with support for the z/VM infrastructure components, there is a new version of the WebSphere Application Server Hypervisor Edition virtual image. While this new image contains the same basic components as the previous hypervisor edition images, it is packaged for the z/VM platform, and it includes a zLinux operating system.
Once you upgrade to WebSphere CloudBurst 1.1.1, you can define your z/VM infrastructure and use the new WebSphere Application Server Hypervisor Edition image to build custom patterns targeted for the z/VM platform. I put together a demonstration that provides a very brief overview of these new capabilities. As always, please reach out if you have any questions about this or any other WebSphere CloudBurst topic.
I'm out at the RSA conference in San Francisco this week, and I'm expecting a lot of good conversations about WebSphere CloudBurst and security. This topic always comes up when I'm out and talking to customers, and I approach it from a few different angles.
First of all, WebSphere CloudBurst enables the creation of on-premise clouds (clouds in your data center). This means that you retain control over the resources that make up and support your cloud, and you have the ability to very tightly secure said resources. Notice that I say "you have the ability". I'm careful to point out that on-premise clouds do not inherently make your environment secure. If you don't already have a robust security strategy in place within your enterprise, then simply moving to a cloud model will not solve much. That being said, if you do have a comprehensive security strategy in place, one built around customized processes and access rights, then on-premise clouds are likely to make much more sense for you.
Moving beyond the opportunity for customized security controls provided by on-premise clouds, WebSphere CloudBurst delivers additional, unique security features. It starts on the outside with the tamper-resistant physical casing. If a malicious user attempts to remove the casing to get to the inner contents, the appliance is put into a dormant state, and it must be sent to IBM to be reset. "So what!" you say. If the user removes the casing and gets to the contents, couldn't they simply read the contents off the flash memory or hard disks directly, or insert them into another WebSphere CloudBurst Appliance and read them from there? Nope. All of the contents stored on the appliance's flash memory and hard disks are encrypted with a private key that cannot be changed and is unique to each and every appliance.
If you are at all familiar with WebSphere CloudBurst, you know that the appliance dispenses and monitors virtual systems running on a collection of hypervisors. Obviously then, the appliance must remotely communicate with the hypervisors. In order to secure this communication, all information between WebSphere CloudBurst and the hypervisors (and vice versa) is encrypted. This encryption is achieved by using an SSL certificate that is exchanged when a hypervisor is defined in WebSphere CloudBurst. This certificate must be accepted by a user, thus preventing rogue hypervisors from being defined in WebSphere CloudBurst.
Finally, WebSphere CloudBurst provides for the definition of users and user groups with varying permissions and resource access rights in the appliance. You don't have to turn over the keys to your cloud kingdom when you add a user to the appliance. You have the capability to define varying permissions (from simply deploying patterns, to creating them, all the way up to administering the cloud and appliance), and you have the ability to control access to resources (patterns, virtual images, script packages, cloud groups, etc.) at a fine-grained level. These two capabilities combine to allow you to control not only what actions a user can take, but also on which resources they can take those actions.
WebSphere CloudBurst was designed with focus on delivering a secure cloud experience, and I think it hit the mark. I'm sure I didn't address all your WebSphere CloudBurst and security related questions. If you have something specific in mind, leave a comment on the blog or reach out to me on Twitter. I'll do my best to address your question.
"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 188.8.131.52 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 184.108.40.206 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.