Skip to main content

Proxy Microservice

Context​

The system is split into multiple microservices with corresponding APIs. There is at least one 3rd party application (e.g. an external API, a CMS, ...) or a legacy system during a migration that shall be integrated into the system.

Problem​

  • In a migration scenario, a big bang integration or parallel adoption is too much risk
  • Integrating 3rd party applications or the legacy system leads to an inconsistent integration landscape (e.g. different communication protocol)

Solution​

Wrap the 3rd party system or the legacy system with a proxy microservice. This technique is also implemented by the strangler pattern and builds a decoupling layer around a 3rd party or legacy system. The specifics of the integration - like the use of the communication protocol - are hidden behind the proxy, leading to a uniform look and feel of the integration between microservices.

In a migration scenario, multiple proxy microservices can be implemented that each wrap a part of the legacy system. Implementing the logic within the wrapping microservices instead of interacting with the monoligh facilitates a gradual migration towards microservices.

This rather abstract techniques has two more concrete implementations:

  • The data replication proxy technique: replicates data from the 3rd party or legacy system to build up a data cache.
    • The CQRS proxy technique: uses the CQRS pattern to build up different optimized read models in the proxy micrservice.

Both of these techniques address the challenge of varying availability guarantees of the 3rd party or legacy system.

This technique can support to gradually replace the legacy system. The following techniques might pose an alternative to this technique:

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

Note: As this technique is an abstraction of the Data Replication Proxy and the CQRS Proxy, we also used their sources to formulate this technique.

L17:

  • Context: migration towards microservices
  • Strangler pattern: new microservices are added around the monolith
    • ecosystem of microservices will gradually replace features of monolith

L34:

  • Context: strategies to deterine how systems interaction
  • anti-corruption layer: translation mechanism to keep both systems decoupled
    • often used for legacy systems

L42:

  • Context: which functionalities migrate first?
  • 14 of 18 participants: phased adoption
  • Strangler pattern as part of phased adoption
  • 3 cases: parallel adoption
  • 1 case: big bang

L44:

  • Use of proxy microservices to encapsulate diverse communication protocols
    • foster interoperability and extensibility
    • easy replacement of existing components with new ones
    • => uniform approach towards modelling physical and logical IoT devices, hide complexity
  • Example: encapsulation of the Modbus interactions
  • Example: meterological microservice encapsulates non-standard web service to implement microclimate data acquisition

L53:

  • Example: weather and calender reportin microservices
    • conntect to remote resources: Google calender
    • translate data into required formats, provide updates to further services

LM43:

  • Context: SLR findings about microservices in DevOps
  • Table 10: list the strangler pattern

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C2-S3
    • existing monolith is replaced and extended piece by peace
    • new system: 10 Java services
    • monolith too important and complex to be replaced at once
    • => operate two systems concurrently
    • additional functionalities: new microservices
      • strangler pattern
  • C9-S13
    • migration of a system to cloud-native architecture
    • traditional WepSphere to Liberty in Docker; service cut postponed
    • instead: strangler pattern for ongoing development
    • Java as exclusive language for all service
    • SOAP + JMS replaced by RESTful HTTP + AMQP

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • External API services as interfaces to external providers (WebTransportDatagramDuplexStream, line-checks)
    • have open socket, translate messages to standard fromat, feed into RabbitMQ

Interview D:

  • integration also topic besides microservices: decoupling layer
  • need to understand non-microservice topics that I want to integrate with, how to access
    • many solutions are quite closed
    • best case: access data schema
    • if I'm lucky: input or output table
  • problem: what is their availability? 24x7 often not guaranteed
    • example SAP: 100k updates per minute => stops working
    • if load on microservice system => decouple the load
      • homogenous API layer above
      • CQRS pattern
      • caching
  • alternative to wrapping APY layer: individual integration services
    • facade reacting on specialities of wrapped system
    • disadvantage: service API driven by system wrapped
  • to consider: API management solution taking some of this job over
    • much effort to build it yourself
  • struggle with availability => predetermined breaking point, esp. under load
  • strugge with consistency
  • their solution: generic part to the microservice site, adapters to external site
    • throwing CSV files around
    • accessing FTP servers
    • accessing database tables
    • remote function calls

Interview F:

  • Context: legacy systems and 3rd party systems
  • facade to introduce it to the microservice world
    • looks to other microservices like a microservice
    • leads to uniform integration