Skip to main content

Service / API Registry

Context​

There are different microservice-based projects within the company. Common functionality is designed as standalone microservices that shall be reused between these projects.

Problem​

  • Searching and finding the microservice to reuse is difficult as there is no central place to look for them

Solution​

Introduce a service or API registry that tracks all reusable microservices and their APIs. This registry becomes the central place to search and retrieve information about microservices and their APIs.

This discovery process happens at design time of a consumer, or possibly leverages the mechanism at runtime as well. Each microservice can register their API at the registry, enabling the integration into the company's application landscape.

Further, the registry can also make meta-data of each microservice available and discoverable. Technique Document Microservice Metadata details which kinds of meta-data might be suitable in this regard.

Maturity​

More data is required (only 2 source).

Sources of Evidence​

L46:

  • Context: enterprise companies
  • several teams need to create/enhance common functionality like customer account
  • goal: effective reuse
  • solution: maintain enterprise-wide specifications about all microservices (=> other code)
  • make interfaces discoverable
    • consumers have to be able to look up and find interfaces without knowledge of underlying impl. or location
  • Reference microservice architecture: Enterprise API registry
    • "discovery" requirements => API registry service
    • make interfaces exposed to consumers visible
    • information content in standard format and access control
    • search and retrieval functionality
    • => design time lookup of API specs
    • => central location for enterprise API portfolio governance
    • Comparison to SOA: service registry

L53:

  • Context: key patterns of microservices for IoT
  • among others: microservices marketplaces
    • classified as structural pattern, solution of decomposition
    • independent deployment => may be as simple as plug-and-play
    • easy exchangeability
  • vision: supermarket of microservices abd IoT devices
    • "goods" are ready-to-deploy microservices
    • sys admin merely needs to "shop" online
    • analogy: like a app store for smartphones
  • Global service registry microservice
    • possibly co-located with API gateway
    • manages ontology of microservices (meta-data)
    • service registration and discovery among multiple sites
    • microservice can talk to registry to publish its structures and interfaces
    • other microservices can make SPARQL query to locate it