Platform Configuration Hierarchy

SystemBlueprint-Structure.vsdx

Blueprint - a Blueprint represents an overall system design which would reflect the target platform, capacity, features and behaviours - initially we would work on just one Blueprint but then as we evolve the platform and increase our functional and configuration capabilites, different blujeprints would be designed. 

Subsystem -  the next conceptual level down from a Blueprint - these are defined for different runtimes and different high level functional groupings e.g. Collector (non containerised, WIndows based), Containerised services divided into various different areas such as API, call processing, Media API (WebAPI, non Containerised).Subsystems are specific to a Blueprint  (e.g. cannot be shared between different blueprints)

Service - A functional grouping of one or more ComponentServices that can be treated as a deployable unit - this will equate with a Kubernetes Service for example - examples: ElasticSearch, NATSStreaming Service, Call End Metadata Processing. Service definitions are specific to a Blueprint (e.g. cannot be shared between different blueprints)

ComponentService - These are the actual microservice implementations/container definitions, third party service containers (Minio,NATS Streaming, EventStore, ElasticSearch) and executables/applications such as the Collector and the media api. Definitions for our microservices will be maintained within the microservices codebase and the tooling will scan for these registrations and update a centrally held registry of component services. Component Service registrations will also contain dependencies and the intention is to extend the definttion to describe configuraiton entries. The component service registrations should represent reference data for devops to be able orchestrate the component service's deployment and configuration.These are defined independently of a blueprint and Blueprint Service definitions refer to these, they will be shared across all blueprints.

The SystemBlueprints repo contains the generated YAML files that describe the COmponent Services and the initial system blueprint.