License to Thrill – bring your MQ license to the cloud – with MQ V9.1, not 007

Your typical IT infrastructure these days has more clouds than a sunny day in England. We easily go from no clouds, to dozens of clouds in an instant. And unless you are prepared and can adjust for this situation, you can quickly start having a bad day.

Let’s think of a common scenario. One which I get asked at least once a week. You are a business, and you are starting to explore the opportunities for running on public cloud. You aren’t likely to go ‘all in’ on day one, but you have 1 or 2 projects that will be a great fit, or so you hope.

But how do you get started? You probably have a cloud in mind. Maybe AWS. Maybe Azure. Maybe even both. Your developers are keen to get started. But you remind them, in order for the applications to work with your wider environment, you will want them to exchange data with many of your other applications using IBM MQ.

This has a number of benefits. Not only are you ensuring you are reliably and securely exchanging the data between applications. But as the different applications connect using IBM MQ, they can remain mostly unaware of where they are running and where the applications they are connecting to are running. As application deployment updates happen, IBM MQ configurations can be updated but the applications remain unchanged, not caring about the deployment details.

But one of your concerns might be around licensing. As you are used to running IBM MQ on-premises, you are used to running ILMT to track your deployments and using this to generate reports to show to IBM you are running within your entitlements. But how does this happen if you are running in a public cloud? Let’s assume you haven’t chosen the option of the hosted service of IBM MQ on cloud, but have chosen to deploy and manage your own MQ deployments on your clouds of choice.

The good news is that you can make use of the same PVUs that you have typically used to entitle your on-premises deployments. Imagine your new deployments will require throughput that you have been testing and figure out you will need 5 cores of IBM running on AWS, and workload needing 10 cores of IBM MQ Advanced running on Azure. How does this map to your existing PVU entitlement that you currently have sitting unused ‘on the shelf’.

The good news is that IBM has evaluated deployments on public cloud infrastructures and allows simply mapping of public cloud cores to IBM PVUs. You can review that information here with the general rule looking like for each vCPU that your deployment uses in public cloud, you need to ensure you have 70 PVUs of entitlement. So for the example given above, the 5 cores on AWS would require 350 PVUs of MQ entitlement and 700 PVUs of MQ Advanced on Azure. In common with most other IBM software, there isn’t a license key. But you will need to be able to keep records that can be shared with IBM to show your deployment and that you are compliant with your entitlement. Ordinarily, on-premises, this would require ILMT to run everywhere. However when deploying MQ on public clouds, these also have good reporting mechanisms. IBM will accept these reports as proof of deployment, and of the size of the deployment. However, if possible it is preferred to also ensure ILMT is deployed on these cloud environments to ensure consistent reporting with other environments. This, however, isn’t mandated, as long as you bring your own license to the cloud to provide entitlement.

So whether a “License to Thrill”, or a “For Your Eyes Only”, you can be sure “Messages are Forever” with the reliable, secure, once and once only messaging of IBM MQ, on public cloud, or on premises.

If you want to get started there are a number of technical blogs like this.

Or don’t forget our Quick Start for IBM MQ on AWS with a blog here and the actual link available here

Advertisements

Trying to contain your excitement – IBM MQ and Containers

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.

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.

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.

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.

 

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

Next steps might involve downloading container images here.

Or reading more about MQ and containers here

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

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.

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.

Reach out with IBM MQ and Amazon Web Services

Some of you reading this might be old enough to remember a commercial from AT&T urging you to “Reach out and Touch Someone” with a phone call. Which was a pretty clever concept – taking the ephemeral and remote nature of a phone call and making a real difference to people’s lives, actions and feelings.

Every business today is still trying to do this: interact with their customers, partners, and the market in general. And just as with phone calls the medium they are choosing to use is ever more widely IT infrastructure, which is more frequently now developed and running in clouds. And why is this? Why are businesses building and running applications in clouds such as Amazon Web Services?

A key reason is speed. That is speed to build, speed to deploy, and speed to reach those customers who you are trying to ‘reach out and touch’. Because the market is moving faster than ever, and you need to move just as fast, because if you don’t your competitors will.

Deploying applications on clouds such as AWS has never been faster or easier. But simply building an application does not mean you have built a business. If you are investing to build applications to engage with customers and progress opportunities, then it is essential that you handle those business opportunities with care. If you build an application to engage with a customer, then you need to capture that engagement and not lose that data. If you have taken an order you need to make sure you process it once and once only, not duplicate it or lose it. Your new cloud-based applications need to connect to the rest of your business with a reliable and secure messaging layer such as IBM MQ.

The good news is that IBM MQ can be deployed anywhere in your business, and beyond to provide the connectivity infrastructure you need, where you need it. That includes IBM MQ running on AWS. This has been possible for years, but now there is a new option: IBM MQ on Cloud deployed on AWS. In this case IBM will deploy and maintain the MQ Queue Manager on your chosen AWS region, and all you need to do is configure the Queues and use MQ as required. You can not only respond quickly to business needs and opportunities but do so without the concern of managing the physical infrastructure or keeping MQ deployed and running, allowing more time to work with customers.

If you want to reach out and touch your customers by making use of IBM MQ on Cloud running on AWS then you probably want to find out more. Why not check out the upcoming webinar about MQ on AWS by Woz Arshad  which goes out on November 14^th.

And if that’s not enough, and you are coming to AWS re:Invent in Las Vegas at the end of November, we will have experts from IBM Hursley there to talk to, with David Richards giving a talk (DEM42 : IBM MQ on AWS – Don’t Go Home Without it, Wednesday 28^th November at 1.10pm), and myself, David and Matt Roberts in the Expo. Maybe not ‘reach out and touch us’ but come by and say hello! We will be happy to tell you more about IBM MQ on AWS, and the unique benefits it offers, such as connecting workloads on AWS to on-premises applications.

 

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

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.

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.

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.

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.

What is happening in your business? What are your customers doing? Let IBM Event Streams show you the way ahead

You are developing applications to make your business more responsive. The heart of your business depends on the once-and-once-only delivery of IBM MQ messages to ensure your invoicing, shipment and supply-chain applications can reliably and securely move data between systems, and keep your business running smoothly. But you need to do more.

The world is moving faster, and your customers are harder to reach, and harder to keep. You need to build applications that engage more directly with customers, providing your business with an increased level of insight into their behavior as they engage with you online.

You want to be in more control and respond to the events taking place triggered by your customers. To do this your new engaging applications need to be event driven and inform you of each action and activity as it happens. Although you know the benefits that IBM MQ provides with messaging, you want to receive a greater amount of data from these new applications as a stream of events, which is a different type of messaging to that provided by IBM MQ.

What you need is IBM Event Streams, powered by Apache Kafka. Newly announced by IBM, and becoming Generally Available on Friday September 28^th, 2018, this offering will allow you to build new applications using Kafka clusters deployed on-premises or in a cloud environment. Your applications can now be built to take advantage of streaming event data offering more insight for your business. As an added benefit IBM Event Streams not only comes with IBM’s enterprise class support, but also a bridge to allow connectivity between IBM MQ and IBM Event Streams. You can then feed your applications with activity in your core business applications, as well as your new event streaming applications.

And the place to start is our webinar on October 2^nd 2018. Presented by Alan Chatt, you can hear all the details you need to get started with IBM Event Streams. Register here.

Data in motion is data adding value. Using MQ for data transfer from files as well as applications

Data. It’s sometimes described as the new gold. Certainly, it is valuable. But how exactly does it compare to gold?

The value of gold is that it can be made into gold objects such as jewelry which will have both the value of the metal and have additional value because it has been put to higher value use. But there are also costs associated with owning gold, keeping it safe, and moving it safely and reliably from where it is to where it needs to be. In order to realize the value, the gold jewelry must be moved from where it has been created to where it is needed.

 

What about data? Like a delicate piece of gold jewelry, some people might value a piece of data highly, but to others it is of little or no value. While gold is essentially fungible – as any gold can be fashioned into something, each piece of data is unique, not just in itself but set in its own context. Think of when you are trying to complete on a purchase of a house. An agreed mortgage is all very well, but what’s important is that the transfer of funds happens at a specific time to a specific account to allow the purchase to go through.

 

While a piece of data might represent something, the value of the data is only really achieved when it is moved to the right place at the right time. Having the data held securely in a system is not valuable on its own. It needs to be moved to be valuable. Data is created somewhere in the infrastructure but needs to be consumed somewhere else to add value.

 

This gives us a number of problems with data. Storing it safely; moving it safely; knowing it has arrived, so it can be put to use. This is again similar to gold. You have to keep it safe, and certainly you have to look after it as it moves as well. And if you have made a piece of jewelry for someone, you have to let them know you have it ready for them.

 

In your business you will have huge quantities of data. Data that is being created every second and stored in your file system. Buried treasure. I have already discussed this in here before. So what are you going to do?  You need to move it safely and securely to the part of the business that can make use of it. Probably the faster you move it, the better. And you certainly don’t want to lose it. Or have it stolen as it moves. And wouldn’t it be helpful if as it was delivered to the destination, the target application could immediately be made aware of it.

 

All this of course is handled for you by the Managed File Transfer component of MQ Advanced or MQ Appliance. The name is slightly misleading as it doesn’t move files but instead the contents of files can be moved as MQ messages. This means they take advantage of MQ’s unmatched secure and reliable delivery. No lost messages. No lost data. Your data gold will reach where it needs to go. And it can even be delivered directly to the target application without being written to the file system again.

 

Just as you wouldn’t want to keep all your gold in a vault where it wouldn’t add value to your business, don’t keep your data held up not adding value. Put it to work by moving it through MQ. When you have MQ Advanced or MQ Appliance you can deploy unlimited numbers of MFT Agents inside or outside your business. You can even embed them inside applications you share with your partners or suppliers. And the latest updates in MQ V9.1 add further enhancements to the MFT functions.

Think of all the buried treasure that has been lost over the years. Don’t let your data join those wasted resources. Get started today by learning MQ or with downloading a MQ trial. Or see what you can do with a hosted MQ on IBM Cloud or now on Amazon Web Services.

 

Not all data is treasure of course. You have to understand what’s valuable. But if it is valuable, then you should ask yourself why you aren’t moving it reliably through MQ Advanced, taking advantage of end-to-end encryption. After all you don’t want to go on a pointless quest with nothing at the end of it. Or find that your treasure has been taken.

No need to watch the clock with new hourly container-based pricing for IBM MQ

Your business is 24×7 now. No downtime. No waiting for additional machines to be brought online. Simply deploy more containers to handle more workload. On-premises or on cloud, either public, or private, or both.

After all workload varies through the day, across the week, throughout the month, and over the year. If that’s the case, then you are either already adjust or are planning to adjust the deployed resources to match the workload.

Deploying into containers makes this easier than ever. Co-ordinating these deployments into a managed environment using Kubernetes is the basis to private cloud infrastructures such as IBM Cloud Private or Red Hat OpenShift.

But building resources based on container deployments provides flexibility to make use of these assets either in these private clouds, or in public clouds, or anywhere really.

 

If that’s all understood, then let’s imagine a scenario of a workload that is only run at certain times. Perhaps it is payroll or ordering new supplies. But the applications, and their supporting infrastructure, such as the IBM MQ messaging layer only needs to run for a relatively well-defined period of time. And with the applications, as well as the MQ Queue Managers ready for container deployments, you can quickly and easily get everything up and running with the containers started with just the right number of cores to match the expected workload. But how will this be licensed? For transient workloads buying perpetual entitlement might not be the most cost-effective answer. Especially if the applications only run for a short time, or if there are brief spikes in the workload which require a large amount of resources but only for a short time.

 

The good news is that today IBM announced that for IBM MQ V9.1, as well as IBM WebSphere Application Server V8.5.5 and V9 a new licensing approach to reflect this type of deployment, making it easier for businesses to not only gain operational benefits from new container deployments but also cost benefits as well.

There are 2 main aspects of the announcement. One is that the licensing required for container deployments is based on the number of cores allocated to the container, rather than the size of the physical or virtual machine where the container is running, as reported by the deployed product to an instance of IBM Cloud Private which is monitoring and reporting on this. The second aspect is that this monitoring and reporting will be fine grained enough that the reports will include the number of cores used for the number of hours, and license entitlement will be available based on Core-Hours.

 

Let’s go back to the example. We are deploying a WebSphere Application Server (WAS) application into 8 cores of containers, and this will be supported by 4 cores on IBM MQ in containers. This needs to run on a Sunday, and runs for 20 hours solid, before finishing all tasks, cleaning up all data and shutting down the containers. If this runs 4 times per month, then for each month you would need license entitlement for 4x20x8 core hours of WAS, and 4x20x4 core hours of MQ. The new licensing allows customers to buy blocks of 1000 Core Hours of WAS or MQ. And the included free entitlement to an instance of IBM Cloud Private just for reporting on this usage will allow customers to track and report on their usage against their purchased entitlement.

But supposing at the end of the year things are busier and the workload needs to run for longer – maybe 60 hours per week instead of 20 hours per week, although still the same number of cores. Then each month would be 4x60x8 for WAS and 4x60x4 for MQ – so 240 hours per core in these busier months. The good news is the licensing provided in this announcement includes a cap on monthly usage of 160 hours per core. So although each core used for this workload is running for 240 hours each month, the reporting mechanism will make it clear that only 160 hours of usage per core is chargeable.

 

This new licensing includes support for both the new Virtual Processor Core Hours part, as well as the existing VPC month part for MQ. If you are deploying MQ or WAS inside IBM Cloud Private, rather than simply using it for reporting on usage, then PVUs can also be used for container deployments.

 

You can now get on with deploying and using IBM MQ and WebSphere Application Server to run your business, however and wherever you need. And the licensing will help you better reflect your container usage. Try to contain your excitement!

MQ Advanced powered by MQ V9.1 – now it’s time for business – join the webinar

It’s early September and seasons are changing. For some, summer is turning to autumn, and elsewhere, winter is changing to spring. Despite holidays ending for some, business is never on holiday. There are increasing demands to improve availability, response times, security and agility.

 

Businesses can’t take infrastructure for granted. In fact, it is critical to the success of the business. Ensuring that IT infrastructure is delivering maximum value is a huge differentiator in an ever more competitive world. And that can mean not being left behind and taking the best advantage of what your infrastructure can do.

 

IBM MQ has been at the heart of many of the world’s leading businesses for years. And MQ Advanced allows businesses to do even more with their MQ infrastructure, moving more data, from any environment more securely and reliably. The recent release of MQ V9.1 provided even more value to customers, especially if they are using or if they upgrade to MQ Advanced.

 

On September 12^th there will be a webinar covering the benefits of MQ Advanced and the advances included in IBM MQ V9.1. Simply click here to register and find out how your business can take advantage.

Why the IBM MQ Appliance might be a good choice for your business

I have already written about the announcement of the new IBM MQ Appliance M2002 which is generally available today (July 27th 2018). It is an amazing bit of kit, and already has demonstrated some staggering performance figures.

But you may well be sitting there reading this going “so what”? Why would I want a physical appliance? Surely this is enterprise middleware software, so I simply build an image, configure it and deploy it on a server, either somewhere inside my enterprise, or in a public cloud. And that is a perfectly valid question. And selecting to deploy software on servers, perhaps in a VM or a container is certainly the typical choice of deployment model these days. And IBM is doing what we can to make that style of deployment easier, simpler and yet more powerful as well. So, given all that, why might you consider and choose a MQ Appliance?

 

Most importantly, it is a choice. It provides an alternative. One of the benefits of the MQ Appliance as an alternative is that it provides a lot of benefits enabling the use of a very powerful MQ configuration without a number of the costs and burdens that otherwise might be associated with such a deployment. And although it might initially look expensive, it is important not just to realize that the price includes state of the art hardware, but that along with that, there are a multitude of benefits which make the MQ Appliance actually a lower cost alternative to many other software deployment configurations.

Many businesses using MQ have one or more highly skilled MQ administrators, who have, over the course of a number of years, built up a rigorously controlled MQ environment where individual Queue Managers are carefully deployed and managed for significant periods of time. While this is effective, it can also be limiting, as each environment becomes bespoke and dependent on the skills only available in the team and become restrained to the specific deployment environment which is tuned to fit that particular need.

 

Problems in this type of deployment arise when one of the key resources is no longer available for some reason. There can also be significant disruption at maintenance time, and when moving machines for lifecycle reasons. In the same way it becomes very difficult and time consuming to try and add to the system either to provide additional capacity to the existing applications or to support new applications as the MQ environment is very strong, but not very agile and responsive to change. And one of the problems is that with IT infrastructure, change is continuous. Servers need regular attention, with new OS or firmware patches required, and new hardware needing to be purchased and deployed that is always slightly different to the existing deployed systems.

 

The MQ Appliance is designed to provide a very strong and resilient MQ environment, primarily for production environments on premises. And it does this without requiring a highly skilled MQ administration team to design, configure, deploy, maintain and operate the MQ environment.

 

There is no need for what can turn out to be months of optimization and tuning of the MQ environment, as the MQ Appliance gives you optimized Queue Managers out-of-the-box.

There is no need to disrupt operations as an operating system or firmware update is scheduled. With no need to then have another disruption as a separate patch is applied to MQ itself. Instead the MQ Appliance is updated with a single firmware flash, updating all aspects of the appliance including MQ in a matter of minutes.

 

Unlike with servers where each machine might be different, each generation of MQ Appliances are identical, and will have exactly the same counterpart in IBM itself for development and testing of each firmware update. No more differences between systems. No more ‘install and hope’ that your environment is close enough to the supported environments for that version of MQ. And if the MQ Appliances are defined as a Highly Available pair, then both appliances can be updated to the latest level, with no down time, in less than 15 minutes.

 

With the MQ Appliance there is no risk that malware or additional code will be placed on the system as it is completely locked down. The only code that can be added to the MQ Appliance is the signed firmware updates that are downloaded from the IBM systems. And with MQ AMS included in the MQ Appliances, all messages flowing through the MQ Appliance can be encrypted end-to-end, simplifying audits, and helping to protect data from breaches, and to help meet GDPR requirements for data protection.

Even High Availability becomes much easier with the MQ Appliance. With each MQ Appliance able to run as a self-contained solution with local storage inside the appliance (the M2002A provides 6TB of SSD storage), it is trivial to set-up replication between 2 appliances. This offers a very easy solution to meet high availability needs, with no external dependencies, and literally just a 2-click setup. One of the outcomes of this benefit is that it makes it very easy to deploy MQ Appliances in remote locations, where MQ might be needed in HA configurations, but there aren’t any local skills to setup and maintain a complex network attached storage environment.

 

Imagine therefore you have MQ running today in an existing environment. Your hardware is old and needs replacing, and so you would need to start planning and evaluating for new hardware. Then there is the issue of how long it will take to order and configure the hardware, which is likely to be done by a different team to the MQ administration team. Once that is setup then there is the issue of what is the standard environment for that type of system? What other software needs to be installed, and then what is the maintenance program for the hardware, OS and other software. All that before installing a version of MQ, configuring it, and then figuring out how to move the existing MQ configuration and runtime across, once sufficient testing had been done.

 

Or you can simply select the MQ Appliance. It comes as a choice of 2 models offering different levels of processor capacity and storage capacity. And you can upgrade from one model to the other with a command. Then you install it into the rack, cable it into the network. It will already have the latest version of MQ and as you create Queue Managers they will be allocated a protected share of the Appliance resources. If you want to configure the Queue Manager as Highly Available, it’s as simple as identifying where the other appliance is on the network. You want to have Disaster Recovery as well in a remote site – again as simple as connecting to that appliance.

The MQ Appliance is a simple, secure, reliable and powerful way to deploy, run and maintain IBM MQ in your on-premises environments. Suitable for consolidating your existing MQ infrastructure in your data center, or deploying new MQ capacity in your data center, or in remote locations. The MQ Appliance works well if you have existing MQ systems, or if the MQ Appliance is your first MQ system.

It’s good to have a choice. Especially if you choose the IBM MQ Appliance, with the M2002 model available today.