Occam’s razor, or Keep It Simple Stupid?The IBM MQ Appliance is the right choice.

Diagnosing technology problems can be hard. I have an old car I drive in the summer and to get music, I plug my mobile phone into a cassette adapter to play music through the car stereo.  I had problems with it a year ago and replaced the cassette adapter and everything worked again, but a few weeks ago I had problems again. The music started playing fine, but then it would start to have problems. It would stutter, and the sound would break up making it pointless to try to listen to it.

 

How should I go about trying to fix it as there are so many variables? Buy another cassette adaptor? Or was it the old radio cassette player in the car? Or maybe it was the connection between the radio and the speakers? Or maybe there was a problem with the phone connection? Or the phone itself? Or the app on the phone I was using? This was not a problem I wanted to spend a lot of time on, but equally I didn’t want to just throw money at the problem to try to fix it if replacing parts wouldn’t fix the problem.

William of Occam told us when reviewing a hypothesis, to select the one with the fewest assumptions, so what I needed to do was to reduce the variables to try and narrow down the cause of the problem. This thought of ‘reducing variability’ is one of the reasons for choosing the IBM MQ Appliance and you might want to consider this alongside the other benefits it can bring to your business.

Consider the deployment environment where you may install, configure and manage MQ on servers today. Many of our customers have MQ deployed on multiple machines, and although there is a move towards VMs and containers, there is a lot of variability in the servers themselves, the OS levels, the MQ install and configuration, and even VMs and containers can suffer from these problems. While not necessarily done as a conscious choice, the outcome is a lot of potential for complexity and confusion. This variability can become a serious issue when problems arise, and the issues multiply further once you scale up your deployment. MQ deployments tend not to condense down to just a single Queue Manager for many reasons and this means that Queue Managers proliferate. In the move to containers this ‘doubles-down’ with each Queue Managers typically in its own container.

 

The MQ Appliance can be seen as another form of container, but for the MQ administrator, it might be much simpler than multiple Docker containers, especially if you haven’t managed to consolidate to a single container image, repeated in every deployment, as the MQ Appliance is a dedicated environment optimized for running MQ Advanced. And a single appliance (or a pair of appliances for HA) can run multiple MQ Queue Managers, with the resources defined and protected from each other.

 

Going back to the point of reducing complexity and variability, the MQ Appliances are built to be physically identical, with no additional code installable on them, and the MQ as well as the operating system is held in firmware, updated as a complete ‘flash’ in a single operation. This can be done in confidence as the MQ Appliances we build and test the updates on will be identical to the MQ Appliances in the customer data centers, making it typically much easier to reproduce problems and fix them, as long as they are within the MQ Appliance itself. This of course can help to identify that problems are outside the Appliance – such as with the networking, or even the cables.

You run MQ where it is most important to your business. It handles your most critical data. You expect it to run all day and every day, without interruption. It exchanges millions or billions of messages and it doesn’t compromise as it is designed to never lose a single message. When you hit problems, you want them to be as easy to diagnose as possible. You don’t want to have your deployment choices causing confusion, whether that is the weird mix of servers, or the range of operating systems you are running. And you don’t want your devops team blasting away and renewing your MQ container to ‘tidy up’ because the container had been running without stopping for 3 months.

 

IBM MQ is the most resilient, robust and secure enterprise messaging platform available. It is relied on by virtually every bank, every credit card company, insurance businesses, retailers, manufacturers, health care providers and the travel and transportation industry. The MQ Appliance is the deployment option that has been built specifically for it, and MQ has been optimized to run there. Once you have a High Availability pair of MQ Appliances up and running, handling maybe 200000 persistent messages per second, you know it will be easy to reproduce that environment exactly by buying and deploying more exactly like them.

 

The problem I described at the start with the music in my car was caused by the phone. The app settings were set to optimize battery life, so it would start playing, and then the screen would switch off and it would try to use less battery which would mean it would stop and start the music. It took time to identify the problem, but at least I didn’t have end users or my CEO asking me what the problem was within seconds of it occurring. Maybe your business needs a reliable, repeatable high-performance messaging solution like the IBM MQ Appliance?

The best things in life are ‘3’. Now announcing IBM MQ V9.1.3

There are many time in old Monty Python sketches where the number 3 seems to come up. There is a 3 headed giant in Monty Python and the Holy Grail. There is also a problem where King Arthur is trying to count to 3 to throw the ‘Holy Hand Grenade of Antioch’ but goes “1, 2, 5”.

 

As we move through the 2^nd set of Continuous Delivery releases we are expecting to follow the same pattern for the 9.1.x releases as we did for the 9.0.x releases then we would anticipate that the final release will be 9.1.5, but we aren’t there yet. We have just announced MQ V9.1.3 on all platforms including the MQ Appliance. You can read the announcement letter for the distributed and Appliance offerings here. And you can read the letters for MQ z/OS here, and MQ z/OS VUE here. An important additional announcement to be aware of is that IBM is announcing withdrawal the separate MQ Advanced Message Security and MQ Managed File Transfer offerings on z/OS, with MQ Advanced for z/OS VUE being the recommended way to get these extended capabilities going forward.

For this blog I will call out a number of the key new features in MQ V9.1.3, and why I think they are important.

Let’s start with a feature that was first delivered in MQ V9.1.2, is of strategic importance and has been extended in MQ 9.1.3. This is a feature called Uniform Clusters and it allows MQ itself to balance application connections across multiple different queue managers. The initial release only supported this balancing for C applications and in this release the capability is extended to JMS applications. Why is this a useful feature? If you have multiple application connections to a set of queue managers, there is no easy way to ensure a fair distribution of workload across the queue managers. And then imagine what might happen if you remove or add queue managers for maintenance or to adjust available capacity. How can you rebalance workload, especially when new queue managers are being added? This feature allows MQ itself to be aware of the group of queue managers to spread the work across, and will take care of the balancing and rebalancing needed. As workload and queue managers become more dynamic with hybrid cloud deployments and containers, then this will become increasingly essential.

Recent releases over the last year or so have seen new feature enabling use of a REST API for admin, as well as also using REST for messaging. MQ V9.1.3 sees enhancements in both of these areas. The REST API for admin now allows calls to ‘runmqsc’ to use JSON inputs through the REST interface to return JSON output. The JSON input and output means that it will be much easier to send commands and to understand and take actions based on the output of the commands. This will help more customers and vendors build new tooling, or to update their existing tooling to be more powerful and dynamic and to use modern tooling frameworks.

REST Messaging offers the ability to send and receive MQ data without using MQ clients. Previously there was only the ability to use PUT and GET commands, but MQ V9.1.3 adds support to Browse messages.

 

New enhancements in MQ Advanced include a number of updates for the MQ MFT feature. One of these enhancements extends the FTP protocol bridge to now support FTP servers that run on the IBM i platform. With MQ Advanced V9.1.3, customers who use FTP to move files into and out of the IBM i platform can have them intercepted by the FTP Protocol Bridge and moved into the MQ network.

And for those increasing numbers of customers using MQ Advanced container images, in Kubernetes environments there is now the option to configure multi-instance queue managers with active and standby pods, or to use a single resilient queue manager with Kubernetes and system monitoring for high availability.

 

For the MQ Appliance there is a useful enhancement to the HA and DR functions that builds on the capabilities and enhancements previously available. Our MQ Appliance customers really appreciate the High Availability and Disaster Recovery configurations for the appliances. Now with MQ V9.1.3 notifications about HA and DR status, or changes in status are written to the MQ Appliance system log. In MQ V9.1.2, the MQ Appliance system log could be configured to stream off the appliance as with other MQ log targets. This combination of features would allow 3^rd party monitoring tools to detect HA and DR status changes and rapidly alert MQ Appliance customers of failover activity. An additional feature of the latest MQ Appliance update is also to report on the data and time when data synchronization was stopped or lost between Appliances in a HA pair, or in a DR configuration. This will be useful for both offline analysis and for DR restart consistency.

Read the official IBM blog by Ian Harwood about the new release here.

 

This latest MQ V9.1.3 will be available to download on July 11^th 2019. Are you ready for ‘3-dom’?

Packed and ready to go. IBM Cloud Pak for Integration includes IBM MQ Advanced.

With holiday season coming up one of the challenges is always what to pack for your holiday. Are you sure you are bringing the right clothes? What if you go out for a nice meal and you haven’t brought the right outfit? You want to pack the right selection of clothes that you can mix and match to use in different combinations to meet any need. You wouldn’t sit on a beach in a business suit or wear your swimsuit to a fancy restaurant. But equally you don’t want a single item to wear that claims to be appropriate for everywhere, but actually is not a good choice for anywhere.

It is the same with many things. It’s said if all you have is a hammer then every problem looks like a nail. But also, you don’t necessarily want to bring you entire toolbox when all you need is a screwdriver.

 

In the same vein, when I am talking with customers, I will often say that nobody uses IBM MQ on its own. After all the applications send the messages and MQ is simply providing them with a service. But it is an essential service as IBM MQ provides reliability, security, high-availability and more, and not simply the movement of messages. MQ is just one part of the set of tools needed to build and maintain a connected and integrated business, especially at such a rapidly changing and demanding time. You need the right set of tools for the job. Not too big a set, not too small. And tools that work together. That’s why IBM has been spending time and effort to pull together a number of related products into platforms that are designed to be more than the sum of their parts. These platforms are now called IBM Cloud Paks and you will find IBM MQ Advanced as a part of the IBM Cloud Pak for Integration.

What else is part of the Cloud Pak for Integration, as well as MQ Advanced?

• API Connect
• App Connect Enterprise
• Aspera High-Speed Transfer Server
• DataPower Virtual Edition
• Event Streams

 

It’s also important to understand that to bring these capabilities together within an integrated framework, additional work has been done to provide a single sign-on feature between the different offerings, as well as shared monitoring and logging.

 

Just as you don’t wear every item of clothing together, and you don’t need to use every tool in the toolbox for every job, you might find that you keep using the individual products in the same way as you did before. If you want to securely and reliably move transactions between applications as part of payments solution, then you are likely to use MQ Advanced, rather than Aspera. But equally if you want to stream video files between London and Singapore, then you would choose Aspera.

But if you want to build a solution that reliably pulls together multiple pieces of data from different backend systems and presents them as a single integrated result to a user based on an API driven query, then you might use nearly every component to build the right solution with the right tools.

 

As well as the different capabilities and the integration between them already mentioned, there is also licensing flexibility. The offering itself is container-based, to allow for the rapid and repeatable devops style of deployment that many businesses are moving towards, and therefore the licensing provides you the flexibility to use different components and deploy them in containers at different times, swapping out as you replace one component for another.

But if you aren’t quite there yet with your container deployment strategy, you can still buy IBM Cloud Pak for Integration entitlement and choose to convert the entitlements to standalone deployments of the same core capabilities but deployed outside the container-based deployment environment. So if you are happy to deploy API Connect and DataPower Virtual Edition as container images, but don’t currently plan to deploy MQ Advanced in a container environment, then under IBM Cloud Pak for Integration entitlement you can deploy MQ Advanced on bare-metal, or in a VM outside of the container environment, but as part of the overall entitlement. Both comprehensive, and flexible. Just what you need in this fast-changing world.

 

With IBM Cloud Pak for Integration, including MQ Advanced, you are now ready for the days ahead. Secure, agile, reliable, robust, and highly available. It’s just up to you to know what you want to do.

 

Queuing around the Block – How IBM MQ connectivity helps make Blockchain real for business

The IT market moves in cycles. It reinvents or rediscovers technology on a regular basis. It might apply old technology to new problems or apply new technology to old problems. This can lead to looking at new or updated solutions and thinking that it must replace an existing technology. We find this happens a lot where people assume a new solution is a replacement or an alternative to IBM MQ which is widely used in many different use cases and has been around for years even though there is no real overlap or similarity. There is always someone new who wants a shot at the title…

Blockchain is currently exploring the different opportunities that exist for it today in the marketplace. We have probably moved on from where we were a few years ago when it was being touted as the solution to everything, to where we are now where it is being used in a number of different real customer use cases and we are seeing where it fits and adds value. These examples tend to vary according to the industry where it is being deployed, and also it depends on which Blockchain technology is being used with solutions based on Hyperledger Fabric (IBM), Ethereum (ConsenSys), and Corda (R3) all seemingly getting traction in different areas at this early stage in the market.

Now might be a good time to talk about both IBM’s Hyperledger Fabric based Blockchain and a messaging product like IBM MQ, contrasting them and showing how and why they should work together. MQ is designed to do just one thing – to move data in the form of messages between applications, systems and services, and to do so reliably and securely. The use case for this is to enable applications to exchange data that normally then triggers some action or activity. This might happen infrequently but typically in many customer environments there are millions or billions of these messages every day. These messages aren’t just representing the data flowing around the business and between the applications, they actually are the data flowing between these MQ enabled applications. Anything that actually happens in the business as a result of the data in these messages will take place due to the actions of these applications in the processing of this data, or in applications that are triggered into action on the basis of these messages being sent or received. If money is being transferred between accounts, then the applications are making the debit or credit, but on the basis of the information passed in the message. And a response might be generated to confirm the action back to the originator, but these actions are all discrete.

How is this similar or different to blockchain? First while blockchain might mean different things to different people, it is primarily seen as a type of distributed ledger where multiple parties are agreeing on a set of actions that might relate to the exchange of physical or digital assets but could also cover many other different exchanges. To enable these exchanges there might be actions required in the physical world, but there will certainly be a need to have corresponding digital exchanges of information to allow the internal systems of each participant to be updated to reflect the current or changing state of the items on the blockchain. These additional digital updates would most likely involve the exchange of multiple MQ messages between application to ensure the reliable update of systems based on the change of information.  Each individual update on the blockchain would likely trigger thousands of related MQ messages as the back end systems are updated in sync with the blockchain, or the blockchain gets updated as a result of these MQ triggered updates.

It is because of this dependent relationship between MQ and Blockchain implementations that IBM has included a Bridge to Blockchain as a part of the MQ Advanced entitlement. As businesses start to explore how to leverage Blockchains like IBM’s Hyperledger, either as a global payments solution, or a food trust solution or anything else, knowing it will be simple to ensure that MQ enabled applications can be connected to the blockchain and to ensure that any updates on either side are accurately reflected will help to accelerate solutions, either as a proof point, or in production.

In this instance, although there is queueing, it is message queueing so there is no need to stand in line and wait before starting your blockchain journey. Move up to MQ Advanced and get on with making Blockchain real.

 

From the mainframe to the mobile or to infinity and beyond. IBM MQ is everywhere!

Probably more than a decade ago, when I had a role in IBM marketing I was looking for a phrase to describe the way in which IBM MQ, and more widely the whole span of IBM integration solutions could be used across the business infrastructure, and I came up with the phrase “from the mainframe to the mobile”. IBM MQ has been at the heart of the enterprise, running on mainframes right from the early days. And MQTT support has been around for many years as well, placing MQ endpoints in sensors and mobile phones providing a great breadth of coverage for businesses wanting to ensure they can reliably and securely exchange data across both servers and physical devices.

But recently as part of a refreshed move to listen to and work with developers, the IBM MQ team in Hursley have gone a step further. With the examples above, we would typically expect the MQ Queue Managers to be running on the mainframe, or on physical appliances, or maybe on Linux servers in a datacenter or in the cloud. And the applications would be running on their own servers with MQ Clients or MQTT clients at the endpoints connecting to the MQ Queue Managers over the network. But as part of this new initiative, we are demonstrating MQ Queue Managers running on the smallest servers yet – Raspberry Pi Zeros.

Our developer initiative is showing that MQ can be simple to develop for, and simple to deploy, and we can use both of these aspects to demonstrate the value of IBM MQ to anyone who might not be familiar with messaging as a programming technique. One example is programming MQ using Scratch. Also being able to show MQ running in a portable non-threatening environment is a great way to demonstrate the usefulness, especially if all the same MQ capabilities are in action. Our demonstration includes installing separate MQ Queue Managers on 2 separate Raspberry Pi Zero boards. And not just running, but running as a High Availability configuration, so that messages were preserved and the 2nd Queue Manager would take over when the 1st one fails.

The demonstration may be simple, but it is very effective, but what I find most compelling is the example of the MQ Queue Managers running on such a small piece of kit. IBM MQ is one of the most important software offerings in the world. Most of the world’s infrastructure depends on it. Banking, insurance, travel and transportation, retail. You name it, most of the leading businesses in the world rely on MQ running and processing trillions of messages per day. But the perception would be that MQ runs in the datacenter, or maybe these days in both the datacenter and the cloud.

What I would like us to think about is the idea of MQ running embedded in such small devices like the Pi Zero. If you can run a fully featured MQ Queue Manager there, then where else could you run it. What difference might it make in today’s infrastructure or tomorrow’s infrastructure if IBM MQ was running in the smallest computing devices? Are there any use cases?

It’s important to point out that MQ running on the Pi Zero is not an officially supported implementation, and IBM has no plans to support it in the future. But sometimes it is great for us to think outside the box. So let’s have your ideas as to whether MQ would benefit from running in these smaller configurations. Either share here or reach out to me directly and I will try to comment with another blog entry later.

As well as the demonstrations mentioned above, IBM has been working a lot on improving IBM for developers. There was a recent release of the MQ Client for Mac OS. We added REST Messaging as an option for MQ. There is a tutorial called Learn MQ, and a badge for MQ developer essentials. And we have had MQ Advanced for Developers available for free download since 2013.

In Toy Story Buzz Lightyear could fall with style but set his sights on the stars. Let’s move from the “mainframe to the mobile” to “infinity and beyond” with IBM MQ.

(Buzz Lightyear is obviously Disney IP – image just used here for effect, and does not signify any ownership or endorsement.)

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

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). You can read a detailed description of MQ AMS here.

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.

 

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.

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.

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

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.

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.

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.

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.

 

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

Not just the great State of Texas but the Integrate State of Texas. Learn more about IBM Cloud Integration Platform and IBM MQ at the 2019 Integration TechCon

I have written about MQ and containers before here and here and let’s face it, I will be writing about them again in the future. Just about every customer is trying to build a modernization strategy which today means a container strategy.

Containers are a great fit for stateless objects. Things like micro-services, but also other applications. And as well as those objects, the other integration capabilities like API Connect are stateless, and thus easily get provisioned and cleaned up through a container/dev-ops approach. And Kubernetes is widely used as a deployment and orchestration environment for containers. However you might have questions about how a stateful product like IBM MQ, which holds critical persistent data fits in a container deployment strategy.

To help with this, IBM is investing to provide modern container-based offerings, such as IBM Cloud Integration Platform, which like a number of our other offerings and platforms are based on IBM Cloud Private.

Offerings like the Cloud Integration platform are designed to not just offer containerized versions of the individual products but provide additional integrated services which enable common shared single sign-on, logging and monitoring for the integration capabilities, with more to come.

One of the capabilities within the Cloud Integration Platform is MQ Advanced. This is delivered as an IBM Cloud Pak, providing the production ready containerized image, along with a Helm chart and full IBM support for the product and the environment.

However, let’s review why you might be moving to container deployments of various offerings, as it could be for many reasons:

• Faster deployment
• Simpler provisioning
• Faster, easier maintenance
• Deployment in any environment
• Lightweight images
• Rapid version migration
• Reduced operational costs
• etc. etc.

 

Layered above these reasons will be some of the benefits provided by the individual integration offerings that might be deployed in containers. And then there are the further benefits that could be available if taking advantage of integrated offerings.

 

That sounds like a lot of consider. Wouldn’t it be great if there was some easy way to get insights not just into the individual products but the IBM Cloud Integration Platform? And it would be best if there was lots of technical information and not just high level content. So welcome to the 2019 IBM Integration TechCon, held in Grapevine Texas April 30^th to May 2^nd this year. Hear from technical experts in all the IBM integration products including multiple deep topics on MQ, MQ Appliance, MQ on Cloud and MQ Advanced, and also sessions on IBM Cloud Integration Platform.

Register today

Banish those winter blues with IBM MQ V9.1.2

In the depths of winter in the UK we are told that Monday 21^st 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 2^nd Continuous Delivery release of MQ V9.1, this builds on the previous release with a number of enhancements and new capabilities.

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!

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

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.

 

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.