Before you start
About this tutorial
In this tutorial, the authors demonstrate how to use WebSphere® CloudBurst to build patterns you can use to represent the configuration of both your application and application infrastructure. They also show you how to use these patterns to consistently deploy the application environment as it moves through the four life-cycle stages — development, test, quality assurance, and production. The tutorial offers a complete, step-by-step example of using patterns to handle changing topologies, underlying platform architectures, and configuration properties.
Our goal with this tutorial is to:
- Show you how to use CloudBurst to build patterns that can represent the configuration of your application/application infrastructure.
- Show you how to use these patterns to deploy the application environment in a consistent manner, regardless of what life cycle stage you're engaging (development, test, QA, production).
- Make you familiar with these types of patterns so you can use them in similar tasks.
The information in this article will be more meaningful to developers with some understanding and experience with the WebSphere CloudBurst Appliance, pattern creation, and cloud computing application development; however, since this tutorial is both about specific steps to build patterns to aid in cloud application/application infrastructure migration and the concepts involved in these tasks, those without specific knowledge of the software products we use can also benefit.
To absorb the concepts we expose in this tutorial, all you need is your good developer brain. However, if you wish to replicate these exercises, you will need access to a WebSphere CloudBurst Appliance with permissions to create catalog content, create patterns, and deploy patterns.
First, some background
Why define consistent configurations?
Organizations are confronted with the challenge of deploying applications and the associated infrastructure into different environments. For example, most applications move through some type of promotion chain that includes moving the application and the infrastructure it depends on from development to test and eventually to production. In each stage, you install and configure the application and application infrastructure — this process is often time consuming and may include manual elements.
Of even more significance, each time you reinstall and configure the application and associated infrastructure to support a migration, there is an opportunity for bugs to be introduced, notably unknown or unintended changes added to the configuration of the application or its platform. When these types of bugs are introduced, the cause is often difficult, if not all but impossible, to detect. This results in the common phenomenon: "It used to work; what changed?"
The IBM WebSphere CloudBurst Appliance provides the ability to define consistent configurations for your infrastructure and applications. WebSphere CloudBurst also supports moving them from one environment to another:
- You use the appliance to build patterns that capture your application infrastructure, applications, and configuration.
- These patterns are saved on the appliance and deployed repeatedly, providing consistency of the resulting application environments.
- You parameterize the patterns to shape the application environment for the stage you are deploying.
WebSphere CloudBurst's unique combination of images and patterns provides for expedited deployment, measured in minutes instead of days or weeks. The result is a fully configured, repeatable application environment ready for your use at a moment's notice.
What is the life cycle?
Most applications move through multiple stages including development, test, and production. If each environment was identical, getting consistent and repeatable deployments might not be that difficult; however, in most IT shops there are differences in the hardware available, the software configurations, and the back-end resources in use. This results in required configuration changes at each stage in the life cycle, making it impossible to copy a configuration directly and making it difficult to distinguish and track required configuration changes from undesirable changes that introduce problems.
Let's look at a common set of changes that applications and supporting infrastructure might go through across the life cycle and we'll discuss how to use WebSphere CloudBurst features to simplify the management of these changes to provide very repeatable deployments. Some typical changes include:
- Different infrastructure topologies.
- Different hardware platform architectures.
- Different configuration settings.
- Different resources.
Different infrastructure topologies
Though virtualization makes it possible to more easily replicate multinode production topologies for development and test without requiring as much capital outlay, many still prefer simpler topologies for the earlier stages of the life cycle. For example, WebSphere development environments commonly consist of a single virtual machine containing deployment manager, Web server, and custom node. The same infrastructure components are present as the application moves through the life cycle; however, later stages split these components across multiple virtual machines.
The following figure shows a typical progression with the all-in-one development environment moving to a multinode test topology with the application server nodes separated and formed into a cluster, then later moving to separate the Web servers into a DMZ for final quality assurance and production purposes.
Each distinct topology maps to a pattern in CloudBurst
In WebSphere CloudBurst, each of the distinct topologies map to a pattern. Therefore, as you will see in the example, the life cycle in the figure has three unique patterns. The pattern-creation process copies the preceding pattern to assist in maintaining any configuration information and specifically any of the unique scripts.
Different hardware topologies
Another life cycle change may be the hardware architecture platform of choice. For a variety of reasons, WebSphere development is sometimes on a different platform from production or there may be multiple development, test, and production platforms in use.
For example, the previous figure shows development and test environments on VMware and QA and Production on PowerVM. WebSphere CloudBurst topology definitions are platform independent allowing the same pattern definition for deployment to different platforms.
The images, of course, are platform unique; therefore, as the scenario will show, to move the same pattern from VMware to PowerVM, you just make a copy of the pattern and choose the image corresponding to the new platform. When copying a pattern for another platform, you will need to account for any platform-unique scripts you have developed and make the necessary changes.
Different configuration settings
Configuration settings also require changes for different life cycle deployments. One of the promises of virtualization — to copy a virtual machine and reuse it — butts against the challenge that identical copies present conflict. At a minimum, names, passwords, and other settings often need to change to avoid conflicts.
WebSphere CloudBurst patterns expose parameters that allow for configuration changes when starting virtual machines. During the pattern-creation process, you can either lock these values into the pattern or allow them to be altered at deploy time. For example, if you want a specific cell name, you can lock this value into the pattern; if you want to use the same pattern with different cell names, you can leave it for deploy-time specification.
Most WebSphere applications talk to something (such as databases, directory servers, etc.) and the location of these resources is likely different from within the development, test, and production environments. For example, the quality assurance environment most likely contains some test database, modeled or replicated off the production data. WebSphere CloudBurst scripts allow you to define parameters. Adding such a script to a pattern automatically exposes the parameters as part of the pattern or deployment configuration. Script parameters provide a great deal of flexibility for keeping patterns common while allowing for switching the resource location.
When you develop your scripts, you can add parameters for resource connections that change through the life cycle. WebSphere CloudBurst automatically adds the parameters to the pattern and you can choose to specify the parameter values when you define the pattern or maintain flexibility in the pattern by leaving the parameter value specification until deploy time. For example, to reuse the same pattern for different resources, just make the location a script parameter and specify this value at deploy time.
In the example scenario that follows, we use this technique for both the database location and the application location. This same technique is also useful for any application specific configuration settings.
The sample scenario
Now we'll look at an example scenario implementing each of these concepts using WebSphere CloudBurst. In this example, the application infrastructure will be a clustered WebSphere Application Server environment. The environment consists of the following nodes and application servers:
- One deployment manager node.
- Two custom nodes federated to the deployment manager. Each node contains a single application server instance and the application servers belong to a cluster.
- One IBM HTTP Server node.
In addition to the basic WebSphere Application Server topology, we also have a Java™ 2 Platform, Enterprise Edition (J2EE) application (which we will call Account Management) installed on the application server cluster. This application has a dependency on an external IBM DB2® database instance and the configuration of that dependency is different in different settings.
Figure 1 illustrates the application environment we just described.
Figure 1. Example application environment
In our scenario, we will show how you can use WebSphere CloudBurst to create and manage this environment as it is moved from development to test to quality assurance and then finally on to a production setting. This includes the following steps:
- Create the necessary WebSphere CloudBurst script packages.
- Create the initial WebSphere CloudBurst pattern for development settings.
- Migrate and deploy the application environment to a test setting.
- Migrate and deploy the application environment to a QA setting.
- Migrate and deploy the application environment to a production setting.
During each migration and subsequent deployment, we will illustrate the ease with which you can make slight changes to the setup without compromising the overall integrity of the resulting application environment. These changes will include alterations to the WebSphere Application Server topology, changes to the configuration for DB2 integration, and even changes to the underlying operating system platform.
Please notice, if you attempt to replicate some of the steps we take in the rest of the article, you will need access to a WebSphere CloudBurst Appliance with permissions to create catalog content, create patterns, and deploy patterns.
Creating the script packages
In WebSphere CloudBurst, script packages are the mechanism through which you can provide custom configuration to the WebSphere middleware application environment. A script package consists of a binary archive that contains an executable and supporting artifacts, as well as the configuration settings that tell WebSphere CloudBurst (among other things) how to invoke the script package.
For this example, we will create two different script packages:
- One will install the Account Management application into the WebSphere Application Server environment.
- The other will configure a DB2 data source for use by the application.
To create the script package to install and configure the Account Management application, first click the Catalog -> Script Packages link on the top toolbar in the WebSphere CloudBurst Web console. This brings you to the script package portion of the WebSphere CloudBurst catalog. Click the green cross in the upper left-hand corner to create the new script package.
Figure 2. Creating the new script package
Now upload the binary archive for this script package. The archive for this script package contains a wsadmin script that retrieves the Account Management from a specified location and installs it into the WebSphere Application Server environment
To upload the archive, use the file upload dialog in the Script package files field on your Account Management Application script package details page. After uploading the archive, you'll provide other information about the script package.
Figure 3. Account Management Application script package
Notice that you define a variable in the Environment section named APPLICATION_URL: This enables you to specify the value of this variable at deploy time for patterns containing your script package. The specified value will be accessible to your installation script, enabling the script to retrieve the application binaries from the specified location.
In addition to the variable, you also provide information that directs WebSphere CloudBurst as to how to invoke your script package. Specifically you tell WebSphere CloudBurst to use the wsadmin tool included in the WebSphere Application Server installation to invoke the installApp.jy script that is included in your script package archive. Per the Executes field, WebSphere CloudBurst will automatically invoke this script near the end of pattern deployment, meaning the result of the deployment process will be a WebSphere Application Server environment that includes the Account Management application.
You also need to create a script package that configures a DB2 data source in the WebSphere Application Server environment. The Account Management application will use this data source in order to interact with a DB2 instance. Name this script package "Create DB2 data source." Its archive contains a shell script that coordinates the execution of multiple wsadmin scripts to configure the appropriate resources in the WebSphere Application Server environment.
Figure 4. Script package to create a DB2 data source
Most notably, there are multiple environment variables that allow you to provide data source configuration information at deploy time for patterns containing this script package. This includes information like the data source name, database name, database location, and more. By taking this approach, you can use the same script package to configure a DB2 data source in different environments (development, test, production), and for a number of different DB2 database instances.
After defining the two necessary script packages, you can build patterns using these resources.
Creating the initial development pattern
Once the necessary script packages exist in the WebSphere CloudBurst catalog, you can create a WebSphere CloudBurst pattern that represents the application environment detailed earlier.
First, create a pattern that represents this application environment in a development setting. To do this, click the Patterns link on the top toolbar. Since you will deploy this pattern into development environments, you want to use as few compute resources as possible. With that in mind, create a pattern that when deployed results in an entire WebSphere Application Server cell running in a single virtual machine.
First, click the green cross to create a new pattern. When the dialog panel appears, provide a name for the new pattern, a short description, and choose the virtual image on which to base the pattern.
Figure 5. New pattern dialog
Next, navigate to the Pattern Editor for the new pattern by clicking on the pencil icon in the upper right-hand corner. Once in the pattern editor, drag and drop a single deployment manager part from the left-hand side of the page to the empty canvas on the right.
Figure 6. Including the deployment manager part
Ignore the warning message regarding the absence of custom nodes federated to the deployment manager because in this case, you will build the entire cell in the virtual machine represented by the deployment manager part.
In the drop-down menu on the left-hand side, select Script Packages. Now choose the script packages you want to use in this pattern. In addition to the two created earlier:
- also include a script package to set up the entire cell in a single virtual machine and
- include a script package to create an application server cluster within the cell.
Figure 7. Pattern with script packages
By placing these script packages on the deployment manager part, you ensure that they run from within the virtual machine containing the deployment manager node.
The script packages will be able to successfully complete their tasks by using a combination of the information you supply during deployment and the information WebSphere CloudBurst makes available in the /etc/virtualimage.properties file of each virtual machine it creates.
Once you are done editing the new pattern, click the Done editing link in the top right-hand corner of the pattern editor page. This brings you back to the details page for the Account Management Cluster — Development pattern. Here's where you lock the pattern down by clicking the lock icon in the top right-hand corner of the page.
Now you can start the deployment process by clicking Deploy. Provide a name for the new virtual system (in our case, "AcctMgmt Cluster — Dev"). After that, click Configure virtual parts and then Deployment manager link to configure the single deployment manager part.
Besides containing the deploy-time configuration information that is common for most pattern parts:
- Virtual machine CPU and memory allocation
- WebSphere Application Server node name and cell name, and
- Password information
your pattern includes four script packages, each of which has its own set of configuration by way of the variables it defines. Figure 8 shows the configuration information for the Create cell and Create cluster script packages.
Figure 8. Configuration for cell and cluster creation
To create the cell, specify a node name prefix ("AcctMgmtNode"), the number of nodes to create (2), and the number of IBM HTTP Server instances to create (1). To create the WebSphere Application Server cluster, simply specify the cluster name ("AcctMgmtCluster") and the member name prefix ("amServer").
The other configuration information you supply is for the script packages that install the Account Management application and create the DB2 data source for the application.
Figure 9. Configuration for the application and data source
All of the values shown in Figures 8 and 9 are available to your scripts when invoked by WebSphere CloudBurst.
After you are done specifying the deploy-time configuration, click OK to begin the deployment process. WebSphere CloudBurst directs you to the virtual systems page where you can monitor the status of the deployment. When the deployment process is complete, the status for the virtual system reflects that it is in the started state.
At that point, expand the Virtual machines section, then expand the section for the deployment manager virtual machine. Near the bottom of the deployment manager VM section, use the WebSphere link shown in Figure 10 to login to the WebSphere Application Server administration console.
Figure 10. Logging into the WebSphere Application Server admin console
Once in the administration console, you can verify that the correct configuration was established. Besides checking that the WebSphere Application Server nodes and cluster exist, you also want to verify the correct configuration of the DB2 data source and Account Management application.
To check the DB2 data source, expand the Resources section, then the JDBC section and click the Data sources link. You should see the amDataSource we specified during deployment.
Figure 11. The DB2 data source in the administration console
In addition, the Account Management application should appear in the enterprise applications listing of the console.
Figure 12. Account Management application in the administration console
At this point, the WebSphere Application Server environment is fully configured and ready to use for your development purposes.
Migrating the Account Management environment to test
Your development efforts for the Account Management application will now conclude so you are ready to begin testing on the environment. We propose the following goals for the migration:
- The custom nodes should each run on their own hosts and not be collocated with the deployment manager.
- The application binaries should be retrieved from a different repository.
- The data source should be configured to refer to a different database instance.
The changes start by going to the patterns page and selecting the Account Management Cluster — Development pattern you created previously. Clone this pattern to create a new pattern called Account Management Cluster — Test and then navigate to the pattern editor page for the new pattern.
Once in the pattern editor, remove all of the script packages from the deployment manager part. You will be adding some of the script packages back, but you need to make sure you add them in the correct order.
Next, set up the new topology by dragging and dropping a custom node from the part list on the left-hand side to the canvas on the right. The count for the custom node part increases from one to two.
Now you add the script packages back to the deployment manager part. This time start by adding the Add IBM HTTP Server node script package that ships on the appliance. This script package establishes an IBM HTTP Server in the same virtual machine as the deployment manager, thus allowing you to conserve resources in your test environment. Finally, add back the script packages to install the Account Management application and create the necessary DB2 data source.
Figure 13. The new test pattern
WebSphere CloudBurst invokes script packages in the order that they appear on a pattern part. In this case, it is important to create the IBM HTTP Server instance before installing the application since it allows the application to include the server among its deployment targets, thus allowing requests for the application to route through our IBM HTTP Server instance.
The editing is not complete yet because you need to set up a WebSphere Application Server cluster. In this case though, you will not need a script package. Since you are using custom node parts, you can leverage the ability to define clusters as an advanced option for the pattern. To do this, click Advanced Options and select the Define clusters option.
Figure 14. Defining a WebSphere Application Server cluster
As a result of selecting this option, WebSphere CloudBurst will automatically create one or more WebSphere Application Server clusters during deployment of this pattern. You will provide the configuration information that tells WebSphere CloudBurst how many clusters you want and how many cluster members you want to create on each of your custom nodes. This is done either in the pattern or during deployment.
After configuring the pattern to include WebSphere Application Server clusters, you are done with the required changes; click the Done editing link to return to the pattern detail page. At this point, you can optionally lock the pattern. You are ready to deploy.
The deployment is slightly different from last time since your pattern contains two parts. When configuring the deployment manager part for deployment, you still need to provide the necessary configuration for the application installation and data source creation scripts. In this case, change the values for this configuration data to reflect the appropriate values for your test environment.
Figure 15. New configuration data for test environment
In particular, change the location of the application binaries, the database username, and the database host values (but you could have changed any values necessary to ensure a successful deployment into our test environment).
Unlike the previous deployment, you do not need to provide information to create managed nodes in the cell because you included custom node parts in your pattern. As a result, WebSphere CloudBurst will automatically create the nodes and take care of federating them into the cell. You still have to provide information about the WebSphere Application Cluster you want to create: The only difference is that in this deployment, WebSphere CloudBurst will create the cluster instead of you having to do it, including a script package to carry out that configuration action.
Figure 16. Configuring the WebSphere Application Server cluster
The values in Figure 16 result in the creation of a single cluster which contains one member on each node. In this case, that means your WebSphere Application Server cluster will have two members because your pattern contains two custom node parts.
In this pattern, you also have to configure the custom node parts before you deploy. There are no script packages on this part, so all you need to do is provide password information. Deploy the pattern by clicking the OK button on the deployment dialog. Again, this takes you to the Virtual Systems page and when the deployment process is complete and the virtual system is in the started state, you login to the WebSphere Application Server administration console just as you did last time. The only real difference for this deployment besides the altered application and data source configuration, is that the custom nodes exist on different hosts than the deployment manager.
Figure 17. Node listing for WebSphere Application Server cell
The CloudBurstNode and CloudBurstNode1 nodes shown in Figure 17 were created from the two custom node parts in our pattern. The CloudBurstNode0 and cbmv-112.rtp.raleigh.ibm.com-node nodes represent the deployment manager and IBM HTTP Server instance respectively.
The key point in the migration from your development environment to your test environment is not the differences though — the real key is that the net result of these two deployments is the same. In both environments, the Account Management application runs on a WebSphere Application Server cluster and that application has access to a data source for a DB2 database. Further, you achieved this migration by simply making a few changes in a drag-and-drop interface and providing a very small amount of deploy time configuration.
The migration from one environment to the next took just a matter of minutes.
Moving on to quality assurance
The Account Management application will not remain in the test environment forever. Its ultimate home is running live in production so that it is available to the larger enterprise, but you cannot just jump from test to production.
First, you want to move the tested and verified Account Management application environment into a quality assurance (QA) setting. Specifically, this means five changes:
- The WebSphere Application Server environment must run on the AIX® platform.
- The IBM HTTP Server should run on its own separate host and not be collocated with the deployment manager.
- The Account Management application environment should utilize compute resources dedicated for our QA and disaster recovery purposes.
- The application binaries should be retrieved from a different repository.
- The data source should be configured to refer to a different database instance.
Like with the move from development to test, the changes start with cloning a pattern. As part of this transition, you have to make sure your WebSphere Application Server environment runs on the AIX platform. Traditionally, moving an entire application environment and associated application infrastructure stack from one platform (in this case SUSE Linux® running on VMware) to an entirely different one (AIX running on PowerVM) can be complex, time-consuming, and error-prone. With WebSphere CloudBurst, that is no longer the case.
To rebase your application environment on AIX for PowerVM, simply clone the existing Account Management Cluster — Test pattern and choose a different image on which to base the pattern. Do this in the initial dialog panel during the pattern clone process as illustrated in Figure 18.
Figure 18. Creating the Account Management QA pattern
Select the WebSphere Application Server 220.127.116.11 (PowerVM) image as the basis for your QA pattern. This image runs on the IBM PowerVM hypervisor platform and includes an AIX operating system. In a matter of seconds and with a few clicks, you have rebased our Account Management application environment on an entirely new operating system! Further, all of the customizations built into the pattern, such as the topology of the cell, installation of the Account Management application, and the configuration of the DB2 data source, are preserved.
After creating the new pattern, enter the pattern editor interface. Once there, remove the Add IBM HTTP Server node script package from the deployment manager part and drag and drop an IBM HTTP servers part from the list on the left-hand side to the pattern canvas.
Figure 19. Account Management cluster: QA pattern
It is worth pointing out that when you alter a pattern containing advanced options, those advanced options may reset. In this case, after removing the script package from the deployment manager part, the Cluster configuration and JVM tuning script packages (created because the Define clusters advanced options setting was selected) disappear. To reset these options, simply click Advanced Options and re-select the option to define clusters.
After making the necessary changes in the pattern editor, you are ready to begin the deployment process.
Though not discussed to this point, every time you deploy a pattern in WebSphere CloudBurst, you target a specific cloud group. A cloud group is a collection of hypervisors used by WebSphere CloudBurst to host the virtual machines it creates during deployment. At least one cloud group is required, but you can define multiple cloud groups in order to more effectively divide shared resources across the organization as seen in Figure 19.
Figure 20. WebSphere CloudBurst cloud groups
Within a particular cloud group, all of the hypervisors must be of the same type (like, all VMware ESX hosts or all PowerVM hosts). Create your new pattern using the WebSphere Application Server Hypervisor Edition packaged for the PowerVM platform. You need to ensure that you deploy to a cloud group that is managing a collection of PowerVM hosts. With that need in mind, it is a good time to point out that not only can WebSphere CloudBurst manage multiple cloud groups, but also one appliance can manage multiple cloud groups which in turn manage different hypervisor platforms.
Figure 21. Managing a heterogeneous cloud
As seen in Figure 21, WebSphere CloudBurst effectively abstracts the underlying infrastructure so that the end-user experience when deploying patterns is the same. To deploy your new pattern to the PowerVM platform, simply choose the QA Cloud Group that happens to be a PowerVM cloud group. Other than that, configure the pattern for deployment in exactly the same way, likely changing certain information about the application and data source configuration as you have done for previous deployments.
Figure 22. Selecting the QA cloud group
Next, configure the virtual parts similar to the way you did for the previous deployment of the Account Management Cluster — Test pattern. The only change for this deployment is specifying different information for application and data source configuration.
Figure 23. Application and data source configuration for QA
Like in the previous migration step, change the application binaries, database username, and database host name values. Again, you could change any or all of these values as necessary. After configuring the deployment manager part, configure the custom node parts and the IBM HTTP Server part (because you included that as a separate part of your pattern) with the necessary password information.
Now you can deploy to our quality assurance cloud; once the virtual system is up and running, login to the WebSphere Application Server administration console as before. If you want, you can confirm the correct makeup of your cell by going to the nodes listing. This time you should see different hosts for each of the nodes in your cell.
Figure 24. Node listing for QA environment
Other than different hosts for each of your nodes, the resulting environment is much the same. You still have your Account Management application configured to run on a WebSphere Application Server cluster and utilize a DB2 data source.
Again, you have accomplished the migration process via changes made in a drag-and-drop interface and small deploy-time modifications. And you can measure the entire process in minutes rather than in days (or worse yet, in weeks).
Showtime! Moving to production
You're at the point where it is time to put your brand new Account Management application into production and open it up for enterprise use. To accomplish this you can use the same Account Management Cluster — QA pattern created earlier or if organizational processes dictate, you can simply clone it and create a new pattern with a new name. Nothing about the makeup of the pattern will change. In fact, in order to deploy your Account Management cluster environment into production, you only need to make two familiar changes:
- The application binaries should be retrieved from a different repository.
- The data source should be configured to refer to a different database instance.
This means you simply change the configuration data at deploy time as you have done previously.
Figure 25. Deploying the pattern to production
This is all it takes to move your application environment from quality assurance into a production environment! Once the deployment process is complete and the virtual system started, you can access the WebSphere Application Server administration console just like you did for previously deployments and you can manage the virtual system in WebSphere CloudBurst in the same manner as you managed virtual systems deployed on the VMware ESX platform.
Not only is the end-user experience consistent with respect to creating and deploying patterns for different platforms, the experience is the same when managing the resultant virtual systems regardless of the type of infrastructure on which the virtual machines are hosted.
How does it feel? You have moved an Account Management application from development to test to quality assurance and finally into production. Each migration action was little more than a combination of drag-and-drop actions paired with tweaks to deploy-time configuration data. In addition, each time you performed a migration task in minutes.
The truth is that few developers, testers, or administrators look forward to the migration of an application environment. It is typically a process associated with long hours, frustrating and hard to find errors, and all too often missed goals.
As we've demonstrated here, you can eliminate some, if not all of these problems, by adopting the patterns-based approach afforded by WebSphere CloudBurst.
WebSphere CloudBurst patterns provide you the ability to capture and save your middleware application environment and its configuration. These patterns can be deployed repeatedly with slight tweaks each time if necessary, thus ensuring you of consistent results. Add to that the ability to quickly clone and modify the topology or platform of a pattern without affecting the consistency of your applications and their configurations and you get the perfect balance of hardening and flexibility. Simply put, instead of the application migration process being an inhibitor within your business, WebSphere CloudBurst can turn that process into a competitive advantage.
- developerWorks cloud computing offers updated resources on cloud computing.
- developerWorks WebSphere covers every technical detail on how to use WebSphere CloudBurst.
- IBM Cloud Computing serves up a high-level overview of IBM Cloud offerings.
Get products and technologies
- WebSphere CloudBurst Samples Gallery: Download free samples that help you get started with WebSphere CloudBurst.
- With IBM trial software, available for download directly from developerWorks, build your next development project on the cloud.
- Get involved in the developerWorks community (developer blogs, groups, forums, podcasts, profiles, newsletters, wikis, and community topics).
Dig deeper into Cloud computing on developerWorks
Exclusive tools to build your next great app. Learn more.
Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.
Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.