Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 Architectural Approach C.

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.

...

  1. is the data (related to a all models and instances) stored in a single database or
  2. is the data (related to a specific model and instance) stored in separate databases
    1. Secondary question for 2: within a shared or separate DBMS

...

Architectural approach A

All data access id via interfaces provided by the owning service.

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

Data access to any data is allowed regardless of ownership.

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

Data access is permitted only when there is an explicit agreement between components.

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

µServices given access to the model may then query the data store directly, bypassing the owning µService.

This approach can have additional benefit in that it may help with data access race conditions.

I.e. it becomes a decision on the part of the owner to 'relax' encapsulation. The coupling is made visible.

...

This approach is backwardly compatible with Option Architectural Approach A.

Discussion