Product
Elan8 is the Architecture Control Plane for Microservices. It establishes a declarative architecture model and continuously validates deployed environments against it. Below are the core technical layers and capabilities.
Currently in Development
We’re actively developing the MVP. The features below are the intended capabilities for our initial release.
How the control plane is structured
Architecture DSL
The declarative model defines services, API contracts (OpenAPI, gRPC, etc.), dependency relationships, exposure intent (public vs internal), and governance policies. Text-based, versioned in Git, and readable by humans and tools. This model is the authoritative architectural reference.
From this single source of truth, Elan8 can also generate documentation and diagrams (e.g. C4-style) for onboarding and reviews; the primary function of the DSL is to drive validation and governance.
Environment model
Each environment (dev, staging, production) is modeled separately. You point Elan8 at the deployment artifacts for that environment — for example Kubernetes manifests or Helm values — so that resolution and validation are environment-aware. Deployment files remain the source of truth for runtime configuration; Elan8 reads and validates against them.
Binding engine
The binding engine maps logical services from the architecture model to deployed workloads. It uses labels, annotations, Kubernetes selectors, and standard naming conventions with deterministic matching strategies. The result is a resolved architecture per environment without requiring intrusive changes to existing deployments.
Governance rule engine
Policies enforce structural integrity: no undeclared service dependencies, no cyclic dependencies, contracts required for inter-service communication, controlled public exposure, cross-domain dependency restrictions, and detection of unauthorized deployments. Policies can be tuned per environment (e.g. stricter in production).
API impact analysis
When a contract changes, Elan8 determines which services consume it, which environments are affected, whether the change is breaking, and what the blast radius is. This enables safe evolution of distributed systems and prevents breaking changes from reaching production unnoticed.
Drift detection
Elan8 continuously detects services deployed but not modeled, modeled services not deployed, new public exposure paths, unexpected service coupling, and structural inconsistencies between environments. Architectural intent is kept aligned with deployed reality.
CI integration
Validation runs in CI so that releases that violate architecture or introduce breaking API changes can be blocked. The control plane becomes part of the delivery pipeline without replacing existing CI/CD tooling.
Capability overview
Architecture DSL
Declarative model: services, contracts, dependencies, exposure, policies. Git-native.
Environment model
Per-environment configuration; point at manifests and deployment artifacts.
Binding engine
Map logical services to workloads via labels, selectors, naming.
Governance engine
Policies: no undeclared deps, no cycles, contract requirements, exposure control.
API impact analysis
Blast radius and breaking-change detection when contracts change.
Drift detection
Detect model vs deployment mismatches and unexpected coupling.
CI integration
Run validation in pipelines; block releases that violate architecture or introduce breaking changes.
What Elan8 is not
- • Not a diagramming tool: Diagrams are output, not input. You define architecture; we generate views when needed.
- • Not an IaC replacement: IaC is deployment; Elan8 is architectural intent and governance. They complement each other.
- • Not a replacement for Kubernetes or CI/CD: Elan8 sits above them as the Architecture Control Plane; it validates and governs, it does not deploy or run workloads.