Application Environment Migration With WebSphere CloudBurst

Application environment migration with WebSphere
CloudBurst
Preserving the fidelity of application environments through
patterns
Skill Level: Intermediate
Dustin Amrhein
Technical Evangelist
IBM
Ruth Willenborg
Senior Technical Staff Member
IBM
01 Jun 2010
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, QA, and production. The tutorial offers a complete,
step-by-step example of using patterns to handle changing topologies, underlying
platform architectures, and configuration properties.
Section 1. 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 environment migration with WebSphere CloudBurst Trademarks

© Copyright IBM Corporation 2010. All rights reserved. Page 1 of 36
developerWorks® ibm.com/developerWorks
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.
Objectives
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.
Prerequisites
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.
System requirements
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.
Section 2. First, some background

ibm.com/developerWorks developerWorks®
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.
Different resources
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.

Section 3. 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:
1. Create the necessary WebSphere CloudBurst script packages.
2. Create the initial WebSphere CloudBurst pattern for development

settings.
3. Migrate and deploy the application environment to a test setting.
4. Migrate and deploy the application environment to a QA setting.
5. 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.
Section 4. 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.
Section 5. 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.
Section 6. 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:
1. The custom nodes should each run on their own hosts and not be
collocated with the deployment manager.
2. The application binaries should be retrieved from a different repository.
3. 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.
Section 7. 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:
1. The WebSphere Application Server environment must run on the AIX®

platform.
2. The IBM HTTP Server should run on its own separate host and not be
collocated with the deployment manager.
3. The Account Management application environment should utilize compute

resources dedicated for our QA and disaster recovery purposes.

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 7.0.0.7 (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).
Section 8. 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:

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.

Section 9. In conclusion
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.

Resources
Learn
• WebSphere CloudBurst customization series: Learn how to create highly
customized clouds with WebSphere CloudBurst.
• Cloud computing for WebSphere developers: Keep up to date with the latest
WebSphere CloudBurst and cloud computing news in WebSphere.
• My developerWorks is both a professional network and unified set of community
tools for connecting, sharing, and collaborating. Immerse yourself in IT
development:
• You start by registering or signing into My developerWorks. (Individualized
features are not available unless you register.)
• At My Home, you can drag and drop modules to customize your view.
(Individualized.)
• Profiles help you find individuals to share knowledge and let you show the
community what you know.
• Blogs let you share your knowledge or discover the innovative ideas of
peers: Here's cloud computing topics on the blogs.
• Groups provide communities you can join or create that interested in
similar topics: Here's cloud computing topics on groups.
• Forums are the ultimate e-exchange for interactive problem solving: Here's
cloud computing topics on the forums.
• Bookmarks help you create an organized collection of information, much
like a private (or shareable) library: Here's bookmarks tagged for cloud
computing.
• Files gives you a space to collaborate on files: Here's cloud computing
topics on the files.
• Wikis let you manage knowledge and content in one central place: Here's
cloud computing topics on the wikis.
• Activities lets you create your own topic-oriented calendar. (Individualized.)
• The developerWorks cloud computing site offers updated resources on cloud

computing, including
• An introduction to the world of cloud computing.
• Updated technical articles and tutorials and pod- and Webcasts to ease
your development efforts, as well as a window in professional workshops

and recorded sessions to make you an efficient cloud developer.

• Connections to IBM product downloads and information designed for use
in cloud environments.
• An active feed into the topics the community is buzzing about.
• The developerWorks WebSphere site covers every technical detail on how to

use WebSphere CloudBurst.
• The IBM Developer Cloud Blog gives you the latest details on the Developer
Cloud from the experts in cloud computing.
• The how-to wiki is always being updated with common use scenarios for the
developer cloud.
• Stay current with developerWorks technical events and webcasts.
• The IBMdevcloud channel on YouTube offers all kinds of hands-on demos such
as using a range of IBM products on the Test Cloud and creating and accessing
instances.
• The IBM Cloud Computing portal 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.
• The IBM Smart Business Development and Test on the IBM Cloud site is your
place to start developing your applications for the cloud.
• Discover more about the WebSphere CloudBurst Appliance: Extend smart SOA
applications and services into the cloud.
• With IBM trial software, available for download directly from developerWorks,
build your next development project on the cloud.
Discuss
• The Developer Cloud group on My developerWorks is the community for the
Smart Business Development and Test on the IBM Cloud.
• Get involved in the developerWorks community (developer blogs, groups,
forums, podcasts, profiles, newsletters, wikis, and community topics) through
My developerWorks, a professional network and unified set of community tools
for connecting, sharing, and collaborating.
About the authors

Dustin Amrhein
Dustin Amrhein joined IBM as a member of the development team for
WebSphere Application Server. While in that position, Dustin worked on
the development of Web services infrastructure and Web services
programming models. In addition, Dustin lead the technical effort in the
development of a Java RESTful services framework. In his current role,
Dustin is a technical evangelist for emerging technologies in IBM’s
WebSphere portfolio. His current focus is on WebSphere technologies
that deliver cloud computing capabilities, including the WebSphere
CloudBurst Appliance.
Ruth Willenborg
Ruth Willenborg is a Senior Technical Staff Member in IBM's
WebSphere Technology Institute where she is currently working on
WebSphere cloud computing and virtual appliance initiatives and is the
technical evangelist for the new IBM WebSphere CloudBurst Appliance.
Prior to her work on virtualization and appliance initiatives, she was the
manager of the WebSphere Performance team responsible for
WebSphere Application Server performance analysis, performance
benchmarkingm and performance tool development. Ruth has more
than 20 years of experience in software development at IBM and is
co-author of Performance Analysis for Java Web Sites
(Addison-Wesley, 2002) and numerous articles on both WebSphere
performance and using WebSphere with virtualization technologies.


Application Environment Migration With WebSphere CloudBurst

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Environment Migration With WebSphere CloudBurst

Uploaded by

Copyright:

Available Formats

Application environment migration with WebSphere

Skill Level: Intermediate

Section 1. Before you start

About this tutorial

Application environment migration with WebSphere CloudBurst Trademarks

Section 2. First, some background

Application environment migration with WebSphere CloudBurst Trademarks

Why define consistent configurations?

What is the life cycle?

Application environment migration with WebSphere CloudBurst Trademarks

that introduce problems.

Let's look at a common set of changes that applications and supporting

• Different infrastructure topologies.

Though virtualization makes it possible to more easily replicate multinode production

Each distinct topology maps to a pattern in CloudBurst

Application environment migration with WebSphere CloudBurst Trademarks

In WebSphere CloudBurst, each of the distinct topologies map to a pattern.

Different hardware topologies

Application environment migration with WebSphere CloudBurst Trademarks

Different configuration settings

WebSphere CloudBurst patterns expose parameters that allow for configuration

Most WebSphere applications talk to something (such as databases, directory

Application environment migration with WebSphere CloudBurst Trademarks

Section 3. The sample scenario

• One deployment manager node.

Figure 1 illustrates the application environment we just described.

Figure 1. Example application environment

Application environment migration with WebSphere CloudBurst Trademarks

1. Create the necessary WebSphere CloudBurst script packages.

2. Create the initial WebSphere CloudBurst pattern for development

3. Migrate and deploy the application environment to a test setting.

4. Migrate and deploy the application environment to a QA setting.

5. Migrate and deploy the application environment to a production setting.

Section 4. Creating the script packages

For this example, we will create two different script packages:

Application environment migration with WebSphere CloudBurst Trademarks

Figure 2. Creating the new script package

Figure 3. Account Management Application script package

Application environment migration with WebSphere CloudBurst Trademarks

Notice that you define a variable in the Environment section named

Application environment migration with WebSphere CloudBurst Trademarks

Figure 4. Script package to create a DB2 data source

Application environment migration with WebSphere CloudBurst Trademarks

Section 5. Creating the initial development pattern

First, create a pattern that represents this application environment in a development

Figure 5. New pattern dialog

Application environment migration with WebSphere CloudBurst Trademarks

Figure 6. Including the deployment manager part

Application environment migration with WebSphere CloudBurst Trademarks

Besides containing the deploy-time configuration information that is common for

• Virtual machine CPU and memory allocation

Application environment migration with WebSphere CloudBurst Trademarks

• WebSphere Application Server node name and cell name, and

Figure 8. Configuration for cell and cluster creation

Figure 9. Configuration for the application and data source

Application environment migration with WebSphere CloudBurst Trademarks

Application environment migration with WebSphere CloudBurst Trademarks

Figure 11. The DB2 data source in the administration console

Application environment migration with WebSphere CloudBurst Trademarks

In addition, the Account Management application should appear in the enterprise

Figure 12. Account Management application in the administration console

Section 6. Migrating the Account Management

Application environment migration with WebSphere CloudBurst Trademarks