
Domain Cloud Native
- 609 installs
- 1.3k repo stars
- Updated May 24, 2026
- zhanghandong/rust-skills
This is a copy of domain-cloud-native by actionbook - installs and ranking accrue to the original listing.
domain-cloud-native is a Rust Claude Code skill that applies cloud-native architecture rules and Rust implementation patterns when creating scalable, observable microservices.
About
domain-cloud-native is Layer 3 domain constraints in the rust-skills stack for cloud-native Rust services. A constraint table links domain rules—12-Factor config from env, observability with metrics and traces, liveness/readiness health checks, graceful shutdown—to Rust design choices like environment-based config, tracing plus OpenTelemetry, dedicated health endpoints, and clean termination handling. Keywords span kubernetes, docker, grpc, tonic, microservice, service mesh, and observability. Developers reach for domain-cloud-native when scaffolding Rust microservices destined for k8s with production-grade telemetry and health probe endpoints.
- 12-Factor compliant environment-based configuration
- Stateless design with external state stores (Redis/DB)
- Graceful shutdown using tokio::signal for zero-downtime
- Full observability with tracing spans and OpenTelemetry export
- Health-check endpoints and container-friendly small binaries
Domain Cloud Native by the numbers
- 609 all-time installs (skills.sh)
- +6 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill domain-cloud-nativeAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 609 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | zhanghandong/rust-skills ↗ |
How do you build cloud-native Rust microservices?
Apply cloud-native architecture rules and Rust patterns when creating scalable, observable microservices.
Who is it for?
Rust backend engineers deploying tonic gRPC microservices to Kubernetes with observability and 12-Factor configuration requirements.
Skip if: Single-binary CLI tools, frontend Rust WASM apps, or teams not targeting container orchestration and distributed service meshes.
When should I use this skill?
User builds Rust microservices for kubernetes, docker, grpc/tonic, or cloud deployment with observability and health checks.
What you get
Rust microservice code with env-based config, tracing/OpenTelemetry instrumentation, gRPC endpoints, and liveness/readiness health handlers.
- Cloud-native Rust microservice scaffold
- Health check and tracing instrumentation
Files
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 mutGraceful Shutdown
RULE: Handle SIGTERM, drain connections
WHY: Zero-downtime deployments
RUST: tokio::signal + graceful shutdownObservability
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
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
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 | m12-lifecycle |
Related skills
FAQ
What cloud-native rules does domain-cloud-native enforce?
domain-cloud-native maps 12-Factor configuration, observability (metrics and traces), health checks, and graceful shutdown to Rust design constraints including tracing, OpenTelemetry, and dedicated probe endpoints.
Which Rust crates does domain-cloud-native emphasize?
domain-cloud-native highlights tonic for gRPC, tracing for instrumentation, and OpenTelemetry for observability, alongside environment-based config and health check endpoints for Kubernetes deployments.
Where does domain-cloud-native sit in rust-skills?
domain-cloud-native is Layer 3 domain constraints in the rust-skills hierarchy, applied when building cloud-native apps with keywords like kubernetes, docker, grpc, and microservice.
Is Domain Cloud Native safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.