What does cloud-native development actually require?
Cloud-native describes an application built to survive what a cloud platform routinely does to it: restart it without warning, run several copies at once, move it to a different machine and take its local disk away. A container is the packaging, not the property. Plenty of containerised applications are not cloud-native in any useful sense, and they say so the first time an orchestrator reschedules them.
Is a containerised application already cloud-native?
No. Containerising changes how an application is shipped, not how it behaves. If it writes uploads to local disk, keeps sessions in process memory, takes four minutes to start or assumes it is the only copy running, the container preserves every one of those traits and hides them behind a tidy build pipeline.
The gap shows up the moment the platform does something ordinary. A node gets drained and the pod moves. A rolling deploy starts a second replica before the first has gone. An autoscaler adds a third instance at lunchtime and removes it at two. All three are routine operations, and all three are fatal to an application that assumed continuity of process and disk.
The test takes an afternoon. Run two copies behind a load balancer, use the application through both, then kill one at random mid-session. An application that is merely containerised loses whatever that copy was holding. A cloud-native one loses a connection, and the client retries.
What does the platform assume about your application?
Six things, none of which are written down anywhere in your codebase, which is why they get discovered in production. The platform assumes it may stop your process at any moment, that it may run any number of copies, that the filesystem is disposable, that configuration comes from outside the image, that you will say when you are ready to serve, and that every network call can fail or hang.
Read these as a contract rather than a set of good practices. Each one has a specific code consequence and a specific way of failing when it is ignored, and the failures are the sort that appear under load or during a deploy rather than in testing.
| Platform assumption | What it means in code | What breaks if you ignore it |
|---|---|---|
| The process can be killed at any moment | No work held only in memory; anything in flight is resumable | Half-written records and jobs that vanish on every deploy |
| More than one copy runs at once | No in-process cache treated as truth, no timer that assumes it is alone | Duplicate emails, two workers claiming one job, caches that disagree |
| Local disk is temporary and per-copy | Uploads and generated files go to object storage | Files that exist on one instance and 404 on the next |
| Configuration arrives from outside the image | Read from environment or a mounted file, never baked in | Rebuilding and re-testing an image to change a hostname |
| The platform asks whether you are ready | Separate liveness and readiness endpoints that mean different things | Traffic routed into an instance still loading its caches |
| Every network call can fail or hang | Timeouts on every outbound call, retries with backoff, idempotent handlers | One slow dependency exhausting the thread pool of the whole fleet |
Does cloud-native mean microservices?
No, and treating the two as the same thing is the most expensive assumption in this field. A single deployable application can satisfy every item above: stateless, configured from the environment, honest about readiness, safe to run in multiples, safe to kill. That application is cloud-native. Splitting it into fourteen services adds a distributed system to your problems and adds none of those properties by itself.
Splitting pays when two conditions hold together: parts of the system have genuinely different scaling profiles, and separate teams need to release without coordinating. One without the other rarely justifies the cost, because the price of the split is paid in network calls, partial failure, distributed tracing and a deployment matrix that grows with the service count.
The question to ask is whether two teams currently need to deploy on the same afternoon and cannot. If you have one team and one release train, a well-built single service will outperform a microservice estate on every axis that matters, including the ones the architecture diagram is meant to improve.
What actually has to change in the code?
Less than a rewrite and considerably more than a Dockerfile. The recurring list is short: move session state to a shared store, move file writes to object storage, read configuration from the environment, expose readiness and liveness separately, handle SIGTERM by refusing new work and finishing what is in flight, put a timeout on every outbound call, and make anything that can be retried safe to run twice.
The last one surprises teams most. Cloud platforms and message brokers give you at-least-once delivery, which means a handler that charges a card or sends an email will eventually run twice for the same input. Making it idempotent usually means giving each unit of work a natural key and recording that key when the work completes, so the second attempt becomes a no-op rather than a duplicate charge.
Startup time is the other quiet requirement. An application that takes four minutes to become useful cannot autoscale in response to a spike, turns every rollback into a slow one, and makes node maintenance a scheduled event rather than a background activity. Anything that loads a large cache at boot is worth revisiting before anything else.
When is cloud-native the wrong choice?
When the load is steady, fits comfortably on one machine, and the team is small enough that nobody is on call. A predictable internal application with fifty users does not need elastic scaling, and giving it a container platform means adding an orchestrator, a registry, a secrets store, a monitoring stack and a set of skills to the maintenance burden of an application that was fine on a virtual machine with a deployment script and working backups.
It is also the wrong choice when the application is genuinely single-instance for a reason you cannot remove, such as a licence tied to a machine, a hardware dongle, or a dependency that only runs on an operating system the platform does not offer. Wrapping those in a container makes them harder to reason about without making them elastic.
The discipline is worth adopting even when the platform is not. Configuration from the environment, no state on local disk and a clean shutdown are good properties on a single virtual machine too, and they leave the door open later. The platform is a separate decision from the code, and it is the expensive half.
How do you test whether an application is genuinely cloud-native?
Four experiments in a staging environment, all of them doable in one afternoon. Run two instances behind a load balancer and use the application through both. Kill one instance in the middle of a request. Recreate a container and confirm nothing important disappeared with its filesystem. Start the application with an empty environment and see whether it fails loudly or quietly falls back to a default that points at something real.
Add a fifth if there is time: block outbound access to one dependency and watch what happens to the rest of the system. The correct behaviour is a fast, contained error affecting only the feature that needs that dependency. The common behaviour is every request queueing behind a connection that will never open, until the whole service is unavailable because one report generator is.
Everything that breaks in those five tests will break in production. The only variable is whether you are watching when it happens and whether anyone has to be woken up.
Common questions
- What makes an application cloud-native?
- It behaves correctly when the platform stops it without warning, runs several copies at once, replaces its filesystem and hands it configuration from outside the image. In practice that means no state held only in memory or on local disk, configuration read from the environment, separate readiness and liveness signals, a clean response to SIGTERM, and operations that are safe to retry.
- Is a Docker container cloud-native?
- Not by itself. A container is a packaging format, so an application that keeps sessions in memory, writes uploads to local disk and takes minutes to start keeps all of those problems once it is containerised. The difference becomes visible the first time an orchestrator drains a node or a rolling deploy runs two versions at once.
- Does cloud-native require microservices?
- No. A single deployable application can be stateless, externally configured, safe to kill and safe to run in multiples, which is the whole of the definition. Splitting into microservices is worth doing when different parts have genuinely different scaling profiles and separate teams need to release without coordinating. With one team and one release train, the split costs more than it returns.
- What is the difference between cloud-native and cloud-hosted?
- Cloud-hosted describes where an application runs. Cloud-native describes whether it can tolerate what running there involves. A virtual machine in a public cloud running an application that assumes a permanent disk and a single instance is cloud-hosted and nothing more, which is a perfectly reasonable position to occupy as long as nobody expects it to autoscale.
- When should you not build cloud-native?
- When load is steady and fits on one machine, when nobody is on call, or when a licence or hardware dependency ties the application to a single instance anyway. The platform brings an orchestrator, a registry, a secrets store and a monitoring stack, all of which need maintaining. The code discipline is still worth adopting, because it is cheap and it keeps the option open.
