Cloud-native is an approach to designing, building and running applications so they take full advantage of cloud environments: on-demand capacity, automation and managed services. A cloud-native application is typically made of smaller, independently deployable parts, packaged so it can run consistently anywhere, deployed through automated pipelines, and designed to scale out under load and recover from failures on its own. Common building blocks include containers, orchestration platforms, serverless functions and managed databases, but the term describes the design and operating approach rather than any single technology.
At a glance
- Cloud-native describes how an application is designed and operated, not where it runs; it can run in public cloud, private cloud or on-premises.
- Applications are typically split into smaller services that can be updated and scaled independently.
- Automation handles deployment, scaling and much of the recovery from failures.
- Common tools include containers and orchestration, serverless functions and managed platform services.
- Benefits come with costs: more moving parts, new skills and more demanding monitoring.
What problem it solves
Many applications moved to the cloud unchanged, running on the same kind of servers as before. They gain some benefits, such as no hardware to buy, but they often cost more than expected and do not get faster to update or easier to scale. A large application that must be released as one piece makes every change risky and slow, and it must be sized for its peak load all the time.
Cloud-native design addresses that. Splitting an application into smaller services lets teams release parts of it independently and often. Automated scaling adds capacity at peaks and removes it afterward, so you pay closer to actual use. Designing for failure, with health checks, redundant instances and automatic restarts, means individual servers or containers can fail without users noticing.
How it works
Microservices. The application is divided into services that each handle one function, such as orders, payments or search, and communicate over APIs. Not every cloud-native application is fully split this way, but the trend is toward independently deployable parts.
Packaging. Containers bundle each service with its dependencies so it runs the same way on a laptop, a test environment and production.
Orchestration and platforms. An orchestrator such as Kubernetes, or a managed Platform as a Service (PaaS), schedules services onto servers, restarts failed ones and scales them with demand. Serverless functions take this further: the provider runs code in response to events, and you pay per execution.
Automation. Infrastructure is defined as code, and continuous integration and delivery pipelines build, test and deploy changes automatically.
Observability. Because requests pass through many services, teams rely on centralized logs, metrics and tracing to see what is happening and find faults.
For evaluating cloud platforms to run cloud-native applications, see our public cloud solution page.
When it matters for buyers
- When planning a cloud migration. Decide which applications to move as-is, which to modify, and which to rebuild; cloud-native redesign costs more up front and pays off mainly for applications that change often or scale unevenly.
- When cloud costs disappoint. Applications moved without redesign often run on always-on, oversized servers; cloud-native patterns can help, but only with good cost management.
- When buying software. Vendors describe products as cloud-native as a selling point; ask what it means concretely for scaling, updates, resilience and where it can run.
- When hiring or outsourcing. Cloud-native operations require skills in containers, automation and observability that a traditional infrastructure team may need to build or buy.
- When portability matters. Choices between open tools and provider-specific services decide how hard it will be to move later.
Questions to ask vendors
- What does “cloud-native” mean for your product specifically: how does it scale, update and recover from failures?
- Does it run only on your cloud or one provider, or also on other clouds and on-premises?
- Which components are open source or standard, and which are proprietary to you or a cloud provider?
- How is it priced when usage scales up and down?
- What monitoring and logging do you provide, and can we export it to our own tools?
- What skills will our team need to operate it, and what managed services do you offer?
How it differs from cloud-hosted applications
A cloud-hosted application simply runs on cloud infrastructure, often on virtual machines (VMs) rented through Infrastructure as a Service (IaaS), with the same architecture it had on-premises. This is often called lift and shift. A cloud-native application is designed around cloud capabilities: automated deployment, elastic scaling and resilience to failure. Lift and shift is faster and cheaper to start; cloud-native takes more work but can deliver faster releases and closer-to-usage costs. Many organizations lift and shift first, then modernize selected applications over time.