...
Table of Contents
| Table of Contents |
|---|
Architecture Tenets
Here we discuss the tenets of the architecture. Which things are most important and why. When we make architecture decisions below, they take these tenants into account.
The System Must be Manageable
We will have a distributed network using distributed ledger technology in the guise of Hyperledger Fabric. The surrounding components such as APIs, UI Applications, Databases, Extraction Patterns and Data Transformation and Enrichment must all be managed. That is, when we have the need to add some new functionality, we want all the participants to have the necessary components. To make this work, the node must be manageable. For this purpose we intend to use GitOps, where the configuration is managed by a configuration held in git which is used to update the node components automatically.
The System Must be Cloud Agnostic Whenever Possible
The openIDL components will most often be deployed to the cloud. While we will use AWS, other participants may choose another cloud provider. For this reason, we want the deployment to work in any one of the possible clouds without undo alteration or duplication. There will be specific areas where the cloud provided services must differ. In these cases, we will use a layer to normalize the interface if possible. We must always be careful to balance cost and complexity with flexibility.
Infrastructure as a Service before Self Managed Infrastructure
Whenever possible when there is a choice between implementing infrastructure that we manage and that which is managed automatically by the cloud provider, lean toward cloud provider managed solutions.
The System Must be Transparent
The use of Infrastructure as Code will make they system’s configuration self documenting. Anywhere this does not fully explain, extra documentation must be provided. This is generally found in the README.md files in git.
Architecture Decisions
SECURITY
SUBJECT | Secret Management |
|---|---|
| STATUS | Open |
DECISION | The secrets are held in: Vault? The secrets are managed by: The secrets are accessed from Iac …? |
DISCUSSION | The management of secrets is complicated. Below are some requirements for the solution. If we can tick off all these, we’ll have a winner. Must be able to manage: - carrier secrets - api keys - aais secrets - common secrets - cloud provider secrets - database secrets - hlf network secrets like certs - application secrets - distributed secrets Must: - rotate passwords - be encrypted - permissioned so only visible to specific individuals or ci/cd - manageable - update / delete / create / view - auditable - know what changed and that no breaches have occurred - be accessible from IaC - terraform - be accessible from IaC - helm - be accessible during CI/CD - be cloud agnostic for use - be multi-cloud - have a health check of the system - at startup and intervals - provide logging and notifications of updates - exhibit CIA - confidentiality, integrity, access - have a user interface for managing the secrets Options: - tools o vault o aws secrets manager - |
...
| SUBJECT | MongoDB HDS Implementation |
|---|---|
| STATUS | Open |
DECISION | Mongo DB is a cloud managed service |
DISCUSSION | The default implementation for MongoDB is a cloud managed service. In AWS this will be DocumentDB, as long as, it implements the API we need. In other cloud providers it will be specific to that cloud. For local deployments it will be inside the kubernetes cluster. The Terraform to setup the mongo db will be pluggable so it can be replaced with the appropriate platform specific configuration. Options discussed were: - self-managed cloud implementation - cloud-managed Infrastructure as a Service - mongo db atlas - a mongo provided infrastructure as a service (requires separate account, so it was dismissed) DocumentDB does NOT support mapreduce which is how we run the extraction patterns. So we have two options:
So, for the migration project we switch to a mongodb self managed db For the longer term we'll reimagine the extraction pattern processing. |
APPLICATION DEVELOPMENT
| SUBJECT | Common UI Code Management |
|---|---|
| STATUS | Open |
DECISION | Single Application Angular UI Variations will utilize angular libraries |
DISCUSSION | The library will be a different kind of angular app located in the same super library as all apps that use it. This is the approach for the data-call-ui. (openidl-ui and openidl-carrier-ui) For common / shared libraries we will use an npm registry. |
DEV / OPS
| SUBJECT | Local Kubernetes Development |
|---|---|
| STATUS | Open |
DECISION | Use Kind or Minikube for Local Kubernetes Runtime |
DISCUSSION | We will use Minikube |
...