What separates a cloud native platform that runs quietly from one that wakes engineers at 3 a.m.? Usually not the tooling. It is a short list of habits that teams adopt early or learn the hard way. The Cloud Native Computing Foundation, which stewards Kubernetes and dozens of related projects, defines the approach as building and running scalable applications in changing environments with containers, service meshes, microservices, immutable infrastructure, and declarative APIs. That definition states the approach in one sentence. The hard part is applying it every day. (AI Chips and Computing Infrastructure) (Cloud-native computing)
This article walks through the practices that consistently matter, the mistakes that show up again and again, and the trade-offs nobody warns you about.
Start With the Application, Not the Cluster
A common failure mode is treating Kubernetes as the goal. Teams containerize a legacy monolith, deploy it, and wonder why nothing improved. Cloud native design begins one layer up, with how the application is built.
The twelve-factor methodology, published by Adam Wiggins in 2011, still reads like a checklist for what breaks in production. Config belongs in the environment, not baked into images. Processes should be stateless so any instance can serve any request. Logs should flow out as event streams rather than being written to local files that vanish with the container. Dev and production should stay as similar as possible.
None of this requires Kubernetes. It requires discipline. A useful exercise is to take one service and ask three questions: can it start on a fresh machine with only environment variables, can two copies run side by side without colliding, and can it die at any moment without losing data? If the answer to any is no, that is the next piece of work, not a new platform feature.
One practical warning: the twelve-factor advice on logs conflicts with how many clusters actually collect them. Node-level agents and sidecar shippers are both common and both fine. Treat the factors as principles to reason from, not commandments.
Make Declarative Configuration the Source of Truth
Declarative systems describe the desired end state and let a controller close the gap. That is the core idea behind Kubernetes objects, and it is also where teams get sloppy. Manually editing live resources with kubectl creates drift that nobody can reproduce.
GitOps formalizes the fix. The term was coined around 2017, and the OpenGitOps project later published four principles: the desired state is declarative, versioned and immutable, pulled automatically, and continuously reconciled. In practice this means a Git repository holds the manifests, an agent inside the cluster applies them, and any manual change is overwritten. The payoff is an audit trail and a rollback path that does not depend on someone’s memory.
Two habits make this work in practice. First, separate the application repository from the environment configuration repository so a code change and a production rollout are not the same commit. Second, keep secrets out of Git entirely and reference them through an external store. Teams that skip the second step usually discover it the day a repository goes public or a contractor leaves.
Before adopting any of this, it helps to know what you actually run. A structured inventory of workloads, dependencies and data flows is worth more than a tool comparison, and the guidance on what to inventory before a cloud migration maps directly onto platform work even if you are not migrating anywhere. (9481.org)
Size Workloads Honestly
Resource configuration is where good intentions meet real bills. Kubernetes lets you set requests, which the scheduler uses to place pods, and limits, which cap consumption. The official documentation on managing resources for containers explains the mechanics and the quality-of-service classes that follow from them. (Kubernetes Documentation: Overview)
The common mistakes are predictable:
- Setting no requests at all, which lets the scheduler overpack nodes and produces mysterious evictions.
- Setting limits equal to requests for everything, which forces every pod into the Guaranteed class and wastes capacity.
- Copying limits from a tutorial without measuring anything.
CPU and memory behave differently, and conflating them causes trouble. Exceeding a memory limit gets the container killed. Exceeding a CPU limit gets it throttled, which shows up as latency spikes rather than errors. Some experienced teams run latency-sensitive services without CPU limits to avoid throttling, accepting the risk of noisy neighbors. Others keep limits for isolation. It is a genuine trade-off, not a rule, and the right answer depends on whether you fear throttling or a runaway process more.
Measure first. A week of real usage data beats any default. Tools that track request and usage ratios will tell you quickly which services are over-provisioned, and the same discipline applies to data movement, where a clearer way to track cloud data transfer costs shows how often the invisible line items dwarf the compute bill.
Get Health Checks Right
Kubernetes offers three distinct probes, and mixing them up causes outages that look like application bugs. Liveness probes ask whether a container should be restarted. Readiness probes ask whether it should receive traffic. Startup probes give slow-booting applications time before the other two kick in; the startup probe arrived as alpha in Kubernetes 1.16 and became stable in 1.20 in December 2020.
The classic mistake is pointing a liveness probe at an endpoint that depends on a database. When the database hiccups, every pod restarts at once, and the outage gets worse. Liveness should check only that the process itself is healthy. Readiness can and should check dependencies, because removing a pod from the load balancer is a reversible, gentle action.
Another common error is setting timeouts too tight. A probe that fires every two seconds with a one-second timeout will restart healthy pods under load. Give startup probes generous budgets and let readiness handle the rest.
Design for Failure With Service Level Objectives
Cloud native systems fail partially and constantly. The mature response is to define what “working” means in numbers. Service level indicators measure something users care about, like request latency or success rate. Service level objectives set a target for those indicators. The difference between the target and perfect reliability becomes the error budget, which tells teams how much risk they can spend on releases.
The SRE Book chapter on service level objectives lays out the full model and makes a point that surprises newcomers: alerting on symptoms beats alerting on causes. A disk filling up is a cause. Users getting errors is a symptom. Page on the symptom, because it is what actually matters, and let dashboards handle the causes.
Observability supports this. OpenTelemetry, which merged OpenTracing and OpenCensus in 2019 and graduated within the CNCF in 2023, standardizes traces, metrics and logs behind one set of APIs and SDKs. The OpenTelemetry overview of traces, metrics and logs is a reasonable starting point for understanding how the three signals fit together. Adopting a vendor-neutral standard early saves a painful migration later, and it keeps instrumentation out of application code where possible.
Secure the Supply Chain and the Runtime
Container security has two halves that teams often treat as one. The first is what goes into the image. The second is what the container can do once it runs.
For the first half, the SLSA framework (pronounced “salsa”) defines build-integrity levels 1 through 4, and the SLSA build levels specification explains what each level requires. The practical starting point is level 1: scripted, reproducible builds with provenance. Most teams can reach it in a sprint and it closes the door on hand-built images pushed from laptops.
For the second half, NIST’s Application Container Security Guide, published in September 2017 as Special Publication 800-190, remains a solid checklist covering image, registry, orchestrator, container and host concerns. Its advice to run containers with minimal privileges and read-only filesystems is still routinely ignored, and still causes incidents.
A short list of habits that pay off:
- Pin image versions by digest, not by a floating tag.
- Scan images in the pipeline, not after deployment.
- Drop Linux capabilities the workload does not need.
- Use network policies so a compromised pod cannot reach everything.
Security posture also depends on how you segment accounts and environments. The reasoning behind when to split workloads across cloud accounts applies equally to blast-radius thinking inside a cluster.
Watch the Cost Curve
Cloud native economics are strange. The platform makes it trivial to provision, which means waste accumulates silently. Idle namespaces, orphaned load balancers, over-replicated services and forgotten volumes all bill monthly.
The practices that work are unglamorous. Tag everything at creation. Review the largest cost lines monthly with the teams that own them. Set budget alerts that reach engineers as well as finance. Treat cost as a design constraint during architecture reviews, not a cleanup task afterward. The broader material on cloud infrastructure and architecture covers how these decisions compound over time.
Train People as Well as Pipelines
The most underrated best practice is investment in the humans. A platform that only two engineers understand is a single point of failure wearing a YAML hat. Run game days. Rotate on-call. Write runbooks that a tired person can follow at 3 a.m. Give application teams enough Kubernetes literacy to read an event log without escalating.
This connects to a broader theme: enterprise AI and cloud security decisions increasingly depend on whether platform teams can explain their systems to auditors, regulators and new hires. Documentation is not overhead. It is the product.
Conclusion
Cloud native computing rewards teams that treat it as a set of disciplines rather than a shopping list. Put configuration in version control. Size workloads from data. Separate liveness from readiness. Define reliability in numbers and spend your error budget deliberately. Secure both the build and the runtime. Watch the bill. And invest in the people who carry the pager.
None of these practices require a specific vendor or a bleeding-edge stack. They require consistency, and they compound. A team that gets the fundamentals right can adopt new tooling without drama, because the principles underneath stay the same.
Frequently Asked Questions
What is cloud native computing in simple terms?
It is a way of building software that assumes the infrastructure can change at any moment. Applications run in containers, are configured through their environment, and are managed by declarative tooling that continuously works to match the desired state. The goal is software that scales, recovers, and updates without manual intervention.
Do you need Kubernetes to be cloud native?
No. The core ideas, including stateless processes, environment-based configuration and declarative deployment, predate Kubernetes and can be applied to virtual machines or serverless platforms. Kubernetes is popular because it automates a lot of the reconciliation work, but it also adds real operational complexity. Smaller teams sometimes get further with simpler platforms.
What is the difference between a liveness and a readiness probe?
A liveness probe asks whether a container should be restarted, so it should check only that the process itself is functioning. A readiness probe asks whether the container should receive traffic, so it can check dependencies like databases or caches. Failing readiness removes a pod from the load balancer; failing liveness kills and restarts it.
Should you always set CPU limits in Kubernetes?
Not necessarily. Memory limits are usually worth setting because exceeding them kills the container. CPU limits cause throttling when exceeded, which shows up as latency rather than an error, so some teams leave them off for latency-sensitive services to avoid unnecessary slowdowns. The trade-off is that a runaway process can then affect its neighbors. Measure your workloads and decide per service rather than applying one policy everywhere.
How many nines of reliability should a service target?
Far fewer than most teams assume. Each additional nine roughly multiplies the cost and slows the pace of change. A sensible approach is to set objectives from what users actually need, measure them with service level indicators, and use the remaining error budget to decide how aggressively to ship. Internal services often do fine with two or three nines.
What is the first thing a team should fix?
Usually resource requests. Missing or wildly inaccurate requests cause scheduling problems, evictions and unpredictable costs, and fixing them requires only measurement and a pull request. Health probes and declarative configuration are close behind, because both prevent outages that look like application bugs but are really platform misconfigurations.
