|I want to stay in the realm of the deployment process for our next frequently asked question regarding the WebSphere CloudBurst Appliance.|
|The ability to quickly deploy entire WebSphere Application Server cells (anything from single node cells, to multi-node clustered cells) is a hugely compelling feature of the appliance. Instead of spending days or hours deploying a WebSphere Application Server cell, users can deploy these in a matter of minutes (less than twenty minutes for clustered environments)!|
|For the most part, WebSphere CloudBurst patterns represent entire cells. This includes management parts (AdminAgent, DeploymentManager), managed parts (custom nodes), and proxy parts (IHS). When you deploy a pattern, the result is a complete and fully functional WebSphere Application Server cell running in your private cloud.|
|So, now that you have a complete cell out in your cloud, what happens if you need to add more nodes? If the the user-demand for the applications on your cell has exceeded the initial topology, can you use WebSphere CloudBurst to add more cells? Sure you can!|
|In short, this involves creating a pattern that contains only a custom node part, and then at deploy time, providing information about the existing cell. WebSphere CloudBurst then takes over the deployment of that custom node and federates the node into the existing cell based on the information supplied about that cell. I won't go into an entire explanation here, because I think the demo I put on our YouTube channel explains it pretty well.|
|In my experience with the WebSphere Application Server, this represents a much more seamless and automated process for deploying new nodes into an existing cell than what exists outside of WebSphere CloudBurst today. Of course, we value your comments and feedback above all else. So let us know what you think!|
|-- Dustin Amrhein|
A view from the clouds: Cloud computing for developers
DKA 0600026VJ2 Tags:  cloud_computing cloudburst websphere_cloudburst private_cloud virtualization 3,167 Views
I have written in this blog before about how using WebSphere CloudBurst, users can achieve fully customized WebSphere Application Server environments. Those customizations start at the operating system level by extending the shipped virtual images, modifying those images, and recapturing the custom image in the WebSphere CloudBurst catalog. On top of operating system level customizations are customizations made to the WebSphere Application Server middleware environment.
Customizations to the middleware environment are mainly achieved through what WebSphere CloudBurst calls script packages (click here for the script package section in the WebSphere CloudBurst Information Center). Very simply script packages are merely ZIP files that users uploaded into the WebSphere CloudBurst catalog and include in their custom WebSphere CloudBurst patterns as necessary.
The ZIP file that is stored in the catalog includes an executable script and optionally a set of artifacts used or needed by the script. In addition to uploading this ZIP file into the WebSphere CloudBurst catalog, users tell WebSphere CloudBurst how to invoke the script package and provide other information like environment variables that need to be present during script execution. WebSphere CloudBurst then uses this information to invoke the script packages upon completion of pattern deployment.
Script packages are very open-ended. As long as WebSphere CloudBurst can execute the script in the operating system environment, then it can be included in a pattern. So, users can create script packages that utilize the WebSphere Application Server wsadmin tool to install applications, set server trace settings, or otherwise alter the WebSphere Application Server configuration. Alternatively, users can supply operating system executables like shell scripts that otherwise configure the application environment. As long as a valid executable is supplied, then there are really no imposed limits on what a script package can do.
However, just because script packages can do just about anything doesn't mean they should! You can read this developerWorks article for a more complete discussion about WebSphere CloudBurst customizations and the use of script packages, but the bottom line is that script packages are best suited to deliver customizations that vary over application environments (like installing applications). For customizations that are needed in just about every application environment (required anti-virus software comes to mind), creating a custom virtual image is the way to go.
If you want to learn more about WebSphere CloudBurst script packages, I'd suggest you check out the WebSphere CloudBurst Information Center link and the developerWorks link above. As always, let us know if you have any questions by commenting here, sending us a tweet (@WebSphereClouds), or by sending an email to firstname.lastname@example.org.
-- Dustin Amrhein
DKA 0600026VJ2 Tags:  cloud websphere cloudburst websphere_cloudburst cloud_computing 4,887 Views
The more and more we visit with customers about our new WebSphere CloudBurst Appliance, the more we see a common thread of questions emerge around the offering. In an attempt to address some of these questions in a more accessible medium, I figured I'd start a series of blogs that relays some of these questions and of course the answers. Today I want to start with what is perhaps the most frequently asked question about WebSphere CloudBurst.
One thing I've noticed while talking to customers is that virtualization and virtualization management tools are widely used today. When we talk to customers already using these tools, they immediately understand the benefits WebSphere CloudBurst delivers in the form of virtualizing WebSphere Application Server environments and bringing a set of lifecycle capabilities to this virtualization. However, almost invariably they ask why they would use WebSphere CloudBurst over their existing tools, for instance VMware's vSphere offering.
There's a two-word answer to this question: WebSphere intelligence. What exactly does that mean? WebSphere CloudBurst was built with WebSphere in mind, and it knows how to configure, tune, and maintain WebSphere Application Server environments without the need for custom scripting.
For instance, when a user is building a WebSphere CloudBurst pattern (if you are wondering what a pattern is, or just want to learn the basics of WebSphere CloudBurst, take a look at this article) the relationships among the various WebSphere Application Server parts are automatically configured. This means that custom nodes are automatically federated into the Deployment Manager cell, web servers are automatically configured to route to application server nodes (and the web server's config file is setup to be automatically propagated), and much more. In addition to establishing these relationships, WebSphere CloudBurst also applies best practice tuning to the WebSphere environment. This tuning of course is just a suggestion and can be easily changed by users.
In addition to configuring and tuning a topology, WebSphere CloudBurst allows users to apply both fixes and service level upgrades to running virtual systems. Through the console, users can select virtual systems and apply either a fix or upgrade directly to the system. All the while, WebSphere CloudBurst automatically backs up the state of the system before the change is applied, and users can easily roll back to the previous system state if undesired behavior is encountered after the change.
I'm not disputing that all of these actions could be potentially accomplished using some "black-box" virtualization management tool, but the burden of supplying WebSphere intelligence is placed directly on the user. In order to configure, tune, or maintain virtualized WebSphere Application Server environments, users would accompany their virtual machine definitions with a heavy dose of scripting. These scripts only add to the pile of IT assets that need to be owned, updated, and maintained over time, and they only serve to distract users from the end-game of getting their applications up and running.
It's important to note too that WebSphere CloudBurst was only just released, so I would expect that the WebSphere intelligence it provides will only grow and get better over time. If you want to learn more about WebSphere CloudBurst, or if you think your company would be interested in a briefing and demo please get in touch. You can reach me at email@example.com. We would love to explain both the business value and technical capabilities of the appliance.
-- Dustin Amrhein