Posts Tagged ‘MQ Appliance’

Trust is a fragile gift. Protect your customers’ trust with end to end encryption from IBM MQ Advanced and MQ Appliance

May 14, 2019

Screenshot 2019-05-14 at 19.33.06

Every time any of us go online we are taking a leap of faith and putting our identity and personal data at risk. Whether you are reading a blog post, watching a video, checking your account or buying something, you have probably had to expose your identity a little. It might be just being tracked by cookies, or you may have needed to create an account, or prove your identity, or even share your bank or payment details. All of these actions can leave you, or your personal information at risk.

 

As a consumer, while you are expected to take some precautions to protect yourself, much of the responsibility lies with the businesses in whom you are putting your trust when you provide them with your personal data. But what happens when that trust is misplaced? Would you make a different choice of who you trust if you thought the business or organisation was going to lose control of your data?

 

Breaches happen regularly. The happen to all sizes of company or organisation. It could be a retailer, or a bank. It could be an airline, or a dating site. It could be an accidental exposure, or it could be the result of malicious hacking or malware. Sometimes the reason is clearly an attempt to divert money or steal payment information. However, sometimes access to the data itself is enough. The UK government is drawing up guidelines to block access to all porn sites unless the user is verified, creating a potentially large database of user information that could be a target of hackers. There are many costs associated with security breaches: fines, lost business, reputational damage, with lots of details in the IBM and Ponemon Report.

 

If you go onto some of the sites which have had breaches, very few of them mention it. They would rather you forgive and forget. However, I would certainly like to know they have taken steps to ensure it doesn’t happen again. And if any business I am looking to put my trust in are a user of IBM MQ, I would hope they are also using IBM MQ Advanced or MQ Appliance, as these provide the access to MQ Advanced Message Security (MQ AMS).

Screen Shot 2018-07-11 at 11.13.48

One of the ways in which breaches can happen is not by the failure to secure a program but the failure to consider the end to end security aspects. For messaging, while encrypting the messages over the wire is normal, without considering encryption at rest there can be a risk of access to the storage itself. Unauthorised access to storage, either accidental or otherwise, would expose the contents of all messages unless these contents were encrypted. And adding in application to application encryption is complex and expensive.

 

With MQ Advanced or MQ Appliance, you can define policies within MQ to have the message contents encrypted without any required changes to the applications themselves. This encryption of the contents will ensure that even if the access to any of the storage between sender and receiver were compromised, then those contents are protected, and the trust of your customers has been earned.

Even if your total security focus is successful enough to prevent actual breaches, there is a benefit from protecting your message contents in this way. As a conscientious business you will have regular security audits, potentially consuming weeks of time to validate your security. How much simpler would it be to explain the end to end encryption of your messages, ensuring data protection and removing the need to include in the audit of the messaging system the potential access to possibly dozens of systems. And by excluding the possibility of unauthorised access to data, you have reduced the overhead of complying with GDPR or other regulations.

padlock

 

The latest performance improvement to the implementation of this encryption in MQ Advanced as detailed here show that for the Confidentiality setting there is only an impact of a few percentage points on overall throughput, which should mean every customer ought to be considering why not use this, rather than why use it. Or if using the MQ Appliance, which has this feature included, then the performance of the M2002 model is exceptionally high, giving a great platform for robust, rapid and secure messaging.

M2002performance

Your customers are putting trust in you. Isn’t it about time you responded to their needs, protected their data, and moved to use MQ’s end to end encryption with MQ Appliance and MQ Advanced? Start reviewing how to use it today. Your customers and your business are waiting.

Advertisements

Custom-build or container image? The choice is always yours with IBM MQ

May 10, 2019

silicon wafer

Once upon a time (as all good stories begin) I was doing my final year project for my Computer Science degree. The project was based on the custom chip design software and systems we had access to. During the previous summer I had interned at LSI Logic (at the time a large custom chip designer and fabricator) and had written some code for them to lay out a custom resistor on the chip.

Screenshot 2019-05-09 at 16.56.53

The goal I had been set was to lay out the resistor taking the smallest amount of silicon, within the parameters of the space on the chip with the resistive layer. After all, space on a chip was expensive, and it was critical to be able to do what was needed without taking up space that could be used for other tasks.

When discussing my final year project with my tutor, he suggested I redo that program for the chip design system at University, but also create a new program for a programmable logic array generator. For this, the goal would be for the user/customer to enter all the logic gate sequences they wanted, and the entire chip would be designed and laid out to meet the requirements.

This was a very different type of requirement. Lots of different individual components would be plugged together, but the outcome would be effectively an entire chip designed and ready for fabrication in seconds. Every component needed a separate design file, and they all needed to be created such that they would work together successfully and a new integrated design file would be built. Once the initial hard work of the component design was done, such that all the components would fit together, then it became easy, after a bit of coding, to build the output file based on the multiple required inputs. And entire custom chips would be ready to build in seconds.

Screenshot 2019-05-09 at 16.55.56

What’s the relevance of this ancient history? When reviewing discussions with customers regarding deploying in containers I was reminded of some of the design choices I made back in those days of project work. I have written previously here and here about containers. The programmable logic array generator is conceptually pretty similar to container deployment. The design generated will not be the most efficient, either in terms of layout or size. But it will be ready to go in seconds. And if you want to make changes, you do so and run it again and generate another design file, ready to go. Undoubtedly this is great, as long as you are happy to not go for maximum efficiency. And these days, when trying to minimize operational cost instead of minimizing hardware usage, or maximizing performance, then this is a good trade off.

The other part of my project – the resistor design and layout program gives the other aspect of the decisions being made today. It was built to be as efficient as possible. It would have been possible to have more standard forms of resistor, but given the constraints and business goals, this would have used more silicon. And there are still lots of systems, or parts of systems where performance, throughput and efficiency is worth the extra effort. And so not everything is best with a ‘one-size-fits-all’ approach. Sometimes you need to have just the right solution in place.

 

Looking around the connectivity segment, I see fewer and fewer solutions which give customers a choice. Everyone wants simplicity, but in order to build and deploy the right solution, you need more than just having a hammer and treating every problem as a nail.

Screenshot 2018-12-31 at 17.03.13

IBM MQ is offered in multiple forms – as base or Advanced software to be configured and managed by the customer, as container images (IBM Cloud Paks) for deployment in environments like IBM Cloud Private and Red Hat OpenShift, as a physical appliance, as a native z/OS offering, or as a public cloud hosted and managed solution. Even as a part of the IBM Cloud Integration Platform. The combination of these deployment options, as well as the proven technical advantages IBM MQ has over other messaging offerings is designed to provide customers with the best solution for all possible use cases.

 

With IBM MQ you get to have your cake, and eat it.

 

MQ25cupcakes

(Sadly I have misplaced my project write-up or I would have included the original design images from the PLA and resistor programs)

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

Is your business getting indigestion? IBM MQ can ease that pain by ingesting your file data into MQ including MQ on Cloud.

January 14, 2019

egg-eating-snake-856

Christmas and New Year is over for another year. At this time of year, it can be easy to eat and drink too much. Consuming too much can lead to indigestion and the results can be unpleasant.

 

But have you considered it might be similar when you move data through your enterprise? Data can be large. Data can be small. But once it exists, it has a purpose. And that means it has a use, and value. In that case it should delivered, in a timely way, with security and reliability, to where it can add value to the business.

 

However, moving the data can be a problem. Data can be moved by the application as it is created. And certainly, IBM MQ has a long history of being an ideal solution for this, as it is designed to connect applications, exchanging data reliably and asynchronously.

MQ messages have a maximum size of 100MB. Which is actually very large for individual application generated messages, especially if you are sending the data out as it is created, so while some use cases do use very large message sizes, mostly it is much smaller. And not only is MQ optimized for this traffic, enabling it to send millions, or even billions of messages per day through your network, your own infrastructure is likely built to meet this need.

 

But consider when data is created, or pulled in from elsewhere, and may be at rest in the filing system. It needs to move through the business to where it will add value. But this data in the filing system might be thousands, or millions of individual records, imported or built up over time. Trying to send gigabytes, or even terabytes of data in one lump is going to give your network the equivalent of indigestion. It’s going to be blocked up until it can pass through. Traditional file transfer approaches suffer from this issue.

 

Let’s think of how this might happen. You are a retailer. Some of your stores process their transactions as they happen, flying through the network as each one is small. Others instead batch them up and send them as a file. The file can be very large, and if coming from a remote location could take minutes or even hours to come through the network, because of the way that networks can slow down data transfer rates because of errors. This impacts the ability of the business to act on this data.

wmqfte_intro

 

An important feature of MQ Advanced (and MQ Appliance), and now MQ on Cloud is the ability to ‘ingest’ the data from files on the file system into MQ. This data is then moved as MQ messages through your network. As even the largest files are automatically broken into chunks suitable for sending as MQ messages, with all the reliability, security and assured delivery that MQ provides, your business gets the benefit of the data delivery, without suffering ill effects from the movement.

 

Moving all data, from applications and the file system, all through a single reliable high-performance pipe like IBM MQ gives your business the assurance that all data is handled with the right care and attention. And your business suffers no ill effects even when handling the biggest inputs. Allowing more of the data traffic to move rapidly and reliably through your network, without everything slowing down.

Your data is no longer getting stuck in a file, or in a remote system. It won’t even get lost moving between systems. It is moving freely between systems as it moves as MQ messages. No single message is too large for the network. And the business gets to benefit from your data now being handled and processed directly as MQ messages. It is no longer file data, so no longer stuck in the slow lane. Data ingestion is better than indigestion. Accelerate your data use by ingesting your file data with MQ on Cloud, MQ Advanced or MQ Appliance.

Don’t forget you can download and try all the features of MQ Advanced for free from this download page and you can also try MQ on Cloud in just a few clicks here.

screenshot 2019-01-14 at 18.44.43

Happy 25th birthday to IBM MQ. Something to rely on, yesterday, today, tomorrow.

December 31, 2018

 

MQ25cupcakes

December 31st, 1993. It seems like a very long time ago. It actually was a long time ago, but that was when IBM announced the availability of a brand-new software product: MQSeries.

If we think back to 1993, what else is memorable from that year?

Movies released in 1993 that are still memorable:

Schindler’s List

Jurassic Park (no comments about dinosaurs with reference to MQ thank you)

Groundhog Day

With maybe additional mentions to The Nightmare Before Christmas, Sleepless in Seattle, and The Fugitive.

Screenshot 2018-12-31 at 16.47.46

Some Albums from 1993:

Pablo Honey by Radiohead

Modern Life is Rubbish by Blur

Tuesday Night Music Club by Sheryl Crow

August and Everything After by Counting Crows

Screenshot 2018-12-31 at 16.54.13

Some Memorable Books from 1993:

Trainspotting

The Shipping News

Girl, Interrupted

Screenshot 2018-12-31 at 16.58.08

Memorable TV shows that started in 1993

The X-Files

Frasier

NYPD Blue

Screenshot 2018-12-31 at 16.51.10

Hopefully some of these will give you some memories from 1993. But they will likely also make you remember this was a long time ago. It seems like Trainspotting, Groundhog Day, The X-Files etc. have been with us forever.

These, and the others are cultural reference points that you simply rely on everyone having seen, read or at least understand the references. They are with us even to this day. And so is IBM MQ, although it is much more a cornerstone of our culture which most people have never heard of and have no idea that they use every day. And they certainly wouldn’t think they rely on a product from so long ago.

 

There are not many other software products that are still around from 1993, and still being used in the same way. One example (also developed in Hursley) is CICS which has been around for even longer. Another example would be Microsoft Windows. Certainly, there are sometimes press stories about a business still running an old release of Windows. And we experience the same with MQ. We have customers still running in production versions of MQ from 15 years ago or more. And this is because, on the whole, IBM MQ doesn’t go wrong. It does something simple, but very effectively. It is designed to never lose a message. Therefore, if you are building a system that needs to connect and exchange data between applications, and this data is important, then a good idea is to use IBM MQ to exchange the data, as then you shouldn’t need to worry about, and mitigate for any data loss.

Screenshot 2018-12-31 at 16.41.14

A 25-year life span is impressive for an enterprise software product. There are clearly very few of these. But given that most of the world’s leading businesses, the ones you likely use every day, have built their IT infrastructure to depend on IBM MQ, perhaps it is not surprising that it is still here. But, as the product manager (offering manager) for IBM MQ, this isn’t something we take for granted. We continue to focus on the needs of the customer. What can we do to make IBM MQ better today? And how can we make it better for tomorrow? Whether on mainframe, or mobile. As a physical appliance, a virtual machine, a container or a cloud hosted service, MQ is still doing what it is designed for, and moves trillions of messages every day, all important to someone.

Screenshot 2018-12-31 at 17.03.13

Being around for another 25 years is never certain. Only if we continue to be essential to our customers. Focusing on delivering data between applications, systems and services with reliability, security, scalability and robustness. Without being there for our customers we would not be here.

 

IBM MQ thanks all the customers and users for 25 years.

 

One of the long standing MQ supporters – Morag Hughson – has collected details from a number of MQ birthday celebrations over the years – you can read those here

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

All aboard the 9.1.x CD train. First stop is IBM MQ V9.1.1.

November 27, 2018

steam-train-north-shore-scenic-railroad-two-harbors-minnesota-17-9-00159

I am sure everyone knows the phrase about buses. If you miss one, don’t worry. There’ll be another one along in a minute. And while it could be said that applies to Continuous Delivery releases, I think it is more like getting on board a train. The destination is the next Long Term Support release, and you think you know what stops will be coming up. But maybe you don’t know exactly what you will find at each destination. You know there will be something new to discover at each stop. You could almost think of the train growing at each stop with the content of each new continuous delivery release, ready to be delivered finally to the Long Term Support destination.

 

Which brings us to the latest MQ CD release, MQ V9.1.1, announcing today, which is the first CD release in the 9.1.x set of releases. The experience we have of our 9.0.x CD releases is that we have seen a lot of interest from customers. Some have been able to move quickly to take up the CD stream into their environments and run them in production, at least for some of their queue managers. Others have been able to experiment with the new features in their test environments to see whether it is worth their while adopting the content early. And there seems to be a larger set of users who, while they haven’t been adopting the CD content into the production systems, the earlier availability and visibility of the new content has helped them move much more rapidly to adoption and use of the MQ V9.1 LTS release than we might have previously expected. I have personally talked with a lot of existing MQ customers who have either already started using MQ V9.1 LTS or are planning to move to use it very shortly.

Screenshot 2018-11-27 at 08.47.09

The MQ V9.1.1 release isn’t a destination in itself. It is the first part of our continuing journey. The MQ team works to accommodate a mix of strategic development priorities into releases to move the MQ offering forward, as well as other customer driven priorities, and reacting to and supporting other offerings and platforms as they change and adapt. Let’s find out how this mix has shaped the release. As well as suggesting you read the announcement content in the announcement letter, I will call out a few of the interesting new features.

 

One important new set of capabilities, driven by customer requests, is around the choice and negotiation of the use of TLS ciphers. Security of the MQ environment is hugely important in the current environment and is likely to remain a key area of focus. The importance of security and data protection is one reason customers are moving to MQ Advanced or MQ Appliance as a way to get the end to end encryption in MQ AMS. But this release focusing on enhancement to the security used in the TLS ciphers – used for encryption on the wire, not encryption at rest. As time passes, some ciphers become less secure and customers need to take prompt action in their environments to ensure the ciphers they use are updated to meet their own business requirements as well as the needs of the different systems.

In MQ v9.1.1 the choice of ciphers can be negotiated dynamically from a set or ‘whitelist’ available on each MQ channel. This reduces the potential for downtime and administrative overhead through faster movement to new ciphers when an old cipher is deprecated. Weaker ciphers can be removed from the list of allowable ciphers without needing to wait for a security fix update from IBM.

 

Another update driven by customer requests is the new support in MQ V9.1.1 for .NET Core for Windows. Customers who choose .NET as a framework for running applications on Windows environments have been looking to move to .NET Core. Following a number of requests, we have now added support for .NET Core for Windows environments to help support those customers.

 

As we have seen in the 9.0.x CD stream, one of the important set of capabilities that was added was the REST API for Admin for MQ. And at the end of that set of releases we started to look at adding REST API calls for the administration of MQ Managed File Transfer features, available with MQ Advanced and MQ Appliance. Many customers find it value to ingest and move data through MQ, even when the starting point or destination for this data is a file on the file system. To MQ, it is all just data moving in MQ messages. Therefore, from an administration point of view, it is important to offer similar features and controls for managing the movement of this data through MQ as is available for MQ exchanges of application data. In MQ V9.1.1 the MQ MFT feature gains REST API calls to list the resource monitors as an alternative to previous methods.

 

A further update is to provide support for pausing message delivery to Message Driven Beans running in WebSphere Liberty, in addition to the support previously made available for WebSphere Application Server.

 

The MQ V9.1.1 release offers a good foundation to start the journey through the various 9.1.x CD releases. There was a mix of updates driven by customer needs, wider platform and offering support as well as some functions to enhance longer term MQ strategic plans. We are now pulling out of this station and heading to the next one. Hitch up the V9.1.1 wagon to your V9.1 MQ train, hop on board and enjoy the ride.

glacier-express-furka-pass

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

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

July 19, 2018

Screen Shot 2018-07-19 at 15.24.18

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.

Screen Shot 2018-07-19 at 15.48.09

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?

Screen Shot 2018-07-19 at 15.48.23

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.

RDQM1

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.

everest-guide

 

Buried Treasure – embedding IBM MQ clients and MFT Agents into applications

June 13, 2017

treasure

I haven’t been doing this blog so long that I am going to repeat myself. Or at least not yet. But last year I did a blog on why you would use MQ – and that is broadly the topic of this entry as well but it comes from a specific use-case perspective. Plus – warning – it is longer than usual – sorry. Why do businesses, in their thousands, use IBM MQ – and its many different yet critical functions? Sadly, and I say this as the Offering/Product Manager for MQ, no one wakes up in the morning and decides they want to buy more IBM MQ – but they do so because of the benefit using MQ provides for the applications that run their business.

 

IBM MQ enables the exchange of data between applications, systems, services and files with reliability and security. It does this with scalability and simplicity. It has proved itself in doing this over the last 20+ years that much of the modern online business world takes IBM MQ, and its capabilities for granted.

 

The IT infrastructure is evolving rapidly – as it always is. As such there is both growth in new applications and existing applications are being updated and enhanced. Today’s applications typically have to be more resilient than ever, but also more portable – to be deployed pretty much anywhere. In most businesses applications will be extended out to business partners as the wider ecosystem is more tightly integrated than ever before.

 

These changes drive a greater need for seamless connectivity throughout the infrastructure and it makes it more important that all business data can be simply and quickly moved inside and outside the business. So how has IBM been working on IBM MQ to enable this? And will IBM MQ be able to help all customers – whether they are trying to connect and exchange data between applications, systems, services and files – not just the latest and greatest APIs?

 

IBM MQ allows for connectivity and exchange of data through MQ Clients and MQ MFT Agents and to make it easier for these to be used in many different use cases, IBM has been making changes to the packaging and licensing of these.

MFT Agents

One of the key changes was at the end of 2015, there was an update to the license documentation to allow for the redistribution of MQ Clients. IBM makes the MQ client libraries available for free download. These are then built into the MQ enabled applications to allow these applications to send and receive MQ messages. There is no cost for the MQ Clients – as they require a licensed MQ Queue Managers in order to function. However, until late 2015, the license prevent redistribution of these MQ Client files. This meant that if a business built the MQ Clients into an application, it wasn’t permitted to then distribute this application outside the business – i.e. it couldn’t share it with a business partner to allow that partner to work closely as an integrated partner. To allow this under the terms, the partner would need to either install the MQ Client library themselves or agree licensing terms to redistribute the MQ Client with IBM. This restriction was not helpful to these businesses or to the IBM MQ business and therefore it was changed to allow redistribution.

 

Now let’s look at a scenario – Company A uses MQ to exchange information throughout its business. It has suppliers (Company B and Company C) and it wants to streamline the manufacturing processes to enable them to get production statistics and thus help to plan for more efficient resupplies to their factories and warehouses. To do this it wants to provide them with a copy of their own in-house written application that uses MQ. Now that IBM allows for redistribution of the MQ Clients, Company A can simply provide their application to the partner companies to enable them to communicate seamlessly with no need to even be aware of the MQ Client embedded within the application. MQ messages can flow securely between the companies – and as only Company A has a MQ Queue Manager, they are the only ones licensed for MQ – and there is no additional MQ cost for this configuration. Note that companies exchanging MQ messages like this might want to make use of the MQ Internet Pass-thru feature to simplify passing messaging through their firewalls.

 

Now let’s imagine Company D. They are also part of the supply chain ecosystem for company A, and also many other businesses. But the stock control and distribution management systems are built mainly on files and file data. They keep these files updated with stock quantities and prices, but they find it simpler to keep using this method rather than online application updates and exchanges. They are used to sending these files to their customers using FTP but they always have a number of issues around FTP failures, reliability issues, and having to spend time diagnosing the problems inherent in these transfers.

 

Company A have a solution – the Managed File Transfer capability that is a part of IBM MQ Advanced. In place of regular FTP, the data inside the files can be sent as MQ messages from Company D to Company A, taking advantage of MQ’s reliability, security and management of data. And best of all Company D don’t need to change the way they handle data as they can still focus on keeping the file contents updated, but Company A can provide a program that can also embed the MQ MFT Agent which can run and extract the contents of the file and send it as MQ Messages to Company A. Just as with the MQ Client, the MQ MFT Agent is designed for easy embedding in an application, and benefits from also being redistributable under the license. The key difference is that MQ MFT Agents are free but only when they connect to MQ Queue Managers that benefit from the MQ Advanced license entitlement or are in the MQ Appliance. In providing this application making use of the MFT Agent to Company D, Company A is taking advantage of the recent change to make the Agent license redistributable, as well as the fact there is now no cost to embed MFT Agents and distribute them anywhere, as long as they connect to their MQ Advanced Queue Managers. Also, the packaging changed to ensure the MFT Agent was available as a standalone zip file for easier embedding.

 

As a business, your buried treasure may be hidden in your data. You owe it to yourself to ensure it is used as widely as possible and as timely as possible. But to do this you need buried treasure in your applications as well – and this time the buried treasure is the MQ Clients and MQ MFT Agents you can now embed in those applications. Hidden in your code, but providing value every day – maybe not buried treasure, but the goose that lays golden eggs?

Goose Golden Egg