What

This task will identify an architecture and plan for merging the inventory-api and relations-api services in Management Fabric. It implements an architectural decision to merge them as depicted in Miro, which describes a unified model of the fabric. 

Why

The need for a separate “ReBAC” layer, ultimately the relations-api service, was identified in  AUTHZ-001: Assets and ReBAC API base projects, runtimes, & deployment architecture, in which it was considered premature to combine it with the “Assets” layer, which has since been split out into Rbac and inventory-api. In light of subsequent experience and projected future needs, we believe there is no longer a case for maintaining separate inventory-api and relations-api services, and that the existing relations API surface can be subsumed into either a) operations that are only called by inventory-api internally, and b) endpoints that can be exposed to external services via inventory-api’s API. That being the case, there are advantages to combining both services:

• Reduce the burden of maintenance and support 
• by having only one service to deploy, observe and patch/repair.
• by having only one set of artifacts to maintain, e.g. deployment pipeline, code repository, API specification, policies, runbooks, docs, and so on.
• by removing an external dependency of inventory-api and all of the deployment templating and version bumping that goes along with that.

• Improving the performance and reliability of inventory-api by removing an unnecessary network hop for operations that require a call to relations.

DDR: https://docs.google.com/document/d/1TX-dq91eujANM9pgrMbOQCv6l2d6txR68oegnqhvPOE/edit?usp=sharing