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.

• Components are things that you can drag and drop in the Pure VAP editor.  Everything about them, from their appearance to their properties and actions and the real system nodes they may represent, is defined in a plug-in.  Components often represent real world nodes such as a DB2 instance, but they don't have to.
• Links between components also have properties and are in fact a kind of component, defined in a plug-in.
• Policies are sets of rules that apply to components or to the application as a whole (e.g. ‘when latency above X, spin up Y new VMs’).  Policies, too, are actually a kind of component, defined in a plug-in.

 

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 application-specific rather than Pure-specific, and in many cases won’t necessarily involve a large investment in skills.  In fact, assuming plug-ins have been made for you (which is the case for many key IBM products already) there is no need to drill any deeper.  Having said that, if your building blocks are anything other than core IBM products, you’ll need to factor in the effort required to wrap those building blocks up as plug-ins.  Once again, it’s not conceptually difficult; PureApplication does not add much overhead to the complexity of the underlying application.  A quick guide to structure and terminology, however, can be useful in building up a mental image of what is involved.

 

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:

• Components: a component is anything that's visible as a box in the VAP editor.  Components often represent real assets such as databases, but they don't have to.  Components have rules about what properties they can have, what actions can be taken with them, and what policies can be attached to them.
• Links and Policies: along with components, these make up the plug-in’s outward-facing interface.  They are defined in the same place as components.
• Packages: within a plug-in, a package is the unit of actual content that is deployed.  Packages are internally composed of one or more ‘parts’ and ‘node parts’ (see below).  The script files that define the fundamental behaviour of a plug-in reside in these.
• Templates: a template tells Pure what kind of VM a plug-in requires.  There are several ways to give Pure this information, but templates are the most convenient in most cases.  Templates take the form of fairly simple configuration files, and a plug-in may have several of them.
• Metadata: the plug-in’s name, the pattern types to which it belongs, and so forth.

 

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:

• The components and the packages are separate sets of entities having a many-to-many relationship.  For example, a package representing the installation of a particular set of files might be referenced from many components, but one component might use different packages depending on the node hardware.
• Components are part of the ‘application model’, the set of data that determines how the plug-in’s contents are presented to the user.  Components (plus links and policies) are thus the presentation layer of the plug-in, whereas packages form the actual content.

 

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.

 

Package concepts

Packages have some metadata, including their names and optionally their hardware requirements, but generally they contain two types of data item:

• Node parts are sets of scripts that are per-node and are shared by all services on a given node.  They have simple lifecycles which consist simply of being set up on the node.
• Parts are the main building blocks of Pure Application (we had to get there eventually) and have complex life cycles. 

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.  These express an actual asset, such as an EAR file deployed on an app server.
• Links.  These express a relationship between two components.
• Plug-ins.  These are add-ons to a component which handle features such as scalability.

 

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.

 

Summary

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.

Etiquetas:  virtualsystempattern patternsofexpertise virtualapplicationpattern plugins pureapplication iconsolutions