The majority of my posts on this blog address using various features of WebSphere CloudBurst to build private cloud computing environments. Today though, I want to switch gears and instead of talking private cloud, let's talk public cloud. Specifically, let's take a look at the capabilities and services delivered via the IBM Smart Business Development and Test on the IBM Cloud (hereafter referred to as the IBM Cloud).
For some of you, the fact that IBM has a public cloud offering may be a little surprising. After all, if you listen to some uninformed critics you may hear that IBM only cares about private clouds for large enterprises. That is simply untrue. The IBM Cloud is an Infrastructure as a Service public cloud that delivers rapid access to services hosted on IBM infrastructure via a self-service web portal. The IBM Cloud offers multiple payment options, including usage-based billing and reserved capacity billing, and even features a cost estimator so you can confidently establish a monthly budget for your usage.
Regardless of whether you use a private or a public cloud, security should always be a chief concern. As such, IBM takes security very seriously in the IBM Public Cloud. The infrastructure that constitutes the cloud is subject to internal IBM security policies that include regular security scans and tight administrative governance. Your data and virtual machines stay in the data center to which you provisioned them, and physical security policies match those of internal IBM data centers. Additionally, you can optionally make use of the virtual private network option to isolate access to the virtual machines that you provision on the IBM Cloud. Rest assured that security in the IBM Cloud was a guiding design principle and not an afterthought.
With the basics out of the way, let's get on to the question I'm sure you have: What can I run on the IBM Cloud? To get you started, the IBM Cloud provides a nice list of public images in its catalog that are ready for you to provision. These images include WebSphere Application Server, WebSphere sMash, DB2, WebSphere Portal Server, IBM Cognos Business Intelligence, Tivoli Monitoring, Rational Build Forge, and many more. In addition to the public images provided by the IBM Cloud, you can build your own private images. Private images allow you to start with a base public image and then customize it by adjusting the configuration or installing new software. Once customized, you can store these private images on the IBM Cloud and provision them whenever needed. Whether you are using public or private images, you have a number of server configurations to choose from in order to host your environments.
While very brief, I hope this overview provides you with some of the more important details regarding the IBM Cloud. There are few, if any, service providers out there with the enterprise expertise of IBM, and I think you see that reflected in the IBM Cloud. If you are looking at public cloud options for your enterprise application environments, you should definitely take a closer look at the IBM Cloud.
The recently announced IBM WebSphere CloudBurst Appliance is creating a fair amount of stir in the cloud computing market. Its ability to create, deploy, and administer private WebSphere cloud environments gives customers the ability to create and manage a services oriented cloud. To provide a more in-depth look at what the appliance delivers, I’d like to take a short look at the creation, deployment, and administration capabilities to understand what each one means to the user.
To get started, in order to leverage WebSphere environments in a private cloud, you need to construct WebSphere configurations optimized for such a virtual environment. Using WebSphere CloudBurst you can do just that. WebSphere CloudBurst ships a virtual image packaging of the WebSphere Application Server called WebSphere Application Server Hypervisor Edition. From this new virtual image offering, complete WebSphere Application Server topologies can be constructed to create what WebSphere CloudBurst terms a pattern. These patterns are representations of fully functional WebSphere Application Server environments. For example, using WebSphere components in the WebSphere Application Sever Hypervisor Edition, you can create a cluster environment that includes a WebSphere Deployment Manager, two customs nodes, and the IBM HTTP Server.
In order to create these patterns, WebSphere CloudBurst provides a drag-and-drop interface that allows users to select WebSphere components from the new virtual image and drop them onto a canvas that visually represents the WebSphere configuration. In addition to adding WebSphere components, users can also drag and drop script packages onto the components within a pattern. These script packages allow users to provide scripts and other artifacts that further customize the WebSphere Application Server environment once it has been deployed in the cloud. These script packages can do just about anything, from tuning WebSphere security settings to installing applications in the newly created environment.
Building the virtualized WebSphere Application Server environment, or pattern, is only part of the process. Once the pattern is built, it is ready to be deployed to the cloud. WebSphere CloudBurst operates on a ‘bring your own cloud’ model, so the cloud resources are defined to the appliance. These cloud resources consist of a set of supported hypervisors and a list of IP addresses available to the cloud. Once these resources are defined, WebSphere CloudBurst has all the information it needs for deployment. On deployment of a pattern, WebSphere CloudBurst determines the state of the available resources, and places the pattern across the available hypervisors accordingly. It places the WebSphere instance to ensure efficient use of resource, high performance, and high availability. In addition to placing the pattern instance onto the hypervisors, WebSphere CloudBurst selects and assigns an IP address to each WebSphere component in the configuration. Both the placement and IP address assignment are done with no user input or intervention. The result of the pattern deployment is a fully instantiated WebSphere environment that can be accessed and used like any other such environment. It is important to note that the WebSphere environments do not run on the WebSphere CloudBurst Appliance, and in fact the appliance plays no role in the runtime of the environments.
While it is true that the WebSphere CloudBurst Appliance is not involved in the runtime of the patterns that it deploys, it does provide users the capability to monitor and administer these environments. From the WebSphere CloudBurst console, each of the WebSphere virtual systems can be viewed to understand network configuration, memory consumption, and CPU usage. Usage of cloud resources (i.e. memory, CPU, IPs) is also tracked at a user or user group level allowing WebSphere CloudBurst to support chargeback across an enterprise. In addition to these monitoring capabilities, maintenance features are part of the appliance’s administration story. WebSphere CloudBurst provides users with a central administration point for applying maintenance, such as iFixes and service packs, to the WebSphere virtual systems it created. These fixes can be applied within the WebSphere CloudBurst console with only a few mouse clicks providing an unprecedented ease of maintenance application.
The above is only a glimpse at the capabilities of the new IBM WebSphere CloudBurst Appliance. Look for more information about this offering at ibm.com/cloudburst, and stay tuned to our blog, twitter account (@WebSphereClouds), and websiteas we continue to deliver insight into WebSphere CloudBurst.
For those of you basically familiar with IBM Workload Deployer, you are likely aware that the appliance has many different capabilities. On the surface it is a cloud management device for middleware and middleware applications. Of course, there are quite a few details that are important to understanding the functionality provided, and I spend quite a bit of my time talking with various users and potential users about these details. One thing I have noticed that can become an obstacle in having effective communication regarding IBM Workload Deployer is the lack of a commonly understood language. I sometimes find that me and the user are simply using different terminology to describe the same thing. As you can imagine, this just serves to create confusion, and neither party gets the most out of the conversation.
In order to combat this communication gap, I thought I would put together a simple presentation that introduces and defines IBM Workload Deployer terminology. Check it out below (you can also download it here):
While the presentation does not dive deep into the terms it introduces, it does provide a basic definition and illustrative example of each. My hope is that this fosters an understanding of some of the basic concepts in IBM Workload Deployer, and ultimately pushes us towards a common vernacular. Please let me know what you think!
Since bundles are such a core component of the IBM Image Construction and Composition Tool, I thought it would help to take a closer, more thorough look at them than I did in my post last week (if you have not already, I suggest reading the overview post before continuing). To help us in our closer examination, we will consider an example bundle I built using the IBM Image Construction and Composition Tool. The example bundle I built encapsulates the logic to install and configure WebSphere Application Server Community Edition. Let's take this step by step.
The first part of the bundle is the General section. This section allows you to provide a name and description for the bundle, the bundle ID and version, and the products represented by the bundle.
The next section of a bundle is the Requirements section. In this section, you can define the operating system and software requirements for your bundle. In the OS section, you specify the type, distribution, and version level of the OS your bundle requires. In the software section, you can indicate that your bundle requires other bundles defined in the IBM Image Construction and Composition Tool. You do this by providing the bundle ID for required bundles.
Next, we move on to the Install section of the bundle. Two major subsections make up this section. The first subsection is the Files to Copy section. Here, you provide files, via a file upload dialog or by providing a URI, and you specify a destination directory. When you add a bundle to an image and initiate the synchronization process, the IBM Image Construction and Composition Tool will automatically copy the files you list here to the specified destination directory on the virtual machine. In the sample WebSphere Application Server Community Edition bundle, I specify a single install.sh file to copy to the virtual machine.
The second major subsection of the Install section is the Command subsection. In this section, you will specify the installation command that the IBM Image Construction and Composition Tool should automatically invoke during the synchronization process. Additionally, you can define variables that you want to make available to your installation scripts. The tool makes these available as environment variables for the process within which your script runs. In the sample bundle, I tell the Image Construction and Composition Tool to invoke the install.sh script specified above, and I define parameters that specify the location of the binaries to install, the location to install the binaries on disk, and more.
The next section in a bundle is the Configuration section. The configuration section allows you to define configuration operations that provide actions that execute for each deployment of an image containing the bundle. You can define 0 to N configuration operations in a bundle, and each configuration operation definition contains three major subsections. The first is the Files to Copy subsection. This subsection is similar to the Files to Copy subsection in the Install section. You provide files or file URIs and you provide a destination directory to which the tool will copy the file. The WebSphere Application Server Community Edition bundle contains a single configuration operation called ConfigWASCE. In the Files to Copy section, I define a single file to copy into the image's activation engine directory.
The second major subsection in the configuration operation definition is the Command subsection. Like the Command subsection in the Install section of the bundle, you specify a command to execute and optionally associate variables with the command. There is a key difference between the command definition for configuration operations as opposed to installation operations. The Image Construction and Composition Tool invokes the command you specify for installation operations exactly ONCE at image creation (synchronization) time. On the other hand, commands you specify in the configuration operation definition execute EACH time someone deploys an image containing your bundle. In the sample bundle, my ConfigWASCE.sh script will automatically execute for each deployment. The tool will package the image in such a way that ensures the automatic passing of parameters defined in the Arguments list (including num_servers, WASCE_HOME, and more) to the ConfigWASCE.sh script.
The final major subsection of a configuration operation definition is the Dependencies section. This allows you to define other services on which your configuration operation is dependent. This can include other configuration operations in the same or other bundles, and it can include general operating system services. The WebSphere Application Server Community Edition sample bundle includes a few dependencies.
The Install and Configuration sections are really the meat of your bundle, but there is more. There is a Firewall section that allows you to define port ranges and associated protocols that the IBM Image Construction and Composition Tool should ensure are open when provisioning an image containing your bundle. Currently, the tool supports firewall configuration data when building images for the IBM Cloud. The Reset section of the bundle allows you to define tasks that should execute when capturing the image back into the Image Construction and Composition Tool (after synchronziation completes). This allows you to clean up the state of the image after the install completes. Reset configuration is not currently available in the alphaWorks version of the tool. Finally, there is a License section where you can define software licenses associated with your bundle. The tool automatically adds these licenes to the constructed image's metadata, thereby allowing deployment tools to prompt the user to accept all pertinent licenses. The WebSphere Application Server Community Edition sample bundle defines a product license.
Of course, once the bundle definition is complete, you can leverage it to compose and produce an image that you can use in WebSphere CloudBurst, Tivoli Provisioning Manager, or on the IBM Cloud. In the case of the WebSphere Application Server Community Edition sample bundle, I used it to create an image that I loaded into WebSphere CloudBurst and used to build patterns.
I hope this helps to provide a better idea of what bundles are all about in the Image Construction and Composition Tool. Don't forget to take a look at the overview demo and stay tuned for more to come about this new tool!
Maybe you remember, but not long ago I wrote a post about scenarios when WebSphere CloudBurst and Rational Automation Framework for WebSphere (RAFW) combine to form quite the pair. You can read that post for details, but the basic scenarios were configuring and capturing, importing existing environments into WebSphere CloudBurst, and migrating from virtual to physical installations. Well, after talking with customers and colleagues lately, you can add another scenario to the list: version-to-version WebSphere Application Server migrations.
I want to be clear here about one thing before I go further. I am in no way advocating against the use of the migration tooling that ships with WebSphere Application Server. It is an excellent tool that can make migrations simple and fast. I am merely pointing out that when it comes to version-to-version migrations you have options, and you should survey them all before making a decision.
With that understanding, let's take a look at WebSphere CloudBurst and RAFW in the context of a version-to-version migration. This integrated approach to migration is ideal if you are amenable to moving up to a newer version of WebSphere Application Server in a cloud-based environment. Using both products makes migrations fast and easy, and you can be very confident that the configuration of the migrated environment is faithful to the original. The figure below shows the basic flow of the migration and breaks it down into a set of discrete steps.
Now, for a quick break down of each step:
Extract config & apps from old environment: The first step involves pointing RAFW at your existing configuration, the one you want to migrate from, and using an out-of-the-box action to import all of the configuration into a RAFW environment. You can also import your application binaries in this step.
Store config & apps from old environment: In step two, you will store the extracted configuration and application binaries in a source control repository or some backup location separate from your RAFW server. This is an optional, but recommended step.
Analyze and update apps: Before migrating your applications to the newer version of WebSphere Application Server, you can use the completely free Application Migration Toolkit to analyze the source code of your applications. This toolkit will recommend any required updates to ensure your application continues to behave as expected when moving to the new version. Again, this is an optional step, but the toolkit is free and very handy. So, why not?
Deploy new version of the environment: Step four starts by building a new WebSphere CloudBurst pattern. This new pattern matches the topology of the environment you are migrating from, and you build it from an image containing the version of WebSphere Application Server to which you want to migrate. Once built, you deploy it to your private cloud and you have a running environment in minutes.
Apply stored config and deploy updated apps: Now that you have your new environment up and running, use RAFW to apply the configuration you extracted from your old environment. RAFW inherently understands any configuration translation that needs to occur to apply the old configuration to your new environment, and it can also deploy your updated applications for you.
That's the basic overview for version-to-version migrations when you are moving to a cloud-based environment. In time, I will be posting more information about this process to shed a little more light about what is going on under the covers. In the meantime, you know how to reach me if you have questions!
It seems like it was announcement day across IBM, and specifically in WebSphere. While the announcements were numerous and touched many different topics, I want to focus on a couple of announcements of particular interest to those of you interested in WebSphere CloudBurst and IBM Hypervisor Edition virtual images.
First, for all of our WebSphere Process Server and WebSphere Business Monitor users, there are a couple of important pieces of information in this announcement. This announcement outlines the availability of WebSphere Business Monitor Hypervisor Edition. The new image allows you to dispense WebSphere Business Monitor 7.0 environments using WebSphere CloudBurst to VMware hypervisors. In addition, the announcement outlines the expansion of the existing WebSphere Process Server Hypervisor Edition image to support the z/VM platform and the Red Hat Enterprise Linux (RHEL) operating system for VMware.
Moving beyond our BPM set of solutions, IBM also announced the availability of a WebSphere Message Broker Hypervisor Edition. This virtual image allows you to construct and deploy WebSphere Message Broker and WebSphere MQ environments using WebSphere CloudBurst. The stack includes the RHEL operating system, and it is ready to run on VMware hypervisors.
With that in mind, here's an update to the WebSphere CloudBurst supported product matrix:
* Availability subject to dates documented in referenced announcement letters
As you can see, we are continuing our effort to expand the choice you have when using WebSphere CloudBurst to create and deploy application environments to your cloud. If you are interested in using WebSphere CloudBurst for WebSphere Business Monitor, WebSphere Process Server, or WebSphere Message Broker, check out the above announcements. You will find more technical information as well as planned availability dates.
Just one last scrap of food for thought. Feedback from you, our users, is instrumental as we continue to expand software choice with WebSphere CloudBurst. Please continue to let us know your thoughts and needs!
Typically we spend most of the real estate on this blog talking about cloud computing and specifically, IBM Workload Deployer. However, I am hoping that this week you permit me to take a bit of a detour to discuss a very important new announcement. Last week, IBM announced the early availability of the WebSphere Application Server v8.5 Alpha. In all fairness, your response may be 'You guys always have WAS Alphas. Why should I care about this one?' I have two words for you: Liberty Profile.
Based on my own experience in the IBM labs and my conversations with numerous enterprise developers out there, I think I understand many of the needs to create an efficient development environment. Developers need tools and runtimes that are lightweight, easy to install, simple to configure, and fast to recycle or otherwise update. Enhancements in our WebSphere Application Server v8.0 took many of these concerns head on with features such as directory-based install and drastically improved server startup times. The new v8.5 Alpha, and specifically the Liberty Profile, extend this developer focus even further.
The Liberty Profile is a lightweight, fast, and easy to use application runtime that you can download for free by visiting the WASdev community site. The design of the runtime is best described as fit-for-purpose and you configure it by selectively enabling and disabling features based on application need. For example, you may enable the servlet, JPA, and JSP features, or you may decide you only need to enable the servlet feature of the runtime. It is completely up to you! In addition to this innovative new runtime, the WebSphere Application Server v8.5 Alpha also includes free tools for Eclipse. These tools make it simple to create Liberty Profile server instances, start server instances, stop server instances, install applications, and remove applications. In fact, you can do all of this and even download and install the WebSphere Application Server v8.5 Alpha without ever leaving your Eclipse workspace! Check out the demonstration below to see an example of installing and using the new Alpha.
I really hope that you will participate in the new WebSphere Application Server v8.5 Alpha. The setup process that includes both tools and runtime will take just a few minutes of your time, and leaves but a small footprint on your machine (the Liberty Profile of the WAS v8.5 Alpha is only ~50 MB unzipped). In the meantime, you can find more information about the Alpha on the WASdev site or in the new Information Center. Finally, don't forget to join in on the conversation on the WASdev forum!
I'm going a little off-topic here as this has nothing much to do with cloud computing, but I thought this was definitely worth a mention. Just recently, IBM announced the new WebSphere Application Server for Developers edition.
This new edition of the WebSphere Application Server product is a completely FREE version of the application server that allows developers to download, install, and use the product on their personal machines. It is the same code base as the production version of the WebSphere Application Server, thus providing developers with an environment in which to unit test with confidence that their applications will run unchanged in the production environment.
Further, users can install free feature packs on this version just as they do with other WebSphere Application Server versions. If users have questions or problems using the WebSphere Application Server for Developers edition, they can use the same forums used for existing WebSphere Application Server offerings.
I'd encourage anyone interested to download the WebSphere Application Server for Developers edition. It's worth a look, after all it's free!
Lately Joe and I have been pretty vocal about bringing up the new IBM Image Construction and Composition Tool capabilities in IBM Workload Deployer v3.1. While writing about such new capabilities is always good, I think seeing is believing. In that light, I hope you will take a look at the recent demo I put together that shows how to use the Image Construction and Composition Tool with IBM Workload Deployer v3.1!
By utilizing the cloud hosting environment for applications, enterprises can benefit in several ways. Two benefits that immediately enter the picture are a consistent and responsive application user experience, regardless of demand, and a reduction in energy wastes caused by under-utilization of resources. Yesterday, IBM and SAP showcased technology that promises to enhance the state of the art in how these two benefits are realized.
In a demonstration at CeBIT, IBM and SAP previewed a technology that ensures demand-based capability of SAP applications hosted on IBM POWER6 servers. By using the Live Partition Mobility feature of the AIX operating system on the POWER6 servers, partitions are transferred across servers, regardless of physical location, in real-time. This means SAP applications can be migrated across physical resources in real-time as demand dictates. In addition to this capability, the solution also provides the ability to power up and power down physical servers to meet demand, thus eliminating energy wastes from under-utilization. What's more is that these two features are completely autonomic! You can read more about the demonstration here.
I think this revolutionary solution gives us a look into the future of cloud computing. Solutions will continue to evolve to become more autonomic and more integrated, and you can be sure that IBM will be on the leading edge of the movement.
One of my favorite things to do with users or potential users of WebSphere CloudBurst is to help them understand how they can construct a custom environment using the appliance. Typically, we take one of their existing application environments and discuss the configuration steps that contribute to its makeup. From there, we map the required configuration actions to different customization capabilities in the appliance. It is one thing to talk about how you can customize every layer of your application stack with WebSphere CloudBurst, it is quite another to talk about it in the context of an existing environment. This exercise usually serves to greatly enhance a user's understanding of how to construct tailored environments with the appliance.
While I cannot take every one of you through this exercise in the context of one of your own application environments, I can propose a scenario that will help to illustrate the WebSphere CloudBurst customization process. Consider that I want to deploy a clustered WebSphere Application Server environment whose application server instances utilize WebSphere DataPower XC10 for HTTP session management. In order to deploy such an environment, I would need to do the following:
Install an OS and WAS
Install the WebSphere eXtreme Scale Client binaries - required for integration
Construct a clustered cell
Augment profiles with WebSphere eXtreme Scale profile templates
Configure the application server instances to use WebSphere DataPower XC10 for session management
So those are the steps, but how do they map to WebSphere CloudBurst? First, I know that the WebSphere Application Server Hypervisor Edition image used by WebSphere CloudBurst encapsulates the installation of the OS and WAS. I also know that WebSphere CloudBurst will automatically construct the clustered cell during the deployment process. That means I need to address the installation of client binaries, augmentation of profiles, and configuration of application server instances. In order to do this, I will use a combination of image extension and custom script packages.
To get started, I extend an existing WebSphere Application Server Hypervisor Edition image and simply install the WebSphere eXtreme Scale Client binaries. I then capture that image and store it as my own unique image in the WebSphere CloudBurst catalog. Now, you may wonder why I did not capture the profile augmentation in the custom image. Remember, you cannot change profile configuration during the extend and capture process as WebSphere CloudBurst resets the profiles as part of capturing the custom image.
My custom image encapsulates the installation of the client binaries, so now I turn to custom script packages. I need two in this case. One script package will augment a profile (either deployment manager or custom node) with the WebSphere eXtreme Scale profile template. The second script package will configure application server instances to use WebSphere DataPower XC10 for HTTP session management. Once done with these script packages, I have all the assets I need to build my target environment.
Using my custom image, I build a pattern that contains the number and kind of WebSphere Application Server nodes that I want. I use the advanced options to define a WebSphere Application Server cluster ensuring its creation happens during deployment. Next, I drag and drop the profile augmentation script onto the deployment manager and custom node parts in my pattern. Finally, I drag and drop the WebSphere DataPower XC10 configuration script onto the deployment manager. The pattern is now ready to deploy!
For those of you that are visual learners like me, this demonstration provides a nice overview of exactly what I wrote about above. Check it out and let me know what you think.
One of the things that often comes up at some point in IBM Workload Deployer conversations is the notion of self-service access. Specifically, users want to know what the appliance provides that enables them to allow various teams in their organization to directly deploy the middleware environments they need. In other words, they want to use IBM Workload Deployer to tear down the traditional barriers that exist between those that request the environment and those that fulfill said request. Now, as we begin to elaborate on this notion, it becomes quickly apparent that in order to effectively enable self-service, IBM Workload Deployer must deliver a few things.
First, IBM Workload Deployer must provide the means to define users with various levels of access. Second, IBM Workload Deployer must provide the means to define resource access at a fine-grained level to different users and groups of users. Check and check. The appliance has been doing this since the beginning of WebSphere CloudBurst. Without those two things, the conversation of self-service access would end pretty quickly. However, there is a final capability that is equally important: IBM Workload Deployer must deliver a means to limit resource consumption at a fine-grained level.
In IBM Workload Deployer there are a couple of ways to achieve this. First, you could define multiple cloud groups and allow access to those groups in a way that maps directly to resource entitlements. While that may work in some situations, others call for even more granularity. You may want to allow multiple different users or groups to access a cloud group, but you may want to allow different consumption limits for each of these groups. In this situation, you can take advantage of environment profiles and a new option when defining users of IBM Workload Deployer.
Consider the case that you have a group of developers and you want to limit their consumption of memory in the cloud. First, you start by defining your development users and for each you select Environment Profile Only as the value for the Deployment Options field.
By selecting the above value for the deployment options of a user, you restrict that user to only deploying via an environment profile as opposed to general cloud group deployments. After defining all of your development users, you may choose to organize them into a user group for easier management. At that point, you can define environment profiles and determine which ones your developers should have access to using the Access granted to field of the profile.
Within the environment profile, you can define resource consumption limits for compute resource and software licenses. For instance, you can define a limit on the amount of virtual memory consumed by all deployments using the profile. It is important to note that the limit is cumulative for ALL deployments that use the profile.
Now that all of the controls are in place, consider the deployment process for one of your development users. They pick a virtual system pattern, click the deploy icon and begin to configure the pattern for deployment. In the Choose Environment section of the deployment dialog, your development user will only be able to select the Choose profile option for deployment. Further, they will only be able to deploy using the environment profiles to which they have access.
After the deployment completes, a look at the Environment limits section in the profile shows the current usage totals.
Now suppose another development user, or even the same one, comes along and attempts to deploy another virtual system pattern even though the profile limits have already been reached. The user can initiate the deployment, but they will get a near immediate failure owing to the fact that they would exceed consumption limits if the deployment were allowed to proceed.
The same kind of enforcement occurs regardless of the resource limit type. You can use this approach to limit the consumption of CPU, virtual memory, storage, or software licenses among the various different users or groups of users you define in IBM Workload Deployer. If you combine fine-grained resource consumption limits with varying permissions and fine-grained access, I think you are on the road to truly enabling self-service in the enterprise.
Script packages are an integral part of virtual system patterns in IBM Workload Deployer. By attaching script packages to your patterns, you provide customizations particular to your unique cloud-based middleware environments. Customizations provided by script packages might include installing applications, creating application resources, integrating with external enterprise systems, and much more. The bottom line is, if you are creating virtual system patterns, you will almost certainly be creating script packages.
Largely, the act of creating a script package is independent of IBM Workload Deployer. The appliance does not dictate a particular scripting language, so all you need to do is make sure you can invoke your logic in the operating system environment. Your script package may be a wsadmin script, shell script, Java program, Perl script, and on and on. After you create the actual contents of your script package, you will then load that asset into the IBM Workload Deployer catalog.
Once loaded into the catalog, you define several attributes of your script package, including the executable command, command arguments, variables, execution time, and more. The process for defining these attributes is trivial using the intuitive UI in IBM Workload Deployer, but I wanted to take a little time to remind you of a technique I recommend to all users defining script packages. You can actually package a JSON file within the script package that defines all of the script's attributes. The format of the file is simple, and I am including an example below:
The example above is one taken from a script package in our samples gallery, and it shows the basics of which you need to be aware. Notice that in the JSON file, you can provide a name, description, unzip location, executable command, command arguments, variables, and more. You only need to ensure that the name of this JSON file is cbscript.json and that you include it at the root of the script package archive. Once you have done that, you load the script package archive into the catalog, refresh the script package details, and voila -- all the attribute definitions appear!
You may ask why I recommend this since it could seem like an unnecessary step. My answer to that is that you have to define these attributes anyway, so you might as well capture it once in the file. Once you capture it once in the file, you can ensure that if the same script needs to be reloaded, or if you need to move it to another appliance, its definition will be exactly the same (and presumably correct). I use this approach for all of my work, and for all of the samples I contribute to our gallery, and it really saves me a lot of misplaced effort that can result from typos. If you are out there creating script packages, try adopting this approach. I'm pretty sure you will be happy you did!
The concepts that govern users and user groups in WebSphere CloudBurst are fairly basic, but I get asked about them enough that I believe they warrant a short discussion. First things first, you can define users in WebSphere CloudBurst and optionally define user groups to assemble users into logical collections. For both users and user groups, you can assign roles that define the actions a particular user or group of users can take using the appliance.
All of that is straight forward, but it can get a bit tricky once we start considering the effects of user permissions when managing at the user group level. The basic premise is that when a user belongs to a group or groups, the user's effective permissions are a sum of the permissions to all of the groups to which they belong. While that is easy to say, and maybe even to understand, I feel like an example always helps.
Consider that we have a single user WCAGuy that belongs to the PatternAuthors, ContentCreators, and CloudAdmins groups. The permissions for those groups are as follows:
PatternAuthors: Users in this group have permission to create and deploy patterns
ContentCreators: Users in this group have permission to create catalog content as well as create and deploy patterns
CloudAdmins: Users in this group have permission to administer the cloud, create catalog content, and create and deploy patterns
Naturally then, it follows that the WCAGuy user can administer the cloud, create catalog content, create patterns, and deploy patterns. So then, what happens if we remove the WCAGuy user from the CloudAdmins user group? Well, as you may expect, there is an update to the user's permissions. The WCAUser user can no longer administer the cloud, but they can still create catalog content, create patterns, and deploy patterns (owing to their membership in the other two groups). Similarly, if we next removed the WCAGuy user from the ContentCreators group, then the user would retain only the permission to create and deploy patterns.
Just one more thing, let's talk about what happens when I remove a user from a group and they no longer belong to any groups. Consider that I created the WCAGuy user with the permission to create catalog content as well as create and deploy patterns. Next, I added the user to the CloudAdmins group, meaning the user now has the permission to administer the cloud. I promptly decide that the user has no business with those permissions, so I remove the user from the CloudAdmins group. What happens? The user retains the permission set of the last group to which they belonged. In this case, that means the WCAGuy user retains cloud administration rights. I have to update the user's permission set if I want to take that right away, but in this case, it will not automatically disappear upon removing them from the CloudAdmins group.
I hope this helps clear up any ambiguity you may have had concerning users, user groups, and permission sets in WebSphere CloudBurst.
IBM trekked further into the cloud today by announcing new offerings that will help clients to leverage the cloud within their enterprise. These offerings include development environments, test environments, and desktop services running either in the IBM cloud or a private cloud, as well as something called IBM CloudBurst (not to be confused with the WebSphere CloudBurst Appliance).
In particular, the IBM CloudBurst offering jumps out to me as a truly innovative offering. This offering promises our clients a complete private cloud solution that includes hardware, software, and services all in a single package.
Essentially it sounds like the IBM CloudBurst offering is all about building out a cloud-enabled data center. The hardware provides the bulk computing power to host private clouds, and the software provides enhanced service management capabilities to give users full control and insight over the elements of their private cloud.
Couple these computing capabilities with included IBM service, and this means clients should be able to get up and going with their private clouds very quickly.
This new offering really seems to hit a sweet spot. While the number of cloud computing offerings continues to grow, few if any offerings take such a holistic approach to providing such a solution.
This type of comprehensive solution gives users what they need in terms of the hardware to host a private cloud and the software to manage that cloud. Just as importantly though, it helps users put the hardware and software to work via implementation services also offered in the solution.
I invite you to take a look at the new IBM CloudBurst offering, and don’t forget to sign up for the IBM CloudBurst webcast scheduled for June 25th.