Posts Tagged ‘IBM Cloud private’

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

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

September 18, 2018

IBM Clock 2

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

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

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

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

 

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

 

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

Money-cloud

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

 

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

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

 

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

 

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

IBMShippingContainer

Everyone gets the point. MQ V9.1 delivers the latest features in a Long Term Support release.

July 3, 2018

Screen Shot 2018-07-03 at 09.42.14They say anticipation is half the fun. And one of the good things about the split release approach for MQ with Continuous Delivery releases and Long Term Support Releases is that as new function is developed and made available in the CD stream, customers intending to use the LTS release can build their anticipation for the new function for up to 2 years.

 

Of course, there is nothing to stop early experimentation with the CD releases even though you may be waiting for the LTS availability. But the good news is that the wait is now over and IBM has published the announcement letter for MQ V9.1 and MQ Advanced on distributed platforms here. Also MQ V9.1 is being announced for the MQ Appliance, as well as a new model of the MQ Appliance – the M2002. You can read that announcement letter here, and a blog about it here. Also we have announced MQ V9.1 for z/OS – there is an announcement letter here for the MLC offering, and another announcement letter for MQ Advanced for z/OS VUE and other z/OS OTC offerings here.

 

Has it been worth the wait? What has been the most anticipated new capability? It’s not like a Christmas present where you are not sure what’s under the tree. Almost every feature, function and enhancement in MQ V9.1 has been already available in one of the CD releases, so there shouldn’t be much of a surprise. You can read some of my past blog entries covering the prior V9.0.x releases (V9.0.1, V9.0.2, V9.0.3, V9.0.4, and V9.0.5)

 

And don’t forget than the previous LTS release – MQ V9.0 included important updates that have proved very useful such as the enhancements to MQ AMS providing end to end encryption, including encryption at rest without performance impacts, which can be very helpful in addressing GDPR requirements.

 

However, let’s cover here some of the most interesting areas of focus over the last couple of years of function, and which ones seem to have attracted the most customer interest.

 

There are many different areas of enhancement, which hopefully means pretty much all users have something to interest them.

Screen Shot 2018-07-03 at 09.52.28

Simple and more powerful Administration

  • MQ Console – a customized browser based for configuration and operations
  • REST API for admin – an extensive set of APIs enabling new tools to be written using REST HTTP calls, usable across older releases as well
  • Improved awareness of MQ activities and logging – Publishing MQ statistics to Prometheus and Grafana; forwarding MQ error logs to ElasticSearch or Splunk; Error logs output JSON for improved parsing
  • Automation of Linear Logging – simplifying the operations and administration of logging and management of those logs.

 

Supporting Developers

  • REST API for messaging – Enabling developers writing simple applications and micro-services to access MQ capabilities.
  • Additional API and protocol support – as well as publishing a new online tutorial for using MQ
  • Connecting to Salesforce – the MQ bridge to Salesforce allows for the 2 way publishing of information between SalesForce and MQ
  • The MQ Bridge to blockchain – only available for MQ Advanced or MQ Appliance customers.

RDQM1

High Availability and Disaster Recovery without complexity and cost

  • Replicated Data Queue Managers for HA – synchronous replication across 3 nodes using local disks instead of network attached storage.
  • Replicated Data Queue Managers for DR – manual failover with synchronous or asynchronous replication across 2 nodes.
  • RDQM requires MQ Advanced licenses. But with specific licenses to reduce cost.

 

Managed File Transfers

  • Licensing, packaging and pricing changes. MFT Agents are now free with MQ Advanced or MQ Appliance, and both embeddable and redistributable.
  • FTP Protocol Bridge enhancements
  • Improved reliability and monitoring for Transfers

 

 

z/OS enhancements

Many of the updates described above also apply to MQ on z/OS. There are also some additional enhancements specific to z/OS

  • AMS Confidentiality Performance. MQ Advanced for z/OS VUE sees enhancements in performance of this feature in MQ V9.1
  • Extended deployment for MFT – with MQ Advanced for z/OS VUE.
  • The MQ Bridge for blockchain now using the Hyperledger Composer API to build out the connectivity.
  • Connecting CICS and MQ – Java programs running on a CICS Liberty JVM server can now use MQ classes for JMS to access MQ capabilities.

 

AS MQ now moves to MQ 9.1, this time the point is available for everyone. All the features above, and more I haven’t had a chance to describe will be available later in July 2018. Whether deploying in on-premises environments, on physical Appliances, on VMs, in containers, on private clouds like IBM Cloud Private, or public clouds like IBM Cloud, AWS, or Azure, the Long Term Support release now means the 2 years of functional enhancements, tested already in multiple Continuous Delivery releases are now available for more to use.

UPDATE: MQ V9.1 now available as of July 23rd 2018. Read more here.

And there is plenty more to come. Watch this space both for more updates and use cases of these features, and well as future updates in the next Continuous Delivery releases.

Putting out a new release like IBM MQ V9.0.5 is more than a 9-5 job

March 16, 2018

9-5clocks

At least in the UK, the traditional hours worked in a day job were 9 to 5. You would ‘clock-in’ at 9am and leave at 5pm. I guess it is common as there was a 1980s film called “9 to 5” starring Dolly Parton. These days office life is rather more flexible, and certainly the idea of clocking in and out at fixed times is gone.

 

For 25 years, virtually every major IT infrastructure has been able to rely on the secure and reliable exchange of data between applications and systems thanks to IBM MQ. Previously called MQSeries, then WebSphere MQ, this software offering, developed in the IBM Hursley Lab in the UK has been a critical part of the business world. So much so that most people living their lives have no idea they use IBM MQ so much on a daily basis as it ‘just works’.

 

There is a great team of developers who work hard day-in and day-out to enhance and update IBM MQ, and . We have now released IBM MQ V9.0.5, going GA on Friday March 16th. And our developers have worked for months, giving up evenings and weekends to not just add new features, but to make sure it is another offering that works when put into use. So not 9-5 at all.

 

Now for some customers this will be more of a prelude to the main act. This is referring to V9.0.5 being a Continuous Delivery release. When we brought out V9.0 we split it into 2 streams: Continuous Delivery and Long Term Support. This release marks the final release in the initial set of Continuous Delivery releases. The next release will be the first of a new Long Term Support release. And customers can expect that the functions delivered in the 5 CD releases will be made available in the new Long Term Support release.

 

When that new LTS release is available, you can expect me to summarize all the new features, but for now in this blog I will call out a few of the new features in V9.0.5.

 

The new Easy HA feature (Replicated Data Queue Managers) delivered in MQ Advanced V9.0.4 gets updated to add support for a Disaster Recovery mode, with manual takeover after either synchronous, or asynchronous replication between a pair of MQ servers.

 

The MQ Managed File Transfer capability, available with MQ Advanced or MQ Appliance gets the first support for the REST API admin interface for listing current transfers and querying MFT Agent status.

 

MQ Advanced itself will do more to identify itself when it is installed, and so prevent compliance issues, and ensures that components can recognize Queue Managers.

 

Other updates include a MQ Console refresh, and for customers who use MQ with WebSphere Application Server, performance enhancement through implicit syncpointing.

 

For MQ Appliance users there is an enhancement for better reliability by allowing aggregated IP interfaces for the Floating IP feature. This removes a potential single point of failure.

 

And for users of MQ Advanced for z/OS Value Unit Edition there have been improvements including enhancements to MQ AMS which will see increased performance.

MQ clouds puttenham

Perhaps even more exciting is the new availability of a hosted instance of MQ on the Cloud. More about this can be found here, but it creates a great opportunity to quickly and easily make use of MQ without needing to install, deploy or manage the environment. Just configure and go! Nice that after 5 years of talking about it on this blog we have an explicit offering running in the cloud. This is of course alongside MQ already being able to run in AWS as a QuickStart. Or deployed as containers in IBM Cloud private.

 

As well as looking forward in the future to a new Long Term Support release, the statement of direction indicated that the Blockchain bridge, available in MQ Advanced, will be updated to be based on the Hyperledger Composer interfaces. And additionally, customers deploying MQ in containers will in the future be able to track the size of the container, and the duration of use, and license based on that container size, rather than the full capacity of the system where the container is running. The intent will be to support existing pricing metrics such as PVUs and VPC monthly metrics, but also a future VPC Hourly metric.

ibmthink

IBM MQ, along with many other IBM and business partner solutions will be some of the highlights discussed at IBM Think in Las Vegas running March 19th-22nd. I will be there and I hope to see some of you there as well. Famously Las Vegas never sleeps, so I guess that’s something else that’s not 9 to 5. Lucky we have IBM MQ V9.0.5 now though.

9to5dolly