The Microservice Adapter pattern allows adding missing features, adapting one system to another, or migrating an existing application to an event-driven architecture model, to name a few possibilities. The Microservice Adapter pattern is similar to the Adapter pattern we cover in Chapter 9, Structural Patterns, but applied to a microservices system that uses event-driven architecture instead of creating a class to adapt an object to another signature.In the scenarios we cover in this section, the microservices system represented by the following diagram can be replaced by a standalone application as well; this pattern applies to all sorts of programs, not just microservices, which is why I abstracted away the details:
Figure 19.33: Microservice system representation used in the subsequent examples
Here are the examples we are covering next and possible usages of this pattern:
- Adapting an existing system to another.
- Decommissioning a legacy application.
- Adapting an event broker to another.
Let’s start by connecting a standalone system to an event-driven one.
Adapting an existing system to another
In this scenario, we have an existing system of which we don’t control the source code or don’t want to change, and we have a microservices system built around an event-driven architecture model. We don’t have to control the source code of the microservices system either as long as we have access to the event broker.Here is a diagram that represents this scenario:
Figure 19.34: A microservices system that interacts with an event broker and an existing system that is disconnected from the microservices
As we can see from the preceding diagram, the existing system is disconnected from the microservices and the broker. To adapt the existing system to the microservices system, we must subscribe or publish certain events. Let’s see how to read data from the microservices (subscribe to the broker) and then update that data into the existing system.When we control the existing system’s code, we can open the source code, subscribe to one or more topics, and change the behaviors from there. In our case, we don’t want to do that or can’t, so we can’t directly subscribe to topics, as demonstrated by the following diagram:
Figure 19.35: Missing capabilities to connect an existing system to an event-driven one
This is where the microservice adapter comes into play and allows us to fill the capability gap of our existing system. To add the missing link, we create a microservice that subscribes to the appropriate events, then apply the changes in the existing system, like this:
Figure 19.36: An adapter microservice adding missing capabilities to an existing system
As we can see in the preceding diagram, the Adapter microservice gets the events (subscribes to one or more topics) and then uses that data from the microservices system to execute some business logic on the existing system.In this design, the new Adapter microservice allowed us to add missing capabilities to a system we had no control over with little to no disruption to users’ day-to-day activities.The example assumes the existing system had some form of extensibility mechanism like an API. If the system does not, we would have to be more creative to interface with it.For example, the microservices system could be an e-commerce website, and the existing system could be a legacy inventory management system. The adapter could update the legacy system with new order data.The existing system could also be an old customer relationship management (CRM) system that you want to update when users of the microservices application execute some actions, like changing their phone number or address.The possibilities are almost endless; you create a link between an event-driven system and an existing system you don’t control or don’t want to change. In this case, the microservice adapter allows us to follow the Open-Closed principle by extending the system without changing the existing pieces. The primary drawback is that we are deploying another microservice that has direct coupling with the existing system, which may be best for temporary solutions. On that same line of thought, next, we replace a legacy application with a new one with limited to no downtime.
