November 1, 2012 | Written by: Dominique Vernier
Share this post:
Through this blog, I would like to explain the extra benefits you can get from IBM SmartCloud Application Workload Service (SCAWS) versus creating your own scripts with the provided IBM SmartCloud Enterprise API to deploy a topology on IBM SmartCloud Enterprise.
IBM SmartCloud Application Workload Service (SCAWS) is one of the services provided by the IBM SmartCloud Application Services. SCAWS is based on the same deployment engine as IBM PureSystems, called IBM Workload Deployer (IWD).
We have two types of deployment engines on IBM SmartCloud Application Workload Service, one for virtual systems and another for virtual application patterns.
You can find definitions of these by reading Fabio’s blog “IBM PureSystems acronyms for beginners” on Expert Integrated Systems blog. Because SCAWS and IBM PureSystems used the same deployment engine (IWD), we can reuse the documentation.
First, SCAWS is much more than a simple script to deploy a topology, because the script will finish once the topology is deployed. Here SCAWS will follow your deployment, and you will be able to interact with it through the SCAWS console until you decide to delete the deployment.
Now, let me list a number of capabilities you get out of the SCAWS box which would require a huge effort to implement yourself.
Pattern based: For creating a virtual application pattern, you will use a pattern-type, creating a virtual system pattern which requires images and scripts. Pattern-type, images and scripts can be provided out of the box, but you can also create your own. It is based on a pattern, it is easily reusable, and is easier to modify than a bunch of scripts.
Portability: As the same deployment engine (IWD) is used on SCAWS and IBM PureSystems, you can use the same Virtual application pattern on both platforms. You can also develop a pattern on one platform and port it to another platform.
Auto-Resiliency: SCAWS offers auto-resiliency, which means that if your virtual machine crashes, SCAWS will automatically regenerate a new one with the same IP address and same configuration.
Policies: For example, the out of the box ‘Web Application Pattern’ has policies that you can apply on the ‘Enterprise Application’ component. The most interesting policy is the ‘Scaling‘ policy. By setting this policy, an instantiated pattern can dynamically scale in and scale out depending on rules (for example: based on request response time). You can do this also while developing your own pattern-type.
Monitoring: In order to implement the above scalability policy, you will need monitoring functionality. Out of the box, each deployed virtual machine contains an agent which monitors some metrics. These metrics are visible from the portal. You can also develop your own metric collectors and have them displayed in the portal and/or use them in a policy. Here, for example, is a collector I created to measure the number of files on a directory.
Operation and Tweak: Once a pattern is deployed and is defined in the pattern-type, you can take several actions on the deployed pattern. For example, the ‘Web Application Pattern’ allows you to upload a new version of the ear file for your application. The tweak as opposite of operation will allow you to persist parameter in the deployed topology and thus can be taken into account in case of auto-resiliency.
Updates: If a patch is available for your pattern, you can apply it either on the pattern or on instances of this pattern. The patch could be for the pattern itself or a software installed on a server by the pattern.
Conclusion: For all the reasons explained above, I would choose a pattern-enabled deployment tool which follows the entire lifecycle of my deployment such as IBM SmartCloud Application Workload Service (part of IBM SmartCloud Application Services) to deploy my topology on the cloud.