Refine taxonomy terms and definitions

[swapdisk]

The taxonomy section needs some love. Let's use this issue for collaboration.

I'll lead off the discussion with a follow up comment proposing a list of standard terms and suggested definitions. We'll welcome feedback and additional contributions from the community.

Then, as we reach consensus, I'll raise the PR(s) to update the terms and definitions under the taxonomy folder.

[swapdisk]

Here's a draft of a first level taxonomy. Feedback welcomed!

Taxonomy of DCM

The first level of the taxonomy defines the main DCM architectural domains.

Here are the five categories of that taxonomy:

1. Developer Experience: This domain focuses on the unified interface that developers and application owners use to interact with DCM. It includes the self-service catalog, templates, and all user-facing documentation. This is where the DCM’s abstractions are consumed. Multi-tenancy is experienced at this level.
2. Control Plane: This is the central nervous system of DCM. It provides the unified API and maintains the DCM data model including the inventory of resources. It also enforces authentication and role-based access control.
3. Orchestration & Automation: This domain contains the code and workflows for provisioning and managing resources. It provides the engines that execute commands from the control plane to interact with the underlying core infrastructure.
4. Core Infrastructure: This domain represents the physical and virtual assets in the data center. It includes the compute, storage, and networking resources that are managed by the automation domain.
5. Platform Governance & FinOps: This domain is a set of overarching requirements that ensure that DCM operations are secure, compliant, and cost-effective. It encompasses policy management, real-time metrics, and cost allocation.

Users of DCM

The most obvious class of users are the consumers of cloud services acting within the Developer Experience domain. However, users from platform engineering and infrastructure operations teams will interact with DCM domains below the control plane.

Given the security architecture governing these groups will vary, these different user classes must be clearly defined.

Multi-tenancy in DCM

DCM multi-tenancy is experienced at the Developer Experience layer and enforced by the Control Plane.

The Orchestration & Automation and Core Infrastructure domains operate in "privileged mode” to implement the isolation and confinement for multi-tenancy.

The Platform Governance & FinOps domain has access to the tenant-wide scope required to implement policy management and billing.

[swapdisk]

I baked a layer cake to help visualize my proposed first level taxonomy... 🍰

[croadfeldt]

Add - Region, Zones, DC, these were in a separate Issue previously.

[swapdisk]

I'm working now on defining the vocabulary of terms for each of the domains. Planning to get a PR opened in the next few days.

[swapdisk]

Calling phase 1 of taxonomy refinement done with merge of #53. We settled on different domain names than spelled out above, but they are functionally equivalent.