Posts Tagged ‘Docker’

Trying to contain your excitement – IBM MQ and Containers

November 30, 2018

Screenshot 2018-11-30 at 10.09.23

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

Screenshot 2018-11-30 at 10.07.52

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

Screenshot 2018-11-30 at 10.12.41

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

 

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

 

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

Screenshot 2018-11-30 at 10.13.38

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

 

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

 

Screen Shot 2018-07-27 at 15.30.23

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

Next steps might involve downloading container images here.

Or reading more about MQ and containers here

Advertisements

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.