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.

 

 

Setting out markers for MQ’s road ahead

February 16, 2016

2016-road-ahead

Working as the Offering Manager for IBM MQ and the IBM Messaging Portfolio, there are lots of parts of my day-to-day work that I can’t share on here until we announce it. However there are times when we can provide a small look ahead at what’s coming. This is called in IBM a “Statement of Direction”. And today IBM MQ has released a Statement of Direction for both IBM MQ and for the IBM MQ Appliance.

You can read the Statement of Direction here.
As you will see in reading it we are talking about a couple of important points. I will deal with the MQ Appliance statement first. As covered elsewhere in this blog, there has been a lot of interest in the MQ Appliance since we announced it at IBM InterConnect 2015 – just about 1 year ago. One of its key features has been about the High Availability function – the simple way to connect up two appliances and to allow for seamless failover between them benefitting from synchronous replication.
At the end of 2015, as detailed here IBM extended this High Availability option with asynchronous replication to other MQ Appliances, which could be deployed further away, offering Disaster Recovery. However, deployments needed to choose either one style of replication or another, on a Queue Manager by Queue Manager basis. So a Queue Manager on a MQ Appliance could be defined for High Availability, or for Disaster Recovery, but not both.
This created an obvious question when we discussed this with customers, who in some cases would want to have local MQ Appliances offering High Availability, but in the case of a whole site failure, wanted to then offer Disaster Recovery off-site. As giving forward looking statements can be an issue without legal clearance, we have ensured that with this Statement of Direction we can clearly state and assure customers that IBM indeed does intend to support the ability of Queue Managers to be configured for both High Availability and Disaster Recovery in a future update.

DR-phase2

For MQ itself the Statement of Direction covers less function, and more the delivery and support approach used for MQ itself. For many years IBM has released updates to IBM MQ every 2-3 years as major new versions, and sometimes with additional interim updates as incremental releases. But over the last few years IBM has been adding function into the regular fixpack deliverables where we also include maintenance updates alongside the new function.
While this approach allows IBM to add useful new functions between releases, and thus getting it to customers earlier, it can lead some customers to choose to keep their MQ implementations on older releases until IBM stops adding new function to that particular release. The concern is that adding new function in a release that will be used in production can create the need to have a major new testing cycle, even if IBM has designed that the new function is off by default.
As IBM thinks customers would benefit from being at the latest level of code, and certainly IBM wants to encourage customers to stay up to date with the latest fixpacks, IBM has decided to offer two separate code delivery and support options.

One option will be the Long Term Support Stream. A new version of MQ will be released, and from that point on, there will be no new function shipped on that code-stream. The fixpacks that IBM will continue to ship on a regular basis will only contain fixes to existing functions and no new functions will be added. As such it should be simpler and safer for customers to move more rapidly to this level of code and to then stay on it as fixes are rolled out, improving stability and performance.
The second option will be the Continuous Delivery option. Based off the same original code drop as the Long Term Support option, subsequent updates will be delivered containing not just fixes but also incremental new function. Each mod-level update will be designed to continue to add new function. And, important to understand, customers who choose to deploy the Continuous Delivery stream will have to keep taking the additional functional increments and fixes if they want to stay on that stream by moving to the most recent mod-level. If they decide they want to be on the Long Term Support stream then will need to change the MQ installed which will likely cause a degree of disruption as they will effectively be moving to a different release. While this continuous delivery of function will ensure that customers of MQ will have new functions that enhance MQ and the operation of their environment, those customers will need to be able to continue to update their environment with each update as it is delivered. For many customers this might be appropriate as they have a need for the new function or they may want to apply it only to a particular environment and set of applications.

LTS

After a number of functional updates to the Continuous Delivery Stream of IBM MQ, over probably a period of 2 years or so, it is expected that the incremental set of new functions delivered in the Continuous Delivery Stream will be released as the new starting point for the next version of the Long Term Support stream, and will reset the version for the Continuous Delivery Stream as well. The cycle them will repeat again, with fixes applied to the Long Term Support Stream and new mod-level updates with new function (as well as fixes) delivered to the Continuous Delivery Stream.

This new approach for delivering MQ may be significantly important for some customers as they make future plans, and IBM therefore thought it was important to set this out in a Statement of Direction prior to a future announcement of a new release of IBM MQ supporting this model.

As for when any new releases to backup these Statements of Direction are coming out? Well, keep watching this space.

A message awakens: What is IBM MQ and why do you need it?

January 5, 2016

Stormtroopers

Why are we here? Not in the existential way. The answer to that is not in this blog. That would probably require more than the page of general MQ related discourse that I generally include. No, this is more why are you reading about IBM MQ? And maybe more pertinently why am I writing about it.

Do you ever read the book of the film? The novelisation. It’s what happens when instead of a book being turned into a film, generally with about 2/3 of the detail and exposition cut out, you have an original film, and then it is made into a book. Generally these tend to be less satisfying than an original novel.

Earlier in 2015, in an effort to try and communicate more with the tens of thousands of people who use IBM integration products, the team in IBM Hursley have been doing live Google Hangouts on multiple subjects – and these are then saved as YouTube videos. With my colleague John McNamara I have done a number of these and 3 of them have been titled “What is messaging” to try to cover why you might find messaging valuable and useful as opposed to some of the other choices around for communicating and exchanging data.

You can see the 3 videos here: Part 1  and Part 2 and also Part 3 

John and Leif

In those videos we tried, as best we could, to be product agnostic – to focus instead on messaging as an approach rather than a specific implementation such as IBM MQ. However the question naturally arises why should you specifically use IBM MQ?

Now in the years I have been writing this blog I have written a few posts that talk to the usefulness of IBM MQ – see here, here and here. However why is it that IBM MQ is still the selection of so many businesses today?

Again, as with the ‘why are we here’ question above, this isn’t something that can be quickly and easily summed up in an easy to read blog entry. So what I will do is try and call out some of the major reasons in simple terms, and then hopefully, as time permits through the year, I will try to add more detail.

Why use IBM MQ then?

  • It works – it does what you need it to do
    • There are many thousands of the world’s leading businesses using IBM MQ, and not just using it – but they are depending on it. They trust it to work, and do what it is asked to do, connecting their business simply, securely, rapidly and reliably.
  • Businesses depend on it – as above – for critical parts of their business – at its heart IBM MQ is built around transactions
    • The business world, and IBM MQ, is largely based on the notion of ‘once and once only’ transactions. While there are other approaches, so much of the critical aspects of business depend on this style of transactionality.
    • It is not easy to offer reliable, persistent messaging that provides once and once only delivery. That’s why many other messaging providers can’t offer this, and why many businesses select IBM MQ
  • IBM MQ scales to meet your business need
    • Developing a small scale application that needs messaging is great and it can be simple to use one of many different messaging tools
    • Ensuring this messaging tool works as the application usage scales is another matter. IBM MQ scales horizontally and vertically, running highly efficiently on single machines or spanning multiple machines in large clusters.
    • Whether sending a few messages per day or scaling to a billion messages per day, it is likely you want good performance. As well as being efficient in scaling, IBM MQ also offers high performance to move messages rapidly between application endpoints.
  • Your business is at risk – how secure is your messaging software?
    • You can’t afford to take risks with your business data, or the information your customers entrust with you. IBM MQ has multiple layers of security on the system itself and the data being moved and supports the latest encryption standards. Can you afford not to protect your messaging layer?
  • Highly available – it’s what you need and your customers expect
    • You can’t afford to go offline – you need to run all day, everyday. IBM MQ can be right there with you, with built-in support for High Availability as well as being able to use multiple different approaches such as vendor-based clustering, or virtualization.
  • Everything you need, functions and tooling
    • While the problems solved by messaging are well understood – and there is a great benefit from simplifying applications, some of that is lost when the need for additional functions require multiple different messaging offerings. With richness of function and a complete span of capabilities IBM MQ offers a single solution
    • Deploying a messaging solution is only part of using the solution. There is a need for management and tooling to provide insight in what is happening to all the messages, and to identify exceptions etc. With support from multiple different tooling vendors, and dozens of additional free tools and add-ons, as well as the ability to create your own utilities, IBM MQ can be tailored to meet the needs of your business solution.
  • Help when you need it, where you need it
    • With more than 20 years of leadership, and substantial market presence, there are thousands of skilled professionals able to provide guidance in how and why to use IBM MQ, how to configure it, how to program with it, and how to deploy and maintain it. And all that supported by IBM’s global 24×7 support organization to help when needed.

So that’s a few of the high points about IBM MQ. I will look to write more in detail about some of these through the year ahead – although I am also pretty sure I will be adding some new entries about product announcements and enhancements as well. Watch this space.

Appliance close up

What can go wrong will go wrong! How the MQ Appliance helps save the day.

November 30, 2015

Dilbert-DR

Since IBM announced the MQ Appliance earlier in 2015, there has been a huge amount of interest in the solution from pretty much everyone. All the customers and business partners I have talked to (along with the many my IBM colleagues have also been talking to) have almost always seen a place for the MQ Appliance in their organizations.

As expected some of these use cases reflect one of our anticipated scenarios of using the MQ Appliance – deploying in a remote location away from the main data centre. Other use cases are based in the data centre with the MQ Appliance being used either to roll out new MQ capacity quickly and simply or to consolidate an existing MQ deployment that might be installed and running on multiple different machines which can make it complex and expensive to maintain, especially when deploying updates or making configuration changes.

MQAppliance

Other that the simple and quick deployment and the ease of maintenance that the MQ Appliance provides, probably the function which generates the most interest from customers and potential customers is the High Availability function. MQ is used pretty universally for work that is critical to the business. The messages being moved between applications and systems contain business critical data and it is crucial that these messages are delivered once and once only and in the case of failure at any point, the messages are recoverable and the business can continue. No one wants to lose the message with the new customer details or the big order.

 

So the High Availability (HA) in the MQ Appliance was seen as key – it was simple to set up – essentially just a single menu selection when defining a new Queue Manager and you would have another appliance ready to synchronously replicate the persistent messages and logs so that in the case of a failure in the production Queue Manager, a replacement queue manager is started on the second MQ Appliance with full access to the messages and logs already available on that appliance. This simple yet rapid and usable solution is compelling, and can also be used, with manual failover control, to enable seamless operation while applying fixpacks on the appliance.

 

However one of the key details to understand about the HA support was that this used synchronous replication of the data between the disks on each appliance, and as the original message can’t be counted as complete until the replication is also complete, the HA appliance needs to be close enough so that the latency of the replication doesn’t impact the application writing the message. The published recommendation is for latency of less than 10ms, but for best operations latency of 2ms or less is preferred.

 

Now, with the 8.0.0.4 fixpack available on the MQ Appliance from November 30 2015, we have added another key feature – which addresses the need for replication over longer distances where latency is always going to be too high for synchronous replication. The 8.0.0.4 fixpack adds asynchronous replication enabling offsite replication over far longer distances than supported for HA as there is no impact to each individual message completion – the replication takes place independently. This style of replication is typically used for requirements such as Disaster Recovery (DR), to enable business continuity out of region with the ability to continue work as close to the point of failure as possible.

 

Customers using this DR feature with the MQ Appliance will be able to configure individual Queue Managers in their appliance to replicate their persistent messages to another MQ Appliance that can be hundreds, or even thousands of kilometres away. And unlike the HA configuration where appliances need to be a defined and fixed pair, there are much more flexible options for this style of asynchronous replication.

 

As mentioned the DR configuration is done on a Queue Manager by Queue Manager basis – but different Queue Managers on the same production appliance can be replicated to different DR appliances. Also Queue Managers defined on different production appliances can all replicate to the same individual DR appliance.

 

As before with the HA appliance, there can be ongoing work and other active Queue Managers on the appliance being used as the DR appliance – there is no formal limitation for appliances to be DR or HA appliances – any appliance can be configured to offer this in conjunction with the other workload running on it.

 

With the addition of this asynchronous replication for Disaster Recovery, the MQ Appliance can be used for more deployment use cases as the ability to recover from failures to a running environment in another data centre is always going to be crucial, as so many businesses depend on MQ to keep them running.

<BLOG UPDATE> With this MQ Appliance fixpack delivering such an important update we also have blogs from our Appliance development lead Ant Beardsmore here, and from our Appliance HA and DR architect John Colgrave here going into more details on the enhancements and the technical details of how DR works.

With simple configuration for all these scenarios, rapid deployment and ‘push-button’ maintenance, it is no wonder so many businesses are looking at using the IBM MQ Appliance. Want to know more? Check out our main webpage. After all, if things can go wrong, they will go wrong. That’s why you use IBM MQ after all. It is better to be ready and to be able to cope with these disruptions. Your business needs to keep running. With the MQ Appliance you can do that with the minimum of effort.

ApplianceDR

When is a quantum leap not really a quantum leap?

November 3, 2015

Electronimage

A quantum leap, if I remember correctly, is the movement of an electron from one energy level to another energy level. So it is not really a big change – just the change from one discrete level to another discrete level. However the phrase “quantum leap” is often used to describe a big change, when in fact it is describing a very small change. Just like a quantum leap, MQ get updated from one fixpack to another. Sometimes this can be thought of as a small change. However in the case of the latest update to MQ V8, this change can represent significant change and new opportunities for MQ users. When an electron does a quantum leap and drops down to a lower energy level and emits a photon, let’s shine a light on the changes in the latest update to IBM MQ.

Last week, on October 23 2015, IBM brought out an update to IBM MQ V8 that included not just fixes, but some really important new features and functions. I will call out some of these here, and hopefully also link to some other sources of information to find out more about the parts I don’t cover.

The key enhancements I am going to cover are the addition of full MQ Light API support within IBM MQ, and also what we are calling the redistributable MQ Client. There are plenty of others (another interesting new feature is setting a Message Expiry Cap) and these are described in Mark Taylor’s short presentation – which can be found here 

Let’s start with the addition of the MQ Light API as a fully supported option. You can read my previous blog on MQ Light here   – but as a recap, MQ Light is a new API for messaging which is designed to allow developers working with Javascript, Ruby, PHP, etc. to make use of messaging as a part of their applications. This enables them to code microservices, and build applications making use of buffering, but doesn’t force them to learn the richer, more complex MQ API or JMS, or require them to code in C or Java. MQ Light is a good way for many enterprises to start to change some of their infrastructure into Hybrid deployments, supporting both on-premise and cloud deployments.  In this latest update, IBM MQ itself now supports the MQ Light API. So these developers can continue to script their applications making use of the MQ Light API in whichever environment they prefer, but now IBM MQ itself acts as the messaging provider. As these MQ Light  applications publish their messages or listen for their subscriptions using the AMQP protocol, this means that AMQP clients can now for the first time connect in to IBM MQ which is then receiving published messages and forwarding them on, or routing the subscriptions to the applications. By ensuring that only a single messaging runtime environment is needed, this lowers the operational burden, reducing complexity for the infrastructure team, and keeps costs down, while keeping the application developers happy with their preferred development environment and API. And the infrastructure team can ensure they support the growing demand for Hybrid infrastructure for cloud deployed applications, while still meeting their enterprise qualities of service for their middleware infrastructure.

The other key update concerns the MQ Client. The MQ Client is how many MQ customers make use of MQ, embedding the client libraries in their applications which then send and receive MQ messages. In this new update the MQ Clients are now also available as tar or zip files for easy embedding in the applications themselves. As well as removing the requirement for a separate install process, the license has been updated to allow applications that include the MQ Clients to be distributed inside and outside the enterprise without requiring permission from IBM as had been the case in the past, which had prevented the easy inclusion of the MQ Client libraries in many solutions. From now on, the MQ Client can be included in any solution, easily packaged and distributed to allow the seamless distribution and deployment of MQ connected applications anywhere required. I am looking forward to seeing many more customer and vendor applications including the MQ Client libraries from now on.

These two changes are substantial enhancements and dramatically change the options available for businesses looking to use IBM MQ for messaging, making this a real leap into the future, for both on-premise business critical applications and the rapidly changing world of Hybrid Integration.

For more details on using MQ Light and AMQP with IBM MQ to enable Hybrid deployments and more see here.

And for more information on the re-distributable MQ Client see here.

A leap into the future, and into the past was the subject of another ‘Quantum Leap’ – this time a TV series from the late 80s/early 90s. Scientist Sam Beckett would ‘leap’ from body to body throughout time. I guess that’s another example of a quantum leap not being quite a quantum leap. As he used to say when he leapt into someone else: “oh boy”.

QL-ohboy

Simpler and cheaper – MQ MFT changing for your benefit

June 2, 2015

Change is always with us. IT infrastructure needs are changed. Application needs change. Skills profiles change. Even workloads and expected response times change. These changes we see in the market drive how we view our products. We frequently update MQ products, perhaps too frequently for some of our customers. As well as adding to and updating the functions and capabilities of MQ, we also try to update or change the packaging and the pricing of our various MQ offerings. We do this to try to respond to the changing needs of the market and the feedback we get from our customers.

As a way of describing this process, we have been recently talking about the different deployment choices available for IBM MQ. Check out this recent webcast on this.

The fundamental thought here is that your business should be able to use the value that MQ provides; however you choose to deploy MQ and consume it. The presentation in the webcast highlights a number of different ways in which your business might want to deploy MQ. This could be maybe reviewing the new MQ Appliance as a deployment choice, deploying the complete MQ set of capabilities using MQ Advanced or seeing whether you want to deploy and use IBM MQ in the cloud – whether that is a public cloud like Microsoft Azure or IBM SoftLayer, or a private/hybrid cloud infrastructure running on your own hardware on-premise, using something such as IBM PureApplication.

Manwithfiles

Going back to MQ Advanced, IBM announced on May 26th 2015, slightly new packaging and pricing for MQ Advanced. Included in this announcement were also various MQ Managed File Transfer parts. These parts were updated to reflect the needs of our customers – given their growing use of using Managed File Transfer with MQ.

As Senior Product Manager for IBM Messaging I talk to many customers through the year, and one of the constant pieces of feedback I get is about the ever-present need for better handling of file transfers. This is an area where every business has a solution, or 2, or 3 today. No one is happy with their existing offering, and most, even if they are existing MQ customers, are unaware that MQ can help.

MQMFT image

MQ’s Managed File Transfer solution can read data from a file, and send it as a MQ message over the MQ network. Once received on the remote system, the MQ MFT solution can then recreate the original file, achieving the movement of the file with greater security and reliability thanks to IBM MQ. This can help to address many of the issues businesses have with moving files, while also simplifying their infrastructure and consolidating on MQ. After initially using MQ MFT to move files, many businesses then take the next step to make use of one of the unique points of MQ MFT which is ‘file to message’ movement. As the file contents are moved as MQ messages, this data can then be directly consumed as MQ messages – meaning that the file contents don’t need to be written back as a file, identified, and then read in again. Instead the data can be delivered directly to the application as a MQ message.

The May 26th announcement simplified the packaging and lowered the pricing for how customers could purchase the MQ MFT capability – either as an extension to existing MQ licenses or as part of the MQ Advanced bundle. The MQ Appliance can also be a part of a MQ Managed File Transfer solution – acting as the co-ordination Queue Manager to allow the MQ MFT Agents to send and receive the file data as MQ messages. With  more and more MQ customers choosing to use and deploy MQ MFT we are changing the packaging to ensure they can do this more cheaply by removing the Connect:Direct and Control Center products we had bundled in as they haven’t been used as widely as the MQ MFT capabilities.

ApplianceMFT

Don’t forget that if you buy the MQ Advanced offering you not only get the MQ MFT Service part but also the MQ AMS capability for end-to-end encryption. This has also been a hot topic of conversation with customers and if you want to know more you can read my previous blog about it here.

How is the new IBM MQ Appliance different from a BBQ?

February 17, 2015

MQ Appliance Image

When I am eating at home I really love to BBQ. However, living in the UK, we don’t always have the perfect weather to enjoy BBQs, especially when you have a charcoal BBQ. It mustn’t be windy, and you really don’t want it too cold, or rainy. So conditions have to be right, and then there is the issue of whether you have enough charcoal, can you start it ok, do you have the right food to cook on it? And if you are cooking on it will you have enough fuel on to cook everything you need, or will you have to add charcoal in the middle of cooking?

So although I would generally prefer to cook and eat on the BBQ, it is far simpler on the whole to cook in the ovens in the kitchen. They are there and ready, rain or shine, up to temperature in a few minutes, and able to cook pretty much any type of food quickly and simply. And you know what – once you get to understand your oven, you can get it to produce food pretty much as good as the BBQ. In most cases a lot more reliable and certainly a lot quicker and cleaner. I have a pair of ovens – so I can ‘hot-swap’ between them!

Cropped oven

If you need enterprise messaging, then maybe you are in the same dilemma? You know you need enterprise messaging – but the amount of effort you find it takes to install it and deploy it on a system if too high to think about using it everywhere. So you limit use to just your enterprise datacentre. But then there is the problem of keeping it up to date once you have it on multiple different machines, all of them running your business. What you need is a solution where you can just switch on – much like an oven.

IBM is really happy to announce today a new offering – the IBM MQ Appliance. With this you get all the enterprise messaging benefits of IBM MQ V8 – but in a state of the art physical appliance. No more having to configure and maintain a separate physical server and then install IBM MQ. The MQ Appliance is designed to be unboxed and up and running in less than 30 minutes, making it faster and simpler for new MQ messaging capacity to be available wherever you need it.

We anticipate the MQ Appliance will be welcomed in the enterprise datacentre where a highly capable appliance will be able to process high MQ messaging workloads in a single physical footprint, and with not just a simple deployment process but far easier maintenance, with fixes for both MQ and the firmware delivered together as a single firmware flash, allowing you to keep your appliance up to date quickly and simply, knowing the fixpack has been tested by IBM on exactly the same hardware.

Another anticipated use case will be outside the enterprise datacentre, such as in remote locations where there is a need for MQ Queue Managers but no local MQ skills on site to setup or maintain the MQ environment. This could be a factory, branch office, warehouse, or a business partner. Now, if a MQ Appliance is shipped out to the location, it can simply be unboxed, plugged in, and have any further administration done remotely.

Appliances can be deployed in a High Availability pair, with persistent messages mirrored from one appliance to the other, to ensure continuity of workload in the case of failure, without any complex setup or external storage dependencies. A pair of appliances work even more seamlessly than my pair of ovens pictured above – with queue managers starting up and processing work automatically, with no marooned messages.

The appliance is built using the experience of the IBM DataPower appliances to ensure that you can depend on it for your enterprise, but it focuses on delivering just an optimized MQ experience. No tuning is needed to get the best performance out of the MQ Appliance. And a new browser based tool, the MQ Console, provides a customized interface for monitoring and configuring MQ on the appliance.

The MQ Appliance will be available on March 13, 2015, and will be available as the M2000A, and the M2000B – 2 price points to meet different message throughput needs in the market. You can read the announcement letter here. Visit the webpage. And feel free to talk to your IBM rep or selected business partners about it today. Why not come and see us and the IBM MQ Appliance in person at IBM InterConnect 2015, in fabulous Las Vegas. We even have a video posted on YouTube of me talking briefly about the MQ Appliance. We don’t do that everyday!

I will admit, that as good as it is, the MQ Appliance isn’t a great way to cook ribs, burgers or steak. For that, I’ll pick my BBQ.

cropped bbq

IBM MQ Light – What’s in a name?

October 3, 2014

“A picture paints a thousand words”. A well-known phrase. Undoubtedly true, but a single word can be critical. Change a single word and the meaning of a sentence, a paragraph, maybe a whole book or more could be altered. So what about IBM MQ Light? Is it MQ, but Light? And what does Light mean in this case?
We see the description ‘Light’ every day. Some product advertises itself as “Light – all the flavour, half the fat”. You know the sort of thing. So does it apply to IBM MQ Light? How does this new product compare to IBM MQ itself?
Well, I would say that maybe the best way to think of it, is not IBM MQ but “Light”, but rather IBM MQ for those “Lightbulb” moments, such as when Archimedes shouted “EUREKA!”.

eureka
IBM MQ after all already delivers the benefits of messaging to millions of applications running in tens of thousands of businesses around the world. I have described some of those benefits on these pages already. It does this primarily for enterprise critical applications, written in C, Java or even COBOL, dealing with Systems of Record. These applications handle business critical transactions, moving key customer and enterprise data between applications systems and services. And it makes a lot of sense to ensure these applications, and the associated data can benefit from IBM MQ’s reliability, robustness, security and scalability. After all if you are moving and updating business transactions, you want to scale, be secure, and be highly available.
However, there are many millions more applications that don’t face the same requirements, but yet are still critically important to the business. Maybe the app helps the business interact with customers with more immediacy. Maybe it shares information more widely with partners. Maybe it is building brand awareness or promoting the business across different platforms and devices. These type of apps are written by a different type of developer, using different languages, for very different purposes to the more traditional application that works with the systems of record. These are unlikely to be updating business critical information systems or processing transactions, although they will need to interact with existing systems. So maybe they don’t need everything that IBM MQ has to offer. But does that mean they don’t need anything that IBM MQ has to offer?
Messaging as provided by IBM MQ, does after all benefit program architecture and operation. Applications can be simpler. Applications producing and consuming data at different rates can be easily buffered. And aspects of security can be built in. Along of course with the ability to connect and exchange data across different systems, even if one application is down.
If messaging can bring all these benefits, why would the programmers of all applications not use it, when there is a widespread and well proven technology like IBM MQ? We have already called out many of the reasons. The developers are a different set of people, with different skills, and code in languages that IBM MQ doesn’t natively support. And IBM MQ is designed around the needs of those critical business transactions. That doesn’t mean that it can’t handle simpler needs, but if you are not familiar with using IBM MQ, there can seem to be a lot more options in the API to deal with than maybe are needed for a different, more straightforward use case. So why not produce a messaging product, which takes everything from IBM MQ that would be useful to this new set of developers, but presents it to them with a simpler API, more in line with the restricted needs of the type of applications they are producing. This is what IBM has done with IBM MQ Light.
IBM MQ Light is a new and different messaging product from IBM. It aims to bring the benefits of messaging to a new set of developers building the latest applications for a rapidly changing world.
The goals of MQ Light are as follows:
• Provide messaging that application developers will love to use
• Help applications be responsive and scale to meet demand
• Make it easy to get access to the code and to start to use it – simply download, unzip, use
• Run on premise or on Bluemix in the cloud
• Offer simple, open APIs in a mix of popular scripting languages
• A new breed of tooling to ensure developers know what is happening to their messages
You can see by these goals, this is something new. And also MQ Light is not trying to be an alternative to IBM MQ. It is very different. It focuses on the needs of the new developers. And in keeping simple, it means that it doesn’t provide some of the key characteristics of IBM MQ. There is no clustering, no high availability, and no transaction support. If your application is likely to need those functions, then the right choice should be IBM MQ. If however your application doesn’t need any of those, but it still could benefit from messaging, allowing it to buffer and scale workload, respond to events, schedule actions or queue responses, then MQ Light may be a good match for them and their developers.
For development use, MQ Light is of course free to download, and is available on Windows and Linux for x86 or Mac OS X. Once applications are developed and ready to be put in production, they can be run on premise in the MQ Light runtime (payable per Install), or deployed using MQ Light in Bluemix (payable per Message). And in the future, as mentioned in the IBM MQ V8 announcement letter, there will be the ability to run MQ Light applications in IBM MQ itself.
All in all, enough to make a lightbulb go off in anyone’s head. If it is going on in yours – check out the MQ Light webcast to learn more. Or even better download it today and be using it in a few minutes.

lightbulb-idea-14606269

IBM announces IBM MQ V8

April 22, 2014

Image

There are some things that come around every day. Good things, like new business and new customers. Other daily occurrences are not so good, like hardware failures, network problems, or security fixes to apply. Then there are some things that come around much less frequently, but they are worth waiting for. Good days like when a new version of IBM MQ is announced. Days like today.

That’s right. At IBM we are happy to announce IBM MQ V8. You can read the announcement letters here: Click here for the announcement letter for IBM MQ V8 on distributed platforms. Click here for the announcement letter for IBM MQ for z/OS V8. And click here for the announcement letter for the various IBM MQ V8 offerings on z/OS with a One Time Charge pricing metric.

There are a lot of new capabilities, and plenty of enhancements and improvements included in the announcements. At this point I will just call out a few of the high level items, and leave myself plenty of opportunity to come back on subsequent blogs and dive a little deeper into some of the new and improved areas.

Let’s start with one of the changes that maybe either big or small depending on your perspective. We are starting, with this version, to call this product IBM MQ, as opposed to WebSphere MQ, mirroring a change you may have seen in some other products in recent years. After all MQ connects your entire infrastructure, so referring to it as IBM MQ rather than WebSphere MQ is perhaps more indicative of that breadth of coverage. It does of course continue to work with all the previous releases of WebSphere MQ, and in fact when you order it and install it, you will still see it as WebSphere MQ, but over time, expect changes in the product to reflect the new branding, while continuing to deliver the same robust messaging infrastructure.

So what else is new? Plenty of course has changed for the better, and many of the changes can be grouped as enhancements to boost both security and scalability, improving support for standards, and also doing more to exploit the hardware being used. This changes should reflect an overall improvement in the ease of use of IBM MQ in this release, simplifying configuration and reducing operational tasks.

From a security point of view, some of the key changes include the authentication of userids defined in the operating system, or in LDAP for distributed platforms. More changes include support for multiple certificate authorities in a single queue manager, and the use of DNS Hostnames in Channel Authentication Records.

From a scalability point of view MQ is now better at scaling to the limits of a SMP machine. And there are various other enhancements, especially for publish-subscribe, including a change in the way clustering works for pub-sub. These changes in scalability are particularly designed to improve real-world scalability, rather than being tuned to demonstrate performance in confected examples.

Notable in new standards is support for JMS 2.0 with new messaging features and updates to the API. Also there are enhancements in Microsoft .NET support as well as WCF extensions. And for improved connectivity options, the function that was previously a part of MQ Telemetry Advanced is now a part of MQ Telemetry, giving customers more for less.

For our customers using MQ on z/OS there are some particularly notable enhancements that offer new capabilities and exploit some of hardware updates likely to be available. There is support for 64 bit buffer pools, and a wider log Relative Byte Address as well as support for the zEDC compression and Coupling Facility Flash. Likely to be of real interest is the announcement that we have removed the Client Attachment Feature, meaning that there will no longer be a charge to connect MQ Clients on other platforms to MQ on z/OS. This applies from today, not just on MQ V8 but on WMQ V7.0.1 and V7.1 as well.

As I said, there is quite a lot of new information to share here. I didn’t even get a chance to mention that the MQ AMS code is now integrated into the base on all platforms, and available on IBM i for the first time. Lots more detail to come so please come back for more, and hopefully I will see you at IBM Impact next week in fabulous Las Vegas.

Image

The Paradox of Choice – the best Managed File Transfer solution?

March 18, 2014

Image

 

We all know the feeling – you are shopping, maybe for some food. You have a vague idea of what you want until you are confronted by reality – dozens or even hundreds of different options. Which is better for you? Which will better meet your needs? It becomes harder to make a choice if there are too many choices. When I am out for dinner at a restaurant I suffer much the same dilemma. I love Cherry Pie for dessert, but what about the refreshing creaminess of Ice Cream? It might seem a simple choice but it would be easier to make a decision if the menu was more restricted.  

Image

This was explored in a very interesting book by Barry Schwartz called ‘The Paradox of Choice – why more is less’. I highly recommend a read of it.

This applies quite widely in other areas. Take for example how you want to deal with files in your business. Let’s face it; you have files, filled with business critical data, on every system in your enterprise. And you need to move the files, or at least the data inside them, across your enterprise to consume the data elsewhere. So you plan to move them, only this creates your first dilemma – should you use simple FTP even though you know it can be unreliable and insecure, and you never really know what happens to your files. Or should you use a managed file transfer solution?

Well hopefully, your business cares about the files and the data enough to look at a managed file transfer solution. After all you don’t want to create a management and security headache when trying to move the files, and you certainly don’t want to troubleshoot what has gone wrong every day, and maintain hundreds of FTP scripts.

So you want a managed file transfer solution – but which one? This opens up a whole different solution set. Do you want a bespoke solution, dedicated to file transfers, or one that is maybe multi-tasking – perhaps a function built out from another piece of infrastructure that might be more adaptable for some of your use cases, even though the dedicated solution looks good for other use cases?

Many customers today might look at their existing solution providers such as IBM who has been providing middleware for this type of solution for many years. And here there has been a choice to be made:

IBM Sterling Connect:Direct, a market leading managed file transfer solution with years of expertise as a dedicated offering in this space, with a secure protocol and purpose built tooling to provide all a business needs when moving files, extended with IBM Sterling Control Center for event based monitoring of file transfers. Looks good for a dedicated solution.

IBM MQ Managed File Transfer, an extension to the widely used IBM MQ messaging middleware offering. This also provides file transfer, moving the files as messages over MQ, but also allows not just file to file transfer but also file-to-message and message-to-file transfers which can help the business make faster use of the data being moved. A highly adaptable solution, but also supported by IBM Sterling Control Center as a management and monitoring dashboard.

So even from IBM you would need to make a choice, even though you could probably adapt both offerings to meet your needs. But it would be nice to not have to choose, but to use whichever offering was best for any particular use case.

On March 11th 2014, IBM announced that it was solving this dilemma of too much choice by combining the two offerings of IBM Sterling Connect:Direct and IBM MQ MFT, and also including IBM Sterling Control Center. Now there is just one solution to buy for Managed File Transfer. And when you buy it you don’t have to choose which to use, as you get entitlement to both offerings included, as well as Control Center. No more choosing between Cherry Pie or Ice Cream, as you can have both.

Image

A smaller number of choices in this case is definitely better. You can read more about this offering in the announcement letter here. Dig in.