Time to Think about using Cloud Pak for Integration V2020.2.1?

Just prior to big IBM conferences like IBM Think there are usually a number of new product announcements. These are scheduled to allow the conference attendees to get not just the great access to leadership keynotes, but the latest updates covering technical content that has only just been announced.

 

This is why, just a few weeks after the previous announcement of Cloud Pak for Integration 2020.1.1, IBM announced on April 28^th 2020, another new release Cloud Pak for Integration 2020.2.1. It is important to note this was only the announcement, and not the GA. If you read the announcement letter you will see that the GA date is June 26^th 2020. Normally we would look to announce closer to the availability date, but the timing for IBM Think 2020 led us to bring forward the announcement.

 

As you might know for this year, for obvious reasons, IBM Think is now a virtual only event, with far fewer sessions, which are mostly keynotes, and supplemented by online demos. But imagine the event had taken place with all the sessions, and you were in San Francisco at the Moscone Center, what would the Cloud Pak for Integration “What’s new” session covered?

 

Well the big news in this release is the move to support Operators. And if that’s the case, we had better explain what these are, and why they are important.

From reading previous blogs of mine, you might have seen I am a fan of analogies. Our lead architect for the Cloud Pak described Operators like this: Imagine you are hungry. You can assemble all the ingredients you want, prepare them by hand, and then cook everything. It’s a lot of work, and you might mess up. That’s like using Kubernetes and doing everything yourself. Another option might be ordering takeout food to be delivered. You decide what you want, and you request it, and it is delivered to you. That’s like using Kubernetes with Operators. You need to decide what you want, but then you get it, and it should be much less effort than doing everything yourself. Now, as a keen cook myself, I might always personally prefer to cook for myself, but I can certainly appreciate the benefits of the analogy, if we were to stretch it out to cover how much homecooking you would need to do to cater for an entire business…

Operators ease the operational complexity of running software in Kubernetes. This is critical because Kubernetes provides tremendous capabilities, but as this is new to many customers it can take time to harness the power. Operators work across multiple steps in the software lifecycle, through installation, operation and maintenance.

They provide ways to exploit the power that Kubernetes offers, such as repeatability of installation and upgrades of software offerings and helps to ensure that the software is deployed consistently. And once the Operator is defined, then Kubernetes is able to follow the Operator to deliver the outcome specified, again and again.

 

Many of the discussions about the benefits of container deployments might reference the goal for a Continuous Integration/Continuous Delivery (CI/CD) pipeline. Having operators in place to help can assist businesses in unlocking these benefits. Whereas Helm Charts were generally associated with focusing on ‘Day 1’ operations, Operators are more focused on ‘Day 2’ ongoing operations.

 

Cloud Pak for Integration makes use of the Red Hat Operator Lifecycle Manager to help users install, update and manage the lifecycle of all of their Operators as well as providing a consistent method for deployment. This should provide a much better experience in deploying only selected features and components of the Cloud Pak for Integration.

 

IBM will also be designing the Operators to fit our suggested best practices. In this way, businesses should be able to move forward much faster and more effectively as they begin to transform their infrastructure as part of their overall shift to digital transformation and becoming more cloud native.

 

As part of this release IBM Event Streams, which is part of the IBM Cloud Pak for Integration takes advantage of the open source Strimzi Operator that is published by the Cloud Native Computing Foundation.

 

What IBM is seeing in many customers exploring this shift to containers and Kubernetes style deployments is a desire to interact more engagingly with customers. This would be seen through an increase is responsiveness, and also being able to ensure that responses are based on customer and event specific data to allow for higher quality interactions. This would be the case not just for customers, but for internal users and partners across the business ecosystem.

I did an official IBM version of this blog on the IBM Communities site here.

Also you might want to read about the recent IBM MQ V9.1.5 announcement letter here, which includes the long awaited update to RDQM supporting HA and DR deployments.

Also there have been recent updates for IBM API Connect V10 and IBM DataPower V10, announced here.

Something to Think about as you read the announcement letter and sign up to listen to the keynotes at IBM Think 2020.

Stability in times of change – IBM Cloud Pak for Integration

There are times where it seems that all we experience is stormy weather. This might be in our lives, or in business, or even the world around us. And at times like these it is useful to have something to anchor onto. Something to depend upon.

Maybe your business is experiencing unprecedented change at the moment? Are you looking at hunkering down to keep going? Then you need something to depend on?

Or maybe you see the best strategy of trying to make new connections, and to leverage your business strengths by connecting to and working with other businesses to leverage their strengths too. In which case you certainly want to be sure to make use of something that will adapt to new circumstances but also will do the job you need it to do.

What you need is IBM Cloud Pak for Integration.

Cloud Pak for Integration is rapidly becoming the choice of many enterprises across the globe as the ideal way to combine seamless access to leading integration tools and middleware with an agile and modern approach to application connectivity, integration, deployment and maintenance.

Taking advantage of new ways to create, build and deploy applications and integrate them across the business, Cloud Pak for Integration offers a powerful, yet simple interface to provide access to a comprehensive and complete set of integration features and capabilities, easily configured and deployed through a single, tailored user interface.

IBM Cloud Pak for Integration is built to provide a modern container-based integration platform including IBM’s leading integration offerings and capabilities which can be used either as an integrated part of this container deployment environment or deployed standalone as they are today. This is supported through a flexible licensing approach. Existing integration clients can bring their current investments in IBM’s integration offerings into this licensing model, and all clients can buy new licensing entitlements offering complete flexibility, not just in how you choose to deploy integration features, but with the power to change these integration choices as frequently as you want.

The Cloud Pak for Integration includes these market-leading integration offerings:

IBM App Connect

IBM API Connect

IBM Aspera High Speed Transfer Server

IBM DataPower Gateway Virtual Edition

IBM Event Streams

IBM MQ

The Cloud Pak for Integration is further enhanced with additional features such as an Asset Repository and an Operations Dashboard.

The Cloud Pak for Integration is typically updated and enhanced every quarter and I am pleased to announce the latest release of IBM Cloud Pak for Integration. This release, IBM Cloud Pak for Integration 2020.1.1 became generally available on March 31^st 2020. In this latest update there are a number of key new features.

• The addition of App Connect Designer tooling. This tooling, now available for use as an on-premises tool (previously only available as a cloud-based service) enables customers to achieve faster time to market and improve their developer efficiency by creating APIs in minutes, without having to code.
• Support for Red Hat OpenShift Container Platform 4.3
• Improved integration between App Connect and the Cloud Pak for Integration Asset Repository. This will help to encourage reuse across the organization as developers can now share assets from App Connect across the wider Cloud Pak for Integration platform and access those assets directly within the user interface.

 

Clients acquiring Cloud Pak for Integration entitlements can buy licenses in a number of ways. The offering is sold by VPC, and is available as perpetual VPC entitlement, by monthly VPC or through a Committed Term License VPC agreement.

A version of this blog post is also available on the IBM Middleware Community site here

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.