April 25, 2016 | Written by: Valerie Lampkin
Categorized: Community | Compute Services
Share this post:
There’s a lot of buzz these days about microservices. The microservices architectural style allows large, complex software applications to be composed of smaller services, which each focuses on completing one business task. Loosely coupling these tasks together creates a microservices architecture.
In today’s cloud environment it is desirable to implement a microservices architecture for many scenarios. Moving away from monolithic applications to a coalition of smaller collaborating applications requires a way for these small discrete microservices to communicate with each other. This is where messaging can help. By decomposing your application, actually breaking it down to components, it keeps the services modular and scalable so that they are easier to debug.
Using Messaging to Connect Microservices
Messaging is a critical component to the application development world, enabling developers to break down an application into its components, and loosely couple them together. Messaging supports asynchronous coupling between the components, with messages sent using message queues or topics.
A messaging publish/subscribe pattern reduces on unnecessary linkages and network traffic between applications. Rather than having to use the frequent REST polling calls, the application can sit idly until the message is published to all of the interested (subscribed) parties. At that point, the subscribed application receives the message. In essence, rather than using a REST “are we there yet” call, the subscriber gets a “shoulder tap” to indicate that the message they want is available.
In a publish/subscribe topology, the publishing application sends a message to a destination, often a topic string. The ability of the publisher to put the message is not dependent on subscriber applications being accessible. The message broker acts as an intermediary, and is responsible for delivering the message to every subscriber.
At any point in time, a subscriber could be unavailable. Message brokers can retain the message until a subscriber is able to consume it. The level of message delivery assurance is handled by the quality of service (QoS), such as at most once or at least once.
Plan for Growth of the Application
An important advantage of using message queues in your project is feature growth. What begins as a simple application can easily grow into a massive app with a barrage of new features. A fairly straightforward app gets more complex as new requirements arrive, and you need a simple way to add those features with the least disruption to the current application.
Because messaging helps decouple the components of an application, a new application feature can be written to use messaging as a means of communicating with the existing application, and not require changes or downtime for the main application when the new feature is deployed.
Extend On-premise Enterprise Applications
Alternatively, you might have a large monolithic application that is part of your systems of record, and you want to extend your enterprise and focus on integrating systems of engagement. Messaging can be instrumental in integrating the existing systems with new front-end features, by enabling communication between the two without the need for both applications to be running on the same platform or written in the same language.
Many existing systems might already employ some type of enterprise messaging system. Therefore, an optimal design for a new microservice would be one that employs messaging that can be tied into the existing system and communicate with its existing enterprise messaging system.
Some common implementation scenarios for using messaging would be event notification and worker offload:
Event notification and worker offload
As an example, a stock broker application publishes price updates to a set of trading applications in an event notification scenario. The messaging broker manages the storage and distribution of the messages to each interested application. The subscriber does not have to send individual requests, it just subscribes for the topics that it wants, and when those messages are published, they are delivered to the subscriber.
Example: Event notification for stock price
Another example of messaging would be a web application that needs to process work while being responsive to the front-end users. When an application has intensive work to be done, it can be offloaded and distributed among worker processes to be performed asynchronously.
Several instances of a back-end worker application could exist, enabling the web application to send a work request for processing by one of several worker application instances. Messaging helps implement a worker offload scenario in this case, distributing the work among the worker applications and, if the load increases, additional worker applications can be created without the need to alter the web application.
Messaging helps make applications more flexible by enabling the separate microservices to process asynchronously. Incorporating a messaging service in your microservices design can help ensure that applications remain responsive even when another system is not available or responding fast enough.
The IBM MQ Light service in Bluemix is a fully managed cloud service, so all of the operations activities, such as maintenance, availability, and upgrades, are part of the Bluemix service.
Want to learn more about microservices?
For more information about microservices and MQ Light, check out the IBM Redbooks publication Microservices from Theory to Practice: Creating Applications in IBM Bluemix Using the Microservices Approach. Chapter 2 of this book gives details of how to design microservices incorporating messaging. The publication also provides real-life examples of how you can develop applications using the microservices approach with IBM Bluemix.