Messaging is a key element of application development. Whether you are adopting a monolithic or microservices approach, your applications need to communicate with each other and to fit into a wider architecture.

This article looks at how messaging can help you as you write your applications. It also discusses how the advantages of using messaging in your applications apply in the context of a microservice framework.

The decoupled nature of a microservice architecture

Modern application development often uses a microservice architecture, where an application is a collection of microservice components that can be built by independent development teams. Each microservice can be deployed, scaled, and maintained independently. In addition, these applications often follow principles such as the twelve-factor methodology to build a cloud-native application. A central pillar across twelve-factor and a microservice architecture is the decoupled relationship between the microservices within the application. Ideally, this decoupling should enable:

Independent development. Developers can create the microservices in isolation. Each development team should declare an interface for communication with their microservice. This interface acts as a contract, leaving the teams free to change the internals so long as they do not break the contract.
Independent availability. Each microservice should have its own separate runtime such that the availability of one microservice cannot not impact the availability of other microservices. This limits the downstream impact of a failure.
Independent language runtime. When each microservice has its own runtime, the owning team can choose the most suited runtime type for their requirements, such as Java, GoLang, .Net, Node.JS, or C.

Communication between microservices

The communication between microservices needs to enable decoupling by providing:

Implementation independence. Certainty that the connectivity between the microservices hides the underlying implementation.
Broad connectivity. The ability to connect across a wide range of programming languages.
Decoupled communication. An intermediate “store and forward” capability, allowing the communication between microservices to be decoupled from the target’s immediate availability.

Technologies such as REST HTTP APIs provide the first two benefits, but there is no built-in capability for “store and forward” and therefore they do not provide decoupled communication. This decoupled communication is where messaging technologies such as IBM MQ excel, by providing a buffer between microservices that assures the independent processing of the other microservices. (You can read more about when to use APIs and messaging, in this article.)

Successful microservices deployments using messaging technology

For a successful deployment, developers need to consider several additional aspects of the decoupled communication between microservices within the application:

Scaling and workload management. You’ll need to scale the microservices to meet the ever-changing workload demands of the business.
Error Handling. You’ll need to code for the various error conditions.
Security. You’ll need to make sure that the communication between the microservices is protected.

Messaging technology addresses these concerns:

Pull instead of push workload management. A messaging provider sits between the two communicating microservices. The workload management moves from a push model, where the processing microservice receives work to complete, often independent of its current workload capacity, to a pull model, where each instance of a deployed microservice pulls work when it has the capacity to handle it. This avoids overloading instances and assures all instances are being utilized effectively.
Simplified error handling by using assured delivery. Many messaging providers provide assured delivery, where a message will be received at least once (or exactly once for IBM MQ) by the target microservice. This can be incredibly valuable for eventual consistency patterns. Applications do not require extensive error handling logic to verify that a target microservice has completed the work, but instead it will be processed once the microservice has availability.
Configuration-based security. How to secure the communication between microservices is continuously changing to assure greater levels of protection. For instance, TLS 1.3 is becoming an industry standard. Developers do not want to code security directly into their microservice but want it externalized in configuration. This allows the microservice to be configured based on the business requirements, rather than individually and perhaps inconsistently. For example, transport-level encryption may be the current focus, while a few months later message-level encryption may also be required. By setting security in the configuration, this update is easier to add in across the microservices. Messaging technologies such as IBM MQ externalize this security configuration for developers, allowing it to be updated transparently from the application logic.

Summary and next steps

Developers face pressure to assure they are producing enterprise-grade applications in an agile way, to support the ever-changing needs of the business. To be able to respond, they need to reduce their responsibilities and assure they are selecting the right technologies to scale their application in a cloud-native era. Messaging is the decoupled, flexible, and secure communication pipe for microservice architectures.

Now that you’ve learned all about enterprise messaging, you’re ready to learn how to build powerful messaging applications with IBM MQ in the IBM MQ Developer Essentials learning path.

How messaging simplifies and strengthens your microservice application

How messaging simplifies and strengthens your microservice application