Don’t be sheepish. IBM Cloud Pak for Integration can be your secret to wealth and power

My route to IBM Hursley takes me through the Hampshire countryside. And today for some reason I noticed many of the fields along the A32 and the Meon Valley were full of sheep. “So what?” you might say. But sheep were actually the route to wealth and power for the UK. So much so that the Lord Chancellor sat on a Woolsack in the House of Lords to symbolize the importance of the wool trade in the Middle Ages.

Many of the key land-owners in the UK would have huge estates, with walls around them and large numbers of sheep would graze across the land quite freely. But there would be formal gardens close to the house which they would want to keep protected from the sheep. How could you protect the gardens, without building fences or walls that would spoil the view? The answer was a “Ha-Ha”. A hidden feature which would connect the formal gardens to the grazing land, but without being visible. Much like successful integration in your infrastructure.

Think about the concept of the Ha-Ha. You want both your grazing land and your formal gardens to ‘work together’. But you don’t want to impact either of them. Now think about your IT assets. You have your applications. Some new, some existing. All adding value to your business. You want to get the most out of your new applications and the value they bring, without disrupting your existing business.

If only there was a way to seamlessly connect applications together. To move or exchange data from anywhere to everywhere. To call APIs or to provide a secure gateway. Integration is not a single thing. You don’t just flip a switch and it is done. The same way you don’t just have a single tool in your toolbox. You need a hammer to knock in a nail. And a screwdriver to drive in a screw. And the way to integrate different parts of your IT infrastructure is to have a rich set of integration capabilities.

Imagine instead of engaging ‘Capability’ Brown, the renowned landscape designer to solve the issue of sheep coming into the formal gardens, our country estate owner got in their local builder or craftsman. The know how to build a wall or erect a fence. So that’s what they would do. It would do the job. But it could be done so much better.

 

It is the same with any business today. IT assets can be complex, and new applications to respond to today’s opportunities are being developed faster than ever. What you need is an integration solution that does more than a simple solution. Something with breadth and depth. That can connect and secure at scale. Something simple, yet powerful. Reliable and highly available. Something that can feed mobile transactions to your backend invoice applications, but stream data from your new marketing apps to your AI engine. What you need is IBM’s Cloud Pak for Integration.

A powerful blend of leading offerings such as MQ Advanced, DataPower, Aspera, App Connect Enterprise, API Connect and Event Streams. It provides the tooling flexibility your business needs to integrate across the enterprise. And it combines this broad range of capabilities with a single transferable license entitlement, allowing you to pay just for what you need, and to move and change as your business needs change.

 

The IT world moves a lot faster than landscape gardening, and a lot faster than a flock of sheep, even when they are being chased by a big bad wolf. Your business faces many threats, but your applications, your data and your other IT assets are the path to success if you can integrate them and use them together effectively. The Ha-ha is a great example that shows us different things can work together beautifully. And a Ha-ha, built well, would still be there doing its job today. Why do a quick and dirty job and throw up a fence? Is that really what you want? And the best use of your time and money? Doing something right means you are ready for anything.

You might have MQ today, or DataPower, or Aspera. Or you may be looking at Event Streams to deploy some Kafka messaging. Don’t be sheepish about discovering how they are all a part of IBM Cloud Pak for Integration. They can be used by themselves, or together as part of a container-based solution. But either way, they can be as valuable today to your business as flocks of sheep were hundreds of years ago. And your business might grow to an impressive size.

 

Building higher – IBM MQ V9.0.2

When a building is being constructed, it can be hard, from moment to moment to see progress. Yes – you see lots of activity. Lots of people are busy doing all sorts of important jobs, but it can be hard to see what they are all doing. You need to find a way to keep track of how they are doing. What progress are they making, and what milestones are they hitting.

In delivering updates to IBM MQ, now that we are on a ‘Continuous Delivery’ schedule, we set these milestones of deliveries around 3 times a year. We don’t plan to do IBM announcement letters with every update, but will do blogs here and elsewhere for some of the updates, with official announcements for others. For IBM MQ V9.0.1, there was an announcement letter, and I blogged about it here, but with IBM MQ V9.0.2 there are only blogs – both this one and our development blog from Ian Harwood you can find on developerWorks here. Also there is a YouTube video talking about the new update.

So, what has the development team has been working on in MQ V9.0.2? As with the 9.0.1 update there are several areas of enhancement and new function including:

• Additional REST API coverage
• Further updates to the MQ Console
• Improvements in MQ MFT specifically in MFT Agent status reporting
• Simplification in managed MQ logging on distributed platforms
• MQ Appliance support for HA key renewal and 9.0.2 REST API verbs
• Support for IBM Cloud Product Insights for registration and usage
• Integration with Salesforce messaging events
• Native Debian installer support for Ubuntu
• Availability of MQ Advanced for Developers in the IBM Bluemix Container Service

 

Perhaps as with our description about building construction above, the delivery of any of these features might not be significant, although I think that the logging improvements will make a substantial difference to the many aspects of the use of MQ in the thousands of customers using it today.

 

What hopefully does become apparent is our ongoing support for the continuous delivery process. While some of these updates are brand new and have taken a lot of work, others are continuing to build on the work done in the MQ V9 and MQ V9.0.1 deliveries. These incremental deliveries of REST API support, and now the new Cloud Product Insight support will continue in future Continuous Delivery releases, making these features and the product more useful.

 

Let’s look at a handful of these new features starting with the logging support. Logging is very much the heart of IBM MQ and it is these recovery logs which allow MQ to recover from a failure, therefore providing the reliable and robust nature of IBM MQ. While circular logs are easier to manage, many customer use linear logs but these come with a lot of administrative overhead. The new feature allows for automatic management, recording and reuse of logs, lowering both the administrative overheads and improving the overall throughput in the system

 

IBM Cloud Product Insights is a new cloud hosted offering that many different IBM products will be able to work with. Additional features will be added to work with this over time, but initially there is support for registration and usage. You will be able to register your instances of IBM MQ and track them on the Product Insights dashboard. At this time you will be able to see what level of IBM MQ is install, where, and when it was last running. You will also see some usage information such as the number of persistent and non-persistent messages put, and the total size of data being moved through MQ. There is also a beta of log management, where MQ error logs will be shared with the Product Insights dashboard.

You may have seen the recent announcement of IBM and Salesforce working together more closely. We are very pleased that one of the ways this relationship is being demonstrated is through a bridge between Salesforce and MQ. When an event happens in Salesforce such as a change to data or a new application being run (Salesforce Platform Events or PushTopics), there is now the ability to trigger a MQ message to provide information about that event without the MQ application needing to be directly connected to Salesforce, simplifying your environment but making your systems more connected.

 

And finally, we now have a version of MQ Advanced for Developers available in the Bluemix Container Service. This means that the fastest way to create a development environment for IBM MQ might be with a couple of clicks to provision MQ Advanced for Developers. With pre-configured defaults to simplify administration, there has never been an easier way to get started with IBM MQ. What are you waiting for?

Beginning the new, looking back to the old

The month of January is named after the God Janus – who both looked forward to the new year and back to the old one. So it is perhaps time to set ourselves up for what will be no doubt another very busy year for IBM MQ by a quick review of 2016 – looking at what you should have seen, and also finding time to tell you something new, which you are unlikely to be aware of.

So a quick recap first. In June we released a hardware refresh for the IBM MQ Appliance, adding large capacity SSDs and additional 10Gb network ports as described here. And IBM MQ brought out MQ V9.0 with a new option for end-to-end encryption with an order of magnitude performance boost, and CCDTs now accessed through a URI – and this was described here.

There were additional enhancements in November with IBM MQ moving to MQ V9.0.1 – the first Continuous Delivery release, with MFT enhancements and repackaged MFT Agents, availability of the new MQ Console, and the initial delivery of REST API verbs. These were all described here. And the IBM MQ Appliance also moved the MQ V9.0.1 and added additional features like Floating IP support, SNMP and LDAP authentication of admin accounts. This was written up here.

So if we are all ok with that, I had better share the news that you missed at the end of last year. First a word or two about Processor Value Units. This is IBM’s typical capacity based pricing metric for software. Each machine type and processor type has a PVU rating per core. And software products like IBM MQ have a price per PVU. So as a customer you buy a number of PVU entitlements to meet your capacity need and then deploy IBM MQ on the hardware that matches the PVUs you have bought. However this means you need to always count and be sure that the capacity you have provided to IBM MQ is in line with the entitlement you have, and the physical machines you are running on. But more and more these days software is being deployed on environments that are more abstracted from the actual physical machines – and the capacity being allocated, either on premise or in a cloud, is assigned as virtual cores. But with IBM MQ (and other products) priced only by PVUs, there was some confusion in mapping PVUs to virtual cores.

On December 6th 2016, IBM MQ addressed this by adding a Virtual Processor Core metric to its pricing. This is only available as a monthly pricing metric but provides a new simple, and possibly more appropriate way of buying capacity for IBM MQ deployed in these virtual environments either on premise or in clouds where IBM MQ is deployed with a number of virtual cores of capacity rather than into a fixed physical machine. This is an additional metric. The PVU metric with both perpetual and monthly pricing is still available, but customers now have an additional option of the Virtual Processor Core pricing. There is no announcement letter for this, but the pricing is already available for IBM MQ and for IBM MQ Advanced, so simply ask your IBM sales rep or business partner about this if you want to know more.

Certain customers who can find it difficult to count PVUs might find this very useful. These might include customers such as retailers or retail banks where IBM MQ can be installed in 1000+ different environments, and for customers like this there are other ways to price for this type of deployment so again ask your IBM rep.

That was the last news and updates from 2016, but there is plenty to come in 2017. And you don’t need to wait for long. Just one week to go and I expect to have something new to share here. Not long to wait.

Let your troubles float away with the IBM MQ Appliance

Sometimes you instinctively know when something is right. It just seems to fit. To all fall into place. When you solve a mathematical equation. When you put on a jacket. When you pick up a hammer. You just know it is feels right.

Since IBM released the IBM MQ Appliance in 2015, we have had a lot of customers look at it, and for many of them it has seemed to be something just right for them – just what they were looking for, as it simplified their infrastructure and reduced the tasks of configuring, operating and maintaining their MQ installs.

However, there is plenty of opportunity for improvement, both in adding new features and in improving those already there. And some of the early customer feedback about the MQ Appliance has been critical in some of the enhancements that have already been delivered and also feedback has been critical to some of the features just delivered in the latest update to the IBM MQ Appliance M2001, providing MQ V9.0.1 on the MQ Appliance. Note that this latest software update is also available for customers still running the MQ Appliance M2000.

One of the key new features is the provision of Floating IP support to aid in the High Availability failover configurations. The MQ Appliance provides High Availability by connecting appliances as a pair, and individual Queue Managers can failover from one appliance to another quickly and seamlessly, with the persistent messages and logs already replicated synchronously. However, in order to support this, the MQ client used by the application needed to be configured with not just the IP address of the primary appliance but of the second appliance in the pair as well. This wasn’t always convenient for customers to require all the MQ clients and applications to have a string of IP addresses to prepare for failover.

To address this, and make the experience of using the MQ Appliance even better for our customers, in the latest V9.0.1 level of code, High Availability configurations now allow for Floating IP – which means that as the first MQ Appliance fails over, the second appliance not only starts up a Queue Manager, but it starts up the IP address from the primary, enabling the MQ applications to connect to the second appliance even if they only have a single IP address configured. This should make using the MQ Appliance an even better experience for a much wider set of deployments, without requiring too much of a change to the applications.

As already mentioned above, the MQ Appliance now ships with the MQ 9.0.1 continuous delivery release. This means that the MQ Appliance now benefits from the MQ V9 functions such as the new MQ AMS confidentiality option. This also means that all the new and upcoming features in the MQ continuous delivery stream will be available to the MQ Appliance as those releases come out, with more access to the new REST API for admin and configuration as well as a refreshed MQ Console.

 

Also, as well as some usability improvement for management of the appliance and the MQ operational aspects, this update includes s number of key features exposed from some of the underlying firmware. Key among these are support for SNMP and enhanced security, such as role based authorization, and LDAP authentication for appliance admin accounts. These, again, should make the MQ Appliance fit even better into an organization and be applicable to more use cases.

With further updates to come as part of the Continuous Delivery stream for MQ and the MQ Appliance, there will be more improvements to come to continue to make the experience feel even better. So get ready to float away from your troubles with the latest update to the MQ Appliance.

UPDATE: An excellent blog on MQDev developerWorks site by Ian Harwood. Another blog specifically on the MQ Appliance update by Ant Beardsmore.

Keep climbing up – WebSphere MQ V7.5 End of Support date announced

When you have been fundamental to thousands of businesses, and helping to create the modern world for 23+ years, it can seem like you are on a never-ending journey. And certainly the need for simple, reliable, secure and rapid enterprise messaging never goes away, so IBM MQ is needed now more than ever.

But sometimes we need to bring one chapter to an end, but there are plenty more chapters to get to. You may have seen that we have been rather busy with announcements this year, with new announcements for an updated MQ Appliance, and the brand new IBM MQ V9 release. But we also announced back in April the End of Support date for MQ V7.1. On distributed platforms this was set at April 30 2017.

And today we have just announced the End of Support date for MQ V7.5 – we are giving a little bit more notice on this one – with an End of Support date set for April 30 2018.

WebSphere MQ V7.5 was the last MQ release with the WebSphere branding, and it was the first release where we had brought together all the MQ components, which allowed us to then offer MQ Advanced with MQ, MQ MFT, MQ AMS and MQ Telemetry.

So what to do if you are on MQ V7.5 today? Or perhaps you are just about to move to it? Well it will be in regular support until April 2018. Following that, if you want, you can have extended support for another 3 years. But you might want to think about moving forward to take advantage of all the latest features.

The good news is that migrating should be easier than you might be used to. And with the new MQ V9 option of Continuous Delivery or Long Term Support, you can got as fast as you like. And many of our customers are looking at the MQ Appliance when they are planning an update, to take advantage of the simple and rapid deployment, the fantastic performance without complexity, and the operational and maintenance simplicity.

So the choice is up to you. IBM has sections on migration in the Knowledge Center, and we have services offerings to provide Version to Version migration planning, and implementation.

Feel free to talk to your local IBM representative or partner. Leave me a message here, or ping me on Twitter. Don’t get stuck. Onwards and upwards. Just keep moving.

Flash aaaahh – saviour of the universe: IBM MQ Appliance M2001

Anyone who is a fan of cheesy sci-fi movies, or soundtracks by Queen will have the words “Flash, Flash I love you but we only have 14 hours to save the earth” running through their head, along with the line in the song that goes “Flash aaaaah, saviour of the universe”. And of course he did save the universe from Ming the Merciless.

But what if I told you Flash could also save your business? Not Flash Gordon of course, but flash storage, in the form of the SSDs that are now a part of the IBM MQ Appliance M2001 which is now generally available (June 10th 2016). We did cover this in an earlier blogpost, but I thought I would take advantage of our initial shipment date to cover just how critical the IBM MQ Appliance, backed by state of the art 3.2TB SSDs can be to your business.

Each MQ Appliance M2001 model has 2 of the 3.2TB SSDs in a RAID 1 configuration. This means that every persistent message and all log data is written not just once to the SSD storage, but twice giving you complete redundancy of data. And a key part of the MQ Appliance functionality is the High Availability configuration – essentially nothing more than a simple menu option when creating a queue manager – allowing you to have the MQ queue manager on one MQ Appliance synchronously replicated to another MQ Appliance. This means that any message written to the SSDs on one MQ Appliance is not just copied to the second pair of SSDs but is written under the same unit of work that writes the messages on the first MQ Appliance. This therefore means you have 4 copies of the message stored for both reliability and availability.

Another part of the MQ Appliance update was the ability to do not just synchronous replication for High Availability but also asynchronous replication for Disaster Recovery to another MQ Appliance. Therefore you can point the MQ queue manager at another, typically off-site MQ Appliance and the same message will replicate there, ensuring there are another 2 copies of the message, and providing your business with a highly resilient messaging system designed to ensure optimum reliability and availability of messages.

After all, think about how important your messages are to your business. In effect, they are your business. Your messages are your business transactions, your new orders, your customer address details, your stock levels and distribution information. Lose your messages and you lose everything.

With the latest SSD technology inside the MQ Appliance you are calling on Flash to save your business – and with the MQ Appliance M2001, Flash saves the day again.

 

[Flash Gordon image title image above is from  http://orig07.deviantart.net/fc1d/f/2012/163/5/d/flash_gordon_facebook_cover_by_audrey41lorgeoux-d538dgo.jpg]

IBM MQ V9 – A fast, secure, reliable and more agile MQ

Some of you reading this blog may recall the great athlete Ed Moses – who had a record 122 race winning streak in just about the hardest event – the 400M Hurdles. You need to be strong, fast, and agile just to compete, and to keep winning you need to be reliable. Well, this is how we view IBM MQ, especially with the latest release – IBM MQ V9. You may have seen a recent blogpost on here that had a Statement of Direction talking about a new way of delivering IBM MQ – one that provided a Long Term Support release, and a Continuous Delivery release. The aim of this model is to give customers more choice to select either highly stable releases with just fixes, or releases that benefitted from additional function in the fixpacks.

TRY IT: Click here to get a free trial of MQ

UPDATE: There is a FAQ on the new support model. Read it here.

On April 19^th, IBM announced MQ V9 which is the first release that moves to this new more agile delivery model. As such at the initial release it delivers a small set of additional capabilities that will be available to all customers. Then subsequent mod-level updates will deliver even more updates to customers choosing the continuous delivery stream, but all customers moving to V9 will get the benefit of the new capabilities being delivered in this release.

As with previous releases of IBM MQ, customers have a lot of choice in where and how they may want to deploy this version. IBM supports deployment of MQ – and MQ Advanced pretty much on every commercial IT environment where business critical applications may be exchanging data reliably, securely, and at scale. This could be on-premise, deployed in cloud environments like IBM Softlayer, Microsoft Azure or Amazon AWS. IBM also supports virtualization with many customers deploying in VM images, and also in Docker containers, which can be deployed anywhere, including in IBM’s Bluemix platform. This flexibility enables customers to make use of enterprise messaging to support deployments on-premise, on cloud or in hybrid environments.

So what are the key new features of MQ V9 being delivered in this release? Well there are a number of them that are called out in the announcement letters – so you can read the MQ V9 distributed announcement letter here. And the MQ V9 z/OS MLC announcement letter here. And you can read the MQ V9 One Time Charge announcement letter here. But below I will call out a few of the features that I think will be most important to customers.

One of the features likely to be most interesting is a change to the MQ Client Channel Definition Table (CCDT), which is needed by the MQ Client application to provide the channel definitions needed to connect to the MQ Queue Manager. This file is created automatically and prior to MQ V9 needed to be distributed to the client application prior to use. The big change from this new release is that the CCDT can be a web addressable file instead of needing to be distributed out to every client, and to then need to do that with every change. By having a web addressable CCDT accessed by URI, then there are much lower administration needs, and also the MQ infrastructure can be much more dynamic as changes can be made centrally and take effect quickly and without application disruption.

 

The second big change to the new release of MQ is in MQ Advanced Message Security (MQ AMS). This feature, which is a priced extension to MQ (available either separately or as a part of MQ Advanced) provides policy based encryption at rest of the MQ message contents. By using this capability, businesses can be assured that their message contents can only be unencrypted and read by the targeted application destination, and there is no risk of exposure should any security breach take place which provides access to the system or storage where the MQ Queue Manager holds its queues. This privacy and integrity has been assured by the generation of asymmetric keys for every exchange between client and queue manager, which provides an extremely high level of security, but can introduce a high overhead in terms of the processor cost of the asymmetric key generation.

With MQ V9, a new mode of operation is added to MQ AMS, called ‘Confidentiality’. In this mode there is an initial asymmetric key exchange then subsequent exchanges can reuse (to an extent that can be configured) a symmetric key. This still provides a high level of security and protection for the message content, but with a dramatically lower level of overhead in terms of encryption workload cost. IBM expects that due to the increasing importance of security and protecting systems and data from breaches, that this new feature of MQ AMS will help more customers protect their message contents and therefore their business and customer data. IBM expects to produce performance data for the new AMS configuration around the time that MQ V9 is generally available. But the early testing shows considerable improvement.

 

A further change for MQ AMS is the support of non-IBM JREs for use with MQ AMS. Previously applications written in Java that relied on a non-IBM JRE wouldn’t work with MQ AMS. In MQ V9 this has now changed so that suitable non-IBM JREs can be used, as well as IBM JREs, extending the ability of more customers to use MQ AMS.

 

There are a number of other new functions and capabilities available in MQ V9, such as updates to MQ Managed File Transfer capabilities – which are described in the announcement letter, and with the movement to a Continuous Delivery model customers should expect to see more capabilities being delivered in mod levels on top of MQ V9 in the future.

 

With the recent announcement of the End of Support for MQ V7.1 – announced here – along with the related end of support of the older separate versions of MQ FTE and MQ AMS, this latest release of MQ V9, along with the recent announcement of the update to the MQ Appliance provides customers with a strong set of choices of how to take advantage of the latest new releases as they plan to move off the older releases of MQ they may be using, keeping their deployment of MQ up to date and supported.

When you are taking advantage of the benefits of IBM MQ, you may not need to have to work as hard as Ed Moses did to be #1.

UPDATE: Mark Taylor has provided one of his highly useful videos detailing more of the new function in MQ V9. Watch it here.

 

Going faster by not moving – IBM Appliance M2001

Go faster. Faster. Move it! Or actually don’t move it. There are times when to go faster you need to stop moving. We are all familiar with the parable of the tortoise and the hare – where slow and steady wins the race. But what about not moving at all? Sometimes that makes you go much faster. And in the case of the latest update to the IBM MQ Appliance that is exactly what we are doing. Hopefully you already know about the MQ Appliance, which IBM releases early in 2015, and have continued to enhance since its release. You can read my original entry here, and the update at the end of last year here.

 

But today, April 19^th, IBM is announcing another update to the MQ Appliance which not only provides additional functional enhancement, by allowing queue managers to both synchronously replicate for HA and also asynchronously replicate for DR, and adds support for the AMQP based MQ Light API, but also sees a small but important hardware update, making this a slightly refreshed model – the MQ Appliance M2001.

There are 2 key hardware changes in this model update. To help support the simultaneous HA and DR function, which would use both existing 10Gb network cards, the existing 2 port connection is being replaced with a 4 port connection, providing 4 of these 10GB network ports, enabling 2 to be used for HA and DR and ensuring 2 can be used by applications connecting to the appliance, as well as the existing 1Gb ports.

The second hardware change is the replacement of the existing pair of 1.2TB hard disk drives (HDD) with a pair of 3.2TB solid state drives (SSD). As well as the benefit of the greatly increased storage capacity, the major benefit of using SSDs is the increase in performance for persistent message throughput. The MQ Appliance is a highly capable system which can process a lot of MQ messages. However, when using persistent messaging, which needs to be written to disk, it is critical that the storage can keep pace with the high rate of workload being handled by the system and at times with heavy workloads the spinning disk simply couldn’t move fast enough. IBM has selected the latest generation of SSDs to provide large capacity, high performance for both reading and writing data at high rates, and also this latest generation of SSDs, even if the MQ Appliance is used heavily all day, every day, should last for the 5 year supported lifespan of the MQ Appliance. Therefore, this provides the payoff from our ‘tortoise and hare’ parable – with no moving parts in the SSDs, they can be a lot faster than spinning disks. Expect to see updated performance figures for the new MQ Appliance M2001 around the time of its availability (June 10^th 2016), but early figures suggest for some workloads performance improvements of up to 3 times have been seen.

 

There continue to be 2 editions of the MQ Appliance – the M2001A, providing full access to all the processor cores, and the M2001B, which provides access only to a subset of the cores – with an upgrade available from the B to the A system if needed. For customers who may have already purchased the MQ Appliance M2000, please talk to your IBM sales rep to see whether your appliance can take advantage of an upgrade of the HDDs and network card if available.

 

With the improved HA and DR functions, the increased storage capacity and the greatly increased performance, IBM believes this enhanced MQ Appliance makes even more sense to be used as the heart of your IBM MQ deployment, or as a highly available pair of appliances that can be deployed anywhere you need MQ capability. And for customers who may be running older versions of MQ which were recently subject to an announcement of End of Support – as can be seen here – then the latest version of the IBM MQ Appliance can represent a very good deployment option which is then far simpler to deploy as well as to maintain.

 

By moving from spinning disks, to SSDs with no moving parts, you really can go faster by standing still.

 

 

Setting out markers for MQ’s road ahead

Working as the Offering Manager for IBM MQ and the IBM Messaging Portfolio, there are lots of parts of my day-to-day work that I can’t share on here until we announce it. However there are times when we can provide a small look ahead at what’s coming. This is called in IBM a “Statement of Direction”. And today IBM MQ has released a Statement of Direction for both IBM MQ and for the IBM MQ Appliance.

You can read the Statement of Direction here.
As you will see in reading it we are talking about a couple of important points. I will deal with the MQ Appliance statement first. As covered elsewhere in this blog, there has been a lot of interest in the MQ Appliance since we announced it at IBM InterConnect 2015 – just about 1 year ago. One of its key features has been about the High Availability function – the simple way to connect up two appliances and to allow for seamless failover between them benefitting from synchronous replication.
At the end of 2015, as detailed here IBM extended this High Availability option with asynchronous replication to other MQ Appliances, which could be deployed further away, offering Disaster Recovery. However, deployments needed to choose either one style of replication or another, on a Queue Manager by Queue Manager basis. So a Queue Manager on a MQ Appliance could be defined for High Availability, or for Disaster Recovery, but not both.
This created an obvious question when we discussed this with customers, who in some cases would want to have local MQ Appliances offering High Availability, but in the case of a whole site failure, wanted to then offer Disaster Recovery off-site. As giving forward looking statements can be an issue without legal clearance, we have ensured that with this Statement of Direction we can clearly state and assure customers that IBM indeed does intend to support the ability of Queue Managers to be configured for both High Availability and Disaster Recovery in a future update.

For MQ itself the Statement of Direction covers less function, and more the delivery and support approach used for MQ itself. For many years IBM has released updates to IBM MQ every 2-3 years as major new versions, and sometimes with additional interim updates as incremental releases. But over the last few years IBM has been adding function into the regular fixpack deliverables where we also include maintenance updates alongside the new function.
While this approach allows IBM to add useful new functions between releases, and thus getting it to customers earlier, it can lead some customers to choose to keep their MQ implementations on older releases until IBM stops adding new function to that particular release. The concern is that adding new function in a release that will be used in production can create the need to have a major new testing cycle, even if IBM has designed that the new function is off by default.
As IBM thinks customers would benefit from being at the latest level of code, and certainly IBM wants to encourage customers to stay up to date with the latest fixpacks, IBM has decided to offer two separate code delivery and support options.

One option will be the Long Term Support Stream. A new version of MQ will be released, and from that point on, there will be no new function shipped on that code-stream. The fixpacks that IBM will continue to ship on a regular basis will only contain fixes to existing functions and no new functions will be added. As such it should be simpler and safer for customers to move more rapidly to this level of code and to then stay on it as fixes are rolled out, improving stability and performance.
The second option will be the Continuous Delivery option. Based off the same original code drop as the Long Term Support option, subsequent updates will be delivered containing not just fixes but also incremental new function. Each mod-level update will be designed to continue to add new function. And, important to understand, customers who choose to deploy the Continuous Delivery stream will have to keep taking the additional functional increments and fixes if they want to stay on that stream by moving to the most recent mod-level. If they decide they want to be on the Long Term Support stream then will need to change the MQ installed which will likely cause a degree of disruption as they will effectively be moving to a different release. While this continuous delivery of function will ensure that customers of MQ will have new functions that enhance MQ and the operation of their environment, those customers will need to be able to continue to update their environment with each update as it is delivered. For many customers this might be appropriate as they have a need for the new function or they may want to apply it only to a particular environment and set of applications.

After a number of functional updates to the Continuous Delivery Stream of IBM MQ, over probably a period of 2 years or so, it is expected that the incremental set of new functions delivered in the Continuous Delivery Stream will be released as the new starting point for the next version of the Long Term Support stream, and will reset the version for the Continuous Delivery Stream as well. The cycle them will repeat again, with fixes applied to the Long Term Support Stream and new mod-level updates with new function (as well as fixes) delivered to the Continuous Delivery Stream.

This new approach for delivering MQ may be significantly important for some customers as they make future plans, and IBM therefore thought it was important to set this out in a Statement of Direction prior to a future announcement of a new release of IBM MQ supporting this model.

As for when any new releases to backup these Statements of Direction are coming out? Well, keep watching this space.

What can go wrong will go wrong! How the MQ Appliance helps save the day.

Since IBM announced the MQ Appliance earlier in 2015, there has been a huge amount of interest in the solution from pretty much everyone. All the customers and business partners I have talked to (along with the many my IBM colleagues have also been talking to) have almost always seen a place for the MQ Appliance in their organizations.

As expected some of these use cases reflect one of our anticipated scenarios of using the MQ Appliance – deploying in a remote location away from the main data centre. Other use cases are based in the data centre with the MQ Appliance being used either to roll out new MQ capacity quickly and simply or to consolidate an existing MQ deployment that might be installed and running on multiple different machines which can make it complex and expensive to maintain, especially when deploying updates or making configuration changes.

Other that the simple and quick deployment and the ease of maintenance that the MQ Appliance provides, probably the function which generates the most interest from customers and potential customers is the High Availability function. MQ is used pretty universally for work that is critical to the business. The messages being moved between applications and systems contain business critical data and it is crucial that these messages are delivered once and once only and in the case of failure at any point, the messages are recoverable and the business can continue. No one wants to lose the message with the new customer details or the big order.

 

So the High Availability (HA) in the MQ Appliance was seen as key – it was simple to set up – essentially just a single menu selection when defining a new Queue Manager and you would have another appliance ready to synchronously replicate the persistent messages and logs so that in the case of a failure in the production Queue Manager, a replacement queue manager is started on the second MQ Appliance with full access to the messages and logs already available on that appliance. This simple yet rapid and usable solution is compelling, and can also be used, with manual failover control, to enable seamless operation while applying fixpacks on the appliance.

 

However one of the key details to understand about the HA support was that this used synchronous replication of the data between the disks on each appliance, and as the original message can’t be counted as complete until the replication is also complete, the HA appliance needs to be close enough so that the latency of the replication doesn’t impact the application writing the message. The published recommendation is for latency of less than 10ms, but for best operations latency of 2ms or less is preferred.

 

Now, with the 8.0.0.4 fixpack available on the MQ Appliance from November 30 2015, we have added another key feature – which addresses the need for replication over longer distances where latency is always going to be too high for synchronous replication. The 8.0.0.4 fixpack adds asynchronous replication enabling offsite replication over far longer distances than supported for HA as there is no impact to each individual message completion – the replication takes place independently. This style of replication is typically used for requirements such as Disaster Recovery (DR), to enable business continuity out of region with the ability to continue work as close to the point of failure as possible.

 

Customers using this DR feature with the MQ Appliance will be able to configure individual Queue Managers in their appliance to replicate their persistent messages to another MQ Appliance that can be hundreds, or even thousands of kilometres away. And unlike the HA configuration where appliances need to be a defined and fixed pair, there are much more flexible options for this style of asynchronous replication.

 

As mentioned the DR configuration is done on a Queue Manager by Queue Manager basis – but different Queue Managers on the same production appliance can be replicated to different DR appliances. Also Queue Managers defined on different production appliances can all replicate to the same individual DR appliance.

 

As before with the HA appliance, there can be ongoing work and other active Queue Managers on the appliance being used as the DR appliance – there is no formal limitation for appliances to be DR or HA appliances – any appliance can be configured to offer this in conjunction with the other workload running on it.

 

With the addition of this asynchronous replication for Disaster Recovery, the MQ Appliance can be used for more deployment use cases as the ability to recover from failures to a running environment in another data centre is always going to be crucial, as so many businesses depend on MQ to keep them running.

<BLOG UPDATE> With this MQ Appliance fixpack delivering such an important update we also have blogs from our Appliance development lead Ant Beardsmore here, and from our Appliance HA and DR architect John Colgrave here going into more details on the enhancements and the technical details of how DR works.

With simple configuration for all these scenarios, rapid deployment and ‘push-button’ maintenance, it is no wonder so many businesses are looking at using the IBM MQ Appliance. Want to know more? Check out our main webpage. After all, if things can go wrong, they will go wrong. That’s why you use IBM MQ after all. It is better to be ready and to be able to cope with these disruptions. Your business needs to keep running. With the MQ Appliance you can do that with the minimum of effort.