With the ever-growing demand for exceptional real-time customer experiences, it’s no surprise that IT teams are turning to event-driven architecture (EDA) to unlock events and scale responses. EDA enables companies to build decoupled solutions that rely on real-time information and help businesses stay ahead of the competition. When EDAs combine with a service mesh, the solutions are even more powerful and reliable.
In this article, I will explain how integration architects combine service mesh and EDA, creating solutions that bring out the best of both approaches.
Companies have been using event-driven platforms like message brokers as well as SOA and API management solutions to enable communication between applications. However, often there are different IT managers responsible for EDA, SOA, and API platforms. With separate managers owning separate platforms, there is no single source of truth. Additionally, with this structure, there usually are no standard guidelines or methodologies for designing and implementing asynchronous and synchronous artifacts. This lack of standardization coupled with disjointed ownership makes it difficult to implement use cases where both async and sync capabilities are required.
The diagram below shows the standard synchronous pattern most companies follow to design and implement integrations following the request and response pattern, using either SOAP messages or REST APIs. In this pattern, applications invoke APIs published in an API gateway. That API gateway usually relies on a service bus (a middleware layer) that provides connectors that interact with the backends, in this case, an ERP.
However, the synchronous pattern is not enough to solve all the integration needs of the customers. For example, it is common that ERPs act as a master of several entities such as customers or products. Other satellite applications need to be notified when a change is registered in the ERP on those entities. In that case, companies use message brokers to design and implement asynchronous integrations, using patterns such as message queue, request and reply, or publish and subscribe.
In this diagram below, the ERP publishes a message in a topic using protocols such as AMQP or MQTT indicating that an entity has been notified. Several applications are subscribed to that topic and are notified by the message broker when the ERP publishes a change.
Although both integration styles are commonly used, modern architectures need a hybrid approach. In a hybrid approach, the same integration artifacts have to be able to work with synchronous and asynchronous messages, using the protocols that are a better fit for that pattern. These hybrid integration artifacts need a common life cycle model and common tools that allow maintenance and evolution of the documentation for APIs and messages.
Combining service mesh and event-driven architectures
To overcome the problems caused by several integration approaches, customers turn to service and event mesh architectures to design their integration solutions. These architectures rely on artifacts such as evented APIs which provide the ability to work in hybrid models where the consumer applications can either block a request and response interaction or be notified when a change is produced.
The following diagram describes a typical service and event mesh architecture:
In the diagram above, three different applications are using the same integration artifacts to interact with an ERP following different patterns:
- Application 1 uses a synchronous endpoint of an evented API to make a direct call to the ERP. For example, using MuleSoft Anypoint Platform, this pattern can be implemented with a System API that uses an ERP connector (SAP, Oracle E-Business Suite, etc.) to invoke a function in the ERP.
- Application 2 uses an evented API to register itself to be notified when the ERP publishes a message; that registration enables the consumer application to provide a callback or webhook that will be invoked by the evented API whenever there is a change. The ERP uses a message broker like Anypoint MQ or an event streaming platform like Kafka to publish a message. That message is read by a MuleSoft API using an Anypoint Connector. That API uses the list of registered callbacks to send to the consuming applications via HTTPS the messages published by the ERP. You can find the list of registered callbacks in the MuleSoft Object Store.
- Application 3 follows a simple publish and subscribe pattern, as it directly is subscribed to the event streaming platform. That pattern is common when the application is in the same cloud as the event streaming platform.
In addition, many customers are using service and event mesh architectures to implement other patterns like Command Query Responsibility Segregation (CQRS) that relies on a database model to update information and a separate one to read information.
Service and event mesh architectures provide the required flexibility that customers need to design hybrid integration artifacts that leverage different protocols and integration patterns to build evented APIs.
Main components required for service and event mesh architecture
The following components are helping customers to design better integrations using service and event mesh architectures:
- AsyncAPI: AsyncAPI is an initiative that enables the standardization of event-driven APIs. The AsyncAPI has several similarities with the OpenAPI specification, as its goal is to produce documents that are readable by humans and machines. AsyncAPI is protocol agnostic, so customers can use MQTT, Kafka, WebSockets, or other protocols with it. Recently, MuleSoft has added support for AsyncAPI in Anypoint API Designer.
- Event schema registry: Modern event streaming vendors provide tools that store and retrieve schemas in multiple formats such as Avro, Protobuf, or JSON Schema. Schema registries support versioning of the schemas, allowing its evolution while at the same time allowing existing consumers to use old versions of the schemas.
- Event taxonomy: Most event streaming platforms support topics so messages get routed to the appropriate consumers.
- Event portal: Similar to API portals, event portals can publish information associated with the events used in the organizations, enabling reusability. These portals expose information about the topics, the events published, the schemas they use, and more.
Modern companies rely on these tools to design asynchronous integration artifacts that are used to implement complex use cases with service and event mesh architectures.
Want to learn more?
If you want to learn more about evented APIs or service and event mesh architecture, we recommend you to take a look at MuleSoft Anypoint MQ, which is an enterprise-class cloud messaging platform, fully integrated with Anypoint Platform. Additionally, you can get started with service mesah and EDA on Anypoint Platform by signing up for a free trial.
