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

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

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

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

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

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

 

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

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

 

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

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

 

Containers and modernization. Not a one-horse town for businesses using IBM MQ.

This blog was going to be on IBM Cloud Pak for Integration, following one I did last year. But I realized I needed to focus first more on modernization. This aligns with much of what I was going to talk about in my Cloud Pak blog, which I will revisit in another entry. For now, it is probably best to look at modernization specifically for MQ customers.

Modernization is not simply about moving to containers. A couple of years ago we would have had to caution that modernization wasn’t about moving to cloud. Stop jumping on the latest technology and seeing it as a solution to business problems. The solution to business problems is not simply changing our technology for today’s buzzword. That’s not to say containers can’t be part of a good solution, but simply touting containers as a solution rather than a technology that can be used when appropriate is not optimal.

Let’s review Messaging Modernization, and how it applies to MQ users today – of which there are many thousands. Some of these will have used it as a critical part of their infrastructure for more than 2 decades. It would be amazing if across all these infrastructures there weren’t improvements that could be made to these MQ deployments without throwing away the baby with the bath water.

Some of the issue is that even though customers might be using a recent release of MQ, they are still using MQ in exactly the same way that they were many years ago. It’s like moving from house to house over the years, starting small and nasty, and moving through nicer and nicer homes but still with the same furniture. You end up in a beautiful and spacious house, but still with the same tatty armchair, single bed, and peeling bookcase. Using MQ for many years without modernizing your deployment is similar to that scenario of moving from house to house but still using the same furniture and décor from the initial flat share.

 

MQ’s flexibility means it can be deployed in many ways. MQ has been deployed alongside each application instance, which is great for resilience and reliability but can lead to overhead both in costs, and in deployment times when scaling.

Another deployment approach is to have single MQ instances manage workload from multiple different applications. Then yet another style of deployment is having multiple instances of the same application using a single MQ instance. There are of course more combinations but those are certainly prevalent.

 

There is not necessarily anything wrong with those deployment styles, on whatever platform they are deployed on, but many customers don’t see them as being as responsive or as efficient as they would like for today’s infrastructure.

Modernization of MQ is likely to review the way in which you deploy MQ in support of the applications that use it. In many cases, recommended practice would be to define and deploy more, smaller instances of MQ with each instance or Queue Manager supporting an individual application instance. With virtualization and container technology, it is no longer the case that you can have a single instance of MQ on a server, but you can have multiple instances, each maybe only using fractions of a processor core. This provides decoupled deployment, but with the ability to scale on a more granular level, and to spread the workload both horizontally and vertically.

You can have a combination of this modern, agile deployment style. This can be coupled with greater insight into what is happening in the MQ system through streaming of system events and logs to a choice of external tools. Then modern REST API based tooling to control and manage the environment completely transforms MQ for today’s critical business problems.

 

Your business problems might seem to be different, but the challenge of moving data once and once only, with security and reliability remains a constant. There are some things you can rely on even when everything else is changing. IBM MQ remains the messaging solution you can rely on. Even when you have modernized your deployment. Both inside and outside containers.

Crossing the chasm. Creating new value with MQ Advanced accelerated with IBM Aspera

Imagine a stretch of river. The river here is wide, and deep. The water flows swiftly through the year. The farms either side of the river are owned by different farmers. On the left side of the river the fields are best at growing grains. On the right side of the river the land is more suited to raising animals like cattle and chickens. The farmer with the grain would love to sell their crop to the farmer on right with the animals. But the nearest bridge is many miles away, making it uneconomic to trade with each other. This is all about to change. A group of people visit. First on one side of the river and then the other. Later they return, with more people, and then equipment. Very soon a bridge has been built across the river. New possibilities are opened up for the first time. The farmers trade with each other, both becoming more successful. Local roads are built to get to the bridge. Settlements spring up. Communities grow up. Businesses thrive. People are happy. All sparked by the power of communication as demonstrated by the bridge making it faster and simpler to connect two places separated by distance.

We have seen this before throughout history. Roads and bridges. Railways. Telegraph and telephones. Now we will see if with business-critical enterprise messaging. With the latest V9.1.4 release of IBM MQ, we have now opened up the possibility of crossing the chasm of what was previously impossible thanks to the addition of the Aspera FASP streaming gateway.

 

Aspera is world-leading technology built on the FASP protocol to get past the problem of sending large amounts of data over networks that typically span long distances – much like a bridge spans a river or a chasm. It has seen huge adoption in some industries where they have seen insuperable problems in sending large files across networks. But in our global business environment, which is drowning in a sea of data, there are new possibilities and opportunities with the right vision for the future. In the same way that an architect and an engineer can look at a river and see the possibilities that a bridge at that point could bring, so an IT architect and a software engineer could imagine the possibilities of moving more of their data at speeds over long network distances.

 

Not every business has a 10GB video file to send daily over a network link that could be 100s or 1000s of miles long. But plenty of businesses send many millions, billions or even trillions of MQ messages per day. And while most of these messages might be within the same data center, there are certainly a growing number of messages that get sent beyond the data center. But why is this?

 

One reason might be these are messages to or from remote business locations. Maybe the main data center is in New York, but there are other business locations in London, Frankfurt, Zurich, Singapore and Sydney. Today there would be good reasons to have a limited flow of messages between these locations. Sure, you can send messages, but there is a delay, both down to physics, but also to the way that TCP/IP works over longer distances. This would put an impediment to any plan to move higher volumes of messages between these locations to be part of any meaningful timely business flow. But I want you to think back to our scene from the start. The river without the bridge, not achieving the growth possible from the opportunities.

Now let’s consider the possible use of the Aspera fasp.io gateway as a feature of MQ Advanced. MQ Messages sent between New York and Singapore that take advantage of the gateway, seamlessly called by MQ, will be delivered up to 4 times faster, offering new business opportunities and advantages. If you send 1 million messages per day between these locations, the new responsiveness will allow for measurable benefits as well as the option to increase the rate of messages between these locations.

 

Other use cases could be connecting the business to supply-chain partners, such as distributors or manufacturers. In the past, with slower message delivery rates, this might have forced the selection of different partners. Now either to help lower costs, or to expand for growth, network connectivity length shouldn’t be a factor in performance and throughput, widening the potential for business to expand and grow, and try new options in new locations.

 

Soon, with the combination of MQ Advanced and the Aspera fasp.io Gateway, the world will open up with communities and possibilities connected by the bridge of rapid, reliable and secure MQ messaging that can overcome the chasm of network delays.

With MQ Advanced or MQ Appliance entitlement providing the option to deploy the Aspera fasp.io Gateway at no additional cost, you can explore and build new business. What opportunities will be created when you take advantage of this new acceleration? How much will your business grow if you understand how you can now do things that were never possible before?

You can download MQ 9.1.4 today – bridge that gap today, and cross the chasm of lossy or high latency networks. Read more about what was new in MQ 9.1.4 in my previous blog entry. And to see what you can now achieve using this feature in 9.1.4 look at the performance report here.

Accelerating MQ with the release of IBM MQ V9.1.4

Sometimes change happens slowly, and gradually. We see this a lot with updates to IBM MQ over the last few years following the Continuous Delivery cycle. Innovations are rolled out, release by release. The product gains an enhancement and subsequent releases see cumulative improvements to that initial enhancement until, by the time all the enhancements get rolled up into a Long Term Support release, there is a rich set of capabilities that deliver more than the sum of the parts.

 

Enhancements don’t always happen that way. Sometimes they might be small, discrete and delivered in one go. And just occasionally, a significant enhancement comes along out of the blue, and provides potentially huge benefits in one release. In MQ V9.1.4, announcing today, customers with MQ Advanced or MQ Appliance entitlements get access to a breakthrough innovation: the Aspera FASP.io streaming gateway.

 

To explain what this is, and what it could do, it is helpful to understand Aspera technology which is outlined in my previous blog

The FASP.io streaming gateway is a new innovation using the FASP protocol. Deployed within the customer environment with a MQ Queue Manager (either with MQ Advanced entitlement or running on the MQ Appliance) configured to connect to it. Specified messages from MQ would flow from the Queue Manager to the gateway, which would then route them over FASP to another FASP.io streaming gateway which is similarly configured to another appropriately entitled Queue Manager, which would then receive the MQ message.

So why do all this? What would be the benefit? Let’s consider the situation of a business sending MQ messages between locations over hundreds or thousands of miles, such as between New York and Singapore. Individual MQ messages can be up to 100MBs in size. And if the data originated in a file, this could be a much larger total amount of data which is split into multiple MQ messages. Using regular MQ configurations the messages would flow over TCP/IP. Sending large amounts of data over long distances using TCP/IP can be much slower than the notional line speed would suggest if the line is lossy or experiences high latency.

 

In these situations, using the Aspera FASP protocol can provide a predictable and much faster way to transport that data. Therefore, for some use cases, sending MQ messages over FASP will see them delivered much more quickly than would have been the case, which could be an extremely valuable new enhancement if that time helps the business move and respond more quickly. We hope to publish some early performance data shortly that offers an understanding of the size of the acceleration that is possible. And this is available at no additional cost for customers with MQ Advanced or MQ Appliance.

 

Other than this new feature, what else is new in MQ V9.1.4?

 

The uniform cluster feature delivered initially in 9.1.2 and enhanced in 9.1.3 is further enhanced in MQ V9.1.4. We have added support for .Net and XMS .Net applications. We have also simplified the configuration of Queue Managers in the uniform cluster and speeded the time to rebalancing, as well as provided more information about the rebalancing that takes place. This is proving to be highly attractive to customers, especially as they modernize their messaging deployments with increased numbers of queue managers providing more scalability and flexibility, while being decoupled from the application instances.

 

Security remains a critical feature of IBM MQ and we have now added in support for TLS 1.3 for the first time. This is initially supported for C/C++ MQ client applications and will be further extended in the future. In the future we will be stopping support for SSL v3, and TLS 1.0. And for MQ on z/OS the pervasive encryption support added on the z14 hardware sees increased support for some MQ datasets. MQ on z/OS announcement letters are here and here.

 

Adding to the security aspect, many businesses send and receive MQ messages through their firewall. Due to MQ persisting data in storage, IBM doesn’t recommend deploying MQ Queue Managers in the DMZ, and instead has provided the MQ Internet PassThru (MQ IPT) to be deployed in the DMZ. This proxy has been available as a Supportpac from IBM, and although it was fully supported, this delivery outside MQ made it hard for some customers to deploy and use it. With MQ V9.1.4, MQ IPT is now a part of the MQ package and therefore should be more widely available for deployment. And for customers with MQ Advanced entitlement, we have added HSM support for MQ IPT to enable the digital security keys to make use of this enhanced security option.

The MQ Managed File Transfer feature of MQ Advanced also continues to be enhanced. The MFT Agent is now Highly Available, with another instance able to continue to transfer in the case of a failure. And also, the REST API support for MQ MFT is further extended with support for Create Monitor added.

 

Also, for MQ Advanced, the MQ Bridge to Blockchain adds support for Hyperledger Fabric for improved interaction support between MQ and the Blockchain

 

The last point I will mention is around Red Hat OpenShift. Following the acquisition of Red Hat by IBM, the MQ Advanced certified container now supports deployment directly on Red Hat OpenShift, without the need for IBM Cloud Private. The MQ Advanced certified container can either be deployed on its own in OpenShift or as a part of the IBM Cloud Pak for Integration.

I did a webinar to cover the new MQ V9.1.4 content – you can find the replay link here on the IBM Middleware Community

There is also our official blog update for this release.

As with every release, IBM MQ moves forward. Sometimes in small steps and sometimes it accelerates into the future, just like a MQ message sent using the FASP.io gateway. Forza! MQ.

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.