Internal Integration Proxy

Context

Microservices are adopted. Microservices might update independently.

Problem

• Changes to microservice instances affect other deployed microservices

Solution

Introduce an internal integration proxy as single point of access to other microservices. This facade enables microservices to be split, combined, or refactored to a certain degree without affect to other microservices. The internal integration proxy requires a service instance discovery to be able to forward requests to the corresponding microservices.

This technique is the pendant to the API facade towards client applications but acts between microservices. Additional functionality can be put into the internal integration proxy, similar to an API gateway.

Maturity

Proposed, to be evaluated.

Sources of Evidence

L9:

• service proxy: all services only accessible via proxy
  • changes to instance does not affect others
  • proxy needs up-to-date configurations of each service (IP address, port number, ...)
    • retrieved from configuration state manager
  • interacts with configuration state manager to know instances
    • uses confd to sync configuration of CSM => generates new config files and releoads HA proxy to make use of new configs
    • interpretation: takes over discovery

L14:

• Context: Microservices at otto.de
• Vertical = microservice or collection of microservices, represents one bounded context
• Communication between verticals use the "Backend Integration Proxy"
  • (+) easier ensure slow or unavailable applications cannot ear down other applications with a snowball effect

L25:

• Context: different service discovery pattens
• Hybrid pattern: combination of service registry and API gateway
  • gateway replaced by message bus
  • clients communicate with message bus => acts as registry, routes request to requested microservice
  • microservices communicate with each other over message bus (analogy: ESB in SOA)
  • (+) ease of migration: from SOA, ESB can be used in comm layer
  • (+) learning curve: from SOA
  • (-) SOA issues: no benefit from IDEAL properties of microservices and independence
    • isolated state
    • distribution
    • elasticity
    • automated management
    • loose coupling

L52:

• Picture shown with message channels as integration point between microservices

L53:

• Context: secure microservice framework for IoT
• API gateway
  • interface that relays call or request between two or more microservices
  • can aggregate requests
  • instead of direct communication between microservices: use API gatway
    • (+) adjust interconnectivity through the aggregation and distribution function
  • Microservices register => endpoints with unique identity, can be further bound to event channel or method through static configuration or dynamic negotiation
  • Can also be used towards outside world, e.g. for user auth
  • deals with protocol transformation
  • Use of URNs (like URIs) => see dns-for-routing
  • Can do load balancing between instances
  • Conntects different "IoT islands"
  • Natural point to enforce policies: access, name resolution, QoS
    • name resolution policy: static binding between service API and an endpoint
      • useful for integrating microservices of different versions or for load balancing
      • e.g. weight management system: operator only change some bindings to point to new version
      • easy replacement if API backward compatible in syntax and semantics
        • if not compatible: create new virtual objects and methods => run both versions in parallel until all migrated
      • load balancing: run multiple instances of a microservice
        • bind them to the same set of virtual objects and methods
        • events: bind multiple consumers to same event channels so that events are dispatched among them
      • (+) in combi with gateway: decouple event producer and consumer / caller from callee
      • location of IoT microservices might change => need to attach to different API gateways at different times
        • name resolution policies => redirect request to other sites if they can work together with service registry mechanism
    • QoS policy: traffic restriction on a binding (traffic flow)
      • include number of messages per second, traffic amount in bytes per second
      • => protect microservices from DoS attacks / prevent launching them from within system
      • circuit breaker pattern
• Distribution
  • microservices traditionally in the cloud
  • IoT: additionally on device, edge cloud, or gateway component
    • => various gateways, independent physical machine, or software component deployed on a router or server
  • => better performance due to locality and the data stream management
    • usually data to the cloud
    • IoT: get microservice close to data due to bandwidth
      • e.g. aggregate data from wearables already at mobile phone

L59:

• when make call to microservice: go through a proxy or messaging layer that finds suitable instance

LN48:

• API proxy in combination with service discovery achieves service discovery
  • API proxy stores configs as IP, port, timouts,...
  • new services can register by storing runtime config
  • config can be updated at runtime
  • => minimum downtime
  • acts as a load balancer with round robin
  • CI (Jenkins) updates config info in Consul
• Figure 1 shows API proxy forwarding requests to the service instances
• Tools: - API Proxy: HAProxy - Config Storage: consul
• Seems to act as API gateway as well
• Context: service discovery as microservice challenge
• API proxy is also supplied with configuration information (where microservice instances are located)
• API proxy can then make changes
• Example technology: HAProxy
• also acts as load balancer to distribute load between instances via round robin
• part of CI/CD
• HAProxy takes over service discovery and request routing
• Interpretation: the API proxy is also used for routing between microservices