The concept of patterns introduced by WebSphere CloudBurst usually becomes the center of the discussion. These patterns allow users to build and save full representations of WebSphere Application Server middleware environments. WebSphere CloudBurst then allows users to deploy these patterns into a private cloud resulting in quicker, more consistent WebSphere Application server deployments. The appliance also provides facilities to quickly reclaim the resources used by such deployments.

Almost immediately the benefit of using WebSphere CloudBurst in dynamic environments (i.e. test/dev environments) becomes apparent. Users can build and save WebSphere Application Server configurations, quickly deploy those configurations, and reclaim the resources used by those configurations in a rapid manner.

One of the things I've tried to point out during our discussions is that while WebSphere CloudBurst is ideally suited for environments like test/dev, that doesn't mean it can't bring real benefits to a more static production environment.

To start with, the idea of the fidelity of a WebSphere Application Server configuration from development to test to production is compelling. By using WebSphere CloudBurst patterns, the hand-off of an application environment between different teams is expressed as a WebSphere CloudBurst pattern instead of as documents and collections of scripts. This goes a long way in ensuring a smooth production deployment once development and test are satisfied with the environment.

Another extremely powerful feature of WebSphere CloudBurst, particularly with respect to production environments, is the ability to apply both interim fixes and service level upgrades to running WebSphere Application Server environments. Using the WebSphere CloudBurst GUI, users can select virtual systems that were created by the appliance and apply either an interim fix or upgrade the service level of the system. Even better, before the fix or upgrade is applied, WebSphere CloudBurst automatically takes a snapshot of the virtual system. If there are any problems, users can rollback to the previous state of the virtual system by simply clicking a button!

There's little doubt that the most apparent, initial value of WebSphere CloudBurst is likely to be in test and development environments. However, that does not mean the appliance isn't suited for production environments. In fact, it provides many features that make WebSphere Application Server production environments more predictable and easy to maintain. Check out some of the WebSphere CloudBurst content on our community page to learn more about WebSphere CloudBurst in both test/dev and production environments.

I just updated our YouTube channel with a few new WebSphere CloudBurst demos. There is a demo for applying interim fixes, applying service level upgrades, and utilizing cloud groups.

The capabilities for applying interim fixes and service level upgrades are also in some of the longer demos on the channel, but I thought it would be nice to break them out into more consumable chunks (~ 1 minute).

The demo highlighting the utilization of WebSphere CloudBurst cloud groups shows how they can be used to deploy application server nodes behind a firewall while deploying the web server nodes that route to those nodes to a DMZ.

You can check out the demos by going here. Let us know what you think by commenting on the videos or dropping a comment here. I hope the demos help!

Users of the WebSphere CloudBurst appliance have three interfaces with which to interact with the appliance: GUI console, command line, and REST APIs. The GUI console can be seen by watching our demos out on YouTube, and I recently posted a bit about the CLI.

The REST APIs were introduced with the 1.0.0.1 fixpack. The fixpack can be downloaded by going to IBM Fix Central and selecting WebSphere->WebSphere CloudBurst Appliance->1.0.0.1->Linux. Using the REST APIs users can perform some of the same actions that can be achieved through the GUI and CLI interfaces by way of HTTP requests to well-defined URLs.

For instance, consider a user wanted a list of all the cloud groups defined in a particular WebSphere CloudBurst Appliance. To do so using the REST APIs, an HTTP GET request to the https://<cloudburst_host>:443/resources/clouds URL would be sent. The returned content is represented in JSON:

Similarly, a user may decide to create a new cloud group using the REST API. This could be accomplished by sending an HTTP POST request to the same URL. This time though, a request body of the following format is sent with the request:

Users can also utilize the PUT and DELETE HTTP methods to update and remove resources in the WebSphere CloudBurst appliance.

If you are interested in exactly how the WebSphere CloudBurst REST API works, you can download the API's documentation here. This reference provides information on what resources are accessible via the REST API, at what URLs resources can be accessed, what operations are available on those resources, and the correct format for all HTTP requests sent to the appliance. In addition, the document provides examples of data formats in both requests and responses.

The HTTP URLs exposed by the REST interface allow users to view WebSphere CloudBurst data and manage WebSphere CloudBurst from a variety of contexts. Using the URLs, users can easily include WebSphere CloudBurst data into mashups and other web-based portals. Users can also write custom code or scripts that leverage these URLs as part of a wider reaching business processes. The REST interface, combined with the GUI and CLI interfaces, provide users with choice and flexibility in how they manage and interact with the WebSphere CloudBurst Appliance.

In my own opinion, the graphical console offered up by the WebSphere CloudBurst Appliance is among the best I have seen in any product within the WebSphere portfolio. The graphical console is intuitive, adaptive to users, and easy on the eyes. From the console, users can create, deploy, and maintain WebSphere virtual systems in their private cloud.

However, that’s not to say that the graphical console is the only way (or always the best way) to interact with WebSphere CloudBurst. There is also a command line interface (CLI) tool set that users can download from the appliance. The CLI provides a Jython 2.2.1 interpreter and Jython libraries that help users carry out many of the same activities that can be accomplished via the console.

The provided Jython libraries allow users to interact with the components of WebSphere CloudBurst (virtual images, virtual systems, patterns, users, etc.) as a set of resources and resource collections. For instance, the provided cloudburst library can be used to interact with resources that represent appliance users.

# list all users users = cloudburst.users

# get the ‘cbadmin’ user cbadmin = cloudburst.users[‘cbadmin’]

While retrieving a resource collection or specific resource is useful, the CLI can also be used to create, delete, and update resources. The snippet below shows how the cloudburst library can be used to create a new appliance user.

The WebSphere CloudBurst CLI can be used in one of two modes: interactive or batch. In the interactive mode, users issue commands in a shell environment managed by the CLI. In this mode, users can take advantage of interactive wizards that guide them through the creation of different resources, thus providing an easy on-ramp to learning the CLI features.

The other mode of operation is the batch mode which has two different flavors. One way to use batch mode is to invoke the CLI and pass commands inline using the –c argument.

In the above command, a connection to the appliance at the host specified by the –h argument is made under the user indicated by –u with the password indicated by the –p argument. Once the connection is made, the command specified by the –c argument is executed, thus returning all users of the appliance. In addition to supplying a single -c argument as above, multiple -c arguments can be supplied to execute a chain of logic.

The other way to use batch mode is to supply a Jython script file via the -f argument.

The script file should be a valid Jython 2.2.1 script file, and it can optionally use Java libraries as long as they are present on the classpath.

There is so much more to the WebSphere CloudBurst CLI tool set than what is mentioned above. It can be used to create new customized WebSphere patterns, add new script packages, deploy WebSphere patterns to a private cloud, and more. Visit the information center for more information about the WebSphere CloudBurst CLI, or send us an email at wscloud@us.ibm.com.