When IBM released Fixpack 3 for MQ 8.0 on Thursday 18th June, they also delivered a new Virtual System Pattern for PureApplication. This pattern is compatible with Intel based PureApplication System models (W1500 and W2500), as well as PureApplication Software and PureApplication Service on SoftLayer. It replaces the existing MQ 7.x “classic” Virtual System Pattern, which was based on a Hypervisor Image. The old pattern had a number of limitations, including lack of compatibility with externally managed cloud groups (which are required for multi-system deployments on PureApplication System).
The new pattern offers a number of new features including:
Ability to apply a new fixpack to deployed pattern instances through the PureApplication management interfaces
Support for multiple Queue Managers on the same VM
Queue Managers are automatically stopped/started when appropriate by PureApplication
Separate filesystems can be used for MQ logs, data and errors
The other bit of good news is that clients who have a license for MQ 8.0 Advanced Edition are now automatically entitled to download and use the new Virtual System Pattern. You should be able to download the IBM MQ 8.0.0.3 from Passport Advantage as documented here. The part number for the MQ 8.0.0.3 Virtual System Pattern is CN5Q8ML.
You can read more about what has been delivered in IBM MQ 8.0.0.3 here. And finally, here is a link to the IBM MQ Virtual System Pattern in the MQ 8.0 Knowledge Center.
Earlier this week IBM released version 1.0.0.4 of the PureApplication pattern types for WebSphere Application Server. To be more precise, IBM released 3 new pattern types which can be downloaded free of charge from the links below:
These new pattern types include fixes for a number of issues listed further down. However the WebSphere ND pattern type in particular addresses two key concerns from clients:
Cell and Node name improvements: Ability to specify who the cell and node name is formed. You can now chose to no longer automatically have a uuid appended to the cell name or node name.
Improved custom node federation process: You can now create a pattern that just contains a custom node and deploy to an existing deployment manager
The documentation can be found here in the Knowledge Center. Finally here is a list of issues that has also been fixed in this new pattern release:
For long Technotes like this have been IBM’s favorite way to make end users be aware of issues and workarounds in our products. Henceforth it has been decided that IBM will no longer publish these including PureApplication related ones.
IBM Support now documents these issues in a question/answers style on developerWorks Answers instead. If you have not already done so, recommend to follow all answers tagged with PureApp and PureApplication:
If you’ve read about IBM’s PureApplication System, then you’ve probably heard the phrase ‘patterns of expertise’ used quite a lot. But what exactly are they and how can they help you?
Here I answer five questions I’m commonly asked about the patterns. And if you want more, here’s a more detailed Guide.
1. WHAT EXACTLY IS A PATTERN OF EXPERTISE?
Basically, they’re patterns that are used to codify the best practice for deployments. IBM introduced the term to describe the concept of encapsulating installation and configurations of anything from a single-product right the way up to a full solution level topology. They are essentially models backed-up by the actual code that installs and configures the components in a solution. Using them means that you can deploy the solution – time and time again – with 100% repeatability.
2. BUT WHAT IF THAT ‘BEST PRACTICE’ DIFFERS FROM MINE?
That’s not a problem. Firstly, there’s a range of patterns from the more basic to more complex. You can use the more complex patterns as templates for when you import your own estate into PureApplication Systems rather than alter your own standards to fit into the provided patterns.
3. WHAT TYPE OF PATTERNS ARE AVAILABLE?
The patterns of expertise have the capability of interacting with the hardware as well as the software layers of PureApplication Systems. However, the ones I describe here are ones that you can interact with directly and solve the middleware and software layer of the problem.
Your choice of patterns will depend on your needs:
Basic patterns: Are ones that help you install a single piece of software onto the PureApplication platform. It’s important to note though, that many of these patterns will incorporate both the installation and the configuration of the product (this may be internal configuration or connection to another product). They vary in functionality too – for example some patterns show you the best-practice way to do High-Availability or scaling of a single product.
Multi-products patterns: These patterns are more complex and involve multiple products. They encapsulate the components and configuration of the components into an easy to use pattern so that you can install a complex suite of products. These patterns give you the confidence that the moving parts are working together in a fully scalable, highly available and secure configuration.
Solution level patterns: These patterns are multi-product, highly complex topologies. These are patterns that you will need to write yourself, to encapsulate your own best practice and complex system integration. You may end up using the basic or multi-product patterns within your solution level patterns however the solution level pattern will encapsulate your very specific topology that no one else could have written a pattern for.
4. WHERE CAN I FIND PATTERNS THAT HAVE ALREADY BEEN PRODUCED?
You can download a number of patterns (produced by IBM and their business partners) from the PureSystems Center. Most of these patterns are the basic ones but there are a few multi-pattern ones. Obviously, because solution level patterns are based on your own highly personalised topology they probably wouldn’t be available on the Centre.
5. WHAT DO I NEED TO CONSIDER BEFORE WORKING WITH PATTERNS?
To know which patterns are right for you, you need to understand your project at both a high and a low level. You may need a PureApplication specialist to help you review your project in relation to PureApplication’s capabilities. Writing solution level patterns will need very broad and deep knowledge of your topologies as well as of PureApplication.
Once you start using patterns, you’ll soon find that having a library of installation and configuration components means that your solutions can be deployed in a far more robust, repeatable and governed manner.
To find out more about the patterns-of-expertise, have a read of my Guide.
John Hawkins is a Principal Consultant at Icon Solutions. He has over seventeen years of IT industry experience and worked for IBM at their Hursley laboratory on MQ, Message Broker and cloud technologies . John is highly skilled in Pure Application systems, messaging and implementing Proof-of-concepts with bleeding edge technologies. He prototyped MQ and WESB on PureApplication Systems as well as inventing a new type of “business driven” scalability policy.
In my previous post, I discussed the value of patterns of expertise. We can get even more out of a pattern if we can leverage pattern portability through different cloud environments!
Pattern portability provides greater flexibility by leveraging a specific cloud environment based on your requirements. Let’s consider an example: My company needs to start a new project, which requires new hardware, new software, and, of course, all the activity to set up and configure the system. The procurement of all these components can take weeks, or even months. Wouldn’t it be great if I could borrow some public cloud environment, have my system team start designing a pattern that fits the requirement, and maybe have my development team start testing the new application against a test environment quickly? And wouldn’t it be even better if I could export everything my teams have done on the public cloud, import it in an on-premise, cloud-based solution without losing anything, and deploy it in minutes?
Or, I may need the opposite. My company may need additional resources to support an expected peak on an application due to a marketing campaign. Buying or finding additional hardware, software, and configuring everything may take weeks. Wouldn’t it be great if I could just export my pattern and import it on a public cloud provider, click on deploy and have a virtual system up and running, configured, and optimized in a few minutes? This can be done easily if you work with patterns!
Those examples are just ideas. If those samples make you curious, have a look at the Redpaper “Cloud Computing Pattern of Expertise”! The Redpaper covers the value of patterns and how to leverage pattern portability against the different cloud environment provided by IBM.
Feel free to share any comments or thoughts on this post!
While collaborating on the writing of the Redpaper “Cloud Computing Pattern of Expertise” I want to share my initial thoughts on pattern portability in the different cloud environments and how these can positively affect an adoption of a pattern-based approach at an enterprise level. Moreover I’d like to share the results we’re achieving in collaborating at an international level on this technology and who can benefit from this approach.
I’ll leave the technicalities and the detailed results of our work in the dedicated paragraphs of the Redpaper, but in future posts I’d like to share some of the highlights we’ve discussed during the creation and editing of the Redpaper and what we see as beneficial reading for you.
First of all, I want to point out that patterns are not a product out-of-the-box feature, but are the best way to create your recipe, which can combine all of the expertise acquired during years of complex infrastructure management tasks to optimize and automate software deployment. Patterns describe, in a logical way, a repeatable solution based on various images, middleware, applications, and runtime configurations. The result of a deployed pattern is a configured, tuned, and optimized application environment.
The aim of Patterns of Expertise is to create a repeatable approach and an easily deployable environment. This expertise applies to different IT areas, such as:
• Installation • Configuration • Optimization • Management of an environment
In the new world of “clouds” (several private or public cloud), patterns provide a dynamic and efficient usage of IT resources with consistent results while building complex solutions, which leads to a saving in time, money and resources. Read the Redpaper introduction to learn who are the impacted IT professionals and the benefit they can gain in such an approach.
I’d like to simply stress the focus on what happens when using a pattern: instead of spending (and wasting time) on just infrastructure requirements, products’ technical notes and afford problems in installation and basic configuration, you use an “abstraction layer” that will let you leverage a highly optimized and automated solution with built-in features to manage high availability and dynamically react to changing conditions based on your policies defined to accomplish specific business level requirements.
So, when you adopt virtual application patterns as we describe in the Redpaper, deployment tasks require minimal knowledge of the underlying middleware infrastructure, and you can iterate multiple instances of the same application, thus providing the lowest total cost of ownership and shortest time to value.
Hope you’ll have the chance to understand and use this repeatable and secure pattern approach: I encourage you to learn more by reading the chapter on pattern value and pattern portability.
Feel free to comment and share any thoughts on this topic!
In a previous post I started discussing the lifecycle management of patterns. In this post I will focus now on a specific environment: IBM PureApplication System.
Lifecycle management of running systems is probably one of the most important and time consuming tasks in the day-by-day IT specialists’ activities. Late last year, the IDC estimated that in 2013 more than 68% of the IT budget goes to the management and administration of the existing environment*. IBM’s PureSystems deliver value throughout the IT lifecycle, by saving deployment and management labor hours, which helps in reducing that 68% to a lower number. Key to providing these savings are the Patterns of Expertise, which can be provided by IBM, by IBM’s Business Partners, or built by yourself.
One of the new features in the IBM PureApplication System v1.1 release offers an improvement of the update process of your deployed instance’s operating system. Managing the lifecycle of a deployed system requires you, at some point, to upgrade the operating system of the running VM, either to apply a patch or to install any other system components. PureApplication System v1.1 provides a way to upgrade not only the “classic” Red Hat-based and AIX-based Hypervisor Edition images, since the support for those operating systems came with v1.0, but also images based on the newly supported Windows OS. The updates are managed through shared services, with a slight difference:
To update the Red Hat-based images, you have to deploy the Red Hat OS Update shared service. This service provides a local Yellowdog Updater, Modified (YUM) repository for the cloud group it is running on. IBM provides a certificate that grants access to the updates form Red Hat.
To update the AIX-based or the Windows-based images, you have to deploy the IBM Endpoint Manager shared service which allows your system to connect to an external IBM Endpoint Manager server.
This new feature greatly simplifies the lifecycle management of operating system updates in PureApplication System v1.1, and hence the overall simplified management experience that PureApplication System offers.
For additional details on how PureApplication System, and more in general patterns of expertise, helps you to ease your system’s lifecycle management, have a look at the Redpaper “Cloud Computing Pattern of Expertise”.
Feel free to comment or share any thoughts on this topic!
While contributing to the Redpaper “Cloud Computing Pattern of Expertise” I focused my attention to the lifecycle management of patterns. Managing pattern lifecycle means not only managing the pattern components, but also managing the deployed instances of a pattern.
It is quite easy to understand that adopting a pattern based approach helps you gain speed and agility in provisioning a new IT environment by leveraging the expertise done in the past. But being quick and agile in creating an environment is just the tip of the iceberg! IT specialists spend hours every day in managing the lifecyle of those systems.
IBM Workload Deployer based technologies, like IBM PureApplication System or SmartCloud Orchestrator, help you not only in gaining speed and agility, but also to be more efficient in these day-by-day and time consuming activities, allowing your IT specialists to focus on more important and critical tasks to support new business requests.
Adopting a pattern based approach helps you in different ways in the lifecycle management of your environments. Some examples are (differences exist between the IBM different offerings):
You do not need high level skills to complete most of the activities, but you can complete them through a simplified console.
You can manage the deployed pattern as a whole.
You can consistently move and promote configurations to different stages.
You can leverage pre-integrated monitoring features
The console allows you to administer the deployed instances with very basic skills. A number of them can be done in an automated fashion through the workload deployer console. As an example, you can start and stop the whole system by clicking just a single button. Or, you can apply a fix to the middleware automatically and in a consistent way on each of the images composing the deployed pattern just by clicking a button! And the system creates automatically a snapshot of the environment before applying the fix, which allows you to roll back quickly and easily if something goes wrong!
Check out this Redpaper to discover other advantages of leveraging cloud computing patterns of expertise in the day-by-day lifecycle management of your IT environments!
Feel free to comment or share any thought on this topic!
Are you curious about using IBM Image Construction and Composition tool (ICCT) to create Windows images for use with your virtual system and virtual application patterns?
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 2 – Overview of plug-in 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.
IBM Cloud Pak System 