PureApplication and its benefits for testing

A customer of ours recently asked how IBM’s PureApplication can help with testing – and I thought this would make a great topic for a blog post.

(By the way, all the images I’ve used below are actual snapshots from PureApplication patterns we’ve created. This shows just how nice the pattern modelling environment is!)

Aside from the normal PureApplication benefits of being able to spin up complete test suites and environments in hours (not days or weeks as we’ve found many customers do), there are some specific elements which are worthy of note.

Clear Route-To-Live

One of the key problems we see with complex environments is a clear route-to-live. PureApplication helps by allowing what I call “pattern growth” – below is an example of a development topology pattern.  Because it’s being used by a developer, it doesn’t need such things as High Availability or scaling defined in it.

As the project progresses through the Software Delivery Lifecycle that same pattern remains unchanged but what we can do is add scaling and HA policies. You can see the Message Broker servers being scaled in the diagram below.

This capability means you can ensure that the exact same infrastructure and middleware configuration is used throughout the life of the application; from dev, through to test, right the way through to production.

For a tester, having a pattern which tells them that every instance of a topology they test on is identical, right down to the Resource adapter settings and data, is invaluable. The fact that you can take that repeatability through to live is, more than often, unique.

Better Test Client Integration

From a tester’s perspective, PureApplication patterns also help with the emulation of systems (mock systems as some might know them).  This is because the ability to define the topology in a pattern helps in two ways:

Test Clients:

A tester can simply add in their own test client nodes to the pattern. These clients can be ‘mock clients’. I’ve illustrated this in the diagram below.  You can see the original topology pattern as it came into test on the right hand side (shown in the black box), and then the tester has simply added in a test client to the pattern (highlighted in the red oval). The tester can then bring up this complete environment, including the test client, time and time again happy in the knowledge that the tests are going to be running against clean systems, brought up only for them and which will be burnt after use. All of this can also be automated in a DevOps approach, allowing this system to be used for such things as build verification as well as other, more complex, testing scenarios.

Reference Changes:

In the above topology, the Databrokers (bottom right) are actually DB2 systems. As it stands, the node that is currently in the model will create new instances of the Databases, with clean data, each time the pattern is instantiated. As we move towards production we can simply replace that Databroker node with a link to the real production databases.

This shows that we have a strong guarantee that the only difference in the production system, compared to the system used in the dev and test cycle, is the references to the data.

The Benefit Of Automation

Of course, with PureApplication, we always have the ability to automatically stand up test systems and incorporate this entire setup into a DevOps environment. My picture below shows what this could look like using IBM’s urbanCode (but other tools are available ;-)). We find that this is a very important set-up for many of our customers.

Hybrid Cloud

You may have noticed that I’ve not said whether the topologies were deployed on or off-premise. That’s because, with patterns, the exact same topology can be deployed either way and you can be guaranteed of exactly the same results.

This gives you a strong business case for, say, deploying your dev and test systems off-premise and then deploying your production systems on-premise. This gives you the quick time to value of off-premise capability for dev/test combined with the assurance that the on-premise production system will be identical to the off-premise test systems.

This was just a quick view on some very important use-cases for PureApplication patterns.