Posts Tagged ‘AWS’

Banish those winter blues with IBM MQ V9.1.2

February 8, 2019

Screenshot 2019-02-08 at 14.40.14

In the depths of winter in the UK we are told that Monday 21st January is referred to as Blue Monday, when the fun of New Year has died away and it is clearly a long time to go until the arrival of the lighter warmer days of spring. But now, just a couple of weeks after Blue Monday, Big Blue IBM is trying to relieve the gloom with the announcement of the latest CD release: IBM MQ V9.1.2. You can read the announcement letter here.

 

As the 2nd Continuous Delivery release of MQ V9.1, this builds on the previous release with a number of enhancements and new capabilities.

Screenshot 2019-02-08 at 14.27.50

Probably the one that will be of most interest to people is a new capability which is the first step in what will be an ongoing series of updates to MQ. We are calling this a Uniform Cluster, and this specific enhancement is designed to make it easier to balance workload across queue managers which could be both growing and shrinking. This workload balancing will be without the need for the applications to co-ordinate changes in the MQ Queue Manager destinations. Instead MQ will itself balance the workload across the set of Queue Managers defined to be a part of this ‘Uniform Cluster’. Initially this is only for applications written in C. This area of MQ is likely to continue to be an area of focus, as further enhancements could easily be considered with a view to MQ being far easier to scale up and scale down, much as a cloud native service would be expected to do.

 

Another key enhancement is around the use of REST messaging. When this feature was initially introduced, it sparked lots of interest, as there are many use cases where it would be helpful to call MQ without having MQ Client libraries. In this release, connection pools are supported allowing for the caching of connections for reuse, which should improve throughput and reduce resource use.

 

Other updates in the base MQ capabilities include .NET core support for Linux to add to the Windows support added in MQ V9.1.1. Also improvements to scalability and availability when working with WebSphere Liberty for XA transactions.

 

Increasingly important to many MQ customers is MQ Advanced. The MQ MFT feature of MQ Advanced, which is widely used to onboard file data into MQ and then send and consume that data as MQ messages gets further REST API functions to enhance administration. This continues what we have seen in the last few releases for MQ MFT.

 

Other interesting improvements include updates to the Salesforce and Blockchain bridges, and the MQ Appliance sees errors logs integrated with system log external targets.

 

There are a number of other really interesting updates to the MQ family which have also come out at this time.

 

Probably everyone is seeing a lot of the same interest in container deployments. And IBM MQ has been supporting container deployments for many years, and recently have put out an IBM Cloud Pak to better support deployment on IBM Cloud Private. However we have now also released a container image of MQ Advanced for Developers for Pivotal Cloud Foundry. This will be available shortly.

 

The MQ Cloud offering, which provides a hosted MQ environment maintained by IBM has been seeing lots of growth and enhancement, with new data centers being added for both IBM Cloud and AWS, as well as adding functional support for the MQ AMS end to end encryption and the MQ MFT features. The latest update adds a Lite plan, allowing ongoing free use of a hosted MQ environment, without the need for a credit card, limited to 1000 messages per month. Check it out here and now!

 

And finally, something else for the developers. While MQ continues to be a robust production platform on Linux, Windows and other environments, there hasn’t been any IBM provided releases for Mac. If you wanted to develop MQ applications on Mac you would need a VM with a supported OS. However we have now released the MQ client for Mac – you can download today from here and start developing much more simply today.

UPDATE: Now we have availability of MQ V9.1.2 here is a blog from Ian Harwood expanding some of the points and with links to access MQ etc.

And if all that doesn’t blow away the winter blues, what will? Maybe a trip to San Francisco for the Think 2019 Conference? I have a number of presentations there so come by and say hello. Otherwise there will be a number of other events through the year. Let’s hope for some sunny and warm weather!

Screenshot 2019-02-08 at 14.25.32

Advertisements

License to Thrill – bring your MQ license to the cloud – with MQ V9.1, not 007

December 8, 2018

Screenshot 2018-12-07 at 18.13.26

Your typical IT infrastructure these days has more clouds than a sunny day in England. We easily go from no clouds, to dozens of clouds in an instant. And unless you are prepared and can adjust for this situation, you can quickly start having a bad day.

thisisfine

Let’s think of a common scenario. One which I get asked at least once a week. You are a business, and you are starting to explore the opportunities for running on public cloud. You aren’t likely to go ‘all in’ on day one, but you have 1 or 2 projects that will be a great fit, or so you hope.

But how do you get started? You probably have a cloud in mind. Maybe AWS. Maybe Azure. Maybe even both. Your developers are keen to get started. But you remind them, in order for the applications to work with your wider environment, you will want them to exchange data with many of your other applications using IBM MQ.

This has a number of benefits. Not only are you ensuring you are reliably and securely exchanging the data between applications. But as the different applications connect using IBM MQ, they can remain mostly unaware of where they are running and where the applications they are connecting to are running. As application deployment updates happen, IBM MQ configurations can be updated but the applications remain unchanged, not caring about the deployment details.

Screen Shot 2018-11-06 at 11.47.38

But one of your concerns might be around licensing. As you are used to running IBM MQ on-premises, you are used to running ILMT to track your deployments and using this to generate reports to show to IBM you are running within your entitlements. But how does this happen if you are running in a public cloud? Let’s assume you haven’t chosen the option of the hosted service of IBM MQ on cloud, but have chosen to deploy and manage your own MQ deployments on your clouds of choice.

The good news is that you can make use of the same PVUs that you have typically used to entitle your on-premises deployments. Imagine your new deployments will require throughput that you have been testing and figure out you will need 5 cores of IBM running on AWS, and workload needing 10 cores of IBM MQ Advanced running on Azure. How does this map to your existing PVU entitlement that you currently have sitting unused ‘on the shelf’.

The good news is that IBM has evaluated deployments on public cloud infrastructures and allows simply mapping of public cloud cores to IBM PVUs. You can review that information here with the general rule looking like for each vCPU that your deployment uses in public cloud, you need to ensure you have 70 PVUs of entitlement. So for the example given above, the 5 cores on AWS would require 350 PVUs of MQ entitlement and 700 PVUs of MQ Advanced on Azure. In common with most other IBM software, there isn’t a license key. But you will need to be able to keep records that can be shared with IBM to show your deployment and that you are compliant with your entitlement. Ordinarily, on-premises, this would require ILMT to run everywhere. However when deploying MQ on public clouds, these also have good reporting mechanisms. IBM will accept these reports as proof of deployment, and of the size of the deployment. However, if possible it is preferred to also ensure ILMT is deployed on these cloud environments to ensure consistent reporting with other environments. This, however, isn’t mandated, as long as you bring your own license to the cloud to provide entitlement.

So whether a “License to Thrill”, or a “For Your Eyes Only”, you can be sure “Messages are Forever” with the reliable, secure, once and once only messaging of IBM MQ, on public cloud, or on premises.

If you want to get started there are a number of technical blogs like this.

Or don’t forget our Quick Start for IBM MQ on AWS with a blog here and the actual link available here

Screenshot 2018-12-07 at 18.17.54

Trying to contain your excitement – IBM MQ and Containers

November 30, 2018

Screenshot 2018-11-30 at 10.09.23

The world of enterprise IT is always in a state of perpetual change. The one thing that doesn’t change is the ongoing change we are all living with and occasionally challenged by. What’s maybe most interesting about the change going on today is that the change is not one major shift but many different shifts. Some of these are interrelated and overlapping. Others less so.

Screenshot 2018-11-30 at 10.07.52

One of the major changes has, somewhat obviously, been the shift to cloud. This shift is ongoing and is very broad, encompassing both public and private clouds, and indeed multi-cloud. There are some other changes going on which are distinctly related to this cloud move, and these are very much an enabler to this change. This is the ‘containerization’ of IT deployments, seen today in the widespread adoption of Docker containers and Kubernetes environments to deploy them. This technology underpins much of the public and private cloud use, and itself is driven by, and enabled through the shift to a ‘devops’ style of management which allows for better use of resources, and for businesses to be far more agile. This approach is described in a number of ways. Typically this has been as “cattle and pets” to describe the difference between containers and more bespoke systems, but one of my colleagues (thanks Woz) likes to describe the environment as more like hire cars, versus your own car.

Screenshot 2018-11-30 at 10.12.41

With a hire car, you start using it when you want. You do what you want with it. Then when you finish using it you stop using it, not thinking about it again. You haven’t needed to maintain it. You haven’t done anything to it. That car may as well no longer exist as far as you are concerned. Compare that to your own car. You decide exactly what car you want, then once you have it, you likely have it for a long time. You might personalize it. You probably maintain it, and enhance it over time with new tyres, wheels, exhaust. You leave your things inside it, knowing that when you go back to it, they will still be there.

 

That analogy is pretty good for the difference between containers and more traditional long-running environments. Containers are stateless. Once you get rid of them, there is nothing left in the container. This is like a hire car. When you pick up a hire car, it is exactly as you expect it. Nothing inside it. And when you return it to the hire car company, you better remember to take your luggage, your sunglasses, and the rest of your family members, as they certainly won’t be in the car if you come back and hire it again the next day or the next week. The car you own, however, has state. If you leave a bottle of water in it, then it will still be there the next time you use it. The fuel level will be the same (unless your children have used it and emptied the tank). And your sunglasses will be there within easy reach when the clouds clear and the sun comes out.

 

So, let’s talk about IBM MQ and containers. Because MQ is, at its heart, a stateful product. It preserves state in the form of messages. And yet if containers are stateless, why would you run MQ in a container? Isn’t it a contradiction? The answer is no. But it is certainly something you need to think about. And that goes back to why, and how you are using containers. As mentioned above, you are using containers probably as part of a devops environment. You will be deploying applications in containers, which will run as long as needed, and then the container, and the application will be removed. At least until next time. But what does IBM MQ do? It connects applications together. It provides a long running persistent environment to allow multiple applications to reliably and securely exchange messages. It doesn’t matter to MQ if one application in a container goes away. MQ just sits there and runs. It waits for the next application to appear and to put and get more messages. Some messages will sit in the queues for longer than others, depending on the message and depending on when the consuming applications are running. MQ, in essence, doesn’t really care if it is running in a container or not. MQ has supported containers since 2015. MQ can be run natively in Docker based container environments, in Kubernetes environments, in Red Hat OpenShift and in IBM Cloud Private. Indeed the recent MQ on Cloud hosted service is deployed as MQ in containers on both IBM Cloud and AWS. But in many expected use cases, although MQ will be running in a container, it is unlikely that the devops plan will see those MQ containers brought up and shut down as frequently as application containers are brought up and shut down. The administration team will need to be sure that all the messages in the queues have been drained before removing the container running MQ. Otherwise they will destroy a message, which is likely to have business value.

Screenshot 2018-11-30 at 10.13.38

While you may run MQ in a container, businesses should be aware those containers are likely to be much longer running, because MQ is stateful, and preserving that state means keeping MQ up and running.

 

In summary, you absolutely can run IBM MQ in containers, and in your choice of container environment, such as IBM Cloud Private, or Red Hat OpenShift, or a combination. With a container based devops environment, that might be the best way to deploy and manage MQ. And there is a new way to license MQ running in containers as described here. However, the long running nature of MQ might also lead you to review whether, if MQ might be running continuously for months or even years, whether you want to treat MQ the same as your stateless applications. Does running in a container really make sense? It should certainly be thought about. You might even consider deploying MQ in a VM or maybe even deploying the MQ Appliance, which you could even think of as a container – just one that is rather more substantial than the ephemeral nature of the other containers you are using.

 

Screen Shot 2018-07-27 at 15.30.23

Many of the updates that IBM has made with IBM MQ over the last few years have been focused on responding to the customer choice. Wherever and however customers run applications, IBM MQ will be there to support those deployments and environments. On the cloud as a managed service. In containers. As a physical appliance. On the mainframe. Meeting your needs. Never losing a message. No wonder it’s hard to contain your excitement.

Next steps might involve downloading container images here.

Or reading more about MQ and containers here

Reach out with IBM MQ and Amazon Web Services

November 6, 2018

Some of you reading this might be old enough to remember a commercial from AT&T urging you to “Reach out and Touch Someone” with a phone call. Which was a pretty clever concept – taking the ephemeral and remote nature of a phone call and making a real difference to people’s lives, actions and feelings.

Every business today is still trying to do this: interact with their customers, partners, and the market in general. And just as with phone calls the medium they are choosing to use is ever more widely IT infrastructure, which is more frequently now developed and running in clouds. And why is this? Why are businesses building and running applications in clouds such as Amazon Web Services?

Screen Shot 2018-11-06 at 11.41.40

A key reason is speed. That is speed to build, speed to deploy, and speed to reach those customers who you are trying to ‘reach out and touch’. Because the market is moving faster than ever, and you need to move just as fast, because if you don’t your competitors will.

Deploying applications on clouds such as AWS has never been faster or easier. But simply building an application does not mean you have built a business. If you are investing to build applications to engage with customers and progress opportunities, then it is essential that you handle those business opportunities with care. If you build an application to engage with a customer, then you need to capture that engagement and not lose that data. If you have taken an order you need to make sure you process it once and once only, not duplicate it or lose it. Your new cloud-based applications need to connect to the rest of your business with a reliable and secure messaging layer such as IBM MQ.

Screen Shot 2018-11-06 at 11.42.02

The good news is that IBM MQ can be deployed anywhere in your business, and beyond to provide the connectivity infrastructure you need, where you need it. That includes IBM MQ running on AWS. This has been possible for years, but now there is a new option: IBM MQ on Cloud deployed on AWS. In this case IBM will deploy and maintain the MQ Queue Manager on your chosen AWS region, and all you need to do is configure the Queues and use MQ as required. You can not only respond quickly to business needs and opportunities but do so without the concern of managing the physical infrastructure or keeping MQ deployed and running, allowing more time to work with customers.

Screen Shot 2018-11-06 at 11.42.23

If you want to reach out and touch your customers by making use of IBM MQ on Cloud running on AWS then you probably want to find out more. Why not check out the upcoming webinar about MQ on AWS by Woz Arshad  which goes out on November 14th.

And if that’s not enough, and you are coming to AWS re:Invent in Las Vegas at the end of November, we will have experts from IBM Hursley there to talk to, with David Richards giving a talk (DEM42 : IBM MQ on AWS – Don’t Go Home Without it, Wednesday 28th November at 1.10pm), and myself, David and Matt Roberts in the Expo. Maybe not ‘reach out and touch us’ but come by and say hello! We will be happy to tell you more about IBM MQ on AWS, and the unique benefits it offers, such as connecting workloads on AWS to on-premises applications.

 

Screen Shot 2018-11-06 at 11.47.38

Don’t get caught out by clouds of hot air. IBM MQ builds reliable bridges in a multi-cloud world.

October 5, 2018

oldmanyells

More and more businesses are realizing the value of moving to the cloud. There are as many, if not more reasons to move to the cloud as there are different clouds. Any single business is likely to have already deployed to multiple different clouds, both public and private. And different departments will have different priorities and success goals covering agility, availability, location, cost, or multiple other reasons. Certainly some businesses will be looking for the expected benefits of cloud but want to still run in their own data center using a private cloud architecture.

 

Central to these decisions are the business applications, which are already changing rapidly, benefitting from this new deployment environment. Cloud deployed applications typically scale more readily and may be built out of many cloud specific common services, designed to maximize the positive aspects of deploying and running in the cloud, and not have you running off a cliff, instead of running into the future.

wile e coyote cliff

There are however other important design points. If an application is built solely to use the tools and environment specific to a single cloud, then flexibility and freedom to change will be limited. Around 80% of businesses already admit to using more than one cloud provider, which will see a need for applications running on different clouds to connect together, as well as connecting to any applications still running on-premises. Additionally, applications may need to use functions that are available on multiple different cloud environments in case the applications need to be redeployed on other clouds. And that will definitely be important when it comes to the connectivity mechanism for data exchange between applications.

 

IBM MQ was originally built to connect applications running in different environments, allowing them to exchange data with reliability and security, and to provide a common, cross-platform way for applications to do so. And this is exactly the challenge now being faced with applications built for different environments having to connect and exchange data across different clouds as well and into and out of the on-premises data center.

Screen Shot 2018-07-27 at 15.30.23

A strong benefit of IBM MQ is that all applications can drive their connectivity through a single consistent interface. This not only simplifies the application development, but ensures that the application can remain unaware of not just where it is running itself, but also where the applications that it is trying to connect with are running.

 

As an asynchronous messaging layer, IBM MQ can buffer the connectivity between applications that run at different speeds, and also, with MQ running in every locations, then connectivity breaks between locations, or latency issues can be handled by IBM MQ rather than by complex logic within the applications.

Screen Shot 2018-10-05 at 18.59.13

IBM MQ is able to be deployed as an IBM managed and hosted messaging server on IBM Cloud and AWS, or deployed and managed by customers on any public cloud. And on-premises, IBM MQ can be deployed in mainframes, as a physical appliance, or on servers such as Linux, Windows or more, in containers or in VMs. This flexibility, combined with the persistence, security, reliability, scalability and high availability that much of the world’s leading businesses depend on mean that you can move to the cloud with confidence.

 

There is no better way to bridge between your applications and across the clouds that with IBM MQ.

Millau2

Data in motion is data adding value. Using MQ for data transfer from files as well as applications

September 21, 2018

gold bar

Data. It’s sometimes described as the new gold. Certainly, it is valuable. But how exactly does it compare to gold?

The value of gold is that it can be made into gold objects such as jewelry which will have both the value of the metal and have additional value because it has been put to higher value use. But there are also costs associated with owning gold, keeping it safe, and moving it safely and reliably from where it is to where it needs to be. In order to realize the value, the gold jewelry must be moved from where it has been created to where it is needed.

 

What about data? Like a delicate piece of gold jewelry, some people might value a piece of data highly, but to others it is of little or no value. While gold is essentially fungible – as any gold can be fashioned into something, each piece of data is unique, not just in itself but set in its own context. Think of when you are trying to complete on a purchase of a house. An agreed mortgage is all very well, but what’s important is that the transfer of funds happens at a specific time to a specific account to allow the purchase to go through.

 

While a piece of data might represent something, the value of the data is only really achieved when it is moved to the right place at the right time. Having the data held securely in a system is not valuable on its own. It needs to be moved to be valuable. Data is created somewhere in the infrastructure but needs to be consumed somewhere else to add value.

 

This gives us a number of problems with data. Storing it safely; moving it safely; knowing it has arrived, so it can be put to use. This is again similar to gold. You have to keep it safe, and certainly you have to look after it as it moves as well. And if you have made a piece of jewelry for someone, you have to let them know you have it ready for them.

 

In your business you will have huge quantities of data. Data that is being created every second and stored in your file system. Buried treasure. I have already discussed this in here before. So what are you going to do?  You need to move it safely and securely to the part of the business that can make use of it. Probably the faster you move it, the better. And you certainly don’t want to lose it. Or have it stolen as it moves. And wouldn’t it be helpful if as it was delivered to the destination, the target application could immediately be made aware of it.

 

All this of course is handled for you by the Managed File Transfer component of MQ Advanced or MQ Appliance. The name is slightly misleading as it doesn’t move files but instead the contents of files can be moved as MQ messages. This means they take advantage of MQ’s unmatched secure and reliable delivery. No lost messages. No lost data. Your data gold will reach where it needs to go. And it can even be delivered directly to the target application without being written to the file system again.

 

Just as you wouldn’t want to keep all your gold in a vault where it wouldn’t add value to your business, don’t keep your data held up not adding value. Put it to work by moving it through MQ. When you have MQ Advanced or MQ Appliance you can deploy unlimited numbers of MFT Agents inside or outside your business. You can even embed them inside applications you share with your partners or suppliers. And the latest updates in MQ V9.1 add further enhancements to the MFT functions.

treasure

Think of all the buried treasure that has been lost over the years. Don’t let your data join those wasted resources. Get started today by learning MQ or with downloading a MQ trial. Or see what you can do with a hosted MQ on IBM Cloud or now on Amazon Web Services.

 

Not all data is treasure of course. You have to understand what’s valuable. But if it is valuable, then you should ask yourself why you aren’t moving it reliably through MQ Advanced, taking advantage of end-to-end encryption. After all you don’t want to go on a pointless quest with nothing at the end of it. Or find that your treasure has been taken.

journey_cost

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

October 24, 2017

hopscotch

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:

RDQM1

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).

RESTproxy

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.

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

April 19, 2016

edwin-moses-getty_2129850b

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 19th, 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.

MQ AMS performance

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.