Posts Tagged ‘Cloud’

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]

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*

IBM MQ V9 – A fast, secure, reliable and more agile MQ

April 19, 2016

edwin-moses-getty_2129850b

Some of you reading this blog may recall the great athlete Ed Moses – who had a record 122 race winning streak in just about the hardest event – the 400M Hurdles. You need to be strong, fast, and agile just to compete, and to keep winning you need to be reliable. Well, this is how we view IBM MQ, especially with the latest release – IBM MQ V9. You may have seen a recent blogpost on here that had a Statement of Direction talking about a new way of delivering IBM MQ – one that provided a Long Term Support release, and a Continuous Delivery release. The aim of this model is to give customers more choice to select either highly stable releases with just fixes, or releases that benefitted from additional function in the fixpacks.

TRY IT: Click here to get a free trial of MQ

UPDATE: There is a FAQ on the new support model. Read it here.

On April 19th, IBM announced MQ V9 which is the first release that moves to this new more agile delivery model. As such at the initial release it delivers a small set of additional capabilities that will be available to all customers. Then subsequent mod-level updates will deliver even more updates to customers choosing the continuous delivery stream, but all customers moving to V9 will get the benefit of the new capabilities being delivered in this release.

As with previous releases of IBM MQ, customers have a lot of choice in where and how they may want to deploy this version. IBM supports deployment of MQ – and MQ Advanced pretty much on every commercial IT environment where business critical applications may be exchanging data reliably, securely, and at scale. This could be on-premise, deployed in cloud environments like IBM Softlayer, Microsoft Azure or Amazon AWS. IBM also supports virtualization with many customers deploying in VM images, and also in Docker containers, which can be deployed anywhere, including in IBM’s Bluemix platform. This flexibility enables customers to make use of enterprise messaging to support deployments on-premise, on cloud or in hybrid environments.

So what are the key new features of MQ V9 being delivered in this release? Well there are a number of them that are called out in the announcement letters – so you can read the MQ V9 distributed announcement letter here. And the MQ V9 z/OS MLC announcement letter here. And you can read the MQ V9 One Time Charge announcement letter here. But below I will call out a few of the features that I think will be most important to customers.

One of the features likely to be most interesting is a change to the MQ Client Channel Definition Table (CCDT), which is needed by the MQ Client application to provide the channel definitions needed to connect to the MQ Queue Manager. This file is created automatically and prior to MQ V9 needed to be distributed to the client application prior to use. The big change from this new release is that the CCDT can be a web addressable file instead of needing to be distributed out to every client, and to then need to do that with every change. By having a web addressable CCDT accessed by URI, then there are much lower administration needs, and also the MQ infrastructure can be much more dynamic as changes can be made centrally and take effect quickly and without application disruption.

 

The second big change to the new release of MQ is in MQ Advanced Message Security (MQ AMS). This feature, which is a priced extension to MQ (available either separately or as a part of MQ Advanced) provides policy based encryption at rest of the MQ message contents. By using this capability, businesses can be assured that their message contents can only be unencrypted and read by the targeted application destination, and there is no risk of exposure should any security breach take place which provides access to the system or storage where the MQ Queue Manager holds its queues. This privacy and integrity has been assured by the generation of asymmetric keys for every exchange between client and queue manager, which provides an extremely high level of security, but can introduce a high overhead in terms of the processor cost of the asymmetric key generation.

MQ AMS performance

With MQ V9, a new mode of operation is added to MQ AMS, called ‘Confidentiality’. In this mode there is an initial asymmetric key exchange then subsequent exchanges can reuse (to an extent that can be configured) a symmetric key. This still provides a high level of security and protection for the message content, but with a dramatically lower level of overhead in terms of encryption workload cost. IBM expects that due to the increasing importance of security and protecting systems and data from breaches, that this new feature of MQ AMS will help more customers protect their message contents and therefore their business and customer data. IBM expects to produce performance data for the new AMS configuration around the time that MQ V9 is generally available. But the early testing shows considerable improvement.

 

A further change for MQ AMS is the support of non-IBM JREs for use with MQ AMS. Previously applications written in Java that relied on a non-IBM JRE wouldn’t work with MQ AMS. In MQ V9 this has now changed so that suitable non-IBM JREs can be used, as well as IBM JREs, extending the ability of more customers to use MQ AMS.

 

There are a number of other new functions and capabilities available in MQ V9, such as updates to MQ Managed File Transfer capabilities – which are described in the announcement letter, and with the movement to a Continuous Delivery model customers should expect to see more capabilities being delivered in mod levels on top of MQ V9 in the future.

 

With the recent announcement of the End of Support for MQ V7.1 – announced here – along with the related end of support of the older separate versions of MQ FTE and MQ AMS, this latest release of MQ V9, along with the recent announcement of the update to the MQ Appliance provides customers with a strong set of choices of how to take advantage of the latest new releases as they plan to move off the older releases of MQ they may be using, keeping their deployment of MQ up to date and supported.

When you are taking advantage of the benefits of IBM MQ, you may not need to have to work as hard as Ed Moses did to be #1.

UPDATE: Mark Taylor has provided one of his highly useful videos detailing more of the new function in MQ V9. Watch it here.

 

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

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

Enterprise Messaging and beer – putting the fun into fungible

August 28, 2013

So how many articles or blog posts have you read that have something to say about Enterprise Messaging Middleware, yet also are about beer? This might be the first one, although that is probably a shame as certainly most coders I know like a decent beer every now and again, or perhaps more often than that. But the spark for this post was when I was putting the weekly shop away this weekend.

We order online from Ocado, and I had ordered a dozen bottles of real ale, which I do every 2-3 weeks. I don’t order any specific ones regularly, as I just see what is on offer and buy them. To me bottles of ale are fungible goods. On the whole most of them will be fine, so I will just buy whatever is on offer, and the next time I will buy whatever is on offer. Some I might like better than others, or might go better than others with a particular meal, but on the whole there is no reason, give the wide enough choice, to buy anything other than the ones on offer. Even if Ocado have to substitute on the delivery, pretty much anything will be fine.

But how widely does this this apply? Is everything fungible? Or is ale different? Does it help that we are only talking about items which are typically (on offer) 3 bottles for £5? How about messaging systems, given they are also close to my heart? There are certainly lots of choices in the market today. Some which are focused on the enterprise market. Some are focused for cloud deployments. Others make virtue about being open source, or standards-based, and so on. All in all we could probably imagine them sitting on a Supermarket shelf next to one another, with colourful packaging, trying to tempt you into making a purchase.

Let’s consider an example from consumer packaged goods again – tomato ketchup. There was an interesting article, from nearly 10 years ago in The New Yorker, on Tomato Ketchup, written by Malcolm Gladwell. He contended that Heinz Ketchup is an example of what is effectively a non-fungible product. A product that people would not want a substitution, as it is the only satisfactory option. He even compared it to other markets, such as mustard or pasta sauce which have been disrupted through greater choice, but nothing has done so to Heinz Ketchup – it was, in effect, a Platonic ideal product.

So let’s look at Enterprise Messaging. What is it there to do? Why do you use it to move data? You use messaging to connect your enterprise applications with reliability and security. You are probably looking to move the data without any noticeable delay, to keep your applications simple, and to ensure that it works well from a development and test point of view, but also as you scale up your production deployment, and offers you high availability in the form of a failure.

When Malcolm Gladwell was writing about ketchup he was able to give examples of people doing customer taste tests, of rival products which claimed to be better, of careful and scientific analysis, but the market has for years spoken clearly, and people just keep buying Heinz. There were some examples given of other sauces with different formulas, that people might like, but none of them has stood the test of time. Maybe there were flaws in their product. Maybe it didn’t have a good shelf life. Maybe it responded badly to heat, or cold. Maybe the flavour profile only really worked with some types of other foods, or clashed with typical meal drinks. Either way it is very difficult to beat a product which is actually that good in its market. A product that has stood the test of time. And yet they have undoubtedly evolved the product. I am sure it is lower in salt and sugar than before. And certainly I prefer the squeezy bottle to repeatedly hitting the bottom of the glass bottle. I personally have on occasions bought other ketchups – typically store own brands. But yet I choose Heinz. Would I like to have substituted product? No.

So does this have anything to do with WebSphere MQ and the Enterprise Messaging market? Well I would contend that just as Heinz has had to make ketchup that appeals to the widest possible set of people, eating the widest possible range of meals. And despite peoples’ appetites changing, they continue to be the top choice. And WebSphere MQ has been around for 20 years. If you look at the middleware message market, and customer needs over the years, then both have changed. But MQ has changed over the years. It still delivers the same ‘taste’. It is still used in the widest range of ways. And it is still the most widely deployed Enterprise Messaging product bought and deployed by companies all over the world. Is it fungible? If you are looking to move data around your applications in your enterprise, across multiple systems, multiple users, varying security requirements and your business needs to rely on this data being moved, knowing it has been moved once and once only, is this something you want to leave to chance? Would you be happy with any old messaging system? How fungible is your enterprise IT? I would suggest that at least with Enterprise Messaging, it is something you want to choose, and choose well. More and more IT systems are selling themselves as commodities. They are almost selling themselves on their lack of differentiation. And yet you have to know, when you are buying something, that you know what you are buying. Would you take a random selection of items in your shopping basket? Or do you want a choice? Would you deploy your IT to a cloud solution that has a random set of technologies, or do you want to pick the solutions that you actually want to run your business, whether on the cloud hardware or on-premise.

Not everything is as fungible as beer. Not everything is as tasty as beer either. But certainly there are no Enterprise Messaging Systems like WebSphere MQ. Image

A few notes on WebSphere MQ and Clouds

June 27, 2013

A bit of a different blog post from me – not directly about a new announcement but more a few notes on WebSphere MQ and deploying on private clouds and virtual machines.

Living in the UK where WebSphere MQ is developed, we are well accustomed to clouds, and rain. Wind too. Basically any weather that might ruin your plans to sit out and enjoy yourself, maybe have some friends round, and fire up the BBQ. However for pretty much everyone in IT, clouds now have a different meaning. One that many believe means the future of IT.  And if the future is coming, or indeed already here, how does WebSphere MQ help to connect applications and systems in clouds, just as it does for existing on-premise systems?

To explain this more, let’s narrow down what we are looking at, as the term cloud has a lot of different meanings for IT infrastructure. For now, let’s focus on the way many businesses are looking to make the most out of their existing infrastructure, as virtualized environments, or private on-premise clouds. Here there are substantial savings to be made if systems can be provisioned and made available more quickly with the right configuration, either for development, system test, or even for production. After all, these businesses have already invested in hardware, and it will not just frustrating to have it sat idle, but costly.

And it is not just frustrating and costly to have hardware sat idle, but doubly so to have invested in software such as WebSphere MQ, and to not have it readily available when you have an urgent need for a new system ready to go. And in these days of ever more pressing deadlines, alongside ever more capable software, you don’t want to have to install and then configure what might be multiple settings in the software to meet the specific needs of your deployment.

What you need is effectively a push button rapid deployment of your software – in this case WebSphere MQ, onto your waiting systems, to meet the dynamic needs of your business. With WebSphere MQ you can get just that – however you want it.

For example you might have seen the value in IBM PureApplication System which provides a flexible scalable system designed for transactional workload. We have a specific version of MQ – WebSphere MQ Hypervisor Edition, which is optimized for deployment into the virtualized platform offered by IBM PureApplication System.

WebSphere MQ Hypervisor Edition V7.5 is a packaged offering with the choice of either AIX or Red Hat Enterprise Linux Server as the operating system, which is deployed at the same time as WebSphere MQ itself – providing a repeatable deployment pattern for MQ to lay down as a clean image. What’s nice about this is that you can deploy the image, configure it how you want, and then recapture the same image. So that now, when you subsequently deploy it, you have got a tailored image to match your exact requirements, all deployed on a fresh Virtual Machine in around 5 minutes.

Note that you aren’t restricted to just capturing WebSphere MQ by itself. If you have license entitlement to WebSphere MQ Managed File Transfer Edition, WebSphere MQ Advanced Message Security or WebSphere MQ Telemetry, these can also be deployed, configured and recaptured for subsequent deployment. In this way, your virtualized environment can be configured and deployed ready for you to bring up a development, test or production instance at a moment’s notice. There is no faster way to get the complete messaging infrastructure you need when you need it.

Some of the benefits of taking the WebSphere MQ Hypervisor Edition as the offering to deploy into private clouds and virtualized environments are that you get the integration with the IBM Workload Deployer appliance or the IBM PureApplication System hardware. So if you are choosing either, or both of these, then using WebSphere MQ Hypervisor Edition in conjunction with them is great, both from an integrated deployment point of view and also from the license management that they provide. You then have an easy way to configure and capture tested WebSphere MQ configurations to meet your deployment needs at every stage of your application lifecycle.

However if you simply want to manage and deploy your own virtualized environments then you can do this by creating your own scripts to deploy the WebSphere MQ environment of your needs. Clearly this will require more skills and expertise than making use of the WebSphere MQ Hypervisor Editions, but for some virtualized deployment environments, this would be normal practice – aligning with the typical MQ administrator behaviour over many years. 

New post, new job role, long time passed

August 20, 2010

So just a quick note here. I changed roles earlier this year to move back into Product Management for WebSphere Message Broker after a number of years in Marketing. It is funny how both roles have similarities but also substantial differences. I am getting a lot more visibility to customers and sales reps in the new role which is really good, but am continuing to work closely with marketing to make sure we get the right material produced. Keeps me busy – and apologies to those who I respond to later than I should.

Was good talking a bit with Gartner earlier in the year on a couple of occasions – and hearing all the customer interest in cloud – not an area that will be going away in a hurry I think.

It has been very stimulating to work on strategy for both extending current offerings and looking at the opportunity in new segments. Lots I could say here but clearly not going to in public!

I plan to talk to some customers in Istanbul next month as part of a Hursley Comes to you event and there will also be more customer interactions in 4Q which i am looking forward to. All this while trying to get through all the Product Management day to day pieces of work – which I had better get back to.

Focus and prioritization are becoming the watchword….will try to write something more soon

Reuse, cross charging and the Cloud

July 1, 2009

One of the big topics of discussion at the Gartner SOA event in London last week was, unsurprisingly, Cloud Computing – it is everyone’s favourite hot topic this year. One session by Yefim Natis really focused on some of the implications of this – and before he started I made a couple of notes to myself to test as to whether he would answer them.

The first was whether Cloud could solve the cross-charging issue (I will explain this in a moment) and the second was whether Cloud would present a good opportunity for WebSphere Service Registry and Repository. Both of these issues were items that were nagging at me from listening both to clients in the Vendor showcase and also to other Gartner analysts.

The big one was cross-charging – Massimo Pezzini had addressed this as a critical issue to the future of SOA. There was a conflict of interest for those parts of the business who provided services. For the good of the business they were encouraged to make the business services they provided as reusable and shareable as possible. However then as their reuse grew as the uptake of SOA spread in an organization, who then was responsible for the costs associated with not just the initial work to create a reusable service but also then the increase in traffic as it became a fundamental part of multiple composite applications. The service providing department would become a cost center, faced with ever increasing costs and demands for improved SLAs. This could drive future work to be made highly specialized to avoid this issue, impacting the ability of SOA to really be successful.

Now in IBM we have always been keenly aware of the cross-charging issue, as this has always been important to our mainframe/System z customers. Our products such as WebSphere Message Broker, which functions as a highly capable ESB,  have therefore included capabilities to identify and charge users for their use of the environment. But of course in a Cloud – an elastic shared use environment – it is explicitly designed for resource allocation and tracking the user and use. Yefim in his session then proposed that deploying these shareable services in the Cloud, with its ability to track and charge for use could lead to these service providers being seen as profit centers instead of cost centers. Now being a profit center when providing internal services is one thing – moving money from one pot to another within a business does not a profit make. But combine shareable services in the cloud with a move to more dynamic multi-enterprise B2B, sharing the costs with partners, and some of the investment decisions can make sense, as well as streamlining your business connections and processes. A good thought for the future.

The other question I had was around WebSphere Service Registry and Repository (WSRR). I had talked to quite a number of clients at the show who were deploying, or starting to deploy assets connected to one or other of our ESBs – and they were trying to figure out whether this truly made them more dynamic. Of course it does simplify your connectivity to use an ESB but then are you just swapping one change regimen for another? I got a good response talking to them about using WSRR to hold each service step, and to search for the service location through WSRR rather than defining its location in the ESB flow – this allows for very simple updates and changes to services without any disruption to the running processes and ESB flow.

Now of course when the services are defined as ‘in the cloud’ this is the ultimate requirement for flexibility – they will never have a fixed location or definition  anywhere other than the cloud so use of a registry to store and locate these will be essential, as well as the other facets it provdes such as identifying rogue services and enforcing business policies. This says to me that when we are talking to our clients about using the cloud, we need to be sure to discuss the use of ESBs and also WSRR.

Lots to do. Should be interesting!

Attending the Gartner SOA/ADI event in London

June 29, 2009

It was nice to get out of the office/home office routine last week to visit the Gartner SOA/ADI conference – this was the second year I have been to this show and it is always worthwhile. The event seemed to be very busy with the keynote sessions pretty full and some very interested customers from all over Europe and beyond attending to listen to the sessions and also talk to the vendors attending – of whom IBM was one – as a premier sponsor. At pretty much the start of the event there was a vendor panel from the premier sponsors who participated in a quickfire session to review their thoughts regarding a number of Gartner predictions for the future – there was broad agreement with many of the thoughts, although there was a level of scepticism regarding whether the scale of uptake for some of the technologies would be as high as was contended. The state of the economy was judged to be a likely factor in IT change decisions – which is of course to be expected.

The other Gartner sessions I attended were certainly very interesting. A theme which seemed to run through the 2 days was the coming growth in multi-enterprise B2B driven by the need for e-invoicing. And the complexity and business risk associated with this will also drive the need for strong SOA Governance. SOA Governance was one of the key starting points for companies starting SOA implementations, but by far the most common starting point was an ESB – which of course makes a lot of sense as an ESB is a great boon to business whether it is part of a larger SOA deployment or simply looking to improve connectivity.

We had a great stream of different businesses coming to the IBM stand in the Vendor showcase. Due to the focus of the show, all were highly knowledgable about middleware and many were already WebSphere customers, involved in projects, either at early stages or deploying. I had a number of discussions with almost everyone about whether they use FTP as a part of their existing infrastructure, and whether the new WMQ File Transfer Edition product could be of benefit to them – we got some encouraging interest.

Also a popular discussion topic was our WebSphere DataPower appliances – they of course have many uses throughout the enterprise and I had involved discussions about what benefits they provided depending on the type of deployment and where they were being used. And finally an interesting topic for discussion was the brand new WebSphere Cloudburst appliance – there is huge interest in Cloud and this seems a very timely and innovative solution for customers. Hopefully next time we will have a box on display!