WebSphere eXtended Transaction Runtime Blogging Space
with Tags: patterns X
Well, by now most of us are familiar with the word "Patterns" arising out of the PureApplication System. It offers a nice concept to encapsulate all actions (often we call that as a best practices) in to a single deployable unit (technically a compressed tar file) to represent a workload. The PureApplication system defines the framework and provides the necessary platform services for creating these patterns. The benefits of creating such patterns is immense as it provides simplicity and the ability to do repeatable deployments of your applications with just few clicks away. Gone are the days where you have to take a bottom up approach for configuring OS, middleware products, applications, etc,. to run your applications. Its just a matter of minutes for deploying your same applications with the PureApplication Systems's pattern approach.
In terms of patterns it can be classified in to System pattern and a Application pattern. There's always a question to see what's the difference between these two, and which one to be chosen for the application deployment. A virtual system pattern (vsp) is often used in situations where you need to describe a system topology that you want to deploy, especially when it incurs deployment of your products on to multiple instances/systems. This is more of a traditional method of deployment, however once done can be captured (or recorded) as a system pattern and further deployments gets easier with redeploying the pattern itself, rather than creating the topology again. To build the virtual system patterns there are virtual images available for the product that you want to include in the topology along with add-ons and script packages that help you to configure products.
A virtual application on the other hand does not come with the customization control that you had with defining a virtual system pattern - i.e. we do not have to define a topology and other descriptive elements in the virtual application pattern. In the virtual application pattern, it is mainly focused keeping applications (and its associated factors such as SLA) in mind, and the toplogy to run that application workload is determined by the system dynamically. This frees up the application deployer in terms of defining a topology or required system components - and instead focuses only on their application deployment and specifying its SLA and other business application specific requirements. Behind the scenes the plugins and the PureApplication system provides an execution platform appropriately for the deployed applications.
As an analogy for comparing vsys vs. vapp, if you are a vivid reader of EFY (Electronics for You) magazine, it describes solutions say for example if we want to create a water level controller. A vsys way of looking at it is to create a PCB board and define the various electronic components and how they interact with each other - all done from a ground up level, you can customize the board to have the functions that you require in the water level controller... for a vapp you simply go to an electronic shop and request for a ready-to-go device that helps you with the water level controller, albeit with limited control and functionality as provided by that specific device.