Implementation Roadmap
The reference implementation (Lattice) is a working platform, not a finished product. The chapters describe the intended behavior of the complete system — including features not yet implemented. This appendix lists them honestly — so readers know what exists, what’s planned, and what’s described as a design pattern you’d need to build yourself.
Implemented
Section titled “Implemented”These features are built, tested, and running in the reference implementation:
- Derivation pipeline with all six Cedar authorization gates (Chapter 8)
- Five secret routing paths with ESO integration (Chapter 9)
- HPA via KEDA with custom metric support (Chapter 10)
- Node autoscaling via Cluster Autoscaler/Karpenter (Chapter 10)
- Quota enforcement at derivation time with TOCTOU mitigation (Chapter 10)
- LatticeMeshMember for mesh enrollment (Chapter 11)
- Default-deny with CiliumClusterwideNetworkPolicy (ingress + egress) and mesh-wide AuthorizationPolicy (Chapter 12)
- Bilateral agreements with L4 + L7 policy generation from bilateral declarations (Chapter 13)
- Continuous compliance with LatticeComplianceProfile and Cedar/existence/configuration probes (Chapter 14)
- Istio ambient mesh with ztunnel (L4) and waypoint proxies (L7) (Chapter 15)
- Cross-cluster identity federation with shared root CA (Chapter 15)
- Pivot protocol for self-managing clusters (Chapter 6)
- Outbound-only gRPC stream with agent-cell protocol (Chapter 7)
- Runtime binary enforcement with Tetragon TracingPolicyNamespaced derived from image entrypoints and probe commands (Chapter 14)
- Gang scheduling with Volcano integration (Chapter 16)
- DCGM GPU monitoring with anomaly detection baselines (Chapter 17)
- LatticeModel with prefill/decode disaggregation and KV cache autoscaling (Chapter 18)
- VMServiceScrape auto-generation for every compiled service (Chapter 19)
- Randomized bilateral testing and cycle-based verification (Chapter 21)
- Snapshot and property-based unit testing for derivation logic (Chapter 21)
Not Yet Implemented
Section titled “Not Yet Implemented”These features are described in the book as design directions. They represent good ideas that the reference implementation hasn’t built yet.
LatticePackage (Chapter 11). The LatticePackage CRD is described in the book but not yet implemented. Package resolution and versioned dependency bundles are planned features.
Image signing and verification (Chapter 14). Integration with cosign for image signing, digest enforcement, and the AllowTagReference gate is described but not yet implemented. The current model does not enforce image signatures at the derivation pipeline.
VPA integration (Chapter 10). The reference implementation does not use VPA. The book describes how VPA could work alongside the derivation pipeline — either in recommendation-only mode or in update mode with server-side apply field manager separation. Neither is implemented.
Right-sizing recommendations (Chapter 10). The pipeline could query metrics backends to compare declared resource requests against actual usage and surface recommendations in the CRD status. Not implemented — right-sizing is currently the developer’s manual responsibility.
Chargeback/showback (Chapter 10). Cost estimation produces a per-service estimate in the CRD status. Feeding this into finance systems (chargeback APIs, cost allocation tools) is not implemented.
LatticeClusterBackup (Chapter 20). The LatticeClusterBackup CRD for scheduling Velero backups is described in the book but not yet implemented in the reference code.
Dashboard-as-code (Chapter 19). The platform derives metrics scrape targets but not dashboards. Auto-generated Grafana dashboards (via ConfigMap provisioning or VMDashboard CRDs) for every compiled service would be a natural extension.
Alert rule derivation (Chapter 19). Alerting is infrastructure-level (platform team configures). Per-service alert rules derived from the service spec (e.g., observability.alerts block with latency/error thresholds) are not implemented.
Centralized metrics aggregation (Chapter 19). Each cluster runs its own VictoriaMetrics. Cross-cluster dashboards via centralized storage (remote write to a central VM cluster) are the expected architecture but not yet operational.
SBOM generation and vulnerability scanning (Chapter 14). Integration with Trivy/Grype at the DeployImage gate is described but not implemented.
Image admission enforcement (Chapter 14). A ValidatingAdmissionPolicy that rejects unsigned images for pods created outside the derivation pipeline (direct kubectl apply of a Deployment) is not implemented. The current model relies on the derivation pipeline being the only path to production.
Gateway API rate limiting (Chapter 15). Rate limiting at the Gateway is not implemented. It’s a Gateway-level concern that the platform could derive from the service spec’s ingress block.
Cedar policy webhook validation (Chapter 13). Cedar policies are validated by a webhook for syntax. Semantic validation (detecting overly broad permits, conflicting rules) is not implemented.
Spec drift detection (Chapter 20). Comparing CRD specs on the cluster against specs in git and reporting divergence in the CRD status is described but not built.
Design Patterns (Not Platform Features)
Section titled “Design Patterns (Not Platform Features)”These are architectural patterns described in the book that any platform builder could implement. They are not Lattice-specific features — they’re transferable ideas.
- Trust bundle federation as an alternative to shared root CA (Chapter 15)
- API gateway approach for cross-cluster communication (Chapter 15)
- Independent enforcement layers with 3, 4, or 5 layers (Chapter 12)
- Forced migration vs indefinite legacy support strategies (Chapter 23)
- Cycle-based test verification as a replacement for flat timeouts (Chapter 21)