Cloud Native: meaning and definition
Cloud Native in plain language
Moving an unchanged server application to a cloud VM changes its location. Designing it so that instances can be replaced, releases are repeatable and failures can be observed changes how it operates.
Containers, declarative configuration and loosely coupled services can support this approach. They are choices rather than a compulsory shopping list. A small application should not be split into many services merely to acquire the label.
How it works
Make the workload reproducible
Write down how builds and deployments are set up, so environments do not depend on manual changes nobody recorded.
Design for replacement and failure
Keep important state in an appropriate persistent store and define how work resumes after an instance fails.
Observe and improve
Connect logs, metrics and what users actually see. Use that evidence to judge releases and changes in capacity.
Illustrative example · Fictional data
Replacing a fictional report worker
- Input
- A report service uses a queue and an external result store. One worker fails while processing a synthetic request.
- Process
- Start a replacement worker. Use the job’s recorded state and duplicate handling to resume or retry without producing conflicting reports.
- Expected output
- The job completes or exposes a clear failure status independent of the original worker instance.
- How to check it
- If the only copy of a result was inside the worker that failed, being able to replace the computer did not bring the data back.
Where it helps
- Services that need frequent, repeatable releases.
- Workloads that benefit from independently replaceable components.
- Teams needing clearer visibility into distributed failures.
Cloud hosted, cloud native and microservices
- Cloud hosted
- Describes where the application runs.
- Cloud native
- Describes how the workload is designed and operated.
- Microservices
- A design choice where services are run separately. Useful in some designs, but not needed everywhere.
How the cloud-native building blocks fit together
Moving an unchanged app onto a rented virtual machine only changes where it is hosted. Cloud-native design also looks at how the app is set up, released, scaled and monitored. Containers, managed services, serverless functions and separately deployed services are possible building blocks, not a list you must buy.
Declarative configuration describes the state you want, such as which image a service runs, how many copies and its resource limits. A controller keeps working to make what is actually running match that description. Infrastructure as code makes environment changes reviewable and repeatable; immutable deployment replaces a running version with a new one instead of editing a live server by hand.
A delivery pipeline builds and tests a versioned release, moves it through each environment and applies release checks. An orchestrator schedules workloads and, if set up to, can restart failed copies or change capacity. You still need readiness checks, data changes that fit both versions, enough capacity and a rollback plan: containers alone do not guarantee a release with no downtime.
Service communication and observability
Services can talk through request-and-response APIs, such as REST or gRPC, or by sending messages that are handled later. Every network hop brings timeouts, retries and partial failures. Before splitting a working app into more services, decide which actions can safely be retried and how duplicate messages are handled.
Logs record events, metrics sum up behaviour over time, and traces follow one request across all the parts of a system. Linking the three helps a team tell a slow dependency from an overloaded service or a failed release. Collecting lots of data is not enough: make sure the people on call can answer a real incident question.
A service mesh can bring some traffic and security controls into one place, but adds another layer to run. In the same way, managed orchestration takes some platform work off your hands without removing app security, capacity planning or incident response. Choose the smallest design that meets the workload’s needs.
Related reading and learning pathways
Common pitfalls
- More services create additional networking, ownership and debugging work.
- Containers alone do not produce resilience.
- Zero-downtime releases require application and data compatibility, not just an orchestration tool.
Put the idea to work
Try it yourself
Take an app that runs on a single server and note what it stores locally, what was set up by hand and what it assumes will never fail. Choose one change that makes it easier to replace, without adding a new service.
Common questions
Does cloud native require Kubernetes?
No. Kubernetes is one option. Other platforms and deployment approaches can support cloud-native practices. Serverless functions, managed container services and platform services can give you automated deployment, scaling and resilience without running a Kubernetes cluster yourself. Pick the simplest platform that meets your scaling and reliability needs.
Can a private environment be cloud native?
Yes. The approach works in public, private and mixed environments. Cloud native is about how software is designed and run: containers, automation, written-down configuration and resilience. Those practices work in a company’s own data centre too, where platforms such as OpenShift or self-managed Kubernetes are often used.
Must every application become microservices?
No. Split services only where separate deployment and ownership are really needed, and count the running cost. A well-organised single app built in modules is often simpler to build, test and run. Split services out when separate teams, release cycles or scaling needs justify the extra work.
Your next step
Continue learning
Connected concepts
Sources and further reading
Examples on this page are teaching exercises using fictional information. They are not client case studies or measured outcomes.