Posts Tagged ‘MQ Appliance’

Trying to contain your excitement – IBM MQ and Containers

November 30, 2018

Screenshot 2018-11-30 at 10.09.23

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

Screenshot 2018-11-30 at 10.07.52

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

Screenshot 2018-11-30 at 10.12.41

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

 

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

 

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

Screenshot 2018-11-30 at 10.13.38

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

 

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

 

Screen Shot 2018-07-27 at 15.30.23

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

Next steps might involve downloading container images here.

Or reading more about MQ and containers here

Advertisements

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

November 27, 2018

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

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

 

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

Screenshot 2018-11-27 at 08.47.09

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

 

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

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

 

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

 

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

 

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

 

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

glacier-express-furka-pass

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

October 5, 2018

oldmanyells

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

 

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

wile e coyote cliff

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

 

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

Screen Shot 2018-07-27 at 15.30.23

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

 

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

Screen Shot 2018-10-05 at 18.59.13

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

 

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

Millau2

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

July 19, 2018

Screen Shot 2018-07-19 at 15.24.18

How high is high? If you are considering climbing, then Everest is pretty high after all at 8848M above sea level. Although without the right equipment, team and preparation, trying to climb just 2M can be impossible. But ‘high’ is used in other contexts as well. Like when you are trying to keep a business running these days. If you are then it’s likely the high you may be thinking about is High Availability. Without the right approach, tools and infrastructure you may be trying to solve a problem that can seem to be the same scale as Everest.

Screen Shot 2018-07-19 at 15.48.09

With business becoming more global, and being more responsive to events, and with mobile or web traffic coming direct from partners, customers or suppliers, downtime has to be avoided. How do you keep your systems up, your applications running and your data available all the time? Even when, inevitably, there are failures?

Screen Shot 2018-07-19 at 15.48.23

IBM MQ is a critical part of your business connectivity. It provides a reliable, secure, scalable and robust middleware layer connecting applications, systems and services and exchanging data between them. Making use of IBM MQ ensures your applications can be simpler and more agile, yet more reliable, and also easier to shift between deployment environments. Your applications will rely on IBM MQ persisting their messages, ensuring that messages are never lost. How do you reap these rewards of simpler applications unless the MQ middleware is highly available to ensure the applications can keep running?

 

Having been around for 25 years, IBM MQ understands this need very well. As such it provides a variety of ways to configure and manage High Availability. And the most recent innovation, based on the High Availability approach used in the MQ Appliance is designed to not only offer extremely robust and effective high availability, but at the same time ensuring it is simple to set up and maintain, without additional external complexity: Replicated Data Queue Managers.

 

Many clients were facing the same set of problems: they didn’t like the costs and complexity of providing and maintaining network attached storage, which was a common way of providing high availability for MQ. The request was high availability that was more self-contained, without external dependencies. A way to deploy MQ in highly available configurations without the requirement for an environment that needs lots of setup, with highly skilled resources and additional costs.

RDQM1

With IBM MQ V9.1, our new Long-Term Support release, customers can now take advantage of Replicated Data Queue Managers, which offer a 3-node configuration, making use of replicated local storage, which make the MQ messages available on each of 3 MQ systems, instead of relying on a single copy of data on network storage.

 

Instead of requiring lots of setup, and ongoing extensive maintenance, MQ itself will do almost all the setup during the initial MQ install. Then, when you are creating a Queue Manager, you simply request it as a RDQM resource, and that’s pretty much all that’s needed. And it’s not just simple in the configuration of the Queue Managers. As it supports Floating IP, when one Queue Manager fails, and another instance automatically starts up on one of the other 2 nodes, the original Queue Manager IP address will move with it, meaning the applications are essentially unaware of the move, and the workload is uninterrupted as the messages and logs had been kept up to date synchronously on all 3 systems.

 

With an additional option allowing for manual startup in a replicated pair of systems by choosing either synchronous or asynchronous replication to provide Disaster Recovery configurations, this new approach to HA really goes a long way to make it much simpler to reach the highest peaks of high availability.

 

There are already a few places to look for more information on this exciting new development. There is a technical blog entry by John Colgrave, along with a GitHub community, and of course the Knowledge Center.

 

Suitable for customers on RedHat Linux on the x86 platform, you need MQ Advanced licensing on just one system node, and MQ Advanced High Availability Replica licensing on the other 2 nodes. Also, this can’t be used with container deployments – but virtual machine images or bare metal is fine. With RDQM now part of the Long-Term Support release of MQ V9.1, you can scale the highest peaks of availability. You are not starting at base camp. You are already close to the summit. Let’s get to the top.

everest-guide

 

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

June 13, 2017

treasure

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

 

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

 

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

 

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

 

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

MFT Agents

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

 

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

 

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

 

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

 

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

Goose Golden Egg

Building higher – IBM MQ V9.0.2

March 16, 2017

When a building is being constructed, it can be hard, from moment to moment to see progress. Yes – you see lots of activity. Lots of people are busy doing all sorts of important jobs, but it can be hard to see what they are all doing. You need to find a way to keep track of how they are doing. What progress are they making, and what milestones are they hitting.

building construction

In delivering updates to IBM MQ, now that we are on a ‘Continuous Delivery’ schedule, we set these milestones of deliveries around 3 times a year. We don’t plan to do IBM announcement letters with every update, but will do blogs here and elsewhere for some of the updates, with official announcements for others. For IBM MQ V9.0.1, there was an announcement letter, and I blogged about it here, but with IBM MQ V9.0.2 there are only blogs – both this one and our development blog from Ian Harwood you can find on developerWorks here. Also there is a YouTube video talking about the new update.

So, what has the development team has been working on in MQ V9.0.2? As with the 9.0.1 update there are several areas of enhancement and new function including:

  • Additional REST API coverage
  • Further updates to the MQ Console
  • Improvements in MQ MFT specifically in MFT Agent status reporting
  • Simplification in managed MQ logging on distributed platforms
  • MQ Appliance support for HA key renewal and 9.0.2 REST API verbs
  • Support for IBM Cloud Product Insights for registration and usage
  • Integration with Salesforce messaging events
  • Native Debian installer support for Ubuntu
  • Availability of MQ Advanced for Developers in the IBM Bluemix Container Service

 

Perhaps as with our description about building construction above, the delivery of any of these features might not be significant, although I think that the logging improvements will make a substantial difference to the many aspects of the use of MQ in the thousands of customers using it today.

 

What hopefully does become apparent is our ongoing support for the continuous delivery process. While some of these updates are brand new and have taken a lot of work, others are continuing to build on the work done in the MQ V9 and MQ V9.0.1 deliveries. These incremental deliveries of REST API support, and now the new Cloud Product Insight support will continue in future Continuous Delivery releases, making these features and the product more useful.

 

Let’s look at a handful of these new features starting with the logging support. Logging is very much the heart of IBM MQ and it is these recovery logs which allow MQ to recover from a failure, therefore providing the reliable and robust nature of IBM MQ. While circular logs are easier to manage, many customer use linear logs but these come with a lot of administrative overhead. The new feature allows for automatic management, recording and reuse of logs, lowering both the administrative overheads and improving the overall throughput in the system

 

IBM Cloud Product Insights is a new cloud hosted offering that many different IBM products will be able to work with. Additional features will be added to work with this over time, but initially there is support for registration and usage. You will be able to register your instances of IBM MQ and track them on the Product Insights dashboard. At this time you will be able to see what level of IBM MQ is install, where, and when it was last running. You will also see some usage information such as the number of persistent and non-persistent messages put, and the total size of data being moved through MQ. There is also a beta of log management, where MQ error logs will be shared with the Product Insights dashboard.

MQSalesforce

You may have seen the recent announcement of IBM and Salesforce working together more closely. We are very pleased that one of the ways this relationship is being demonstrated is through a bridge between Salesforce and MQ. When an event happens in Salesforce such as a change to data or a new application being run (Salesforce Platform Events or PushTopics), there is now the ability to trigger a MQ message to provide information about that event without the MQ application needing to be directly connected to Salesforce, simplifying your environment but making your systems more connected.

 

And finally, we now have a version of MQ Advanced for Developers available in the Bluemix Container Service. This means that the fastest way to create a development environment for IBM MQ might be with a couple of clicks to provision MQ Advanced for Developers. With pre-configured defaults to simplify administration, there has never been an easier way to get started with IBM MQ. What are you waiting for?

No waiting in these queues. IBM MQ V9 and the MQ Appliance M2001 delivers fast, reliable and secure message queuing

June 29, 2016

wile_e_coyote

Recent weeks have been pretty busy on this blog, reflecting just how busy the MQ development team has been in bringing out new and updated offerings in MQ V9 and the MQ Appliance M2001 here and here. And of course in our cloud messaging options.

As both of these have been fairly full of new content I thought I would do just a short update to focus on a couple of key benefits which are specifically measurable in these 2 refreshed offerings. After all, a lot of the new and improved features can sometimes be hard to quantify in terms of the benefits they provide, but in each offering this time there are some easy to define benefits.

As you may have seen in my most recent update, the MQ Appliance M2001 added large capacity SSD storage which enables much faster throughput for persistent messages. These are the messages that get written to storage to ensure they are still available in the case of failure before the message has been successfully deliver to all consumers. At high rates of message throughput, there can be a lot of contention for access to storage with traditional hard drives. With the new MQ Appliance M2001, this potential bottleneck has been removed. You can now read the latest MQ Appliance M2001 performance report here which shows that the performance in those scenarios which saw large volumes of persistent messages sees improvement of up to 3.5 times the previous message rate.

Clearly this represents a significant improvement and given that persistent messages are used in those business critical situations where IBM MQ delivers so much value, it is a hugely important benefit.

 

In MQ V9 there were a number of enhancements but the one I specifically want to call out is, as part of the MQ Advanced package, the enhancement to MQ Advanced Message Security (MQ AMS). The change here was to add a new mode of operation – Confidentiality. This new mode changed the way in which the encryption operations are performed on the message contents (MQ AMS offers policy based encrypted message contents which ensures data at rest is protected in case of a security breach). The goal of this change was to continue to offer a strong level of security for the message contents without too big of an impact on the performance and throughput from the effects of the encryption used.

Now instead of new asymmetric keys being generated for every exchange, the feature can be configured to allow for reusable symmetric keys to be used after the initial generation of an asymmetric key. This still provides a very high level of security, but depending on the reuse count before a new asymmetric key is generated, can drastically cut the performance overhead. The benefits can see more than an order of magnitude increase in throughput. You can see a quick snap shot of some of the early results in Jon Rumsey’s blog here – which includes a small table showing performance improvements exceeding 10x gains. With everyone concerned about security these days, the ability to better protect your information and customer data with little performance impact has to be a good thing.

 

So what are you waiting for? With secure, reliable enterprise messaging for on-premise deployments, cloud deployments or physical appliances, there is no waiting with IBM MQ V9 or IBM MQ Appliance M2001.

no-waiting

[An interesting history of Wile E. Coyote here]

Flash aaaahh – saviour of the universe: IBM MQ Appliance M2001

June 10, 2016

flash_gordon_facebook_cover_by_audrey41lorgeoux-d538dgo

Anyone who is a fan of cheesy sci-fi movies, or soundtracks by Queen will have the words “Flash, Flash I love you but we only have 14 hours to save the earth” running through their head, along with the line in the song that goes “Flash aaaaah, saviour of the universe”. And of course he did save the universe from Ming the Merciless.

But what if I told you Flash could also save your business? Not Flash Gordon of course, but flash storage, in the form of the SSDs that are now a part of the IBM MQ Appliance M2001 which is now generally available (June 10th 2016). We did cover this in an earlier blogpost, but I thought I would take advantage of our initial shipment date to cover just how critical the IBM MQ Appliance, backed by state of the art 3.2TB SSDs can be to your business.

MQ Appliance M2001

Each MQ Appliance M2001 model has 2 of the 3.2TB SSDs in a RAID 1 configuration. This means that every persistent message and all log data is written not just once to the SSD storage, but twice giving you complete redundancy of data. And a key part of the MQ Appliance functionality is the High Availability configuration – essentially nothing more than a simple menu option when creating a queue manager – allowing you to have the MQ queue manager on one MQ Appliance synchronously replicated to another MQ Appliance. This means that any message written to the SSDs on one MQ Appliance is not just copied to the second pair of SSDs but is written under the same unit of work that writes the messages on the first MQ Appliance. This therefore means you have 4 copies of the message stored for both reliability and availability.

Another part of the MQ Appliance update was the ability to do not just synchronous replication for High Availability but also asynchronous replication for Disaster Recovery to another MQ Appliance. Therefore you can point the MQ queue manager at another, typically off-site MQ Appliance and the same message will replicate there, ensuring there are another 2 copies of the message, and providing your business with a highly resilient messaging system designed to ensure optimum reliability and availability of messages.

After all, think about how important your messages are to your business. In effect, they are your business. Your messages are your business transactions, your new orders, your customer address details, your stock levels and distribution information. Lose your messages and you lose everything.

With the latest SSD technology inside the MQ Appliance you are calling on Flash to save your business – and with the MQ Appliance M2001, Flash saves the day again.

 

[Flash Gordon image title image above is from  http://orig07.deviantart.net/fc1d/f/2012/163/5/d/flash_gordon_facebook_cover_by_audrey41lorgeoux-d538dgo.jpg]

MQ in the Cloud – Your messaging ‘silver lining’

May 16, 2016

MQ clouds puttenham

As the senior product manager for a product like IBM MQ, I don’t just spend my day writing blogs – but frequently get questions from both colleagues and our many customers. And recently, one of the most common questions I get is whether MQ runs in the cloud.

The answer is “Yes” – that was easy wasn’t it.

However maybe there is some more information to share, to help describe the journey to cloud and to exploit the benefits provided by IBM MQ at every step, whether you are looking for enterprise grade business critical messaging in your private cloud infrastructure, in a public cloud (hosted or not) or a hybrid cloud spanning the combination of these.

 

Mostly the cloud environment that IBM customers I have been talking to are thinking about is best described as “Hybrid”. Almost all of our customers are starting to explore some aspects of the benefits of cloud – and what it means to them. But deployment, especially of business critical applications, is likely to happen in stages. Today many customers run virtually all application workload on-premise, but typically this will be in virtual machine environments. There is a shift to deploy selected workload in the cloud. Perhaps this might start with engagement or marketing applications, but these applications and the associated workload doesn’t run in isolation on the cloud but in conjunction with the rest of the enterprise running on-premise, or connecting to partners in the wider business ecosystem. Then as businesses shift some of their critical back office applications to cloud deployment options, the hybrid nature of infrastructure will increase.

Fundamental to the success of this change is the availability of reliable and secure connectivity to allow the safe and scalable exchange of information between applications independent of whether they are running together in the cloud, on-premise or any other combination.

How does IBM MQ work in this type of deployment? Well, as has been proven for more than 20 years, IBM MQ provides a way to exchange data in the form of messages between applications, systems and services and to do so reliably, securely, rapidly and simply. Messages are moved through MQ Queue Managers that can be deployed locally to the application – wherever that application may be, or remote from the application but accessed by MQ Clients bound to the application.

In pretty much any type of hybrid environment, MQ continues to be a critically useful middleware tool. Either the application running in the cloud environment can make use of the MQ Client to connect to a MQ Queue Manager running elsewhere (such as on-premise) or the MQ Queue Manager can itself be deployed in the cloud environment along with the application. And you might use your own tools to deploy MQ, or you could use tools such as Chef to deploy MQ. Other options for deployment include a MQ plug-in for IBM UrbanCode Deploy.

MQ offers support for running on IBM SoftLayer, Microsoft Azure, Amazon Web Services, and OpenStack cloud. It leverages a Bring Your Own Software License to make it simple for customers to choose where to deploy the IBM MQ license entitlements they may already have. For deployments of IBM MQ on SoftLayer you might choose to use the MQ Advanced pattern designed for IBM PureSystems which can run on the SoftLayer environment.

In addition to this deployment style, IBM recently confirmed MQ is supported to run in Docker environments which further extends where MQ might be deployed to meet customer needs, such as hosted PaaS environments like IBM Bluemix.

Docker_(container_engine)_logo

So basically for every cloud environment, or virtualised environment, or container, your business can continue to take advantage of the benefits of IBM MQ – whether by running MQ Queue Managers in the cloud environment, or continuing to run them on-premise (perhaps as the physical MQ Appliance), or in any hybrid combination.

So what are you waiting for? For MQ on cloud – the answer is yes.

*UPDATED to add link to the AWS example – see above*

Going faster by not moving – IBM Appliance M2001

April 19, 2016

totoise-rocket-patch

Go faster. Faster. Move it! Or actually don’t move it. There are times when to go faster you need to stop moving. We are all familiar with the parable of the tortoise and the hare – where slow and steady wins the race. But what about not moving at all? Sometimes that makes you go much faster. And in the case of the latest update to the IBM MQ Appliance that is exactly what we are doing. Hopefully you already know about the MQ Appliance, which IBM releases early in 2015, and have continued to enhance since its release. You can read my original entry here, and the update at the end of last year here.

 

But today, April 19th, IBM is announcing another update to the MQ Appliance which not only provides additional functional enhancement, by allowing queue managers to both synchronously replicate for HA and also asynchronously replicate for DR, and adds support for the AMQP based MQ Light API, but also sees a small but important hardware update, making this a slightly refreshed model – the MQ Appliance M2001.

HA+DR

There are 2 key hardware changes in this model update. To help support the simultaneous HA and DR function, which would use both existing 10Gb network cards, the existing 2 port connection is being replaced with a 4 port connection, providing 4 of these 10GB network ports, enabling 2 to be used for HA and DR and ensuring 2 can be used by applications connecting to the appliance, as well as the existing 1Gb ports.

M2001

The second hardware change is the replacement of the existing pair of 1.2TB hard disk drives (HDD) with a pair of 3.2TB solid state drives (SSD). As well as the benefit of the greatly increased storage capacity, the major benefit of using SSDs is the increase in performance for persistent message throughput. The MQ Appliance is a highly capable system which can process a lot of MQ messages. However, when using persistent messaging, which needs to be written to disk, it is critical that the storage can keep pace with the high rate of workload being handled by the system and at times with heavy workloads the spinning disk simply couldn’t move fast enough. IBM has selected the latest generation of SSDs to provide large capacity, high performance for both reading and writing data at high rates, and also this latest generation of SSDs, even if the MQ Appliance is used heavily all day, every day, should last for the 5 year supported lifespan of the MQ Appliance. Therefore, this provides the payoff from our ‘tortoise and hare’ parable – with no moving parts in the SSDs, they can be a lot faster than spinning disks. Expect to see updated performance figures for the new MQ Appliance M2001 around the time of its availability (June 10th 2016), but early figures suggest for some workloads performance improvements of up to 3 times have been seen.

 

There continue to be 2 editions of the MQ Appliance – the M2001A, providing full access to all the processor cores, and the M2001B, which provides access only to a subset of the cores – with an upgrade available from the B to the A system if needed. For customers who may have already purchased the MQ Appliance M2000, please talk to your IBM sales rep to see whether your appliance can take advantage of an upgrade of the HDDs and network card if available.

 

With the improved HA and DR functions, the increased storage capacity and the greatly increased performance, IBM believes this enhanced MQ Appliance makes even more sense to be used as the heart of your IBM MQ deployment, or as a highly available pair of appliances that can be deployed anywhere you need MQ capability. And for customers who may be running older versions of MQ which were recently subject to an announcement of End of Support – as can be seen here – then the latest version of the IBM MQ Appliance can represent a very good deployment option which is then far simpler to deploy as well as to maintain.

 

By moving from spinning disks, to SSDs with no moving parts, you really can go faster by standing still.