Particularly in the mobile market, businesses are under growing pressure to release applications more quickly to satisfy consumer demand, and the ones that invest in new innovation and development capabilities see a rise in revenue, positive brand recognition, and, of course, customer satisfaction.

The results of a recent global study commissioned by CA Technologies (CA)—which surveyed 1,450 senior business leaders across 13 countries—show that while line of business executives are aware of the importance software and application development plays on their future success, only 15 percent are completely satisfied with IT’s speed in delivering new applications or services.

When developing applications quickly, success is contingent on efficiently joining application components together, ensuring it’s scalable, and being able to process and implement user feedback from the onset, says Alan Chatt, Product Manager for cloud and application messaging, IBM. 

The key to all of these is messaging. IBM has developed a new lightweight messaging solution, MQ Light V1.0, that provides a simple messaging API that developers can easily install, configure, and use to quickly write and push out proof-of-concept applications. Insights Magazine caught up with Alan Chatt to find out more about this solution and how it can make applications more responsive and easier to scale.

Insights Magazine: What were some of the driving factors in the decision to create MQ Light and what are the main goals of the product?

Alan Chatt: MQ Light came about for a couple of reasons, really. First off, it’s worth noting that already, as IBM we have IBM MQ, which is probably the best and most widely-used massaging engine within the enterprise. We were noticing is that a lot of the new projects that developers are involved in are driving and leading in an enterprise, and that they were creating applications that were ideas—something they needed to prove a concept and get it out into the market, and just prove that an idea worked. In order to do that, developers were picking up whichever tool was easiest to get a hold of or picking technologies with easily findable, blogged examples—and that’s not to do them a disservice, that’s certainly the quickest way for them to get their idea into something tangible and real that they could then test.

Get insights delivered to your inbox every week. Subscribe to our free newsletter. 

What that meant was, when these ideas took off, they were left with the decision to either rewrite the application entirely to make use of investments the company already made in terms of MQ or other software, or set up an entirely new operations team. And it became a real crunch-time issue. Neither option was a particularly good option. We realized we had to create a messaging product that would be incredibly easy for developers to get a hold of, get going with, and had APIs in all of the languages that now are becoming increasingly popular. We had to focus MQ Light on ensuring that someone who was actually creating an application that uses MQ Light, that they had everything they needed while developing. We didn’t want anything getting in the way of [developers] going from the idea to something that worked, so we focused on API and the development tooling for MQ Light.

IM: What are the key differences between MQ and MQ Light?

Chatt: MQ Light is fantastic for getting these kinds of [pilot] projects off the ground, where you know you need a bit of messaging. But when those applications become either more complex or place more demands on the infrastructure in which they depend, then MQ will be the right messaging backbone to run them against. Hence there was a statement of direction that we made with the release of MQ V8.0 that said that in the future we will be supporting the MQ Light API directly into an MQ manager. What that means is that you will be able to take that application you created and prototype and pilot it using MQ Light, deploy it directly against an MQ team manager, once we release those capabilities.

MQ is a really good messaging backbone; it’s fantastic for linking together disparate systems within your organization belonging to different lines of business and doing that in a very reliable and robust way. The focus on MQ Light is really on taking an application idea to something that is actually prototyped. So, in terms of MQ Light, the first thing that is important to application developers is the API. So we’ve focused on having an API that is incredibly easy to get started with in terms of the number of lines of code that you need to write in order to incorporate into your application, as well as making sure the API is available in the locations that you’d expect it. For example, if you’re a Node developer, it’s in the Node package management, so you don’t have to go outside where every other library that you’re going to use exists.

The second thing that we’ve focused on it’s the UI [user interface]; the actual tooling that’s going to help you develop your application. Rather than being just a straightforward way of monitoring MQ Light, the tooling is designed to help you while you're developing—helping you understand the data messaging that is occurring during development. It’s designed for the development phase. Finally, we’ve really focused on not only getting a hold of MQ Light, making sure it’s much easier than a traditional IBM product, but also the getting-started experience. Just the working out what you’re supposed to be doing, the installing, etc. What we’ve aimed for is getting the interface up and running and doing the tutorials in 5 or 10 minutes. It’s that type of experience that we wanted to hit with this initial release of MQ Light.

IM: The IBM MQ Light API will run on three platforms, including Bluemix. What considerations should developers make when choosing which direction is right for them?

Chatt: So, you can either run your application against MQ Light, directly on your laptop—that kind of unzip-and-go that is available on the website—you can deploy it against an existing IBM MQ network, like we’ve talked about; or, within IBM Bluemix—amongst all of its services, there is the MQ Light service as well, so you can also push that application into Bluemix and have it running in the cloud against a robust, scalable cloud messaging service that is the MQ Light Service. Bluemix is a place you could develop your application, but it’s a fantastic place to deploy your application too. So the range of deployment options is another key feature that we think is particularly appealing, especially to the type of developers that we started talking about at the beginning.

MQ Light is great for when you just need to get your application done and to a point to where you can actually demonstrate it. When that time is critical to you, MQ Light is fantastic. By using messaging in the design of your application, it will help ensure that your application is done to scale and the initial pilot can get out as soon as possible. It also means you don’t have to worry if you decide after a few months that this is going to be more critical to you, maybe it requires a more scalable or more available infrastructure. It doesn’t matter that you started in MQ Light. You can move to MQ. That’s one of the questions we wanted to help developers avoid; choosing one way or another.

MQ is great if you are building an application that you know is going to connect straight onto an existing MQ background. But when you are looking to get a prototype or proof of concept out as quickly as possible, MQ Light is most definitely your friend in that situation.

IM: Why is this kind of data messaging so critical to the application development world?

Chatt: The value that messaging brings to a project like that is, when you are developing your application, in order to make it scalable, you need to break it down into its components and loosely couple them together. From a developer point of view, it’s relatively easy to write an application as one big, monolithic piece of code—and it might work great if you are doing it from your laptop, but what is often found, when you put that into an early prototype or early production system and get real users using it, is that it’s common for that monolithic application to get snowed under with requests really quickly. This bogs down the application, and the next user comes along and gets a bad user experience because your application is still trying to deal with the first user’s request. The best case is you end up with a really slow application; worst case is the whole thing comes to a grinding halt and those early users of that application get put off and they never come back again. By decomposing your application, by actually breaking it down to components, it keeps things nice and modular and scalable that is easy to de-bug, and when it comes to deploying your application, you can scale up each individual component on its own, depending on how it needs to be scaled, without having to worry about how it will impact the rest of the system. The final thing is, if you are working on a team and one of you is a fantastic Ruby developer and you want to work in Rails for your front end and someone else is working in Java, then using messaging to hook those parts together means that you can actually work together yet have a consistent way of communicating between the components of your application. So it really helps teams collaborate around producing an idea without restricting them to just one language or one framework.

IM: This release has been in a closed beta since May. Can you give an example of a use case for MQ Light? 

Chatt: People have been shy coming forward with comments and feedback on our forums. We know an awful lot of people have been following what we’ve been up too and are very interested on how it might fit within their enterprise. It’s fair to say people are taking their time to play with it and experiment with it. I know that a number of our [clients] have found it incredibly useful to incorporate [MQ Light] into a series of demos of an event-driven application, etc.—something that would normally take a few days to set up, they are getting it up and running in a matter of minutes. The other thing we see a lot of benefit in is, we call it a worker-offload use case, but essentially this is a way of structuring your cloud-based applications such that you can take all of the work away from your work front end so the actual application itself remains really responsive to end users, and you can do things like image processing or video processing or just uploading any kind of external direction. All of that work can get put on the queue and handled at some point in the future. We find that kind of usage pattern is what people are exploring. A lot of that is happening in the cloud just because of how easy it is to deploy these kinds of micro services.

IM: As IBM continues to develop this MQ Light product, what should clients expect to see in the future?

Chatt: For one thing, the languages will expand over time. Rather than rush out a ton of different APIs for different languages that we don’t necessarily have a complete understanding of ourselves, we are taking our time to develop the APIs that I am working with people in the first case—Node developers—to make sure the API looks and feels native within the Node language. I am proud of the reception by experienced Node programmers. We have, currently on the website in the form of blogs, details on PHP Pipe and Rudy APIs that we are working on. Also, we have details on how you can take the standard Apache QPID Proton clients and actually connect those to MQ Light. At the moment it’s possible to connect to almost any language that has an open source client into MQ Light. And we are working on a dedicated API for the most popular languages, like Ruby, PHP Pipe, and Java, and releasing that soon.

We are very much adopting a continuous delivery model for MQ Light, so we are looking to have an ongoing beta, early access development code available through the community site, as well as the supported GA levels. Straightaway we will be releasing what is coming next, which is open beta, early access drivers—both to see the supportable level that you can work against or take a look at early access versions so you can see what enhancements we are working on and give us feedback as we are actively working on them. We are hoping to build a community around this.

So far it’s been a relatively quick development schedule, which is indicative of how we want to continue to develop MQ Light. We want it to be done openly so people can see what we are working on, if there are any particular features they see they can talk directly to the development team and also comment on what we have released so far.

To learn more about this MQ Light release, sign up now to attend an upcoming webcast on Tuesday, Sept. 30 titled, Make applications responsive and easier to scale: Introducing IBM MQ Light, and hear directly from Alan Chatt.

Read more about this topic—visit the Global WebSphere Community and check out IBM’s MQ Light blog.

Comments

20 Carematrix Drive, Dedham, MA 02026, USA | Sales and Customer Service: 1.781.751.8799 |

Copyright © 2014 Wellesley Information Services. All rights reserved.