|Over the last three posts I've been discussing a few of the most frequently asked questions regarding the WebSphere CloudBurst Appliance. I'd like to wrap up today with a fourth and final installment.|
|If you have read some of my entries before, or if you have read any of our WebSphere CloudBurst articles on IBM's developerWorks, then you know that the appliance brings extreme simplification and safety to applying fixes and service level upgrades to running WebSphere Application Server virtual systems. Users select a virtual system, choose a fix or service level upgrade, and then WebSphere CloudBurst drives the application of the fix or upgrade to the system. Before applying the fix or upgrade, the appliance takes a snapshot of the virtual system, and users can simply click a button to roll back to the previous state if the process produces undesired results.|
|This is a pretty strong value add to WebSphere Application Server management and one that our users typically immediately understand. Almost always though, after users see this they are curious about another aspect of rolling out fixes and upgrades in WebSphere CloudBurst. In particular, they want to know how they ensure that all subsequent deployments (after applying the fix to a specific virtual system) can be ensured of having the correct fixes and service levels.|
|The answer to this inquiry is that there are a couple of different ways to achieve this, and it depends on what you are try to accomplish and your preferences. For instance, if you want to make sure all of your subsequent deployments have a particular interim fix, you will likely go the route of image extension. First, you pick the WebSphere Application Server Hypervisor Edition image in your catalog to which the fix applies. Next, you extend that image, and once a virtual machine based off the image is accessible, you use existing WebSphere Application Server tools (Update Installer) to apply the fix. After the fix has been applied, you can capture the updated image and then use it as the basis for patterns created from that particular version of the WebSphere Application Server.|
|On the other hand, if you are looking to ensure subsequent deployments are based on a new level of the WebSphere Application Server, your process will be a bit different. First you would load a new WebSphere Application Server Hypervisor Edition image (based on the new level of WebSphere Application Server) into your WebSphere CloudBurst catalog. Then you would select any of your customized patterns you wanted to upgrade to the new level, clone that pattern, and simply select the new image as the basis for the pattern. All of your other customizations are preserved. Really, it's that simple!|
|I hope that over the last month I have answered some of the more common questions about WebSphere CloudBurst. At any point if you have any questions feel free to email me or leave a comment right here on the blog.|
|-- Dustin Amrhein|
A view from the clouds: Cloud computing for developers
with Tags: virtualization X
DKA 0600026VJ2 Tags:  websphere_cloudburst virtualization cloud_computing private_cloud websphere 1,608 Visits
jabohn 060000RDQ6 Tags:  virtualization ibm_puresystems ibm_workload_deployer ibm_pureapplication_syste... 1,556 Visits
DKA 0600026VJ2 Tags:  cloudburst cloud_computing websphere_cloudburst private_cloud virtualization 1,526 Visits
Ask any enterprise about its overall IT architecture or strategy, and it won’t be long before you’re taking a look at its middleware infrastructure and the services that are hosted there. This infrastructure is often key to an enterprise’s IT capabilities because many services hosted there are outward-facing, revenue generating applications. This infrastructure needs to be able to support applications to provide efficient performance despite demand, and ideally this need is carefully balanced against inefficient resource use. However, that balance is much easier said than done. In reality, it’s often the practice to statically configure environments for the peak demands of the system thus ensuring responsive services, but ultimately leading to resource and economic wastes during off-peak times. WebSphere Virtual Enterprise seeks to address this need for balance by extending the cloud computing concepts of virtualization and virtualization management to middleware and middleware applications.
You may be wondering how WebSphere Virtual Enterprise provides such balance. That brings us to a very important concept of WebSphere Virtual Enterprise. Dynamic provisioning of middleware and applications is directly linked to application performance. Application performance goals are stated to the system via application service policies. These goals are expressed in terms of both application responsiveness and the importance of achieving such responsiveness in relation to other applications deployed within the system. This allows for a quantitative description of what ‘good’ performance is, and it also allows users to separate business-critical applications from those that are a bit more secondary to the business. By linking provisioning directly to application performance, enterprises can be assured that resources are being allocated based on the needs of users of the system.
It’s nice to have the ability to state application service policies, but the policy is nothing if the system doesn’t have the ability to act on it. That’s where dynamic clusters and on demand routers (ODRs) enter the picture. Dynamic clusters provide the capability to expand and contract the number of middleware servers and associated applications that are available to serve requests. If the system notices service policies are being violated, more instances of servers hosting the application associated with the service policy can be started on the dynamic cluster. Conversely, if WebSphere Virtual Enterprise detects that service policies can be met with fewer resources, instances of servers can be stopped and resources reclaimed. It’s also important to point out that dynamic clusters can contain both IBM and non-IBM middleware components allowing the capabilities of WebSphere Virtual Enterprise to extend to many different technologies.
ODRs are the entry point into a WebSphere Virtual Enterprise environment and help to shape the request traffic entering the system. ODRs provide all the features of an HTTP 1.0/1.1 compliant proxy, and incorporate additional on demand features such as request prioritization, request queuing, request routing, and more. Intelligent request routing is achieved by balancing the current system load with the service policies of the application being requested to ensure members are targeted in a way that allows the system to meet the service goals. ODRs provide the necessary gate-keeping duties to most effectively utilize components of a WebSphere Virtual Enterprise environment.
The four short paragraphs above only begin to scratch the surface of WebSphere Virtual Enterprise. Its ability to provide dynamically-scaled, autonomic middleware and middleware applications can give companies a leg up over its competition by ensuring responsive services balanced against efficient resource use. In effect, WebSphere Virtual Enterprise helps companies implement a smarter middleware infrastructure. Click here to read more about WebSphere Virtual Enterprise, and don’t forget to follow us on Twitter. If you have any questions about WebSphere Virtual Enterprise or cloud computing, send us an email at firstname.lastname@example.org.
DKA 0600026VJ2 Tags:  workload rafw iwd ibm cloud_computing virtualization deployer websphere 1,363 Visits