What Cloud‑Native Tech Stack Should You Use in 2024? A Real‑World Guide

Background

After ten years of moving from monolithic SSM/H frameworks to Kubernetes‑based cloud‑native architectures, the author summarizes the major phases (SOA, micro‑services, cloud‑native, service mesh, serverless) and explains why a comprehensive view of the 2024 stack is needed.

Operating System

The only viable cloud‑native operating system today is Kubernetes. Maintaining a self‑hosted cluster is complex; small teams are advised to use a managed Kubernetes service from a cloud provider, while larger teams should allocate dedicated staff for cluster upkeep.

Multi‑Cloud Advantages

Relying on a single cloud provider can expose you to outages (e.g., the 2023 Alibaba Cloud incident). A multi‑cloud approach mitigates risk by deploying the same code to multiple providers, but it raises challenges such as data consistency. The author recommends using distributed databases or middleware (e.g., Pulsar) that support cross‑region synchronization, and accepting limited runtime data loss during failover.

DevOps

With Kubernetes as the foundation, CI/CD revolves around GitOps. The workflow uses GitLab for source control and pipelines, and ArgoCD to continuously deliver applications to the cluster.

The diagram shows GitLab managing code, pipelines handling builds/tests, and ArgoCD synchronizing the desired state to Kubernetes (GitOps).

Rollback, scaling, and other operations are performed via Kubernetes APIs, and FinOps practices are applied to reclaim unused resources and reduce costs.

Service Mesh

The evolution from local function calls to RPC frameworks, then micro‑services, and finally service mesh is illustrated:

local+------>remote +------> micro-service+----->service-mesh
               +                  |
               v                  v                    v
           +---+----+       +-----+------+        +----+----+
           | motan  |       | SpringCloud|        | Istio   |
           | dubbo  |       | Dubbo3.0   |        | Linkerd |
           | gRPC   |       | SOFA       |        |        |
           +--------+       +------------+        +---------+

Key points:

RPC frameworks simplify distributed communication.

Micro‑service frameworks add governance features such as rate limiting and circuit breaking.

Service mesh abstracts these concerns, letting developers focus on business logic while the mesh provides traffic management, security, and observability.

Istio is recommended when the following conditions are met:

Applications run on Kubernetes.

gRPC is used for inter‑service communication.

API gateway is migrated to Istio Gateway.

At least one dedicated person understands and can maintain Istio.

Other meshes (e.g., Linkerd) or micro‑service frameworks (SpringCloud, Dubbo, Kratos, go‑zero) are also viable.

Observability

Three core pillars are emphasized: Metrics (visualized in Grafana, using VictoriaMetrics as a Prometheus‑compatible TSDB), Traces (using SkyWalking, later migrated to OpenTelemetry), and Logs (collected via Filebeat and stored in Elasticsearch). The migration to OpenTelemetry improves vendor neutrality and future‑proofs the stack.

Message Queue

Pulsar is highlighted as a cloud‑native message queue with storage‑compute separation, making scaling easier than Kafka. The author lists language client support (Java, C++, Python, Go, Node.js, C#) and discusses deployment options (self‑hosted vs. managed services). Community activity and ease of maintenance are cited as advantages.

Business Framework

Choice of language drives framework selection. For Java, simple Spring Boot suffices for small teams; larger teams may adopt Dubbo or Spring Cloud, while teams with a dedicated cloud‑native group should use a service mesh with gRPC. For Go, Gin works for small teams, and frameworks like Kratos or go‑zero serve larger teams. The author notes that Go’s simplicity often leads to cleaner code.

Conclusion

The author summarizes that there is no universally perfect stack; the best choice aligns with team size, expertise, and risk tolerance. Real‑world experience and honest assessment of operational overhead are essential for successful adoption.