Looking at the Reactive Manifesto From an Enterprise Integration Perspective
Let's look at the Reactive Manifesto from an enterprise integration perspective.
Join the DZone community and get the full member experience.Join For Free
With the adoption of Cloud and Cloud-native architectures, application integration has changed. Support for multiple devices, channels, and making the architecture responsive is one of its key tenets. APIs are the key to this. Being application-agnostic and based on web standards, APIs are invokable across channels and serve to decouple the components. An API Management layer helps in security and performance through configurable policies.
There is no longer a central middleware component that does the integration, rather the architecture is distributed and loosely coupled, helping realize the goal of it being elastic. Containerized microservices and integration components are invokable separately resulting in them being more resilient than if they were a single monolith.
The microservices are either invoked through APIs or are message-driven; triggered on the arrival of events as messages. Distributed transactions in microservices are realized without a central orchestration component through the SAGA pattern using the messaging layer for choreography. A Service Mesh enables discovery and security between Microservices by adding a sidecar proxy to them. It also helps in circuit breaking to ensure responsiveness and monitoring of microservices. The Service Mesh is powered by a container orchestration platform that is Cloud Native and portable across environments.
Monitoring the solution is not just about checking the health of the middleware and microservices but to enable Observability by providing insights and helping prevent any issues that may occur due to performance or other reasons. DevSecOps makes us of the monitoring capabilities along with providing developers a seamless path to Continuous Integration and Continuous Deployment (CI/CD). Security is part of development and not an afterthought; whether it be the roles of accessing the services or encryption of data, it is all thought out from the early stage of the lifecycle. Alongside the source control repository, the container registry is used to store and distribute images of services.
There are various products available that can be used to implement the integration architecture described. When building from scratch, it is recommended to choose Cloud-native products, as these harvest the benefits of the Cloud better. Cloud-Native Computing Foundation has a list of graduated and incubating projects that contain products that can be evaluated for the layers in the architecture. By choosing products that help in implementing the tenets described, the goal of having an integration architecture that is also reactive would be realized.
“The views expressed in this article are mine and my employer does not subscribe to the substance or veracity of my views.”
Opinions expressed by DZone contributors are their own.