Ops DSL Ecosystem: Terraform for C#📋

The Thesis📋

Operational knowledge is not special. It follows the same pattern as every other domain in the CMF ecosystem: Attribute + Source Generator + Analyzer + NuGet. Deployment ordering, health checks, migration sequencing, chaos experiments, compliance matrices, cost budgets -- every one of these is a domain with a vocabulary, constraints, and generated artifacts.

The dev-side DSLs proved the pattern works for code: Requirements, DDD, Content, Admin, Pages, Workflow. The Auto-Documentation series introduced 5 Ops sub-DSLs as a sketch. This series builds the complete ecosystem: 22 independently publishable sub-DSLs covering every operational concern from deployment to compliance.

The key architectural insight is the 3-Tier Execution Model:

You start testing ops today. No infrastructure. No cloud account. No Docker. Pure dotnet test with Injectable decorators that simulate faults, latency, rate limiting, and data corruption. When you need real network behavior, you add Docker. When you need scale, you add Terraform. The DSL attributes are the same at every tier -- only the generated artifacts change.

Table of Contents📋

Act I: Foundations (Parts 1--4)📋

Part 1: The Problem -- Why Ops Is Still Untyped📋

The lifecycle gap: code is typed from requirement to test, then falls off a cliff into YAML, bash scripts, wiki runbooks, and Slack messages. The taxonomy of 18 untyped operational concerns and why Terraform/Helm/Pulumi solve provisioning but not operational knowledge.

Part 2: The 3-Tier Execution Model -- InProcess, Container, Cloud📋

THE foundational architectural insight. Not everything needs infrastructure. InProcess uses Injectable decorators for 80% of chaos engineering at zero cost. Container adds real network behavior. Cloud adds scale. The tier constraint system prevents compile-time violations.

Part 3: The Ops Meta-DSL -- Architecture of an Ecosystem📋

Why one big Ops.Lib fails. The NuGet architecture: 22 packages, each with Lib + Generators + Analyzers. The 8 shared primitives registered in the M3 MetamodelRegistry. The cross-DSL validation graph with 14 typed cross-references.

Part 4: Shared Primitives -- The Ops Kernel📋

Deep dive into OpsTarget, OpsProbe, OpsThreshold, OpsPolicy, OpsEnvironment, OpsSchedule, OpsExecutionTier, and OpsRequirementLink. The generated ops-manifest.g.json. Tier constraint enforcement. Bridge to the Requirements DSL.

Act II: The 22 Sub-DSLs (Parts 5--22)📋

Core Operations (existing 5, expanded)📋

Part 5: Ops.Deployment -- Orchestration as a DAG📋

DeploymentOrchestrator, DeploymentApp, DeploymentDependency. Topological sort at compile time. Generated: execution DAG, Kubernetes manifests, Argo Rollout configs. OPS001--OPS003.

Part 6: Ops.Migration -- Schema and Data Changes as Typed Steps📋

MigrationStep, ExeMigration, MigrationValidation. Wave-based parallelism. Generated: ordered execution plan, rollback scripts, validation queries. OPS004--OPS006.

Part 7: Ops.Observability -- Health, Metrics, Alerts, Dashboards📋

HealthCheck, Metric, AlertRule, Dashboard. The most artifact-heavy DSL. Generated: ASP.NET health checks, Prometheus alert rules, Grafana dashboard JSON, PagerDuty integration. OPS007--OPS010.

Part 8: Ops.Configuration + Ops.Resilience -- Environment Correctness and Recovery📋

ConfigTransform, Secret, EnvironmentMatrix (Configuration). RollbackPlan, CanaryStrategy, CircuitBreaker, RetryPolicy, Bulkhead (Resilience). Generated: per-env appsettings, Polly policies, Argo Rollout canary configs. OPS011--OPS016.

Performance & Capacity📋

Part 9: Ops.Performance -- SLIs, SLOs, and Performance Budgets📋

Sli, Slo, PerformanceBudget, CachePolicy, BenchmarkTarget. Generated: multi-window burn rate alerts, Grafana SLO dashboards, BenchmarkDotNet configs, cache registration. PRF001--PRF003.

Part 10: Ops.LoadTesting -- Scenarios as Types, Across Three Tiers📋

LoadTest, LoadProfile, TrafficPattern. InProcess: BenchmarkDotNet. Container: k6 local. Cloud: k6 distributed across VMs. Generated: complete k6 scripts with scenarios, thresholds, custom metrics. LDT001--LDT003.

Part 11: Ops.Chaos -- Fault Injection Across Three Tiers📋

THE 3-tier showcase. ChaosExperiment, FaultInjection, SteadyStateProbe, AbortCondition, ToxiProxy. InProcess: Injectable decorators. Container: Toxiproxy sidecars. Cloud: Litmus ChaosEngine + Terraform. CHS001--CHS004.

Part 12: Ops.Security -- RBAC, Audit, Scanning, and Secrets📋

RbacRule, AuditPolicy, SecretRotation, VulnerabilityScan, PenetrationTestScope. Generated: ASP.NET authorization policies, audit middleware, Trivy/ZAP configs, secret rotation service. SEC001--SEC004.

Testing & Quality📋

Part 13: Ops.Testing -- Strategy Declarations as Types📋

TestStrategy, FuzzTarget, ContractTestConsumer, MutationTestTarget. This DSL doesn't run tests -- it declares what tests should exist and validates they do. Generated: TestStrategyMatrix, fuzz harness, coverage report. TST001--TST004.

Part 14: Ops.Quality -- Code Quality Thresholds as Compiler Diagnostics📋

QualityGate, TechDebtBudget, CoverageTarget. 9 quality dimensions. Generated: SonarQube-compatible quality gates, tech debt burndown report. QLT001--QLT003.

Infrastructure📋

Part 15: Ops.Infrastructure -- Containers, Storage, Certificates, DNS📋

ContainerSpec, StorageSpec, CertificateSpec, DnsRecord, CdnEndpoint. Container tier: docker-compose.yaml. Cloud tier: Terraform modules, Kubernetes manifests, cert-manager certificates. INF001--INF004.

Part 16: Ops.Networking -- Policies, Service Mesh, and Firewalls📋

IngressRule, MtlsPolicy, FirewallRule, NetworkPolicy, EgressRule. Generated: Kubernetes NetworkPolicy, Istio PeerAuthentication, Terraform VPC/subnets/NSGs. NET001--NET004.

Data & Governance📋

Part 17: Ops.DataGovernance -- Backup, Retention, GDPR, and Recovery📋

BackupPolicy, RetentionPolicy, GdprDataMap, RecoveryObjective, SeedData, DataClassification. Generated: backup CronJobs, retention jobs, GDPR data map documentation, seed data runner. DGV001--DGV004.

Part 18: Ops.Compliance + Ops.SupplyChain -- Regulatory Frameworks and Dependency Audit📋

ComplianceFramework, ComplianceControl, DataResidency (Compliance). DependencyAudit, SbomRequirement, LicensePolicy (SupplyChain). Generated: compliance matrix, SBOM, license audit, Dependabot/Renovate configs. CMP001--CMP004, SCH001--SCH002.

Cost & Capacity📋

Part 19: Ops.Cost -- FinOps as Typed Budgets📋

ResourceBudget, RightSizingRule, SpotPolicy, ReservedCapacity, CostTag. Generated: cloud budget alerts (AWS/Azure/GCP), cost allocation reports, right-sizing recommendations. CST001--CST003.

Part 20: Ops.Capacity -- Autoscaling, Throttling, and Projections📋

AutoscaleRule, ThrottlePolicy, CapacityProjection, ScaleToZero. Generated: ASP.NET rate limiter, Kubernetes HPA/VPA, KEDA ScaledObject, Terraform capacity modules. CAP001--CAP004.

Incident & Lifecycle📋

Part 21: Ops.Incident -- On-Call, Escalation, and Status Pages📋

OnCallRotation, EscalationPolicy, StatusPage, PostMortemTemplate, IncidentSeverity. Generated: PagerDuty/OpsGenie configs, status page components, incident response guides. INC001--INC003.

Part 22: Ops.ApiContract + Ops.EnvironmentParity + Ops.Lifecycle📋

ApiVersionPolicy, BreakingChangeGuard, ConsumerContract (ApiContract). ParityRule, FeatureFlag, ServiceStub (EnvironmentParity). SunsetSchedule, SupportWindow, TechDebtItem (Lifecycle). Generated: OpenAPI diff, Pact verification, typed feature flag accessors, deprecation warnings. API001--API002, ENV001--ENV003, LFC001--LFC003.

Act III: The Whole (Parts 23--26)📋

Part 23: Composition -- One Class, Twenty-Two DSLs, Three Tiers📋

OrderServiceV3Ops declared with every DSL. ~200 attributes, ~40 generated files across 3 tiers. The cross-DSL analyzer report: 46 pass, 2 warn, 0 error. dotnet ops report showing complete operational posture. The proof that the pattern scales.

Part 24: CMF Integration -- Ops DSLs Meet Domain DSLs📋

Five typed chains: DDD-to-Deployment, Requirements-to-Ops via OpsRequirementLink, Workflow-to-Resilience, Admin-to-Observability, Content-to-DataGovernance. The unified M3 MetamodelRegistry. Injectable decorators bridging DDD services with Chaos DSL.

Part 25: Comparison -- Terraform, Helm, Pulumi, and Ops.Dsl📋

Fair comparison matrix. Key distinction: Terraform/Helm/Pulumi provision infrastructure; Ops.Dsl specifies operational behavior. They are complementary, not competitive. Ops.Dsl generates Terraform modules at Cloud tier. Why Terraform doesn't belong on a dev machine.

Part 26: The Vision -- Everything Is a DSL📋

No domain of operational knowledge that can't be typed. Every wiki page is a DSL not yet written. The 3-tier model means you start today with zero infrastructure. The specification maturity model (Level 0--5). The cost curve: DSLs expensive Day 1, cheap forever after. "The compiler does not sleep. The wiki does."

Act IV: Walkthroughs (Parts 27--31)📋

Part 27: InProcess Chaos -- A Complete Walkthrough📋

End-to-end: declare a chaos experiment, generate the Injectable decorator, run it in dotnet test, analyze the results. Zero Docker. Zero cloud. Full fault injection.

Part 28: Container Tier -- Docker Compose Generation📋

End-to-end: declare container-tier experiments, generate docker-compose.chaos.yaml, Toxiproxy configs, and TestInfraFixture.g.cs. Real network faults in CI.

Part 29: Cloud Tier -- Terraform Generation📋

End-to-end: declare cloud-tier experiments, generate Terraform modules, Litmus ChaosEngines, distributed k6 scripts. Scale testing in real infrastructure.

Part 30: Full Lifecycle -- One Service, All 22 DSLs📋

OrderService declared with every DSL. 22 attribute groups, 200+ generated artifacts, zero manual ops documentation. The proof that the pattern scales.

Part 31: Generated vs. Written -- The Drift Comparison📋

Side-by-side: a manually maintained ops wiki vs. generated ops artifacts. After 6 months. After a team change. After a major version bump. The drift is the argument.

The 22 Sub-DSLs by Category📋

Core Operations (5)          Performance & Capacity (3)   Security & Testing (3)
├── Deployment               ├── Performance              ├── Security
├── Migration                ├── LoadTesting              ├── Testing
├── Observability            └── Chaos                    └── Quality
├── Configuration
└── Resilience

Infrastructure (2)           Data & Governance (3)        Cost & Capacity (2)
├── Infrastructure           ├── DataGovernance           ├── Cost
└── Networking               ├── Compliance               └── Capacity
                             └── SupplyChain

Incident & Lifecycle (3)     Meta-Packages (1)
├── Incident                 └── Ops.Essentials (curated 7)
├── ApiContract
├── EnvironmentParity
└── Lifecycle

How to Read This Series📋

Architects should read Parts 1--4 + 23--24 + 26 for the vision, the 3-tier model, the shared primitives, the composition proof, and the meta-pattern synthesis.

Developers should read Parts 2 + 5--11 for the tier model, the core DSLs, chaos engineering, and performance testing.

SRE / Platform engineers should read Parts 5--8 + 15--16 + 19--21 for deployment, observability, infrastructure, networking, cost, capacity, and incident management.

Compliance officers should read Parts 17--18 for data governance, GDPR, regulatory frameworks, and supply chain audit.

Everyone should read Part 23 -- the complete lifecycle example ties every DSL to a single service.

Prerequisites📋

• Familiarity with C# attributes and source generators
• Basic understanding of Roslyn analyzers (see Contention over Convention)
• Understanding of the M3 meta-metamodel (see Building a Content Management Framework)
• The Auto-Documentation series, particularly Parts IV--V, which sketched the first 5 Ops sub-DSLs
• The Spec-Driven vs Typed Specifications verdict (Part X), which promised Layer 2: Operational DSLs

Related Posts📋

• Auto-Documentation from a Typed System -- introduced the first 5 Ops sub-DSLs
• Contention over Convention over Configuration over Code -- the Attribute + SG + Analyzer meta-pattern
• Building a Content Management Framework -- the M3/M2/M1 meta-metamodel and the dev-side DSLs
• Requirements as Code -- the Requirements DSL that OpsRequirementLink bridges to
• Spec-Driven vs Typed Specifications -- the comparison that motivated Layer 2