Skip to main content

DNS for Routing

Context​

Microservices are adopted. Microservice instances are deployed to a dynamic environment where fixed network addresses and ports are not guaranteed. Request-response based communication between microservices is facilitated.

Problem​

  • Changing network addresses and ports of microservice instances break communication with clients.
  • Microservices might be configured to direct traffic to instances of other microservices that are not available any more
  • Newly deployed microservice instance might not get traffic since other microservices don't know of them

Solution​

Abstract from the underlying network changes by using DNS names to address deployed components via a name (instead of an IP). For example, the configuration server could be reachable via the DNS name config-server per convention in all deployment environments.

This approach can pose an alternative to using an API or library to fetch the current configuration before sending out a request to another microservice. Under the hood, such an mechanism builds on service instance discovery that makes each microservice availabla under a specific DNS entry.

A DNS-like addressing of communication partners moves the complexity of instance discovery from the microservice to the infrastructure layer.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L25:

  • microservices can have multiple instances, each running in container/VM
  • communication among them dynamically defined => due to dynamically changing instances
    • service discovery usually supports resolution of DNS into IP addresses
    • service registry can forward IP address or DNS

L31:

  • Context: prt of migration practice MP14: Deploy into a cluster and orchestrate containers
  • internal name resolution strategy
    • some services should be identified by using internal name instead of IP address
    • e.g. service registry

L53:

  • Context: secure microservice framework for IoT
  • to address across heterogenous IoT devices, networks, virtual objects, methods, and event channels => URNs (a kind of URI)
    • example for weight management virtual object => compatible with RESTful URLs
  • often microservices on devices have no publicly reachable IP address => gateways required to bridge the gap; combination of API gateway + microservices = "IoT site"
    • gateway transforms protocols etc.
    • ... [not important here]
  • 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

LN44:

  • network structure might change continuously, service instances come and go
  • need for service discovery
    • provides DNS-like central point for locating services

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • service discovery is more than DNS lookup
    • also health checks for availability checking
  • DNS can serve as load balancer