No need to watch the clock with new hourly container-based pricing for IBM MQ

Your business is 24×7 now. No downtime. No waiting for additional machines to be brought online. Simply deploy more containers to handle more workload. On-premises or on cloud, either public, or private, or both.

After all workload varies through the day, across the week, throughout the month, and over the year. If that’s the case, then you are either already adjust or are planning to adjust the deployed resources to match the workload.

Deploying into containers makes this easier than ever. Co-ordinating these deployments into a managed environment using Kubernetes is the basis to private cloud infrastructures such as IBM Cloud Private or Red Hat OpenShift.

But building resources based on container deployments provides flexibility to make use of these assets either in these private clouds, or in public clouds, or anywhere really.

 

If that’s all understood, then let’s imagine a scenario of a workload that is only run at certain times. Perhaps it is payroll or ordering new supplies. But the applications, and their supporting infrastructure, such as the IBM MQ messaging layer only needs to run for a relatively well-defined period of time. And with the applications, as well as the MQ Queue Managers ready for container deployments, you can quickly and easily get everything up and running with the containers started with just the right number of cores to match the expected workload. But how will this be licensed? For transient workloads buying perpetual entitlement might not be the most cost-effective answer. Especially if the applications only run for a short time, or if there are brief spikes in the workload which require a large amount of resources but only for a short time.

 

The good news is that today IBM announced that for IBM MQ V9.1, as well as IBM WebSphere Application Server V8.5.5 and V9 a new licensing approach to reflect this type of deployment, making it easier for businesses to not only gain operational benefits from new container deployments but also cost benefits as well.

There are 2 main aspects of the announcement. One is that the licensing required for container deployments is based on the number of cores allocated to the container, rather than the size of the physical or virtual machine where the container is running, as reported by the deployed product to an instance of IBM Cloud Private which is monitoring and reporting on this. The second aspect is that this monitoring and reporting will be fine grained enough that the reports will include the number of cores used for the number of hours, and license entitlement will be available based on Core-Hours.

 

Let’s go back to the example. We are deploying a WebSphere Application Server (WAS) application into 8 cores of containers, and this will be supported by 4 cores on IBM MQ in containers. This needs to run on a Sunday, and runs for 20 hours solid, before finishing all tasks, cleaning up all data and shutting down the containers. If this runs 4 times per month, then for each month you would need license entitlement for 4x20x8 core hours of WAS, and 4x20x4 core hours of MQ. The new licensing allows customers to buy blocks of 1000 Core Hours of WAS or MQ. And the included free entitlement to an instance of IBM Cloud Private just for reporting on this usage will allow customers to track and report on their usage against their purchased entitlement.

But supposing at the end of the year things are busier and the workload needs to run for longer – maybe 60 hours per week instead of 20 hours per week, although still the same number of cores. Then each month would be 4x60x8 for WAS and 4x60x4 for MQ – so 240 hours per core in these busier months. The good news is the licensing provided in this announcement includes a cap on monthly usage of 160 hours per core. So although each core used for this workload is running for 240 hours each month, the reporting mechanism will make it clear that only 160 hours of usage per core is chargeable.

 

This new licensing includes support for both the new Virtual Processor Core Hours part, as well as the existing VPC month part for MQ. If you are deploying MQ or WAS inside IBM Cloud Private, rather than simply using it for reporting on usage, then PVUs can also be used for container deployments.

 

You can now get on with deploying and using IBM MQ and WebSphere Application Server to run your business, however and wherever you need. And the licensing will help you better reflect your container usage. Try to contain your excitement!

Advertisements

MQ Advanced powered by MQ V9.1 – now it’s time for business – join the webinar

It’s early September and seasons are changing. For some, summer is turning to autumn, and elsewhere, winter is changing to spring. Despite holidays ending for some, business is never on holiday. There are increasing demands to improve availability, response times, security and agility.

 

Businesses can’t take infrastructure for granted. In fact, it is critical to the success of the business. Ensuring that IT infrastructure is delivering maximum value is a huge differentiator in an ever more competitive world. And that can mean not being left behind and taking the best advantage of what your infrastructure can do.

 

IBM MQ has been at the heart of many of the world’s leading businesses for years. And MQ Advanced allows businesses to do even more with their MQ infrastructure, moving more data, from any environment more securely and reliably. The recent release of MQ V9.1 provided even more value to customers, especially if they are using or if they upgrade to MQ Advanced.

 

On September 12^th there will be a webinar covering the benefits of MQ Advanced and the advances included in IBM MQ V9.1. Simply click here to register and find out how your business can take advantage.

Why the IBM MQ Appliance might be a good choice for your business

I have already written about the announcement of the new IBM MQ Appliance M2002 which is generally available today (July 27th 2018). It is an amazing bit of kit, and already has demonstrated some staggering performance figures.

But you may well be sitting there reading this going “so what”? Why would I want a physical appliance? Surely this is enterprise middleware software, so I simply build an image, configure it and deploy it on a server, either somewhere inside my enterprise, or in a public cloud. And that is a perfectly valid question. And selecting to deploy software on servers, perhaps in a VM or a container is certainly the typical choice of deployment model these days. And IBM is doing what we can to make that style of deployment easier, simpler and yet more powerful as well. So, given all that, why might you consider and choose a MQ Appliance?

 

Most importantly, it is a choice. It provides an alternative. One of the benefits of the MQ Appliance as an alternative is that it provides a lot of benefits enabling the use of a very powerful MQ configuration without a number of the costs and burdens that otherwise might be associated with such a deployment. And although it might initially look expensive, it is important not just to realize that the price includes state of the art hardware, but that along with that, there are a multitude of benefits which make the MQ Appliance actually a lower cost alternative to many other software deployment configurations.

Many businesses using MQ have one or more highly skilled MQ administrators, who have, over the course of a number of years, built up a rigorously controlled MQ environment where individual Queue Managers are carefully deployed and managed for significant periods of time. While this is effective, it can also be limiting, as each environment becomes bespoke and dependent on the skills only available in the team and become restrained to the specific deployment environment which is tuned to fit that particular need.

 

Problems in this type of deployment arise when one of the key resources is no longer available for some reason. There can also be significant disruption at maintenance time, and when moving machines for lifecycle reasons. In the same way it becomes very difficult and time consuming to try and add to the system either to provide additional capacity to the existing applications or to support new applications as the MQ environment is very strong, but not very agile and responsive to change. And one of the problems is that with IT infrastructure, change is continuous. Servers need regular attention, with new OS or firmware patches required, and new hardware needing to be purchased and deployed that is always slightly different to the existing deployed systems.

 

The MQ Appliance is designed to provide a very strong and resilient MQ environment, primarily for production environments on premises. And it does this without requiring a highly skilled MQ administration team to design, configure, deploy, maintain and operate the MQ environment.

 

There is no need for what can turn out to be months of optimization and tuning of the MQ environment, as the MQ Appliance gives you optimized Queue Managers out-of-the-box.

There is no need to disrupt operations as an operating system or firmware update is scheduled. With no need to then have another disruption as a separate patch is applied to MQ itself. Instead the MQ Appliance is updated with a single firmware flash, updating all aspects of the appliance including MQ in a matter of minutes.

 

Unlike with servers where each machine might be different, each generation of MQ Appliances are identical, and will have exactly the same counterpart in IBM itself for development and testing of each firmware update. No more differences between systems. No more ‘install and hope’ that your environment is close enough to the supported environments for that version of MQ. And if the MQ Appliances are defined as a Highly Available pair, then both appliances can be updated to the latest level, with no down time, in less than 15 minutes.

 

With the MQ Appliance there is no risk that malware or additional code will be placed on the system as it is completely locked down. The only code that can be added to the MQ Appliance is the signed firmware updates that are downloaded from the IBM systems. And with MQ AMS included in the MQ Appliances, all messages flowing through the MQ Appliance can be encrypted end-to-end, simplifying audits, and helping to protect data from breaches, and to help meet GDPR requirements for data protection.

Even High Availability becomes much easier with the MQ Appliance. With each MQ Appliance able to run as a self-contained solution with local storage inside the appliance (the M2002A provides 6TB of SSD storage), it is trivial to set-up replication between 2 appliances. This offers a very easy solution to meet high availability needs, with no external dependencies, and literally just a 2-click setup. One of the outcomes of this benefit is that it makes it very easy to deploy MQ Appliances in remote locations, where MQ might be needed in HA configurations, but there aren’t any local skills to setup and maintain a complex network attached storage environment.

 

Imagine therefore you have MQ running today in an existing environment. Your hardware is old and needs replacing, and so you would need to start planning and evaluating for new hardware. Then there is the issue of how long it will take to order and configure the hardware, which is likely to be done by a different team to the MQ administration team. Once that is setup then there is the issue of what is the standard environment for that type of system? What other software needs to be installed, and then what is the maintenance program for the hardware, OS and other software. All that before installing a version of MQ, configuring it, and then figuring out how to move the existing MQ configuration and runtime across, once sufficient testing had been done.

 

Or you can simply select the MQ Appliance. It comes as a choice of 2 models offering different levels of processor capacity and storage capacity. And you can upgrade from one model to the other with a command. Then you install it into the rack, cable it into the network. It will already have the latest version of MQ and as you create Queue Managers they will be allocated a protected share of the Appliance resources. If you want to configure the Queue Manager as Highly Available, it’s as simple as identifying where the other appliance is on the network. You want to have Disaster Recovery as well in a remote site – again as simple as connecting to that appliance.

The MQ Appliance is a simple, secure, reliable and powerful way to deploy, run and maintain IBM MQ in your on-premises environments. Suitable for consolidating your existing MQ infrastructure in your data center, or deploying new MQ capacity in your data center, or in remote locations. The MQ Appliance works well if you have existing MQ systems, or if the MQ Appliance is your first MQ system.

It’s good to have a choice. Especially if you choose the IBM MQ Appliance, with the M2002 model available today.

Ensuring your business and customers see you as Highly Available thanks to MQ Advanced

How high is high? If you are considering climbing, then Everest is pretty high after all at 8848M above sea level. Although without the right equipment, team and preparation, trying to climb just 2M can be impossible. But ‘high’ is used in other contexts as well. Like when you are trying to keep a business running these days. If you are then it’s likely the high you may be thinking about is High Availability. Without the right approach, tools and infrastructure you may be trying to solve a problem that can seem to be the same scale as Everest.

With business becoming more global, and being more responsive to events, and with mobile or web traffic coming direct from partners, customers or suppliers, downtime has to be avoided. How do you keep your systems up, your applications running and your data available all the time? Even when, inevitably, there are failures?

IBM MQ is a critical part of your business connectivity. It provides a reliable, secure, scalable and robust middleware layer connecting applications, systems and services and exchanging data between them. Making use of IBM MQ ensures your applications can be simpler and more agile, yet more reliable, and also easier to shift between deployment environments. Your applications will rely on IBM MQ persisting their messages, ensuring that messages are never lost. How do you reap these rewards of simpler applications unless the MQ middleware is highly available to ensure the applications can keep running?

 

Having been around for 25 years, IBM MQ understands this need very well. As such it provides a variety of ways to configure and manage High Availability. And the most recent innovation, based on the High Availability approach used in the MQ Appliance is designed to not only offer extremely robust and effective high availability, but at the same time ensuring it is simple to set up and maintain, without additional external complexity: Replicated Data Queue Managers.

 

Many clients were facing the same set of problems: they didn’t like the costs and complexity of providing and maintaining network attached storage, which was a common way of providing high availability for MQ. The request was high availability that was more self-contained, without external dependencies. A way to deploy MQ in highly available configurations without the requirement for an environment that needs lots of setup, with highly skilled resources and additional costs.

With IBM MQ V9.1, our new Long-Term Support release, customers can now take advantage of Replicated Data Queue Managers, which offer a 3-node configuration, making use of replicated local storage, which make the MQ messages available on each of 3 MQ systems, instead of relying on a single copy of data on network storage.

 

Instead of requiring lots of setup, and ongoing extensive maintenance, MQ itself will do almost all the setup during the initial MQ install. Then, when you are creating a Queue Manager, you simply request it as a RDQM resource, and that’s pretty much all that’s needed. And it’s not just simple in the configuration of the Queue Managers. As it supports Floating IP, when one Queue Manager fails, and another instance automatically starts up on one of the other 2 nodes, the original Queue Manager IP address will move with it, meaning the applications are essentially unaware of the move, and the workload is uninterrupted as the messages and logs had been kept up to date synchronously on all 3 systems.

 

With an additional option allowing for manual startup in a replicated pair of systems by choosing either synchronous or asynchronous replication to provide Disaster Recovery configurations, this new approach to HA really goes a long way to make it much simpler to reach the highest peaks of high availability.

 

There are already a few places to look for more information on this exciting new development. There is a technical blog entry by John Colgrave, along with a GitHub community, and of course the Knowledge Center.

 

Suitable for customers on RedHat Linux on the x86 platform, you need MQ Advanced licensing on just one system node, and MQ Advanced High Availability Replica licensing on the other 2 nodes. Also, this can’t be used with container deployments – but virtual machine images or bare metal is fine. With RDQM now part of the Long-Term Support release of MQ V9.1, you can scale the highest peaks of availability. You are not starting at base camp. You are already close to the summit. Let’s get to the top.

 

Complying with GDPR and the importance of protecting data with MQ Advanced

As a business, acquiring and keeping customers is crucial. You need to ensure that you are continually delighting them, ensuring you deliver the best value, and are easy to do business with. And one critical thing above all others is to ensure that the customer can trust your business.

 

Why is this important? A key reason is that the customer is trusting your business with their information, and you therefore have a responsibility to keep it safe. Because if a customer can’t trust you with their information, they won’t do business with you.

And it is not just a question of customer trust. There is more and more legislation around the world designed to ensure that businesses are taking the protection and security of 3^rd party data seriously. The headlines recently around this have been driven by the deadline date for the EU’s GDPR. But honestly protecting your own data, as well as customer information should have been essential practice anyway.

 

Meeting the needs of GDPR, other legislation in this area, and also customer trust isn’t just about ticking a box and can’t be addressed through a single change or product. There needs to be a comprehensive approach to ensure there aren’t gaps in the security. One of the best ways to ensure that is the thought of ‘privacy by design’ as mentioned in GDPR. Instead of having to try to protect multiple aspects of security in every system, you can ensure security is applied much more widely so that individual areas of security and multiple connected systems are protected without additional effort or overview.

 

There are multiple reasons why a business might use IBM MQ’s messaging to move data within a business, or between businesses. Thousands of the world’s leading businesses have depended on it for reliable, scalable, secure and highly available messaging for 25 years. And while IBM MQ is a secure environment, today’s connected business systems, with the challenge of regulations like GDPR requiring demonstrable protection and records of who could have had access, and the need to show removal of data requires even more security. And this is available as a part of IBM MQ Advanced or IBM MQ Appliance with end-to-end encryption including encryption of data at rest.

 

Why is this important, and how would it help protect data, as well as help to comply with GDPR and other legislation? Consider a typical connected environment with messages flowing across many different connected systems. Maybe data originating from a customer will bounce across different business systems as a message: ordering, invoicing, manufacturing, shipping, loyalty programs. Some of these might be with the enterprise, and others might be 3^rd party businesses who provide a service. As messages flow, they will get persisted to disk to ensure they don’t get lost in case of a failure. But how to ensure that every system and every disk is protecting these messages without having to be in control of all these systems and disks, which might be owned by other organizations?

The end to end encryption in MQ Advanced is policy-based and doesn’t require application updates. In fact, the applications themselves will be unaware that the messages will be encrypted between the sending and receiving applications. The messages being sent over MQ will have the MQ message contents encrypted, but the messaging header (properties) will remain in the clear. As each message is persisted to disk in a queue, the contents will remain encrypted. The messages will only be decrypted at the destination application as set in the policy. With this in place, it becomes irrelevant how many systems the message will travel through between source and destination, or even the security or ownership of each system. It can be demonstrated that the message will not be accessible except to the receiving application, therefore ensuring that there is a complete record of who has had access to every message, and therefore it is under complete control.

 

The enhancements to this end-to-end encryption in MQ Advanced V9.0 and most recently in MQ V9.1 (announced July 2018) not only provide this strong encryption that doesn’t require application changes, but also can be applied with virtually no performance impact either.

 

With your business under pressure from GDPR and other legislation, and the need to ensure your customers can trust you to look after their data and personal information, it has become essential to consider the move to MQ Advanced in order to take advantage of this cutting-edge data protection capability.

Update: For more information in detail about the security features of the IBM MQ family and how they might help as part of a GDPR approach, here is link to a presentation by Jamie Squibb on this topic, presented to Guide Share Europe earlier this year.

Get started today, by downloading the MQ Advanced trial, or MQ Advanced for developers or even simpler try out the new hosted IBM MQ on IBM Cloud .

When 9.1 + 3 equals 2002 – the new MQ Appliance M2002 with MQ V9.1

Children seem to grow up so fast. One day they are new to us, and exploring what they can do, but very quickly they grow up, learn new skills and impress us with their capabilities.

 

For the MQ Appliance it was first released just 3 years ago, as the MQ Appliance M2000. Then 1 year later there was a minor update, released as the M2001 providing bigger, faster SSD storage and more 10Gb networking. Now, stepping out confidently into the world is the 3rd generation of MQ Appliance – the new model M2002, coming out along with the new MQ V9.1 software. Read the announcement letter here.

 

So, what do you need to know about the new model? Many of the benefits are the same. It still is very simple and rapid to deploy and get running. And applying maintenance is also straightforward as a single flash image. And it is still MQ Advanced in a box, with the major benefits of MQ Advanced such as unlimited free connectivity to MFT Agents, end to end message level encryption and access to the Blockchain Bridge. But the M2002 model provides some significant hardware improvements that also lead to pretty outstanding performance improvements.

There are now 24 cores (Intel Skylake architecture with hyperthreading). The storage has expanded with now 4 SSDs, each with 3.2TB capacity. They are now making use of RAID 10, with a doubled RAID cache. And networking has been increased with there now being 6 of the 10Gb network ports. Plus, there are now 40Gb ports – there are 2 pairs of ports, with each pair being able to provide 40Gb in total.

There are still 2 models available – the M2002A and the M2002B. As before the ‘A’ model provides access to the full capacity of the Appliance, including all cores and all storage (about 6TB of usable storage). The M2002B model had access to 6 cores, and access to half of the storage capacity (about 3TB). As before there is an additional capacity option to enable the conversion of the M2002B to the M2002A without any hardware changes or modifications.

 

The combination of the additional number of SSDs and the change to RAID 10 with an increased cache, plus the increased, faster networking means that operational performance can be dramatically increased. Particularly with HA connectivity being able to use the 40Gb networking to reduce latency of the synchronous replication, increased workload can be driven through the appliances at very high rates. Due to various other improvements in MQ V9.1, even customers with the M2001 appliances will see performance boosts.

 

The 40Gb networking ports can be used individually or aggregated together, and while many businesses will yet to have 40Gb networks, if MQ Appliances are in the same rack, they can be cabled directly together.

 

With link aggregation now supported for the 10 Gb network ports, and with 6 of them now provided, the connectivity is far more resilient than before.

 

In another important change, with MQ V9.1’s release, the MQ Appliance will now move to the same mix of Long Term Support and Continuous Delivery releases that have been available for MQ software delivery. MQ V9.1 itself is a Long Term Support release, so MQ Appliance customers will be able to put that into production with stability assured and only fixes in fixpacks, but then subsequent Continuous Delivery updates with additional features will be available, with customers being able to choose to deploy one or other releases on each MQ Appliance.

 

The M2002 models will only be able to have MQ V9.1 or later releases. MQ V9.1 can be installed on all MQ Appliance models, including the M2000 and M2001. With the release of the M2002, the M2001 will be withdrawn from marketing, and the end of support date will be set at 10 July 2023, so that even customers buying the last of the M2001s will get 5 years of regular support. You can read the withdrawal announcement letter here.

 

Another point to note is that the M2002 does not include the Host Bus Adapter that was used in the previous model to provide SAN connectivity. Based on customer feedback, this is no longer viewed as strategic, and will not be progressed any further.

 

The new M2002 Appliances, the 3^rd generation of appliances, will be available later in July, and as before with the previous models of MQ Appliances, will connect easily and seamlessly into existing MQ environments, or be a great way to start out a MQ deployment.

Everyone gets the point. MQ V9.1 delivers the latest features in a Long Term Support release.

They say anticipation is half the fun. And one of the good things about the split release approach for MQ with Continuous Delivery releases and Long Term Support Releases is that as new function is developed and made available in the CD stream, customers intending to use the LTS release can build their anticipation for the new function for up to 2 years.

 

Of course, there is nothing to stop early experimentation with the CD releases even though you may be waiting for the LTS availability. But the good news is that the wait is now over and IBM has published the announcement letter for MQ V9.1 and MQ Advanced on distributed platforms here. Also MQ V9.1 is being announced for the MQ Appliance, as well as a new model of the MQ Appliance – the M2002. You can read that announcement letter here, and a blog about it here. Also we have announced MQ V9.1 for z/OS – there is an announcement letter here for the MLC offering, and another announcement letter for MQ Advanced for z/OS VUE and other z/OS OTC offerings here.

 

Has it been worth the wait? What has been the most anticipated new capability? It’s not like a Christmas present where you are not sure what’s under the tree. Almost every feature, function and enhancement in MQ V9.1 has been already available in one of the CD releases, so there shouldn’t be much of a surprise. You can read some of my past blog entries covering the prior V9.0.x releases (V9.0.1, V9.0.2, V9.0.3, V9.0.4, and V9.0.5)

 

And don’t forget than the previous LTS release – MQ V9.0 included important updates that have proved very useful such as the enhancements to MQ AMS providing end to end encryption, including encryption at rest without performance impacts, which can be very helpful in addressing GDPR requirements.

 

However, let’s cover here some of the most interesting areas of focus over the last couple of years of function, and which ones seem to have attracted the most customer interest.

 

There are many different areas of enhancement, which hopefully means pretty much all users have something to interest them.

Simple and more powerful Administration

• MQ Console – a customized browser based for configuration and operations
• REST API for admin – an extensive set of APIs enabling new tools to be written using REST HTTP calls, usable across older releases as well
• Improved awareness of MQ activities and logging – Publishing MQ statistics to Prometheus and Grafana; forwarding MQ error logs to ElasticSearch or Splunk; Error logs output JSON for improved parsing
• Automation of Linear Logging – simplifying the operations and administration of logging and management of those logs.

 

Supporting Developers

• REST API for messaging – Enabling developers writing simple applications and micro-services to access MQ capabilities.
• Additional API and protocol support – as well as publishing a new online tutorial for using MQ
• Connecting to Salesforce – the MQ bridge to Salesforce allows for the 2 way publishing of information between SalesForce and MQ
• The MQ Bridge to blockchain – only available for MQ Advanced or MQ Appliance customers.

High Availability and Disaster Recovery without complexity and cost

• Replicated Data Queue Managers for HA – synchronous replication across 3 nodes using local disks instead of network attached storage.
• Replicated Data Queue Managers for DR – manual failover with synchronous or asynchronous replication across 2 nodes.
• RDQM requires MQ Advanced licenses. But with specific licenses to reduce cost.

 

Managed File Transfers

• Licensing, packaging and pricing changes. MFT Agents are now free with MQ Advanced or MQ Appliance, and both embeddable and redistributable.
• FTP Protocol Bridge enhancements
• Improved reliability and monitoring for Transfers

 

 

z/OS enhancements

Many of the updates described above also apply to MQ on z/OS. There are also some additional enhancements specific to z/OS

• AMS Confidentiality Performance. MQ Advanced for z/OS VUE sees enhancements in performance of this feature in MQ V9.1
• Extended deployment for MFT – with MQ Advanced for z/OS VUE.
• The MQ Bridge for blockchain now using the Hyperledger Composer API to build out the connectivity.
• Connecting CICS and MQ – Java programs running on a CICS Liberty JVM server can now use MQ classes for JMS to access MQ capabilities.

 

AS MQ now moves to MQ 9.1, this time the point is available for everyone. All the features above, and more I haven’t had a chance to describe will be available later in July 2018. Whether deploying in on-premises environments, on physical Appliances, on VMs, in containers, on private clouds like IBM Cloud Private, or public clouds like IBM Cloud, AWS, or Azure, the Long Term Support release now means the 2 years of functional enhancements, tested already in multiple Continuous Delivery releases are now available for more to use.

UPDATE: MQ V9.1 now available as of July 23rd 2018. Read more here.

And there is plenty more to come. Watch this space both for more updates and use cases of these features, and well as future updates in the next Continuous Delivery releases.

Putting out a new release like IBM MQ V9.0.5 is more than a 9-5 job

At least in the UK, the traditional hours worked in a day job were 9 to 5. You would ‘clock-in’ at 9am and leave at 5pm. I guess it is common as there was a 1980s film called “9 to 5” starring Dolly Parton. These days office life is rather more flexible, and certainly the idea of clocking in and out at fixed times is gone.

 

For 25 years, virtually every major IT infrastructure has been able to rely on the secure and reliable exchange of data between applications and systems thanks to IBM MQ. Previously called MQSeries, then WebSphere MQ, this software offering, developed in the IBM Hursley Lab in the UK has been a critical part of the business world. So much so that most people living their lives have no idea they use IBM MQ so much on a daily basis as it ‘just works’.

 

There is a great team of developers who work hard day-in and day-out to enhance and update IBM MQ, and . We have now released IBM MQ V9.0.5, going GA on Friday March 16^th. And our developers have worked for months, giving up evenings and weekends to not just add new features, but to make sure it is another offering that works when put into use. So not 9-5 at all.

 

Now for some customers this will be more of a prelude to the main act. This is referring to V9.0.5 being a Continuous Delivery release. When we brought out V9.0 we split it into 2 streams: Continuous Delivery and Long Term Support. This release marks the final release in the initial set of Continuous Delivery releases. The next release will be the first of a new Long Term Support release. And customers can expect that the functions delivered in the 5 CD releases will be made available in the new Long Term Support release.

 

When that new LTS release is available, you can expect me to summarize all the new features, but for now in this blog I will call out a few of the new features in V9.0.5.

 

The new Easy HA feature (Replicated Data Queue Managers) delivered in MQ Advanced V9.0.4 gets updated to add support for a Disaster Recovery mode, with manual takeover after either synchronous, or asynchronous replication between a pair of MQ servers.

 

The MQ Managed File Transfer capability, available with MQ Advanced or MQ Appliance gets the first support for the REST API admin interface for listing current transfers and querying MFT Agent status.

 

MQ Advanced itself will do more to identify itself when it is installed, and so prevent compliance issues, and ensures that components can recognize Queue Managers.

 

Other updates include a MQ Console refresh, and for customers who use MQ with WebSphere Application Server, performance enhancement through implicit syncpointing.

 

For MQ Appliance users there is an enhancement for better reliability by allowing aggregated IP interfaces for the Floating IP feature. This removes a potential single point of failure.

 

And for users of MQ Advanced for z/OS Value Unit Edition there have been improvements including enhancements to MQ AMS which will see increased performance.

Perhaps even more exciting is the new availability of a hosted instance of MQ on the Cloud. More about this can be found here, but it creates a great opportunity to quickly and easily make use of MQ without needing to install, deploy or manage the environment. Just configure and go! Nice that after 5 years of talking about it on this blog we have an explicit offering running in the cloud. This is of course alongside MQ already being able to run in AWS as a QuickStart. Or deployed as containers in IBM Cloud private.

 

As well as looking forward in the future to a new Long Term Support release, the statement of direction indicated that the Blockchain bridge, available in MQ Advanced, will be updated to be based on the Hyperledger Composer interfaces. And additionally, customers deploying MQ in containers will in the future be able to track the size of the container, and the duration of use, and license based on that container size, rather than the full capacity of the system where the container is running. The intent will be to support existing pricing metrics such as PVUs and VPC monthly metrics, but also a future VPC Hourly metric.

IBM MQ, along with many other IBM and business partner solutions will be some of the highlights discussed at IBM Think in Las Vegas running March 19^th-22^nd. I will be there and I hope to see some of you there as well. Famously Las Vegas never sleeps, so I guess that’s something else that’s not 9 to 5. Lucky we have IBM MQ V9.0.5 now though.

 

Reaching for SANity with the IBM MQ Appliance

We all like to keep our word, and even though a Statement of Direction is not always a promise, at IBM we like to try and deliver what we set out, as long as the market and need hasn’t changed.

And for customers who have been following the MQ Appliance since the start, back in March 2015, you might recall that there was a Statement of Direction about adding support for the fibre channel cards that were part of the MQ Appliance hardware to allow connectivity to a SAN for customers who wanted that. And we are delighted that as part of the MQ V9.0.4 update on the MQ Appliance, that IBM is delivered on that Statement of Direction.

MQ V9.0.4 is a very significant update for MQ and most of the updates that are not specific to the MQ Appliance are described in my other blog entry here. However, in addition to those features there are specific MQ Appliance updates, and a dedicated announcement letter which I will try to explain in more detail here.

Firstly, the SAN support. One of the reasons the MQ Appliance has been so popular with customers is the built-in storage (2x 3.2TB SSDs in a RAID 1 configuration) and the simple HA configuration allowing a pair of MQ Appliances to replicate messages and log data between them on a QM by QM basis with just a couple of clicks on setup. And a lot of the updates to the MQ Appliance has been to support the wider use of this popular deployment use case.

However, some customers have always wanted us to add support for SANs for some of their use cases. One use case was that 3.2TB of onboard storage might not be enough. If you consider when a consuming application might fail over a long weekend and the queue depths might get very high. One of our customers recently said, “an empty queue is a happy queue” and this is true, but in the case of a protracted failure you want to ensure your queues can hold all the messages. So, if you are concerned about this scenario, then you might want to have the Queues supporting that use case on external storage where there is no effective limit to queue depth.

The other use case, which tends to come up more commonly in customer discussions is around the thought of “consistency groups”. This is when you are trying to recover from a site failure at your disaster recovery location. This is typically a manual task, unlike the automated High Availability configuration. Part of this manual task will be to establish the last known transactions of not just MQ but other parts of the IT infrastructure such as applications and databases. This is likely to be easier if all the data points from all these ‘moving parts’ are stored on a common storage area, and this is replicated consistently between the SAN on one site and the SAN on the disaster recovery site. So this use case is now supported by the MQ Appliance with customer selected Queue Managers able to choose the SAN storage instead of the internal storage and have a MQ Appliance in the disaster recovery site read the replicated messages and data from the SAN there.

A second update to the MQ Appliance specific features is to provide customers with a quicker and simpler way to ensure that Queue Managers on the MQ Appliance have the best allocation of resources on the MQ Appliance. When Queue Managers are initially created the MQ Appliance determines how much space to allow to them. However if workload on a Queue Manager grows faster than other Queue Managers, it is likely that the allocated resources might need to grow to match the likely workload. However, it hasn’t been easy to do that. But with the MQ V9.0.4 update on the MQ Appliance IBM has added dynamic disk allocation, enabling resources for a Queue Manager to be increases even after it was initially created. This will make the ongoing operation and support of production workloads on the MQ Appliance quicker and simpler.

Finally, an update off the MQ Appliance will have a positive impact on potential use cases for the MQ Appliance. Virtually every customer still moves large amounts of data around their business as files and file contents. Much of this is unmanaged, insecure and unreliable, and for a number of years IBM has provided a solution: MQ Managed File Transfer. This enables file contents to move from point to point over the MQ network as MQ messages, taking advantage of MQ’s reliability, security and manageability. Part of the MQ Managed File Transfer functions was a logger to track which files were sent over MQ, and this, if used, always needed to run on the same machine as the Queue Manager. This prevented some MQ MFT use cases from being deployed in environments where the MQ Appliance was the only MQ Queue Manager. Now, with MQ V9.0.4 the file logger component of MQ MFT can be deployed remotely from the Queue Manager, meaning it can be used in locations by pointing to a remote MQ Appliance, without the need to install anything on the MQ Appliance, which has always been prohibited. It’s always good to allow customers more flexibility in deployment.

This combination of enhancements, along with the many non-Appliance specific MQ updates in the MQ V9.0.4 release means that there should be a lot of increased opportunities to consider the MQ Appliance as the right deployment option. After all many customers who review it with regards to overall costs find it has the lowest Total Cost of Ownership, as well as outstanding reliability.

Two steps forward, no steps back with IBM MQ V9.0.4

Compromise is everywhere. We are told to take the rough with the smooth. The easy with the hard. The quick win and the hard slog. And with software we often have to accept compromises. Especially so these days with the drive for new function forcing some compromises with stable deployments.

Not so with the latest update to the MQ family of products. For the last 15 months IBM has been delivering updates to MQ using a Continuous Delivery stream. There have been many useful additions, but they have always required adoption of the latest version to take advantage of the new features. With the latest update moving to MQ V9.0.4, there are even more substantial updates of useful features for both base MQ and MQ Advanced. However in recognition of the need for customers to keep some systems back-level while also wanting to take advantage of new features, some of these updates are designed to allow existing deployed systems to take advantage of the new capabilities, both without being updated and without breaking the Continuous Delivery and Long Term Support principles.

In addition to this extremely useful update, which I will get to in a minute, which can be used across the entire MQ estate, there are some groundbreaking updates that will allow huge changes in the way MQ is used, deployed and managed in this update. It is more leaps forward rather than steps forward.

For MQ Advanced we have 3 key new capabilities:

• A new ‘easy HA’ feature – Replicated Data Queue Managers
• More flexible Managed File Transfer deployments
• Availability of an enhanced Blockchain bridge

For MQ Base (which is part of MQ Advanced) there are a number of other enhancements

• Additional commands supported as part of the REST API for admin
• Availability of a ‘catch-all’ for MQSC commands as part of the REST API for admin
• Ability to use a single MQ V9.0.4 Queue Manager as a single point gateway for REST API based admin of other MQ environments including older MQ versions such as MQ V9 LTS and MQ V8.
• Ability to use MQ V9.0.4 as a proxy for IBM Cloud Product Insights reporting across older deployed versions of MQ
• Availability of an enhanced MQ bridge for Salesforce
• Initial availability of a new programmatic REST API for messaging applications

 

All of these features are called out in the new announcement letter for MQ V9.0.4 here. And there are further updates available for the MQ Appliance listed in the specific announcement letter for it here and in another blog entry here. There are also announcement letters for IBM MQ z/OS V9.0.4 and IBM MQ Advanced for z/OS VUE V9.0.4

However, let’s try and call out some details of the key points of the MQ V9.0.4 update below:

The new High Availability feature (officially described as Replicated Data Queue Managers or RDQM) provides a significant new way to configure High Availability. It is only available for MQ Advanced users on x86 Red Hat Linux. It is designed as a 3 node system which uses replication of messages and logs between the local disks available to each Queue Manager. This style of replication of local disks was previously only available with the MQ Appliance. As moving to this new style of HA will allow customers to stop using network storage for MQ, we anticipate it will be very popular. As well as the disk level replication, Floating IP will be used to help applications move seamlessly to a failover QM. And 3 nodes help to prevent ‘split-brain’ situations where 2 nodes are simultaneously active.

The licensing of the above deployment requires MQ Advanced as already stated. However as long as all Queue Managers on all 3 nodes are Replicated Data Queue Managers, and all 3 systems are the same capacity, then only one node needs to have a MQ Advanced license entitlement. The other 2 nodes can be licensed with MQ Advanced High Availability Replica parts (these parts used to be called Idle Standby parts).

The changes to the REST API for admin are also significant. Over the last few releases more and more ‘verbs’ have been added to allow REST API calls to configure and manage MQ. This was designed to allow more modern tools to be built as an alternative to MQSC and PCF based tooling. The latest V9.0.4 release adds more verbs and also a way to call the remaining equivalent MQSC functions within a REST API structure. However what is perhaps more interesting is that a single V9.0.4 Queue Manager can now act as a ‘gateway’ Queue Manager to allow these new REST API driven tools to configure and manage Queue Managers that are older and don’t include this new Continuous Delivery function. This is hopefully a very good way of providing the best of both worlds. Allowing the older production Queue Managers to remain deployed but still take advantage of new features.

Similar to this ‘bridge’ feature is one for IBM Cloud Product Insights, where the ability to publish deployed Queue Manager data to Cloud Product Insights was limited to releases on the Continuous Delivery stream, but now a single V9.0.4 Queue Manager enables older installs to publish data to this useful dashboard tool.

The MQ bridge for Salesforce has been enhanced to allow MQ to publish data into Salesforce, instead of simply receiving push notifications from Salesforce.

Customers with MQ Advanced who want to explore the possibilities offered by Blockchains now can deploy a bridge which enables MQ applications to query the Blockchain, and also provide data input into it. An earlier version of this was available only to customers with MQ Advanced for z/OS VUE, but this version is available to customers using MQ Advanced on distributed platforms.

MQ Advanced customers also get more flexibility in how they can deploy the file logger in MQ Managed File Transfer scenarios, as this logger can now be deployed on a different machine to the MQ Queue Manager.

And finally, feedback from customers told us that developers were looking to make sure of MQ, but with fewer dependencies, to free them up from client and language bindings. As such we have also added the first layer of support for a new set of programmatic REST APIs for messaging applications. This will replace the previous HTTPBridge function which has already been deprecated. Over the next few releases it is hoped that more functions will be supported in this REST API for messaging to allow additional messaging calls to be supported.

Counting up the advances it does look like it is more than 2 steps forward, and certainly no steps back. And with the ability to use some of these features alongside your older MQ releases, what are you waiting for? Download it from here today. Or try it on Amazon AWS Quick Start.

Want to know more. Check out the webcast. Register or replay at this link.