Originally posted on IBM Developer blog “Exploring PureApplication System, Software Service and more” by Jessica Stevens on 1 May 2013 (4857 visits)
A key use case for PureApplication System is to use it to build private, on-premise cloud environments. Or, in short, it is a system that lets you build your own cloud. An important characteristic of cloud computing is to use existing IT resources as efficiently as possible, assigning them dynamically to ever changing workloads. This is typically achieved through virtualization, and PureApplication System is no different in that respect: you can create and remove virtual machines on the fly, and automatically, as a result of real user demand towards the solutions running in the cloud. What’s more, you can automatically configure these virtual machines to run middleware and applications. So, the ability to dynamically create, remove, change and manage virtual environments hosting middleware-based solutions that comes with PureApplication System is in direct support of one of the principles of cloud computing.
How do we do that? Patterns. Let’s look at a concrete use case: you want to automate the provisioning, installation and configuration of a specific topology. That is, topologies that often consist of more than one (virtual) machine, containing multiple middleware components that have to be configured to work with each other. For example, a typical set up of WebSphere Application Server will include Application Server instances, a Deployment Manager and one or more HTTP Server instances. Often, a Database Server is needed. In order to dynamically provision these types of environments, simply creating new virtual machines is not sufficient. Multiple virtual machines have to collaborate, software has to be installed and configuration scripts have to be executed. Most of our customers have developed scripts that automate some aspects of this, but in most cases, creating new environments, or removing old ones, is a tedious and time consuming task. And that’s not even considering the need to be able to scale these environments to address real usage patterns.
For this, PureApplication System has the notion of Virtual System Patterns. A Virtual System Pattern, or VSP, offers an abstract view of a topology, represented as a visually composed graph, in which each node stands for one virtual machine. And for each node, you define the software image that is loaded on to the virtual machine. A software image is stored in a standard format called OVA and encapsulates the operating system and any other software that will be running on the virtual machine. Moreover, each node in the VSP can contain script packages that implement further configuration that is required for the virtual machine to function. Properties defined for one virtual machine (for example, its IP address) are available to script running in another virtual machine. This is very useful if multiple VMs have to be integrated with each other, for example, when a JEE Data Source is created on an application server that points to a separate database server. You can also control the sequence in which the various elements of a VSP are executed when deployed. Using the ‘application server plus database’ example again: the data source in the application server cannot be defined until the database server has been provisioned and installed. And you define all this using drag and drop in a graphical tool.
Modeling and automating middleware topologies: Virtual System Patterns
A topology described in a VSP is deployed and managed as one unit. With the push of a button (or, via the execution of a client script) you can deploy a topology, provision a set of virtual machines, install an operating system and additional middleware on them, and run whatever configuration is required. PureApplication System offers a console that lets you monitor and manage the resulting virtual machines. Built-in placement policies make sure that the components of the topology are spread across multiple physical compute nodes. The administration of the installed middleware, if not scripted, is done in the traditional way, using administrative consoles or whatever method of access the middleware provides. In that respect, a virtualized environment deployed as a VSP is no different that a physical environment with actual servers.
The more complex your topology is, the more benefit you will get from this concept. And IBM as well as a number of ISVs offer their solutions in the form of such patterns, making sure that the topologies contain optimized configurations that you can simply leverage, or adjust to fit your needs. But the bulk of the work is already done! I expect that in the future, most software products will come packaged with patterns that automate their installation and configuration into readily deployable IT environments.
IBM Cloud Pak System 