One of the most powerful features of WebSphere CloudBurst is the ability to take one of the WebSphere Application Server Hypervisor Edition virtual images that are shipped with the appliance and extend it to a produce a custom virtual image. This allows users to begin creating customized environments from the bottom up, starting with the operating system. To put it in better context, let's take a look at a couple of scenarios where this feature comes in quite handy.
First off, a very common need for our customers is the ability to continually monitor their application environments. For instance, you may install Tivoli monitoring agents on all of your machines hosting WebSphere Application Server processes and configure those agents to report back to a management server. This is a great case for image extension in WebSphere CloudBurst.
In this scenario, you would start by extending an existing WebSphere Application Server Hypervisor Edition image. WebSphere CloudBurst creates a running virtual machine based off of the selected image, and you log into that virtual machine and install the Tivoli monitoring agents. Once the installation is done, you capture the virtual image back into the WebSphere CloudBurst catalog and use the new image to build a custom pattern. The last step is to include a script package on this custom pattern that, upon deployment, will configure the installed monitoring agents to report back to your desired management server.
Another use case is likely to be of interest to you if you are using WebSphere Virtual Enterprise (or something similar), and you could benefit from the same ease of provisioning for those environments that WebSphere CloudBurst brings to WebSphere Application Server environments. You can use the same customization combination above (image extension and custom scripts) to enable WebSphere CloudBurst to essentially dispense WebSphere Virtual Enterprise cells.
Again, this scenario starts off by extending a WebSphere Application Server Hypervisor Edition virtual image. Once the virtual machine for the extension is created by WebSphere CloudBurst, you log in and install the WebSphere Virtual Enterprise product. After the installation is done, you capture the image and store it in the catalog. Next, you build a custom pattern based off of this image and include script packages that, upon deployment, augment the various parts in the pattern from WebSphere Application Server profiles to WebSphere Virtual Enterprise profiles. (You may wonder why you wouldn't just create the WebSphere Virtual Enterprise profiles during the image extension process. This is because during image extension, you cannot make changes to the virtual disk that contains the WebSphere Application Server profiles. Any changes made to the profiles will be wiped out during the capture process.)
There are countless more scenarios for creating custom virtual images in WebSphere CloudBurst. To name a few, you may want to install JDBC drivers that are common to almost all of your application environments, install required anti-virus software, or just make operating system configuration changes. All of these things can be accomplished through the image extension and capture process. Look for an article coming out soon that will discuss and explain, in much greater detail than I provided here, the process of installing and configuring Tivoli monitoring agents in environments dispensed by WebSphere CloudBurst. In the meantime, if you have any questions or comments, drop us a line here or check out our forum.
It's about the time of year when we all look back and try to determine exactly how we spent the past twelve months. Whether we do it because we have to as part of year-end job reviews or because we like to take stock in what we've done and figure out where to improve next year, it's a time for reflection and recall. For me, this exercise made me take a look at various things we have done to deliver WebSphere CloudBurst technical collateral (articles, demos, blogs, etc.) in 2009.
For all practical purposes, our mission and efforts for such technical collateral for WebSphere CloudBurst started when it was announced at Impact in May of this year. Though there was certainly some preparatory work being done on this front, there was nothing we could really push to the public until after the announcement, and in some cases even after the appliance's release in June. Given that most of the content was produced over a six month stretch, I really think we put forth a strong effort, and I hope that this technical material has helped to both raise awareness of and educate users on the WebSphere CloudBurst Appliance.
Seeing as I already went back and rounded up this content, I thought I'd provide you a centralized look at the information. To start, I accounted for the articles that we published to the IBM developerWorks site over the six month stretch. All together I counted 8 articles and a special column entry:
As you can see the articles cover quite a bit of content and range from general level overview articles to technical in-depth "how-to" style articles. In general they seem to have been received well with over 26,000 views to this point. Our goal is to keep the pace up for 2010, and we already have a few articles on our plate for early in the new year (including an overview of what's new in WebSphere CloudBurst 1.1).
Another main medium we utilized to spread the word about WebSphere CloudBurst was YouTube. On our YouTube channel at http://youtube.com/websphereclouds, we currently have 17 different videos that demonstrate how to use certain features of the WebSphere CloudBurst Appliance. Though I think each demo provides value depending on exactly what a viewer is looking for, 3 of them really stick out for me.
Check out our videos if you get a chance. We've made an effort to keep them as short as possible while still providing value to viewers.
We have some WebSphere CloudBurst content spread around other places as well including this blog and my personal blog. Over the next few weeks we'll be taking a look at what worked and didn't work with respect to getting information out to the public. Of course at any time we very much appreciate your feedback on how you like to see content delivered because you are our target audience! If you have a comment, idea, or suggestion, leave a comment on the blog or send me a tweet to @WebSphereClouds.
During the week of IMPACT this year, we announced the launch of the WebSphere CloudBurst Samples Gallery. You can go to this gallery to find and download sample script packages, CLI scripts, and other tools that we hope help you in your endeavors with the appliance. The samples are free to use and offered in an "as-is" fashion.
While I certainly will not write about each and every sample we post out there, I did want to bring your awareness to a new one I just put up today. The new sample is neither a CLI script nor a script package, though you will find it in the script packages section of the gallery. Instead, the new sample is a tool that you can run to produce WebSphere CloudBurst script packages.
Specifically, the tool runs against a target WebSphere cell to produce a WebSphere CloudBurst script package that encapsulates that cell's configuration. The tool works by running the backupConfig command against the target cell. It packages the ZIP file that results from running the command into a special WebSphere CloudBurst script package that you can include in patterns which match the source cell in node quantity and type.
The script package produced by the tool packages logic to run the restoreConfig command using the backed up configuration from the source cell. This will apply the source configuration to a new WebSphere Application Server cell created as the result of deploying a pattern. In addition, the script package contains logic to handle the possibility of changing cell, node, and host names in the target environment.
The tool’s purpose is to help you accelerate the process of importing your existing WebSphere Application Server environments into the appliance as patterns (which is a problem I believe many of you would like to solve). It certainly does not handle everything you need to do to import environments. In fact, it has the same limitations as the backupConfig/restoreConfig utilities in WebSphere Application Server. However, I do believe that it makes it a little easier to start moving your existing environments into the appliance as new WebSphere CloudBurst patterns.
Check out this video to see a quick overview of the tool, and then go download it for free from the samples gallery. The ZIP file that you download has a readme file that gives specific detail about how to use this sample tool. As always, please let me know if you have any questions or feedback.
For the next installment of this series of FAQs, let's move from product positioning and integration, square into the land of operational procedure. For this post, we will consider you are getting ready to deploy a pattern based on the WebSphere Application Server Hypervisor Edition. During the deployment process, you provide configuration information, which includes a password for a user named virtuser.
You read the documentation, and you understand that virtuser is both an operating system user and the user that WebSphere CloudBurst configures as the primary administrative user for WebSphere Application Server. Naturally, this user owns the WebSphere Application Server processes that run in the virtual machine. While it is convenient that this is all pre-configured for you, you want to know one thing: "Can I define a user besides virtuser?"
It certainly would not be the first time this question came up. The short answer to this is yes, but there are of course caveats. You can define another user and have that user own the WebSphere Application Server processes, but you cannot completely remove the virtuser user, nor should you remove virtuser as the primary administrative user. The reason for this is that WebSphere CloudBurst relies on virtuser when it carries out certain actions such as applying maintenance, applying fixes, or otherwise interacting with the WebSphere Application Server environment.
All that being said, I recently put together a script package that allows you to utilize a user other than virtuser. I hope to put the script package in our samples gallery soon, but here's a basic overview of using the script package and what it does:
Attach the script package to all parts in a pattern that contain a WebSphere Application Server process.
Deploy the pattern and provide the necessary parameter values. These include the name of the new user, a password, a common name, and a surname. The last two bits are necessary when creating a new administrative user in WebSphere Application Server.
During deployment, the script package first creates a new OS user with the specified password.
The script adds the new user to the existing OS users group.
The script creates a new WebSphere Application Server user with the same username and password and grants administrative privileges to the user.
The script shuts down the WebSphere Application Server processes.
The script changes the runAsUser value for all servers to the empty string and sets the runAsGroup value for those servers to users. This allows members of the OS users group to start the WebSphere Application Server process.
The script starts the WebSphere Application Server processes.
There are a few other activities in the script, but that should give you a basic overview. Again, note that the script does not remove the virtuser user or change that user's OS or WebSphere Application Server permissions in anyway. I would also point out that if you use WebSphere CloudBurst to apply maintenance to the WebSphere Application Server environment, it will do so as virtuser and it will restart processes as virtuser, so plan accordingly.
I hope this sheds some light on a very common question. I hope to get the sample up soon, and as always let me know if you have any questions.
Cloud Computing is essentially a Systems Management innovation. I understand that, to some, that means simply managing hardware and capacity or computing power. However, it also involves deployment of enterprise level software. While some software is a kind of out-of-the-box asset that can be installed generically as if it were a hard asset, infrastructure software like WebSphere requires considerable skill and knowledge.
Tier1 cloud computing implementations must be able to expand the enterprise into provided capacity quickly and autonomically. If the scale-out requires tremendous effort and specialized skills then the cost savings that cloud offers is severely mitigated.
CloudBurst provides a mechanism to quickly deploy WebSphere environments to private clouds and allows the administrator to simply manage the assets on which WebSphere will run. The expertise of setting up and configuring WebSphere is, in effect, canned. This allows for much more rapid deployments and reduces the need for more expensive admins.
While many companies are still putting forward more technologically sophisticated offerings that still require even more technologically sophisticated staff, WebSphere has produced a product with a value which is more easily realized, understood and which can be seen on the balance sheet.
In my opinion, declarative deployment models are key to the entire notion of Platform as a Service (PaaS). That is, users should concern themselves with what they want, but not necessarily how to get it. The PaaS system should be able to interpret imperatives from the user and automatically convert that to a running system. In this respect, I think the new virtual application pattern, and more specifically policies, in IBM Workload Deployer takes a giant leap toward a more declarative deployment model.
In IBM Workload Deployer, policies allow you to 'decorate' your virtual application pattern with functional and non-functional requirements. In other words, they provide a vehicle for you to tell the system what qualities of service you expect for your application environment. To put a little context around this discussion, let's examine the policies available in the virtual application pattern for web applications. Specifically, let's look at the four policy types you can attach to Enterprise Application, Web Application, and OSGI Application components in this pattern:
Scaling policy: When it comes to cloud, the first thing many folks think about is autonomic elasticity. Applications should scale up and down based on criteria defined by the user. Well, that is exactly what the scaling policy lets you do. You simply attach this policy to your application component, and then specify properties that define when to scale. First, you choose a scaling trigger from a list that includes application response time, CPU usage, JDBC connection wait time, and JDBC connection pool usage. After choosing your trigger, you decide the minimum and maximum number of application instances for your deployment, and then you choose the minimum number of seconds to wait for an add or remove action. At this point, you can deploy your application and IBM Workload Deployer will monitor the environment, automatically triggering scaling actions as needed.
JVM policy: I would be willing to bet that nearly all of you tune the JVM environment into which you deploy your applications. The JVM policy allows you to take two common tuning actions, setting the JVM heap sizes and passing in JVM arguments, as well as attach a debugger to the Java process (especially useful in development and test phases). You can also use the policy to enable verbose garbage collection (invaluable to understanding heap usage patterns for your application) and select the bit level (from 32 or 64) for your application. Again, all you have to do is attach the policy and specify the properties. IBM Workload Deployer will take care of the required configuration updates.
Routing policy: The routing policy provides a simple way to specify virtual hostnames and allowable protocols (HTTP or HTTPS) for your application. Attach the policy, provide the virtual hostname you want to use, select the desired protocols, and that's it! Remember, once you set the virtual hostname you will need to update your name server to map the hostname to the appropriate IP address.
Log policy: During the development and test phase, it is likely that you will want to enable certain trace strings in the application runtime. The log policy allows you to provide trace strings for your application, and it makes sure that the appropriate configuration updates occur in the deployed environment.
While this is not an exhaustive explanation of each of the policies above, I hope it gives you a basic idea of what they are and how to use them. To me, declarative deployment models are going to be a crucial part of making PaaS successful, so I am really excited about the notion of policies in IBM Workload Deployer. What do you think?
In the course of my job, I am lucky to be able to work with both enterprise users and business partners who are adopting and using the WebSphere CloudBurst Appliance. When it comes to the business partner camp, one of my absolute favorites is the Haddon Hill Group. The Haddon Hill Group is an IBM Premier Business Partner, and they have been an early adopter and vocal advocate of the WebSphere CloudBurst Appliance. They have extensive knowledge of the use of the appliance in enterprise accounts, and quite frankly, they are doing some really cool things with WebSphere CloudBurst.
Given the above, I was glad to see summarized results from their various implementations made available recently on the IBM site. The summary is fairly concise, so I encourage you to take a look at the results Haddon Hill Group is getting with WebSphere CloudBurst.
I am not going to rehash the contents of the results here, but there are a couple of things I want to call out. First off, Haddon Hill Group says that WebSphere CloudBurst can provide companies with a '100 times faster time to market' delivery experience. In a practical sense, this means reducing the amount of time to deliver WebSphere environments from 40-60 days on average to just hours. That is an eye-opening data point!
The other thing I want call out here is a quote from Phil Schaadt, President and CTO, Haddon Hill Group. I have had the pleasure of working with Phil and team, and I have heard him echo these same sentiments many times:
"The important thing about the IBM WebSphere CloudBurst Appliance is that it will dispense a WebSphere Application Server image onto your WebSphere Application Server environment or private cloud along with other products within the WebSphere stack, and that application server will be ready in a few minutes. You can do it in a clustered environment, and you can even roll out IBM WebSphere Process Server and get it right in a fully clustered environment with a database connection, in about 90 minutes. You can also easily manage all the configurations of IBM WebSphere Process Server that you need. All the steps that took up so much time and effort on the part of IT staff have been removed. The savings for companies with large WebSphere implementations can be in the millions."
It is always great to see clients putting our technology to use to produce tangible business value. Again, I encourage you to take a look at these reports. As always, I am eager to hear what you think, so leave me a comment or reach out to me on Twitter @damrhein.
I hardly ever have a conversation about WebSphere CloudBurst, or generally cloud computing for application middleware, without the topic of databases coming up. Databases are such an important piece of nearly every application middleware environment, so users want to be sure that whatever they do for their application servers, they can also do for the databases on which their applications rely. That is why the capability to deploy DB2 from WebSphere CloudBurst has been around for as nearly as long as the capability to deploy WebSphere Application Server.
Even though DB2 deployment capability has been around for a while, there are still some common misconceptions regarding the offering. First, I have talked to a fair number of users who are under the impression that we only offer a trial version of DB2 for deployment via WebSphere CloudBurst. While that was true for the first few months of the offering, that is no longer the case. For several months now, a fully supported, 64 bit, production-ready DB2 image has been ready for use in WebSphere CloudBurst. If you were waiting for a DB2 image that you could go live with, wait no longer!
The other misconception, or rather, point of confusion, arises from the fact that the DB2 image for WebSphere CloudBurst is not, by name, a Hypervisor Edition image. I can assure you that is in name only. The DB2 image looks like and behaves like any other IBM Hypervisor Edition image once you load it into the appliance. You can use it to build and deploy patterns in the same way you use other images in WebSphere CloudBurst. You may just have trouble finding it if you search for 'DB2 Hypervisor Edition' as opposed to 'DB2 Server for WebSphere CloudBurst Appliance.'
Instead of going into further detail, I want to refer you to a blog entry from a fellow IBMer, Leon Katsnelson. Leon is a program director for DB2 and is responsible for the team that develops and delivers the DB2 image for WebSphere CloudBurst. In his most recent post, he provides a nice overview of the image and gives good information for those looking to use DB2 and WebSphere CloudBurst (there is also a bit on cloud computing at the beginning that I think is spot on). Check out Leon's post, and let us know what you think!
When we talk about clouds, we tend to think of the usual enterprise with servers centralized in data centers or in server rooms. At least, I do. But why does
it have to be so? Any IT shop will have many more computers than what is in the server farm. With hardware technology accelerating, as always, even desktop machines are capable of multiprocessor computing and doubling as servers.
Cloud offers the ability to do more than web commerce. The concept of cloud can have broad implications for all kinds of parallel processing needs. Right now, there are a number of organizations from SETI to large medical research firms that use volunteers on the internet to help compute through massive computational workloads. The ability to do that on a wider scale is limited by the need to deliver more sophisticated or even proprietary software on the member systems.
What if workstations could be conscribed to be part of a cloud? When the workstation owner is not using it, the entire machine could be repurposed for another need. Then during work hours, the owner's image could be restored. Private owners could even lease their processing time and make some extra money or earn credit of some kind.
Right now I am surrounded by several multicore processor based systems. Any one of them could power a web presence for a small business. All of them could power the website for a medium business. If I maintained a small cloud using the computers of my neighbors, I could possibly lease powerful computing cycles to render the next animated movie or to compute fractal geometry calculations for climate models. If I operated between 9PM and 6AM I could deliver more than a day's worth of computing gain. What would that be worth?