If you've read anything I've written about WebSphere CloudBurst up to this point you know all about patterns. Using the appliance you can easily and quickly build, deploy, and manage these representations of your middleware application environments. Today, I want to focus in on the deployment piece in particular and take a look at how you can easily automate this process.
You can use the WebSphere CloudBurst web console to deploy patterns, and when doing so you can even schedule the deployment to happen at a later date. This scheduling capability certainly gets you on the road to an automated deployment process, but what if you want to take it one step further and eliminate the need for someone to login and manually move around the web console to schedule automated deployments? In this case, you can use either the CLI or the REST interface that WebSphere CloudBurst offers.
In this post I thought I'd take a look at using the CLI interface in order to set the stage for some nice automation around pattern deployment. It starts out with a properties file that provides details about my deployment. This includes the cloud to deploy to, the pattern to deploy, password information, and the time at which the virtual system should start.
SYSTEM_NAME_PREFIX=New App Development
TARGET_CLOUD=Default ESX group
TARGET_PATTERN=WebSphere single server
Imagine that the properties file above gets written as the result of some other action, such as the completion of your application's build process. With the properties file in place, and I'll point out that your properties file can and probably will be more robust than above, let's move on to the code that handles the deployment process based on the information in said file. First, we have a small amount of CLI code to retrieve and parse the input data (I omitted the straight-forward properties retrieval for space):
from datetime import datetime, timedelta
from java.util import Properties
from java.io import FileInputStream
// read in and retrieve properties using java.util.Properties API (i.e. props.getProperty('DEPLOYMENT_DATE'))
parsedParts = deploymentDate.split(" ")
systemName = systemName + "_" + deploymentDate
dateParts = parsedParts.split("/")
timeParts = parsedParts.split(":")
monthPart = int(dateParts)
dayPart = int(dateParts)
yearPart = int(dateParts)
hourPart = int(timeParts)
minutePart = int(timeParts)
Next is the code that actually schedules the pattern deployment:
First we get the desired deployment time and current time as datetime objects. After that, assuming the desired deployment time has not already elapsed, we calculate the difference between the desired deployment time and current time. This difference, in seconds, is then added to the result of the time.time() value to come up with a start time. After that is done, we simply retrieve the cloud that was indicated in the properties file, and then we call the runInCloud method for the pattern indicated. When calling the runInCloud method we supply the name of the virtual system that will be created, password information, and the start time we calculated earlier. As a result of this method call, a task will be generated in the target WebSphere CloudBurst Appliance and the virtual system will be started at the specified time. This will happen in an automated fashion with no human intervention required.
That's really all there is to automating the pattern deployment process using the CLI. In a more complete, end-to-end scenario you may envision the completion of one process, such as an application build process mentioned above, result in the writing of the properties file and in turn the call into the CLI to deploy a pattern. As always, feel free to send me any comments or questions.
Every time I've visited with customers about WebSphere CloudBurst, without fail someone requests that the appliance support products besides the WebSphere Application Server. We started to address these requests with WebSphere CloudBurst 1.1 when we announced the availability of a DB2 Enterprise 9.7 trial virtual image specifically packaged for use in the appliance. Very recently we continued to respond to customer requests by extending the list of supported products in WebSphere CloudBurst to include WebSphere Portal.
The WebSphere Portal Hypervisor Edition, initially offered as a Beta product, is a virtual image packaging of WebSphere Portal 6.1.5 ready for use in the WebSphere CloudBurst Appliance. The image includes a pre-installed, pre-configured instance of WebSphere Portal. Also contained within the image is an IBM HTTP Server instance configured to route to the WebSphere Portal instance and a DB2 instance installed and configured as the external database for WebSphere Portal. The WebSphere Portal instance also includes Web Content Management enablement along with several samples to help users get started right away.
The user experience when building and deploying WebSphere Portal patterns remains consistent with the existing experience for WebSphere Application Server and DB2 patterns. Another good note is that you can expect similar rapid deployment capability for WebSphere Portal patterns. I got a running virtual system, with all the parts I mentioned above installed and configured (meaning no after the fact integration scripting was necessary) in under 15 minutes.
To see more, check out my new demonstration of the WebSphere Portal Hypervisor Edition for the WebSphere CloudBurst Appliance. If you have a WebSphere CloudBurst Appliance you can download the WebSphere Portal Hypervisor Edition image and a usage guide from here.
I was at a customer meeting the other day, and someone asked me if they could query WebSphere CloudBurst for an inventory of all of their virtual system deployments. This person was of course aware that he could go to the web console and very quickly view all of the virtual systems. What he wanted though was something that he could run to generate a report that contained all of this information. For a purpose like this, harnessing the WebSphere CloudBurst CLI is exactly the way to go.
I thought I'd write a simple CLI script that provides an example of how you could do this.
from datetime import datetime
outFile.write("WebSphere CloudBurst Virtual System Inventory\n")
outFile.write("Total virtual systems: " + str(len(cloudburst.virtualsystems)))
def writeVSDetails(outFile, virtualSystem):
outFile.write("\tVirtual system name: " + virtualSystem.name)
outFile.write("\tCreated from pattern: " + virtualSystem.pattern.name)
outFile.write("\tVirtual system status: " + virtualSystem.currentstatus_text)
created = datetime.fromtimestamp(virtualSystem.created)
outFile.write("\tVirtual system creation date: " + created.strftime("%B %d, %Y %H:%M:%S"))
outFile.write("\tTotal virtual machines: " + str(len(virtualSystem.virtualmachines)))
def writeVMDetails(outFile, virtualMachine):
outFile.write("\t\tVirtual machine name: " + virtualMachine.name)
outFile.write("\t\tVirtual machine display name: " + virtualMachine.displayname)
outFile.write("\t\tCreated from image: " + virtualMachine.virtualimage.name)
outFile.write("\t\tVirtual machine hypervisor: " + virtualMachine.hypervisor.name + " | " + virtualMachine.hypervisor.address)
outFile.write("\t\tVirtual machine IP address: " + virtualMachine.ip.ipaddress)
outFileLoc = sys.argv
outFile = open(outFileLoc, 'w')
for virtualSystem in cloudburst.virtualsystems:
for virtualMachine in virtualSystem.virtualmachines:
As a result of invoking this script using the CLI's batch mode, content is written to the file location supplied by the caller.
WebSphere CloudBurst Virtual System Inventory
Total virtual systems: 3
Virtual system name: Single server
Created from pattern: WebSphere single server
Virtual system status: Started
Virtual system creation date: January 15, 2010 16:37:20
Total virtual machines: 1
Virtual machine name: Standalone 0
Virtual machine display name: Single server cbvm-110 default
Created from image: WebSphere Application Server 188.8.131.52
Virtual machine hypervisor: Ruth ESX | https://<hypervisor_host>/sdk
Virtual machine IP address: <ip_address>
Virtual system name: Development WAS Cluster
Created from pattern: Custom WAS Cluster - Development
Virtual system status: Started
Virtual system creation date: January 18, 2010 14:08:46
Total virtual machines: 2
Virtual machine name: DMGR 0
Virtual machine display name: Development WAS Cluster cbvm-112 dmgr
Created from image: WebSphere Application Server 184.108.40.206
Virtual machine hypervisor: Ruth ESX | https://<hypervisor_host>/sdk
Virtual machine IP address: <ip_address>
Virtual machine name: Custom Node 1
Virtual machine display name: Development WAS Cluster cbvm-111 custom
Created from image: WebSphere Application Server 220.127.116.11
Virtual machine hypervisor: Ruth ESX | https://<hypervisor_host>/sdk
Virtual machine IP address: <ip_address>
Virtual system name: DB2 for development use
Created from pattern: DB2
Virtual system status: Started
Virtual system creation date: January 18, 2010 14:09:58
Total virtual machines: 1
Virtual machine name: DB2 Enterprise Server 32bit Trial 0
Virtual machine display name: DB2 for development use cbvm-113
Created from image: DB2 Enterprise 18.104.22.168 32-bit Trial
Virtual machine hypervisor: Ruth ESX | https://<hypervisor_host>/sdk
Virtual machine IP address: <ip_address>
I withheld IP addresses and host names above for obvious reasons, but if you ran the script against your environment you would see actual host name and IP address values. The script above is written once, and it can be subsequently run anytime you want an inventory of virtual systems running in your WebSphere CloudBurst cloud. There's other information available for virtual systems and virtual machines that I didn't show here, and you can retrieve it if necessary for your inventory report. In addition, I chose to print this information as regular text in a file supplied by the caller, but you might choose to generate the report in another format including XML, JSON, or anything else for that matter.
-- Dustin Amrhein
p.s. As with any sample code or script I provide here, the above is only a sample and offered as-is.
If you read some of my entries from time to time, chances are you know that you can use WebSphere CloudBurst to apply interim fixes and fixpacks to your deployed virtual systems. When you choose to apply either a fix or fixpack, WebSphere CloudBurst temporarily stops the virtual system, takes a snapshot of the system (the entire WebSphere cell), applies the fix or upgrade, and then starts the system back up. The result is an updated, running WebSphere cell, and if you need to, you can rollback the virtual system to the previous configuration by simply clicking a button.
In WebSphere CloudBurst 1.0 the application of fixes and upgrades were applied via the web console which made it hard to automate this process. However, in WebSphere CloudBurst 1.1 you can use the command line interface to apply fixes and fixpacks to virtual systems. The appliance still takes the actions I described above, thus the process is still simple, safe, and fast. The only difference is the interface through which you drive the application of the maintenance.
What does it look like? Quite frankly, it's very simple. You can go through all of my virtual systems and apply both fixes and fixpacks with the seven line script below:
for virtualSystem in cloudburst.virtualSystems:
fixes = virtualSystem.findFixes()
if len(fixes) > 0:
upgrades = virtualSystem.findUpgrades()
if len(upgrades) > 0:
You can write this script once, save it as a Jython file, and run it with the CLI's batch mode anytime you want to roll out maintenance to your virtual systems. It's really amazing to me that the above SEVEN lines are capable of rolling out all fixes and all upgrades within your WebSphere CloudBurst catalog to every virtual system the appliance is managing. I can't think of an easier or safer way to automate the deployment of fixes/upgrades to your WebSphere environments.
Let me know if you have any questions. As always you can reach me on Twitter @WebSphereClouds.
Not long ago I created a demonstration that highlighted the new support for the PowerVM platform introduced in WebSphere CloudBurst 1.1. In that demonstration I showed how you can deploy to a PowerVM cloud by defining a new cloud group that interfaces with a VMControl instance to manage a pSeries cloud environment. However, in the demo I did not go into much detail about the components of a pSeries cloud used with WebSphere CloudBurst.
Since pictures help me out a lot, I thought I’d start the discussion with an image that depicts the components in the pSeries cloud environment and the workflow when using WebSphere CloudBurst to deploy systems to this environment.
The workflow begins when a user requests the deployment of a pattern and targets that deployment for a PowerVM cloud group. WebSphere CloudBurst first checks that the cloud group contains the compute resources necessary to deploy the pattern. After the resource checks are complete, WebSphere CloudBurst decides where to place each virtual machine that will be created from deployment using its intelligent placement algorithm. No matter the type of the cloud environment being utilized the appliance retains control over placement decisions, thus ensuring the virtual system has been deployed in a way that optimizes both performance and availability.
Once the placement decision has been made, WebSphere CloudBurst communicates with the VMControl instance, which in turn instructs the Hardware Management Console (HMC) to create LPARs on the targeted pSeries machines. These LPARs will host the virtual machines that represent the WebSphere Application Server nodes in your virtual system. After the LPARs have been created, WebSphere CloudBurst leverages VMControl to instruct the Network Installation Manager (NIM) to deploy virtual images to the necessary LPARs.
When the LPARs have been created and the virtual images have been deployed to those LPARs, the common process of virtual system creation can proceed. This process includes starting virtual machines, starting WebSphere Application Server components, and running any user-supplied scripts. The end result is a ready to use, virtualized WebSphere Application Server cell running on the PowerVM hypervisor platform.
I hope this provides a nice overview of the underlying environment when PowerVM hypervisors are used with WebSphere CloudBurst. As for those users who are not WebSphere CloudBurst cloud administrators, the information above is nice to know but not necessary. The user experience with respect to building, deploying, and managing your virtualized application environments with WebSphere CloudBurst is consistent regardless of the type of your cloud platform.
If you are going to install and use WebSphere CloudBurst in your own environment, it is very likely that you would want at least two appliances. Perhaps you want to have a standby appliance in case of a failure on the main appliance, or maybe you have different teams that are looking to utilize the appliance in different data centers. In any case, once you install multiple appliances there's another requirement that will pop up pretty quickly. Naturally you are going to want to share custom artifacts among the various WebSphere CloudBurst boxes.
When I say custom artifacts, namely I mean virtual images, patterns, and script packages. Script packages have been easy enough to share since WebSphere CloudBurst 1.0 because you can simply download the ZIP file from one appliance and upload it to another. However, there are some enhancements in WebSphere CloudBurst 1.1 that make it easy to share both patterns and images among your different appliances.
As far as patterns go, there is a new script included in the samples directory of the WebSphere CloudBurst command line interface package called patternToPython.py. This script will transform a pattern you specify into a python script. The resulting python script can then be run against a different WebSphere CloudBurst (using the CLI), and the result is the pattern is created on the target appliance. You need to be sure that the artifacts that pattern references (script packages and virtual images) exist on the target appliance and have the exact same name as they do on the appliance from which the pattern was taken. There are no other caveats, and this new sample script makes it really simple to move patterns between appliances.
For virtual images, a new feature was added that allows you to export a virtual image from the WebSphere CloudBurst console. Simply select a virtual image, specify a remote machine (any machine with SCP enabled), and click a button to export the image as an OVA file. This OVA file can then be added to another WebSphere CloudBurst catalog using the normal process for adding virtual images. You can see this feature in action here.
Stay tuned for more information about some of the handy new features in WebSphere CloudBurst 1.1. We also should have a comprehensive look at the new release coming soon in a developerWorks article.
I want to clear something up about WebSphere CloudBurst that can sometimes cause a bit of confusion. In nearly all of our content about the appliance, we talk about it in the context of building private clouds consisting of WebSphere application environments. Typically people think of private clouds as something only those within their organization can access and utilize. However, with WebSphere CloudBurst you are not limited to creating that kind of a private cloud.
Perhaps it is more fitting that we talk about WebSphere CloudBurst as a means to create on-premise clouds. After all, that's really what we mean. You create a shared pool of hardware and network resources owned by your organization, and then you define this cloud of resources to WebSphere CloudBurst. Once that cloud is defined, you can leverage WebSphere CloudBurst to dispense your WebSphere application environments into that cloud. The accessibility of your application environments running in that cloud is entirely up to you.
You may decide that the cloud is indeed private and that only those in your organization or a smaller subset of users can access the environments. On the other hand, you may decide that you want to allow consumers in the public domain to request WebSphere application environments and then have WebSphere CloudBurst provision those environments into a public cloud. I say public here because while the cloud's resources are on your premise, access to that cloud is not restricted to within the organizational firewall. Ultimately, the determining factor for whether or not your WebSphere CloudBurst cloud is public or private is the network configuration you provide. If the virtual machines are associated with network resources that are publicly accessible, then I would say you have a public cloud.
I hope this entry didn't serve to only add to the confusion. The bottom line is this: WebSphere CloudBurst allows you to create, deploy, and maintain virtualized WebSphere environments in an on-premise cloud. Whether that cloud is public or private is entirely up to the network configuration that you setup.
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.
Users of cloud computing solutions today expect to be charged for exactly the amount of compute resource they use. No more, no less. This expectation is often at the forefront of our customers' minds when contemplating the creation of internal or private clouds. They want to be sure that any solution they use audits the activity and usage of their cloud and enables them to consume this information to implement their specific chargeback scheme.
Thought it's not a feature we always seem to talk about, WebSphere CloudBurst provides the necessary capabilities to properly allocate costs to users, teams, and organizations. To start with there are some handy usage reports that you can view directly from the WebSphere CloudBurst console. For instance, as seen below, a WebSphere CloudBurst administrator can see a break down of cloud resource usage for each user of the appliance.
While the capability illustrated above is nice, it is likely that if you are implementing an enterprise-scale chargeback scheme you want to automate the processing of the usage data, thus implying the need to programatically consume such data. WebSphere CloudBurst enables you to do just this by way of its audit log. The WebSphere CloudBurst audit log is a record of each and every action taken in the appliance, along with information about who took the action, when the action was taken, what object the action was taken on, and much more. You can instruct the appliance to generate this file for a specified date range, and the output is a comma separated value file that can then be consumed in a manner of your choosing.
As an example of some of the things you can do with this data, I recently wrote a Java program that parsed the audit file and for each virtual system determined who created it, who deleted it (if it had been removed), and the duration of its existence. This program was simple (more of a string parsing exercise than anything else), but nonetheless provided necessary function and output for billing schemes based on hours of usage. If you are interested in how this was done please let me know and I'd be happy to discuss details. In the meantime, if you have any thoughts you can reach me on Twitter via @WebSphereClouds.
A recent announcement signaled the coming release of WebSphere CloudBurst 1.1. This new release of the WebSphere CloudBurst Appliance delivers enhancements to all phases of the lifecycle of virtualized WebSphere Application Server environments. Let's take a closer look at a few of these updates.
First and foremost, WebSphere CloudBurst 1.1 delivers support for the PowerVM platform. You can now deploy patterns to create virtualized WebSphere Application Server environments running in a PowerVM environment on pSeries servers. Among other things, this is enabled by a new version of the WebSphere Application Server Hypervisor Edition. This new version of the virtual image contains an AIX operating system and has been specifically bundled to allow it to be activated on the PowerVM hypervisor. From a user standpoint, building, deploying, and maintaining WebSphere Application Server environments is done from the same console with the same look and feel regardless of the target platform. Check out this demo to see WebSphere CloudBurst and PowerVM in action.
In addition to support for PowerVM environments, WebSphere CloudBurst 1.1 will also provide a trial edition of a DB2 virtual image. You can import this image into your WebSphere CloudBurst catalog and then use it to build and deploy DB2 environments. This allows you to, from the same centralized interface, deploy and integrate both your application and data environments in your private cloud. Check out this demo for more information on the new DB2 trial virtual image for WebSphere CloudBurst.
One other cool feature I want to point out delivers an enhancement to the use of script packages in WebSphere CloudBurst. In this new version of the appliance, you have more control around when script packages you include in a pattern are executed. Previously, these were executed toward the end of pattern deployment once all the necessary WebSphere Application Server components had been started. While that is still the default behavior, you can also elect to have the script package invoked when the virtual system is deleted, or you can choose the invocation to be user-initiated meaning that you decide when and how many times your script runs. To check out a pretty handy use case for this feature, watch the demo here.
These aren't the only new features and enhancements delivered in WebSphere CloudBurst 1.1. Stay tuned for more demonstrations and more words about these new features and when and why you would want to use them. In the meantime, if you have any questions be sure to stop by our forums.
There have been quite a few announcements from IBM lately that keep referring to the "IBM Cloud". Since IBM has been moving at a pretty substantial pace with cloud offerings as of late, I thought it may help to give readers a concise idea of exactly what the IBM Cloud provides.
Put very simply, the IBM Cloud is a public cloud offering that allows users to provision and utilize IBM Software on an infrastructure hosted by IBM. From the IBM Cloud's web-based dashboard, users choose a software package, provide some deployment information about the particular instance they wish to create, and then simply click OK. In a matter of minutes the software is up, running, and available for full use. At the time I wrote this blog, I saw software from our Information Management, Rational, and WebSphere brands available for use. In addition, users can launch plain SUSE Linux instances out onto the IBM Cloud.
Within WebSphere, users can choose from either the WebSphere Application Server or WebSphere sMash. I just went through a WebSphere sMash deployment, and in about 6 minutes the sMash instance was up and running, and I was able to log into the App Builder development environment. The WebSphere Application Server package that's available on the IBM Cloud is particularly interesting because it contains an embedded Rational Controller Agent. This makes it very easy to integrate some of the Rational offerings on the IBM Cloud (or elsewhere) with the WebSphere Application Server. Many of these integration scenarios focus on making it easier to very quickly build, package, and deploy applications from Rational development tooling to WebSphere Application Server environments.
The best thing about the IBM Cloud is that you can sign up and give it a whirl with absolutely no costs! Go and sign up for a free account and you'll immediately be able to spin up IBM Software in IBM's cloud. You can access and use that software, and then when you are done you can simply delete the running instance. There's no need to download anything to your computer, the interface to the IBM Cloud is completely web-based, and the launched software runs on IBM infrastructure. All of this adds up to give users a super easy way to kick the tires on some of our software. Sign up now by visiting the landing page for the IBM Cloud.
One of the things I haven't written about much here is how the WebSphere CloudBurst Appliance integrates with other IBM software solutions. One of those interesting integration scenarios, and one I think is particularly useful for developers, involves Rational Build Forge.
Very simply put, Rational Build Forge is an adaptive execution framework that allows users to define completely automated workflows for just about any purpose. These workflows are represented as projects that contain a discrete number of steps. When looking at Rational Build Forge through the software assembly prism, the offering allows users to fully automate and govern the process of building, assembling, and delivering software into an application environment.
Now, on to the integration of WebSphere CloudBurst and Rational Build Forge. Users can build custom patterns in WebSphere CloudBurst that include a special script package (which I'll eventually provide a link to from here). This script package provides the glue between the deployment process in WebSphere CloudBurst and Rational Build Forge. When deploying a WebSphere CloudBurst pattern that contains this script package, users provide the name of a Rational Build Forge project as well as information about the Rational Build Forge server on which the project is defined.
Once the necessary information is supplied, the deployment process gets underway. Toward the end of the deployment, like all other scripts included in patterns, the special Rational Build Forge script is invoked. This results in the project specified during deployment being executed on the virtual machine created by WebSphere CloudBurst.
Because the Rational Build Forge project executes on a virtual machine setup by WebSphere CloudBurst, the individual steps of the project can very easily access the WebSphere Application Server environment. Thus, the Rational Build Forge project could very easily contain steps to build, package, and deploy an application into the WebSphere Application Server cell. The result is a fully automated process that includes everything from standing up the application environment to delivering applications into that environment.
I put together a short demonstration of this integration, and you can take a look at it here. As always, please let us know if you have any questions or comments. Your feedback is much appreciated!
If you've attended one of our WebSphere CloudBurst sessions then you've undoubtedly heard us talk about the "special sauce" or "WebSphere intelligence" delivered by the WebSphere CloudBurst Appliance. If you haven't attended one of our sessions, trust me, we talk about it a lot, but there's good reason. This "special sauce" truly sets WebSphere CloudBurst apart from other virtualization management tools.
Essential to the uniqueness of the WebSphere CloudBurst solution is the WebSphere Application Server Hypervisor Edition virtual image that it dispenses. In one sense, the intelligence comes in the format of pre-installed, tuned, and configured software. The operating system and WebSphere components are all pre-installed, and the WebSphere Application Server configuration is tuned based on best performance practices. In addition, the image comes with a pre-configured instance of each WebSphere Application Server profile type that is available in the version that is bundled. This saves time during deployment since the unneeded profiles are simply removed.
The pre-installed, tuned, configured software only sets the foundation for what truly sets apart the WebSphere CloudBurst solution. The activation framework built inside of the WebSphere Application Server Hypervisor Edition allows WebSphere CloudBurst to deliver unique value. This activation framework allows the single virtual image to turn into many different flavors of WebSphere Application Server (Dmgrs, Standalone nodes, Custom nodes, Job Managers, etc), and it provides the facilities to change WebSphere cell and node names, IP addresses, host names, and more while a running virtual machine instance is being created.
On a mostly unrelated topic, the changing of WebSphere cell names, node names, host names, is done with documented, publicly available commands in either wsadmin or other WebSphere Application Server binaries. I know many customers want to do this exact same thing in their existing environments, so if you are wondering how it is done, drop me a line below.
Anyway, I won't get into anymore detail here because you can get a much better assessment of this special sauce elsewhere. Ruth Willenborg, one of the lead architects for the WebSphere CloudBurst Appliance, did a developerWorks Comment lines piece about this special sauce. Ruth provides a deeper look at the topics I hit on above, and it's a really good read. You can check it out for yourself here.
I've blogged previously about some of IBM's work in the public cloud and specifically on our partnership with Amazon to deliver IBM offerings on the Amazon EC2 cloud. Mostly on this blog I've been focused on IBM WebSphere offerings on the Amazon cloud, but coming up on October 1st, you'll get a chance to hear about and see the full breadth of IBM software offerings available on the Amazon EC2 cloud. Better than simply hearing and seeing, by attending the virtual developer's day, you'll get access to try out some of this software absolutely free!
By leveraging IBM software on Amazon EC2, users can very quickly benefit from the advantages of a cloud computing approach to IT. Instead of focusing valuable time and resource on installing, updating, and otherwise maintaining software, users can simply activate instances of the IBM software of their choosing on Amazon's infrastructure. Besides delivering this rapid approach to getting up and going, users can also leverage cloud computing techniques to quickly and dynamically scale up and down their entire application infrastructure. This ability to dynamically scale up and down means your end-users will always enjoy a satisfactory experience when accessing your applications on the cloud.
You can sign up for the Cloud Computing for Developers day here. In the meantime you can learn more about IBM offerings on the Amazon EC2 cloud by visiting the IBM/Amazon EC2 landing page. I hope you can take advantage of a chance to hear both IBM and Amazon experts and learn how IBM software delivered on the Amazon EC2 cloud can make a real difference for your business.
Over the last three posts I've been discussing a few of the most frequently asked questions regarding the WebSphere CloudBurst Appliance. I'd like to wrap up today with a fourth and final installment.
If you have read some of my entries before, or if you have read any of our WebSphere CloudBurst articles on IBM's developerWorks, then you know that the appliance brings extreme simplification and safety to applying fixes and service level upgrades to running WebSphere Application Server virtual systems. Users select a virtual system, choose a fix or service level upgrade, and then WebSphere CloudBurst drives the application of the fix or upgrade to the system. Before applying the fix or upgrade, the appliance takes a snapshot of the virtual system, and users can simply click a button to roll back to the previous state if the process produces undesired results.
This is a pretty strong value add to WebSphere Application Server management and one that our users typically immediately understand. Almost always though, after users see this they are curious about another aspect of rolling out fixes and upgrades in WebSphere CloudBurst. In particular, they want to know how they ensure that all subsequent deployments (after applying the fix to a specific virtual system) can be ensured of having the correct fixes and service levels.
The answer to this inquiry is that there are a couple of different ways to achieve this, and it depends on what you are try to accomplish and your preferences. For instance, if you want to make sure all of your subsequent deployments have a particular interim fix, you will likely go the route of image extension. First, you pick the WebSphere Application Server Hypervisor Edition image in your catalog to which the fix applies. Next, you extend that image, and once a virtual machine based off the image is accessible, you use existing WebSphere Application Server tools (Update Installer) to apply the fix. After the fix has been applied, you can capture the updated image and then use it as the basis for patterns created from that particular version of the WebSphere Application Server.
On the other hand, if you are looking to ensure subsequent deployments are based on a new level of the WebSphere Application Server, your process will be a bit different. First you would load a new WebSphere Application Server Hypervisor Edition image (based on the new level of WebSphere Application Server) into your WebSphere CloudBurst catalog. Then you would select any of your customized patterns you wanted to upgrade to the new level, clone that pattern, and simply select the new image as the basis for the pattern. All of your other customizations are preserved. Really, it's that simple!
I hope that over the last month I have answered some of the more common questions about WebSphere CloudBurst. At any point if you have any questions feel free to email me or leave a comment right here on the blog.
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!
To continue with the series of blog posts regarding WebSphere CloudBurst FAQs, I want to take a look at one aspect of the deployment process.
When you leverage WebSphere CloudBurst to push patterns (complete WebSphere Application Server configurations) into a private cloud, the appliance provides an advanced placement algorithm to determine exactly where the resulting WebSphere virtual systems will reside. It attempts to match the needs of the pattern to the correct set of hypervisors that have been defined. WebSphere CloudBurst considers things like storage, CPU, memory, and high availability characteristics when placing the pattern, and this is all done by the appliance without you having to intervene at all.
This is certainly nice in that it absolves you from having to make such placement decisions. Having said this though, you may be thinking of a question that comes up quite often:
If WebSphere CloudBurst controls the placement of the pattern, how can I make sure that certain deployments end up on certain servers (hypervisors)?
Considering what I just told you above, it may not seem that it's possible to control what machines end up hosting your virtual system since the appliance takes care of that placement for you. However, the organized use of WebSphere CloudBurst cloud groups allows you to take advantage of the intelligent placement provided by the appliance while retaining a level of control over which machines end up hosting particular deployments.
In WebSphere CloudBurst all patterns are deployed to cloud groups. Cloud groups are a collection of hypervisors that have been defined within the appliance. The basic deployment mapping is depicted in the image below:
As seen above, you can create a cloud group for any purpose (dev, test, QA, production, etc.), including any hypervisors that you desire as long as a given hypervisor only belongs to a single cloud group. When you are ready to deploy a pattern, you simply select the cloud group you want to deploy to:
By selecting a cloud group for deployment, you are implicitly selecting the physical machines that will host your deployment. The cloud group could consist of anywhere from one to N hypervisors, so you are afforded the ability to restrict the location of your virtual systems as necessary.
I hope this helped explain a little bit about cloud groups in WebSphere CloudBurst. If you're looking for more information about WebSphere CloudBurst cloud groups, I'd also suggest you watch this video on our YouTube channel.
IBM trekked further into the cloud today by announcing new offerings that will help clients to leverage the cloud within their enterprise. These offerings include development environments, test environments, and desktop services running either in the IBM cloud or a private cloud, as well as something called IBM CloudBurst (not to be confused with the WebSphere CloudBurst Appliance).
In particular, the IBM CloudBurst offering jumps out to me as a truly innovative offering. This offering promises our clients a complete private cloud solution that includes hardware, software, and services all in a single package.
Essentially it sounds like the IBM CloudBurst offering is all about building out a cloud-enabled data center. The hardware provides the bulk computing power to host private clouds, and the software provides enhanced service management capabilities to give users full control and insight over the elements of their private cloud.
Couple these computing capabilities with included IBM service, and this means clients should be able to get up and going with their private clouds very quickly.
This new offering really seems to hit a sweet spot. While the number of cloud computing offerings continues to grow, few if any offerings take such a holistic approach to providing such a solution.
This type of comprehensive solution gives users what they need in terms of the hardware to host a private cloud and the software to manage that cloud. Just as importantly though, it helps users put the hardware and software to work via implementation services also offered in the solution.
I invite you to take a look at the new IBM CloudBurst offering, and don’t forget to sign up for the IBM CloudBurst webcast scheduled for June 25th.
If you work in a development shop similar to mine, you and many of your coworkers have more than one workstation under your desk.We use those extra machines for a variety of reasons but by and large they they tend to serve most often as foot warmers. That is not to say that they are unnecessary but rather they simply aren't used most of the time. If you try to eliminate one, you will surely need it within the next week but if your manager asks if it is really necessary you would be hard pressed to pinpoint precisely when the last time it was used for something really important. To developers, these extra machines are potential sandboxes for isolated experiments or testing scenarios. For managers, they are relatively unused capital investments that require inventory control and have depreciating value. If you are a network administrator there are certainly computers in your inventory that are older and lack the capacity to be counted on for everyday use. They sit in a corner or in a blade rack and are probably idle or even powered off. These assets take up physical space and contribute very little to your data center. However, they have little sale value but may represent a significant investment. Or maybe you just can't part with them for sentimental reasons.
Whatever the reasons for having computing resources lying around that are seldom used, here is an idea: Virtualization. With virtualized images you can use those machines for whatever purposes are required and for as long as they are required without having to spend hours loading them with a compliant OS image, installing software and configuring them for use. Virtual image libraries could hold preinstalled systems for almost any need. It could be for anything:
Workstations provisioned for temporary workers
More server capacity
More machines or load testing
Extra processors for parallel processing systems
Back up systems to carry loads during maintenance hours
If you use WebSphere in any capacity, CloudBurst can be used to lay in place a completely functioning WebSphere install in as little as 20 minutes, OS and all.
When the need for the machine is passed, it can be un-deployed and returned to the pool. This could significantly increase the available computing power of an entire development business. The ability to turn any machine into a needed and useful system on demand is real agile computing and gives a whole new dimension to governance.
WebSphere CloudBurst delivers out-of-the-box capabilities in the form of pre-built WebSphere Application Server configurations, or patterns, which are ready to be deployed to a private cloud. These pre-built patterns range from a single server topology to more complex, clustered topologies. In addition, these patterns have been tuned to produce hardened, best-practice environments. For users, this means once they have the appliance setup, they can immediately begin building a private WebSphere cloud.
The out-of-the-box capability of WebSphere CloudBurst is extremely useful, but what about the situations where those patterns don't align with a user’s needs? What if a user needs to create a highly customized WebSphere environment? Not to worry, WebSphere CloudBurst was built with a focus on bringing customization capabilities to the user. These customization capabilities cover the full WebSphere middleware environment, from the operating system to user applications.
To start with, WebSphere CloudBurst allows users to modify the virtual images that are shipped with the appliance. These virtual images contain the operating system and WebSphere components that are used to build the WebSphere patterns. A perfect use-case for this is if a user needs to install custom software to be used in all of their WebSphere environments.
For instance, if a user wanted to install a JDBC driver that was to be used by each of their WebSphere deployments, they would simply extend one of the shipped virtual images, install the JDBC driver, and then recapture the image. Once the image was recaptured, it could be utilized to build the WebSphere patterns that represent the complete WebSphere middleware environment. By using this virtual image to build patterns, users are assured the JDBC driver will be present in each and every WebSphere deployment to their private cloud.
Another common customization is a change to the WebSphere topology in a pattern. If a user has a particular cluster environment that is different from the shipped WebSphere cluster patterns, they could simply clone the shipped cluster pattern, make any needed topology changes, and then save their new pattern.
The best thing about this process is that the topology changes are done via a slick GUI interface. Users can construct WebSphere topologies by simply dragging and dropping WebSphere components (i.e. stand-alone servers, deployment managers, web servers, etc.) onto a canvas! Once the pattern is constructed and saved, it can be reused as many times as necessary.
Patterns can also be customized to include user applications or other WebSphere configuration tuning. Script packages are compressed files (ZIP or TAR) that are constructed by users to alter the WebSphere environment. These packages might contain an application and scripts to install the application, or it could contain a script to tune or enhance the environment created by WebSphere CloudBurst.
The beauty of script packages is that they can do just about anything. Users tell WebSphere CloudBurst how to execute the script package (i.e. “Call the installApp.sh script in my script package”), and that execution takes place at the end of the pattern deployment. The result is a dispensed WebSphere environment that has been customized according to the script package contents.
There’s more to WebSphere CloudBurst customization capabilities than what I talked about above, including the ability to customize each and every deployment of a pattern, and the ability to align these customization activities with organizational responsibilities. To find out more about these capabilities, check out the demos on our YouTube channel or send us an email at email@example.com. Stay tuned to the blog for more information about the WebSphere CloudBurst Appliance.
Dustin and i manned the IBM booth at InterOp in Las Vegas last week. The conference was very different from the industry conferences I remember, but then again I haven't been to one in a long time. I don't recall seeing boxing matches, light shows or bikini models but I think they are a welcome addition.
Ostensibly this conference was focused on cloud computing and was even called the "Cloud Summit". However, in the vendor area, there were few real cloud computing specific peds. Most of the vendor displays were about hardware, system monitoring and security.
Ric Telford of IBM gave a keynote address and sspoke of IBM's cloud offerings. After the keynote, there was a flurry of visitors asking about IBM, Cloud Computing and IBM's cloud offerings. Most of the visitors were looking for education and we were happy to have the opportunity to talk about the company and cloud computing from IBM's perspective.
We had the CloudBurst Appliance with us and it drew some interest. The purple case definitely stood out and drew inquiries. Some excitement is being generated but I think now the industry and the market has to catch up to us.
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.
The recently announced IBM WebSphere CloudBurst Appliance is creating a fair amount of stir in the cloud computing market. Its ability to create, deploy, and administer private WebSphere cloud environments gives customers the ability to create and manage a services oriented cloud. To provide a more in-depth look at what the appliance delivers, I’d like to take a short look at the creation, deployment, and administration capabilities to understand what each one means to the user.
To get started, in order to leverage WebSphere environments in a private cloud, you need to construct WebSphere configurations optimized for such a virtual environment. Using WebSphere CloudBurst you can do just that. WebSphere CloudBurst ships a virtual image packaging of the WebSphere Application Server called WebSphere Application Server Hypervisor Edition. From this new virtual image offering, complete WebSphere Application Server topologies can be constructed to create what WebSphere CloudBurst terms a pattern. These patterns are representations of fully functional WebSphere Application Server environments. For example, using WebSphere components in the WebSphere Application Sever Hypervisor Edition, you can create a cluster environment that includes a WebSphere Deployment Manager, two customs nodes, and the IBM HTTP Server.
In order to create these patterns, WebSphere CloudBurst provides a drag-and-drop interface that allows users to select WebSphere components from the new virtual image and drop them onto a canvas that visually represents the WebSphere configuration. In addition to adding WebSphere components, users can also drag and drop script packages onto the components within a pattern. These script packages allow users to provide scripts and other artifacts that further customize the WebSphere Application Server environment once it has been deployed in the cloud. These script packages can do just about anything, from tuning WebSphere security settings to installing applications in the newly created environment.
Building the virtualized WebSphere Application Server environment, or pattern, is only part of the process. Once the pattern is built, it is ready to be deployed to the cloud. WebSphere CloudBurst operates on a ‘bring your own cloud’ model, so the cloud resources are defined to the appliance. These cloud resources consist of a set of supported hypervisors and a list of IP addresses available to the cloud. Once these resources are defined, WebSphere CloudBurst has all the information it needs for deployment. On deployment of a pattern, WebSphere CloudBurst determines the state of the available resources, and places the pattern across the available hypervisors accordingly. It places the WebSphere instance to ensure efficient use of resource, high performance, and high availability. In addition to placing the pattern instance onto the hypervisors, WebSphere CloudBurst selects and assigns an IP address to each WebSphere component in the configuration. Both the placement and IP address assignment are done with no user input or intervention. The result of the pattern deployment is a fully instantiated WebSphere environment that can be accessed and used like any other such environment. It is important to note that the WebSphere environments do not run on the WebSphere CloudBurst Appliance, and in fact the appliance plays no role in the runtime of the environments.
While it is true that the WebSphere CloudBurst Appliance is not involved in the runtime of the patterns that it deploys, it does provide users the capability to monitor and administer these environments. From the WebSphere CloudBurst console, each of the WebSphere virtual systems can be viewed to understand network configuration, memory consumption, and CPU usage. Usage of cloud resources (i.e. memory, CPU, IPs) is also tracked at a user or user group level allowing WebSphere CloudBurst to support chargeback across an enterprise. In addition to these monitoring capabilities, maintenance features are part of the appliance’s administration story. WebSphere CloudBurst provides users with a central administration point for applying maintenance, such as iFixes and service packs, to the WebSphere virtual systems it created. These fixes can be applied within the WebSphere CloudBurst console with only a few mouse clicks providing an unprecedented ease of maintenance application.
The above is only a glimpse at the capabilities of the new IBM WebSphere CloudBurst Appliance. Look for more information about this offering at ibm.com/cloudburst, and stay tuned to our blog, twitter account (@WebSphereClouds), and websiteas we continue to deliver insight into WebSphere CloudBurst.
Alas, the wait is over! WebSphere is jumping head first into the cloud computing fray. The announcement today of two new offerings means that companies will be able to build and benefit from private WebSphere clouds. In addition, to these new offerings, IBM also announced two more WebSphere products headed to the Amazon Elastic Compute Cloud.
To start, the new WebSphere Application Server Hypervisor Edition is a virtualized packaging of the popular WebSphere Application Server platform. The virtual image includes a Linux operating system, WebSphere Application Server, and IBM HTTP Server all pre-installed and packaged according to the Open Virtualization Format (OVF). There are six different WebSphere Application Server profiles pre-configured on the image, which allow the virtual image to take many different forms when deployed to a hypervisor. The image supports unattended activation, meaning the virtual image can be deployed to a hypervisor and configured with activation scripts. This feature allows the deployment process to be fully automated. WebSphere Application Server Hypervisor Edition allows users to reap the benefits from virtualization and realize a higher level of business agility with their WebSphere Application Server environments due to the radical ease of deployment.
In addition to WebSphere Application Server Hypervisor Edition, IBM announced the WebSphere CloudBurst Appliance. The WebSphere CloudBurst Appliance is a secure hardware appliance that allows users to construct, store, deploy, and maintain private WebSphere cloud environments. WebSphere CloudBurst delivers WebSphere Application Server configurations including the operating system, which are optimized for virtual environments. These configurations, or patterns as they are called by WebSphere CloudBurst, can be customized by users to build WebSphere Application Server configurations that include the operating system, middleware, and user applications. WebSphere CloudBurst allows users to deploy these patterns to their private cloud, and it provides maintenance and administration capabilities for the deployed virtual systems. In short, WebSphere CloudBurst provides capabilities to manage the entire lifecycle of private WebSphere cloud environments.
The announcement wasn't all about private clouds. IBM also announced its intention to make the WebSphere Application Server and WebSphere eXtreme Scale offerings available as Amazon Machine Images. These AMIs will allow users to utilize both the WebSphere Application Server and WebSphere eXtreme Scale on Amazon's Elastic Compute Cloud (EC2).
It's clearly an exciting and innovative time for cloud computing in WebSphere. Stay tuned to our blog and WebSphere Cloud Computing for Developers site for more information and resources on these new offerings. In the meantime, check out the WebSphere Application Server Hypervisor Edition page and the WebSphere CloudBurst page for more information and live demos!
I recently read the Open Cloud Standards incubator charter proposed by the Distributed Management Task Force (DMTF), and I think this is a great effort to propel the cloud computing effort forward (read the charter here). In the interest of disclosure, I’m not just saying this because I happen to be employed by one of the supporters of the movement. It’s time to acknowledge that open standards are not an inhibitor to innovation, but instead they facilitate the kind of technological adoption that makes innovation both possible and profitable.
The incubator charter sets its eyes on standards around cloud resource management. Its main focus will concern the management of cloud computing elements that make up the Infrastructure as a Service (IaaS) layer, but it will also discuss some elements of the Platform as a Service (PaaS) layer. The charter lists among its deliverables a cloud taxonomy, cloud interoperability white paper, informational specifications, and security requirements for cloud resource management. The hope is that such standards would increase cloud interoperability, mitigate the potential for vendor lock-in, and guide companies who already deliver resource management products and are looking to extend such capabilities to cloud resource management.
In particular, there are a couple of deliverables that sound interesting. The first, a cloud taxonomy including terms and definitions, is a necessary step to move forward any cloud computing standardization efforts. There is too much disagreement among the cloud industry at large as to exactly what defines and makes up cloud computing. While healthy discussion and debate on this subject are good, it is time to agree on a standard definition that all can at least accept. Without a common, acceptable definition, standards movements will be crippled since it’s hard to govern something we cannot define.
The charter also proposes information specifications that would define profiles for the management of resources within a cloud computing environment. If these types of management standards were produced and subsequently adopted by a multitude of cloud providers, consumers could define a common cloud interaction layer and freely switch in and out the provider. In addition to these new specifications, updates to existing standards in DMTF are among the deliverables. The existing specification that is explicitly called out in the charter is the OVF packaging standard. I can only hope this means a standard packaging for virtual images deployed in a cloud environment. If that is indeed the goal, by combining a common cloud management mechanism with a common cloud packaging strategy, consumers would be provided the ultimate choice among cloud providers. They could package and deploy services meant to run in the cloud in such a way that the task would be repeatable across any cloud provider adopting the DMTF’s standards. In addition, the mention of updating existing specifications sends a clear message that cloud computing standardization efforts must not duplicate existing standards work. Instead, new specifications are introduced where necessary, and existing specifications are updated to accommodate this new computing paradigm.
I’m excited about the incubator charter announced by DMTF. I’m sure this is just the beginning in what will be a long journey of providing for an open cloud, but it is a necessary first step. I for one don’t buy the argument that open standards stifle innovation. Instead, I believe open standards increase technological adoption, and more consumers mean more opportunities, and demand, to distinguish offerings by creative innovation. What do you think about cloud computing standards? Let us know below, or send us an email.