
Domain Cloud Native
Apply Layer 3 cloud-native domain rules—stateless pods, graceful shutdown, tracing—when designing or reviewing Rust microservices for Kubernetes.
Overview
domain-cloud-native is an agent skill most often used in Build (also Ship/security-adjacent review, Operate/infra) that encodes Kubernetes-ready Rust constraints for statelessness, shutdown, tracing, and small container
Install
npx skills add https://github.com/actionbook/rust-skills --skill domain-cloud-nativeWhat is this skill?
- Domain constraint table maps 12-factor, observability, health checks, and horizontal scale to Rust choices
- Stateless design rule: no local persistent state—externalize to Redis/DB, avoid static mut
- Graceful shutdown pattern: SIGTERM handling and connection drain via tokio::signal
- Observability rule: traceable requests with tracing spans and OpenTelemetry export
- Container-friendly release builds for small binaries on Kubernetes
- 6-row domain constraints table linking cloud rules to Rust implications
- 3 critical constraint blocks: stateless design, graceful shutdown, observability
Adoption & trust: 735 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are writing Rust microservices for Kubernetes but risk static state, missing probes, or untraceable requests that break scale and rollouts.
Who is it for?
Indie backend devs targeting tonic/gRPC or HTTP services in Docker/K8s who want domain rules the agent applies during design and review.
Skip if: Greenfield learners with no Rust async basics, front-end-only work, or teams needing a full Terraform/platform provisioning skill rather than application constraints.
When should I use this skill?
Building cloud-native apps with keywords kubernetes, docker, grpc, tonic, microservice, observability, tracing, health checks, deployment—Layer 3 domain constraints for Rust.
What do I get? / Deliverables
You align service design with 12-factor and K8s realities—externalized state, graceful shutdown, OpenTelemetry-ready tracing, and release-optimized binaries—before implementation drift.
- Cloud-native constraint checklist applied to a service design
- Mapping from domain rules to tracing, shutdown, and state externalization choices
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build/backend because constraints shape service design before ship and operate hardening, though they recur in later phases. Backend subphase captures microservice boundaries, gRPC/tonic APIs, health endpoints, and env-based config implied by 12-factor and K8s deployment.
Where it fits
Define a tonic gRPC service with env-based config and no static mut state before writing handlers.
Verify liveness/readiness endpoints and shutdown hooks match rollout expectations in staging.
Trace request failures across pods using consistent OpenTelemetry span propagation.
How it compares
Domain constraint layer for Rust services—not a deploy script; pair infra/GitOps skills for cluster provisioning separately.
Common Questions / FAQ
Who is domain-cloud-native for?
Rust builders deploying containerized microservices who need cloud-native invariants reflected in code structure and observability hooks.
When should I use domain-cloud-native?
Use in Build/backend when shaping APIs and workers for K8s; in Ship when reviewing readiness for production rollouts; in Operate/infra when debugging trace gaps or shutdown behavior in running pods.
Is domain-cloud-native safe to install?
It is declarative guidance in the Rust skills repo; review the Security Audits panel on this Prism page and any companion skills that invoke shell or cluster commands.
SKILL.md
READMESKILL.md - Domain Cloud Native
# Cloud-Native Domain > **Layer 3: Domain Constraints** ## Domain Constraints → Design Implications | Domain Rule | Design Constraint | Rust Implication | |-------------|-------------------|------------------| | 12-Factor | Config from env | Environment-based config | | Observability | Metrics + traces | tracing + opentelemetry | | Health checks | Liveness/readiness | Dedicated endpoints | | Graceful shutdown | Clean termination | Signal handling | | Horizontal scale | Stateless design | No local state | | Container-friendly | Small binaries | Release optimization | --- ## Critical Constraints ### Stateless Design ``` RULE: No local persistent state WHY: Pods can be killed/rescheduled anytime RUST: External state (Redis, DB), no static mut ``` ### Graceful Shutdown ``` RULE: Handle SIGTERM, drain connections WHY: Zero-downtime deployments RUST: tokio::signal + graceful shutdown ``` ### Observability ``` RULE: Every request must be traceable WHY: Debugging distributed systems RUST: tracing spans, opentelemetry export ``` --- ## Trace Down ↓ From constraints to design (Layer 2): ``` "Need distributed tracing" ↓ m12-lifecycle: Span lifecycle ↓ tracing + opentelemetry "Need graceful shutdown" ↓ m07-concurrency: Signal handling ↓ m12-lifecycle: Connection draining "Need health checks" ↓ domain-web: HTTP endpoints ↓ m06-error-handling: Health status ``` --- ## Key Crates | Purpose | Crate | |---------|-------| | gRPC | tonic | | Kubernetes | kube, kube-runtime | | Docker | bollard | | Tracing | tracing, opentelemetry | | Metrics | prometheus, metrics | | Config | config, figment | | Health | HTTP endpoints | ## Design Patterns | Pattern | Purpose | Implementation | |---------|---------|----------------| | gRPC services | Service mesh | tonic + tower | | K8s operators | Custom resources | kube-runtime Controller | | Observability | Debugging | tracing + OTEL | | Health checks | Orchestration | `/health`, `/ready` | | Config | 12-factor | Env vars + secrets | ## Code Pattern: Graceful Shutdown ```rust use tokio::signal; async fn run_server() -> anyhow::Result<()> { let app = Router::new() .route("/health", get(health)) .route("/ready", get(ready)); let addr = SocketAddr::from(([0, 0, 0, 0], 8080)); axum::Server::bind(&addr) .serve(app.into_make_service()) .with_graceful_shutdown(shutdown_signal()) .await?; Ok(()) } async fn shutdown_signal() { signal::ctrl_c().await.expect("failed to listen for ctrl+c"); tracing::info!("shutdown signal received"); } ``` ## Health Check Pattern ```rust async fn health() -> StatusCode { StatusCode::OK } async fn ready(State(db): State<Arc<DbPool>>) -> StatusCode { match db.ping().await { Ok(_) => StatusCode::OK, Err(_) => StatusCode::SERVICE_UNAVAILABLE, } } ``` --- ## Common Mistakes | Mistake | Domain Violation | Fix | |---------|-----------------|-----| | Local file state | Not stateless | External storage | | No SIGTERM handling | Hard kills | Graceful shutdown | | No tracing | Can't debug | tracing spans | | Static config | Not 12-factor | Env vars | --- ## Trace to Layer 1 | Constraint | Layer 2 Pattern | Layer 1 Implementation | |------------|-----------------|------------------------| | Stateless | External state | Arc<Client> for external | | Graceful shutdown | Signal handling | tokio::signal | | Tracing | Span lifecycle | tracing + OTEL | | Health checks | HTTP endpoints | Dedicated routes | --- ## Related Skills | When | See | |------|-----| | Async patterns | m07-concurrency | | HTTP endpoints | domain-web | | Error handling | m13-domain-error | | Resource lifecycle