Delivering Integration as a Microservice in a Container
Integrations in a monolithic stack bring all sorts of issues that can be solved by utitlizing the singular properties of microservices.
Join the DZone community and get the full member experience.Join For Free
Traditionally, when a product is integrated with another product the logic of integration is hardcoded into the integrating product. If there is a change in the integrated product, the integrating product is impacted resulting in a new release or patch even when the product’s core functionality is not changed. Also, since the integration logic is part of the core product, it cannot be reused by any other product that requires a similar integration.
Challenges with existing integrations:
- Tight coupling of the integration code with the core products
- No reuse resulting in effort duplications
- Difficult to maintain as the core product will be impacted when there is a change in the integrated product or a new version of the target product needs to be supported
- Usage and health of the integration are not tracked
- Conflict of libraries used by core product and libraries required by integration logic
Product companies require smart integrations that address all the above challenges so that the integrations are developed faster and reused across products.
Integration as a Microservice
Traditional integration challenges can be addressed by developing the integrations as a microservice following the microservice architecture.
What is the Microservice Architecture?
Microservice architecture is an architectural style in which complex applications are made up of small, independent, reusable components called microservices. Microservices run as independent processes and communicate with each other using language-agnostic APIs like REST.
The picture below shows the difference between traditional monolithic architecture and the microservice architecture.
Monolithic architectural design has all the features bundled in a single application, whereas in microservices architecture each feature is deployed as a separate process.
Microservice architecture recommends breaking down a complex monolithic application into small microservices based on the functionality so that each microservice can be developed and maintained separately. Also, each microservice can be scaled separately based on its usage. A microservice, built to provide a functionality, can be reused by any product that requires the same functionality. For example, “Integration to Service Desk” is a common functionality that is required by most of the products in an organization. Integration microservices can be reused by other products with similar needs.
Each microservice internally has multiple layers similar to a monolithic application except that it has the code only for a single feature and fewer lines of code in each layer compared to a complex monolithic application.
API is the key layer of the microservice that exposes the core functionality it supports. Microservice salso expose the operational metrics (health and usage) as the API. UI is an optional component of the microservice and it is completely driven by the API exposed. A microservice has its own dedicated data store and it can have integrations to other microservices and external products.
Solving the Integration Problem using Microservices
The integration code that is hardcoded into the core product is separated from the core product. Decoupled integration code is then packaged and delivered as a microservice with its sole responsibility to provide integration to the target product.
The picture below shows the architecture of a product that supports three core functional features, has an integration with another product and the integration logic hardcoded into one of the core product’s feature:
The picture below is the architecture of the same product with the integration logic decoupled from the core product and delivered as a Microservice.
Delivering the integration as a microservice addresses all the issues associated with the traditional integrations. It also provides various advantages:
Integration Microservices in a Container
Integration microservices are delivered as web applications and are consumed by any product using the API exposed by the microservices. Ways of adopting the integration microservice include:
- Embedding the Microservice in the consuming product
- Integration microservice as a separate process
- Microservice in a Container
Embedding the Microservice in the Consuming Product
In this approach, the Integration microservice is embedded into the consuming product and shares the same runtime as the product. This approach is against the microservice principle, microservice should run as a separate process, but can be used only when the product does not want to run the integration as a separate process.
Challenges with this approach:
- Runtime environment of the consuming product may not be the same as the runtimes on which the Microservice is certified
- Microservice libraries conflict with the consuming product libraries
Integration Microservice as a Separate Process
In this approach, the microservice runs as a separate process from the core consuming product and avoids the conflict of libraries with the consuming product.
Challenges with this approach:
- Need a separate runtime for integration microservice
- Runtime environment in which microservice is certified can be different from the consuming product’s runtime. Due to this, the microservice has to be certified on multiple environments and thereby increases development and maintenance cost.
Microservice in a Container
In this approach, the Microservice is bundled inside a container (e.g., Docker container) and delivered to the consuming products. Putting the Integration microservice in a container solves the challenges associated with library conflicts and complex runtime environment issues. The containers provide a complete isolation of the runtime and avoids any kind of conflicts. As the Microservice runs inside a container engine, it is certified only on a single container environment.
The only challenge with this approach is the need for a container engine. But with container technologies picking up speed, enterprises rewriting the products to align with the container technologies this challenge will be eliminated.
Microservice architecture helps in delivering the integration as a reusable component that can be reused by any product in the organization with a similar need. Integration exposed as a REST API can be consumed by any product written in any technology. Also, the operational metrics exposed by the microservice helps in understanding the usage and health of the integration.
Delivering the integration microservice in a container solves the technical challenges relating to library conflicts and certification on multiple environments. This helps in developing the integration faster and makes the adoption easier.
Opinions expressed by DZone contributors are their own.