Start here
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
Record build and deployment configuration so environments do not depend on undocumented manual changes.
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 user-visible outcomes. Use that evidence to evaluate releases and capacity changes.
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 lived inside the failed worker, replaceability of compute did not provide data recovery.
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
- An architectural choice with independently managed services; useful in some designs but not a universal requirement.
How the cloud-native building blocks fit together
Moving an unchanged application onto a rented virtual machine changes its hosting location. Cloud-native design also considers how the application is configured, released, scaled and observed. Containers, managed services, serverless functions and independently deployable services are possible building blocks—not a mandatory shopping list.
Declarative configuration describes the desired state, such as a service’s image, replica count and resource limits. A controller works to reconcile actual state with that specification. Infrastructure as code makes environment changes reviewable and repeatable; immutable deployment replaces an artefact rather than manually modifying a running server.
A delivery pipeline builds and tests a versioned artefact, promotes it through environments and applies release controls. An orchestrator schedules workloads and can restart failed instances or adjust capacity when configured to do so. Readiness checks, compatible data migrations, capacity and rollback design are still needed: using containers does not guarantee a zero-downtime release.
Service communication and observability
Services may communicate through request/response APIs, such as REST or gRPC, or through asynchronous messages. A network boundary introduces timeouts, retries and partial failures. Define which operations can safely be retried and how duplicate messages are handled before decomposing a working application into more services.
Logs describe events, metrics summarise behaviour over time, and traces follow a request across components. Correlating these signals helps a team distinguish a slow dependency from an overloaded service or a failed deployment. Collecting large volumes of telemetry is not enough: make sure operators can answer a concrete incident question.
A service mesh can centralise some traffic and security controls, but adds another operational layer. Similarly, managed orchestration reduces selected platform responsibilities without removing application security, resource planning or incident response. Choose the smallest architecture 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 a single-server application and identify its local state, manual setup and failure assumptions. Choose one improvement that increases replaceability without introducing a new service.
Common questions
Does cloud native require Kubernetes?
No. Kubernetes is one option. Managed platforms and other deployment approaches can support cloud-native practices. Serverless functions, managed container services and platform-as-a-service offerings can deliver 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 can apply across public, private and hybrid environments. Cloud native is about how software is designed and run: containers, automation, declarative configuration and resilience. Those practices work in an organisation’s own data centre too. Platforms such as OpenShift or self-managed Kubernetes are often used on-premises.
Must every application become microservices?
No. Choose service boundaries for genuine deployment and ownership needs, considering the operational cost. A well-structured modular monolith is often simpler to build, test and run. Split services out when separate teams, release cycles or scaling needs justify the extra complexity.
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.