Cloud-Native Approaches — 12-Factor App and What It Means in Practice

“Cloud-native” has moved from conferences to real project requirements over the past year. What does it actually mean? For us, it’s a set of principles that make an application operable, scalable, and resilient. The 12-factor app is a good starting point.

12-Factor App — What Actually Makes Sense¶

III. Config in env vars. No configuration files in git. On Kubernetes, use ConfigMaps and Secrets.

VI. Stateless processes. Sessions in Redis, files in object storage, shared cache. 10 replicas, the load balancer distributes them anywhere.

XI. Logs as event streams. The application logs to stdout. Infrastructure (Fluentd) collects and sends to Elasticsearch.

Health Checks — Readiness vs. Liveness¶

Liveness: “Is it alive?” — Kubernetes restarts it. Readiness: “Is it accepting traffic?” — removed from the load balancer. A bad liveness timeout → restart loop under load. Spring Boot Actuator handles this elegantly.

Graceful Shutdown¶

SIGTERM → stop accepting requests → finish in-progress work → exit. Pre-stop hook (sleep 5) gives the load balancer time to remove the pod. Watch out for batch jobs (checkpoint/resume), DB pools (drain), message consumers.

Observability — Three Pillars¶

• Metrics (Prometheus): RED method — request rate, error rate, duration
• Logs (ELK/Loki): structured JSON with correlation ID
• Tracing (Jaeger): distributed tracing across services — game changer

Immutable Infrastructure¶

No SSH to production. No quick fixes on a pod. Change = new version through CI/CD. A pod is cattle, not a pet. More of a cultural change than a technical one.