Cloud-Native Architecture: Containers, Mesh, Serverless & Cost Optimization

Cloud-native architecture designs applications to fully exploit cloud platforms -- containers, orchestration, service mesh, serverless, infrastructure as code, and cost-aware engineering. This skill produces architecture documentation guiding teams from cloud readiness assessment through production-grade deployment.

Principio Rector

Cloud-native no es "mover a la nube" — es diseñar PARA la nube. Contenedores por defecto, service mesh para observabilidad, serverless donde stateless, FinOps integral desde el día uno. El objetivo no es usar servicios cloud — es explotar las propiedades de la nube: elasticidad, resiliencia, observabilidad y optimización continua de costos.

Filosofía de Cloud-Native

1. Containers by default. Todo workload comienza como contenedor. Solo se desvía a serverless (stateless, event-driven) o VM (legacy sin refactor) con justificación explícita.
2. Service mesh para observabilidad. mTLS, traffic management y distributed tracing no son opcionales — son infraestructura base para operar microservicios en producción.
3. Serverless where stateless. Funciones serverless para procesamiento de eventos, transformaciones, y glue code. Nunca para lógica stateful o latencia crítica.
4. FinOps integral. El costo es un atributo de calidad. Se mide, se asigna, se optimiza. OpenCost desde el día uno.

Inputs

The user provides a system or platform name as $ARGUMENTS. Parse $1 as the system/platform name used throughout all output artifacts.

Parameters:

• {MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
  • piloto-auto: Auto para assessment y container strategy, HITL para decisiones mesh/serverless y FinOps targets.
  • desatendido: Cero interrupciones. Arquitectura cloud-native documentada automáticamente. Supuestos documentados.
  • supervisado: Autónomo con checkpoint en mesh adoption y multi-cloud decisions.
  • paso-a-paso: Confirma cada 12-factor assessment, container design, mesh config, y FinOps plan.
• {FORMATO}: markdown (default) | html | dual
• {VARIANTE}: ejecutiva (~40% — S1 assessment + S2 container strategy + S6 FinOps) | técnica (full 6 sections, default)

Before generating architecture, detect cloud-native context:

!find . -name "Dockerfile" -o -name "*.yaml" -o -name "*.tf" -o -name "helm" -type d -o -name "serverless.yml" | head -20

If reference materials exist, load them:

Read ${CLAUDE_SKILL_DIR}/references/cloud-native-patterns.md

When to Use

• Assessing application readiness for cloud-native transformation
• Designing container strategy and Kubernetes architecture
• Evaluating service mesh adoption (Istio, Linkerd, Cilium)
• Making serverless vs. container decisions per workload
• Planning multi-cloud or cloud-agnostic architecture
• Implementing FinOps practices for cost visibility and optimization

When NOT to Use

• Infrastructure platform design (VPCs, compute, storage) --> use infrastructure-architecture skill
• CI/CD pipelines and supply chain security --> use devsecops-architecture skill
• Application internal structure and patterns --> use software-architecture skill
• Migrating existing workloads to cloud --> use cloud-migration skill

Delivery Structure: 6 Sections

S1: Cloud-Native Assessment

Evaluate the application against cloud-native principles to identify gaps and transformation priorities.

12-Factor Compliance Audit: Rate each factor as compliant / partial / non-compliant with remediation effort (S/M/L):

1. Codebase: one repo, many deploys
2. Dependencies: explicitly declared, isolated
3. Config: stored in environment, not code
4. Backing services: attached resources (DB, cache, queue)
5. Build/release/run: strict stage separation
6. Processes: stateless, share-nothing
7. Port binding: self-contained, export via port
8. Concurrency: scale out via process model
9. Disposability: fast startup (<10s), graceful shutdown (SIGTERM handler, drain connections)
10. Dev/prod parity: minimize environment drift
11. Logs: treat as event streams (stdout)
12. Admin processes: run as one-off tasks

Containerization Readiness Checklist:

• Stateful components identified (database, file storage, sessions)
• External dependency inventory (APIs, queues, caches)
• Configuration externalized to env vars or config maps
• Health check endpoints (liveness + readiness + startup probes)
• Graceful shutdown with connection draining
• Secret management via Vault, AWS Secrets Manager, or sealed-secrets

S2: Container & Orchestration Strategy

Container Image Best Practices:

• Base images: distroless (Google) or Alpine (<5MB). Never use latest tag.
• Multi-stage builds: separate build and runtime layers. Final image <100MB target.
• Image scanning in CI: Trivy (CNCF, free), Grype, or Snyk Container. Block Critical/High CVEs.
• Registry: private, image signing (cosign/Sigstore), tag immutability enforced.

Kubernetes Architecture:

• Cluster topology: single-cluster per env (simple) vs. multi-cluster per region (HA/DR).
• Namespace strategy: per-team or per-service. Enforce with NetworkPolicies + RBAC.
• Pod design: sidecar for cross-cutting (logging, proxy), init containers for bootstrapping, PodDisruptionBudgets for availability.

Resource Request/Limit Guidance:

• Start with VPA in recommend-only mode for 7+ days before tuning.
• Default LimitRange guardrails: 100m CPU / 128Mi request, 500m CPU / 512Mi limit.
• Overcommit ratio: 1.2-1.5x for CPU (safe burst), 1.0x for memory (no overcommit).

Node Autoscaling Decision Matrix:

• Prefer Karpenter on EKS for new deployments: faster provisioning, better bin-packing, native spot/OD mix, consolidation (replaces underutilized nodes automatically).
• Use Cluster Autoscaler only when Karpenter is unavailable (AKS, on-prem) or organizational policy requires ASG-based scaling.

Pod Autoscaling Decision Matrix:

• Never combine VPA and HPA on the same metric.
• Combination pattern: KEDA for async + HPA for HTTP + VPA recommend-only + Karpenter for nodes.

GitOps Deployment:

• ArgoCD or Flux for declarative, auditable, rollback-capable deployments.
• Helm charts with values-per-environment. OCI registry for chart storage.

S3: Service Mesh & Networking

Gateway API vs. Ingress (2025-2026):

• Migrate all new clusters to Gateway API. Existing Ingress: plan migration before NGINX retirement.
• Recommended implementations: Envoy Gateway (highest conformance), Cilium Gateway (if already using Cilium CNI).

CNI & Service Mesh Comparison:

• Decision rule: <10 services with simple patterns = no mesh. Need mTLS only = Cilium or Istio Ambient. Need L7 traffic management = Istio Sidecar or Linkerd. Already using Cilium CNI = Cilium Service Mesh.

mTLS & Zero Trust: Mesh-managed short-lived certificates (hours). Service-to-service RBAC, deny-by-default. SPIFFE identities.

Traffic Management: Canary (gradual shift), blue-green (instant), A/B (header/weight). Circuit breaking, rate limiting, retry/timeout (idempotent operations only).

Observability Stack:

• Distributed tracing: OpenTelemetry (CNCF standard) with Jaeger or Grafana Tempo.
• Metrics: Prometheus + Grafana. RED metrics per service (Rate, Errors, Duration).
• eBPF-based observability (zero-instrumentation): Cilium Hubble (network flows), Pixie (auto-instrumented traces), Tetragon (security events). Use for polyglot environments where manual instrumentation is impractical.

S4: Serverless Decision Framework

Decision Matrix:

Cold Start Mitigation: Provisioned concurrency, smaller packages (tree-shaking, layers), language choice (Go/Rust <100ms, Java/C# 500ms-2s), SnapStart (Java on Lambda), warm-up pings.

State Management: External stores (DynamoDB, Redis, S3). Step Functions / Durable Functions for orchestration. Event-driven decoupling via queues.

Vendor Lock-in Assessment: Abstraction layers (SST, Pulumi, Serverless Framework). Exit cost per component. Prefer open standards (CloudEvents, OpenTelemetry).

S5: Multi-Cloud & Portability

Strategy Tiers:

• Tier 1: Cloud-agnostic app (Kubernetes, standard APIs). Cost: low. Benefit: portability.
• Tier 2: Portable infrastructure (Terraform, Crossplane). Cost: medium. Benefit: negotiation leverage.
• Tier 3: Active multi-cloud (workloads distributed). Cost: high. Benefit: DR, compliance, best-of-breed.

Abstraction Approaches:

• Kubernetes as portability layer: same manifests across EKS/GKE/AKS.
• Terraform: provider-agnostic HCL modules. State in remote backend.
• Crossplane: Kubernetes-native infrastructure provisioning across clouds.
• Application-level: abstract cloud SDKs behind interfaces (storage, queue, identity).

Cloud-Agnostic Patterns:

• Use open standards: S3-compatible storage (MinIO), OpenTelemetry, OIDC, CloudEvents.
• Data gravity: place compute near data; minimize cross-cloud data transfer.
• Policy-as-code: OPA/Gatekeeper enforced across all clusters.

S6: FinOps Integration

FinOps Tooling Comparison:

• Start with OpenCost for Kubernetes-native cost allocation. Add Kubecost for savings recommendations. Use Vantage or CloudHealth for multi-cloud executive dashboards.
• OpenCost 2025: runs without Prometheus (Collector Datasource), MCP server for AI agent cost queries, plugin framework for Datadog/OpenAI/MongoDB Atlas cost monitoring.

Cost Allocation: Namespace/pod-level via OpenCost/Kubecost. Label strategy: team, service, environment, cost-center. Showback reports per team.

Optimization Levers:

• Rightsizing: VPA recommendations after 2+ weeks of data.
• Spot/preemptible: 60-90% savings for fault-tolerant workloads. Karpenter automates spot/OD mix.
• Scale to zero: KEDA for queue workers, serverless for event-driven.
• Ephemeral environments: spin up per PR, tear down on merge.
• Storage lifecycle: S3 Intelligent Tiering, EBS snapshot cleanup.
• Network: minimize cross-AZ traffic via topology-aware routing.

Cost Governance:

• Daily cost by team/service/environment dashboard.
• Unit economics: cost per user, cost per transaction.
• Anomaly alerts: >20% daily spike triggers investigation.
• Budget alerts per account, per namespace.

Trade-off Matrix

Assumptions

• Application is being modernized or built for cloud deployment
• Team has or is developing container and orchestration skills
• Cloud provider(s) selected or shortlisted
• Budget includes cloud-native tooling (mesh, GitOps, cost tools)

Limits

• Does not design internal application architecture (use software-architecture skill)
• Does not cover infrastructure platform setup (use infrastructure-architecture skill)
• Does not plan CI/CD pipelines (use devsecops-architecture skill)
• FinOps practices require organizational buy-in beyond architecture decisions

Edge Cases

Monolith Containerization: Containerize the monolith first (lift-and-shift to container), then decompose. Use strangler fig pattern. Do not attempt simultaneous containerization and decomposition.

Stateful Workloads on Kubernetes: Use operators (CloudNativePG for PostgreSQL, Strimzi for Kafka). Alternative: managed services outside K8s. Evaluate operational burden vs. portability.

Serverless at Scale (>10M invocations/month): Model break-even point. Container alternative often cheaper at high volume. Reserved concurrency or Fargate may be more cost-effective.

Regulated Industries: Service mesh mTLS may be mandatory. Image provenance required (SLSA, Sigstore/cosign). Multi-cloud may be required for data residency. Audit logging at infrastructure layer.

Small Team (<5 developers): Full K8s + mesh is likely over-engineered. Use managed Kubernetes, skip mesh, use cloud-managed services. Revisit as team grows.

Validation Gate

Before finalizing delivery, verify:

• 12-factor compliance gaps identified with remediation plan
• Container strategy includes security scanning and minimal base images
• Resource requests/limits configured per guidance table (CPU burst, memory capped)
• Node autoscaler selected (Karpenter vs. CA) with rationale
• Service mesh decision justified (adopt vs. defer) with comparison matrix
• Gateway API adopted for ingress (or migration plan from Ingress documented)
• Serverless vs. container decision documented per workload
• FinOps tooling deployed (OpenCost minimum) with cost allocation labels
• Auto-scaling configured for all stateless workloads (HPA/KEDA + Karpenter)
• GitOps deployment pipeline in place

Output Format Protocol

Default output is Markdown with embedded Mermaid diagrams. HTML generation requires explicit {FORMATO}=html parameter.

Output Artifact

Primary: A-01_Cloud_Native_Architecture.html -- Executive summary, 12-factor assessment, container strategy, Kubernetes architecture, service mesh design, serverless decisions, multi-cloud plan, FinOps dashboard.

Secondary: Kubernetes manifest templates, Helm chart structure, service mesh configuration, cost allocation report, 12-factor compliance checklist.

Casos Borde

Decisiones y Trade-offs

Knowledge Graph

graph TD
    subgraph Core["Conceptos Core"]
        ASSESS["12-Factor Assessment"]
        CONTAINER["Container & Orchestration"]
        MESH["Service Mesh & Networking"]
        SERVERLESS["Serverless Decision"]
        MULTICLOUD["Multi-Cloud & Portability"]
        FINOPS["FinOps Integration"]
    end

    subgraph Inputs["Entradas"]
        APP["Application Codebase"]
        INFRA["Current Infrastructure"]
        CLOUD["Cloud Provider(s)"]
        REQS["NFRs & SLAs"]
    end

    subgraph Outputs["Salidas"]
        ARCH["Cloud-Native Architecture Doc"]
        MANIFESTS["K8s Manifest Templates"]
        HELM["Helm Chart Structure"]
        COSTDASH["Cost Allocation Report"]
    end

    subgraph Related["Skills Relacionados"]
        INFRAARCH["infrastructure-architecture"]
        DEVSEC["devsecops-architecture"]
        SWARCH["software-architecture"]
        MIGRATION["cloud-migration"]
    end

    APP --> ASSESS
    INFRA --> CONTAINER
    CLOUD --> MULTICLOUD
    REQS --> MESH
    ASSESS --> CONTAINER
    CONTAINER --> MESH
    MESH --> SERVERLESS
    SERVERLESS --> MULTICLOUD
    MULTICLOUD --> FINOPS
    ARCH --> MANIFESTS
    ARCH --> HELM
    FINOPS --> COSTDASH
    INFRAARCH -.-> CONTAINER
    DEVSEC -.-> MESH
    SWARCH -.-> ASSESS
    MIGRATION -.-> CONTAINER

Output Templates

Formato Markdown (default):

# Cloud-Native Architecture: {platform}
## S1: Cloud-Native Assessment
### 12-Factor Compliance Audit
| Factor | Status | Remediation | Effort |
...
### Containerization Readiness Checklist
## S2: Container & Orchestration Strategy
### Kubernetes Architecture
### Resource Requests/Limits
### Autoscaling Strategy
## S3: Service Mesh & Networking
### CNI & Mesh Selection
### mTLS & Zero Trust
## S4: Serverless Decision Framework
### Decision Matrix per Workload
## S5: Multi-Cloud & Portability
## S6: FinOps Integration
### Cost Allocation Labels
### Optimization Levers

Formato DOCX (bajo demanda):

1. Executive Summary — cloud-native readiness + key decisions
2. 12-Factor Compliance Matrix — status per factor con remediation plan
3. Container Strategy — image standards, registry, K8s topology
4. Networking & Security — mesh selection, Gateway API, mTLS
5. Serverless vs Container Decisions — per-workload matrix
6. Multi-Cloud Architecture — portability tier, abstraction approach
7. FinOps Dashboard Spec — cost allocation, optimization targets
Appendix A: K8s Manifest Templates
Appendix B: Helm Values per Environment

Formato HTML (bajo demanda):

• Filename: A-01_Cloud_Native_Architecture_{cliente}_{WIP}.html
• Estructura: HTML self-contained branded (Design System MetodologIA v5). Light-First Technical page con 12-factor compliance audit interactivo, service mesh comparison matrix, y FinOps cost allocation dashboard. WCAG AA, responsive, print-ready.

Formato XLSX (bajo demanda):

• Filename: {fase}_{entregable}_{cliente}_{WIP}.xlsx
• Via openpyxl con Design System MetodologIA v5. Headers branded (fondo navy, texto blanco, Poppins), formato condicional con colores semaforo, auto-filtros, valores sin formulas. Para auditoria 12-factor, matriz de decision serverless vs container y tracking de optimizacion FinOps.

Formato PPTX (bajo demanda):

• Filename: {fase}_{entregable}_{cliente}_{WIP}.pptx
• Via python-pptx con MetodologIA Design System v5. Slide master con gradiente navy, titulos Poppins, cuerpo Montserrat, acentos gold. Max 20 slides (ejecutiva) / 30 slides (tecnica). Speaker notes con referencias de evidencia. Para comites directivos y presentaciones C-level.

Evaluacion

Umbral minimo: 7/10. Debajo de este umbral, revisar 12-factor audit completeness y FinOps tooling integration.

Autor: Javier Montano · Comunidad MetodologIA | Ultima actualizacion: 15 de marzo de 2026