First, some background
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.
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.
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.
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.
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.