A real concern is the potential that the CPS will make managing coupling between ONAP components difficult.
Decision
We will start with Architectural Approach A in the PoC with the aim of fully supporting Architectue
Details
Micro-service architecture strives to control coupling. The deployment of micro-services enforces good behavior, only published interfaces are available at run-time. This is not new. Encapsulation and data hiding have been around as long as software. What is new is the enforcement at run-time. Note also that mechanisms been put in place to soften this encapsulation: the C++ friend declaration; Java package protected. There are reasons for both approaches and as always there is a balance. The two approaches are not mutually exclusive.
...
- is the data (related to a all models and instances) stored in a single database or
- is the data (related to a specific model and instance) stored in separate databases
- Secondary question for 2: within a shared or separate DBMS
...
Architectural approach A
Classic µService architecture. (One extreme)
...
- Latency in data access (multiple serializations)
- Data transformation (multiple representations)
- Data duplication (multiple representation 'cached' in multiple data stores)
- Data deployment purely a deployment concern.
...
Architectural approach B
Common information model and data lake. (Another extreme)
...
Access control may be used to mitigate the negatives of this approach. However this can be problematic in the selection of the DB technology, and the load on the DBMS
...
Architectural approach C
Hybrid approach.
- A single component is designated owner of the model and data related to it. This is not a common information model.
- Knowledge of the model is always via an interface provided by the µService that owns it.
- Access to data is not possible without knowledge of the model. This is not a data lake.
- Data deployment involves understanding use cases
...