The hidden simplicity of the PureApplication Virtual Pattern
Jessica Piziak 120000AWT2 Visits (2061)
This post was written by Benjamin Peterson, Head of Consulting at Icon Solutions.
At this point in the history of PureApplication System, one of the most important questions is how a given organization can come to a proper understanding of the cost/benefit proposition offered by PureApplication. It’s a far-reaching question and this post will focus on only one facet of it: on the cost side of the equation, as things stand many people perceive the work of migrating software applications to PureApplication as potentially expensive.
Putting applications on PureApplication is not inherently complicated. Sure, complexity is bound to arise, from the details of integration between products, and from the uniqueness of the actual business functions that applications support -- but there is very little complexity that is inherent to the platform.
As one of the relatively few organizations creating PureApplication patterns and plug-ins at this time, we've found that some things do tend to mask the underlying elegance of PureApplication. Chief among these is the wide array of terms and concepts within the PureApplication world, which can at first be difficult to relate to concrete assets. The IBM Infocenter documentation is highly effective from a developer point of view, but it takes a very bottom up approach, describing the contents of a plug-in file by file in a way that does not help us build up a mental image of the total level of skills investment involved.
In this post, a complementary top-down guide is presented, focusing on the concepts rather than the files.
The easy part: The Virtual Application Pattern
It's important to bear in mind that PureApplication contains two different ways to structure a Pure-hosted application; the Virtual System Pattern (VSP) which is based on CloudBurst technology, and the Virtual Application Pattern (VAP) which comes from the SmartCloud world. VSPs offer interesting short term options and are certainly worthy of exploration, but VAPs are where PureApplication’s value is likely to develop in the long term, so we will focus on VAPs in this case.
So, within your VAP, what are the main entities? It's very simple; a VAP is made up of the application pattern itself, and the plug-ins that allow actual VMs, services, and other system elements to be instantiated in Pure. This is a very strongly two-level structure; working with the VAP and working within a plug-in are, rightly, quite different activities. Let's look at the VAP itself first; this is an easy entity to work with and if everything is set up right it’s not necessarily highly technical.
A VAP is a member of a ‘pattern type’. This is a very lightweight concept that simply groups plug-ins together; a VAP in a given pattern type can contain plug-ins that are in that pattern type. There’s a bit of metadata associated with a pattern type but it’s not particularly critical.
Figure 1 - Overview of VAP structure
The VAP contains components, their interconnections, and the policies that are applied to them.
From this overview, it's easy to tell that the vast bulk of the value in PureApplication VAPs comes eventually from the plug-ins. These plug-ins are in fact very powerful objects, nothing less than complete recipes for instantiating and linking together all your Pure-hosted IT assets. Plug-ins come ready-made by IBM to some extent, but to do anything original with Pure at this stage you will not be able to escape an understanding of them.
From the point of view of the solution as a whole, there’s a lot of work to be done at the VAP level. This work is appl
The almost as easy part: The Plug-ins
One of the oddest things about learning to develop PureApplication plug-ins is that the physical folder and file names that make up the physical form of a plug-in sometimes have little in common with the conceptual names that identify the actual value in a plug-in. Leaving aside the physical details, let's enumerate the logical contents of a plug-in:
Put together, the entities and relationships within a plug-in can be informally represented like this:
Figure 2 - Overview of plug-in structure
The important points to bear in mind about these are:
Detailed description of the physical representation of these entities is best left to IBM’s documentation. However, it’s worth summing up some of the terminology that’s specific to the entities within a plug-in.
Packages have some metadata, including their names and optionally their hardware requirements, but generally they contain two types of data item:
Physically, parts consist of life cycle event handlers plus actual application logic and data payloads. The life cycle of a ‘part’ is managed by ‘roles’, a concept taken from Tivoli, specifically from Workload Manager; Workload Manager scripts are used to express role status and dependencies.
Component, Link and Policy concepts
Components, Links and Policies are defined in the ‘application model’ area of the plug-in. They take the physical form of config files which may define three kinds of entities:
Components have static state, and also ‘operations’ and ‘tweaks’ which are post-deployment actions that can be carried out to change component state. These operations are mapped to scripts within the packages that implement the component.
And that’s it for the high-level content of a plug-in. At the software development level, the devil is in the details, but at the architecture level the concepts given here cover 90% of what a plug-in does, and thus 90% of what is done when an application is migrated to a PureApplication VAP.
In this post, I’ve tried to create a mental image of what the engineers actually moving your assets to PureApplication will have to deal with, at the application level. I’ve tried hard to stay away from discussing the physical files involved, and to avoid getting into the complex details of roles and dependencies. Instead, the aim has been to expose the fundamental simplicity of VAP design. The reader is warned that to achieve meaningful real world results, migration teams may need to dig slightly deeper!
Benjamin Peterson, Icon's Head of Consulting, has been planning and delivering IT solutions for the financial sector for the last 15 years, advising on major programmes of change and technological investment. His approach is to keep a sharp eye on the technological details and thus the real costs and benefits to business of each new technology choice.