Cloud-native application architecture patterns formalised in 2020 through the CNCF landscape, Google Cloud's architecture framework, and Microsoft's Azure architecture center. The patterns have matured from best practices to documented, tooling-supported standards.
The twelve-factor application
The 12-Factor App methodology (from Heroku, 2012) remains the foundation. In 2020 it is table stakes for cloud-native: configuration from environment variables, stateless processes, logs to stdout, dependency isolation via package managers. The factors that are frequently violated: backing service abstraction (applications that hardcode cloud-specific SDKs rather than abstracting the backing service), and admin processes (one-off admin tasks run as separate processes, not ad-hoc container exec).
Health checks and readiness probes
Kubernetes readiness probes are the mechanism by which an application signals that it is ready to receive traffic. An application that is starting up, initialising its connection pool, or warming a cache should not receive traffic until ready. The readiness probe checks: database connection health, upstream dependency reachability, and application-specific readiness conditions. A failed readiness probe removes the pod from the load balancer's endpoint list without restarting the pod.
Graceful shutdown
Cloud-native applications must handle SIGTERM gracefully: stop accepting new requests, complete in-flight requests, close connections to downstream services and databases, and then exit. The Kubernetes pod termination sequence: SIGTERM sent, terminationGracePeriodSeconds allowed for cleanup, SIGKILL sent if the process has not exited. Applications that do not implement graceful shutdown lose in-flight requests on every deployment.
The sidecar pattern
The sidecar pattern (a helper container in the same pod as the application container) externalises cross-cutting concerns from the application: a logging sidecar that forwards logs to a centralised system, an Envoy proxy sidecar that handles mTLS and traffic management, a secrets rotation sidecar that refreshes secrets in a shared volume. The application does not need to implement these concerns; they are provided by the sidecar. This is the foundation of service mesh implementations.