What Does Cloud Native Mean?

What Cloud Native Means

Cloud native is an approach to building and running applications so they take full advantage of cloud computing. Cloud-native apps are usually split into small services, packaged in containers, and deployed and scaled automatically.

The term is about design and operations, not just location. An application running on a cloud virtual server can still use a traditional design. A cloud-native application is built to scale out, to recover from failures and to be updated often without long outages. The ideas are widely shared across the software industry, although teams apply them to different degrees.

Core Ideas: Microservices, Containers and Automation

Cloud-native designs usually combine several practices:

• Microservices: the application is split into small services that each handle one job, such as payments or user profiles, and can be updated separately.
• Containers: each service is packaged with its dependencies so it runs the same way across environments.
• Declarative configuration: the desired state of the system is described in files and enforced automatically, as in infrastructure as code.
• Continuous integration and delivery (CI/CD): code changes are tested and released automatically, which makes frequent, small updates practical.

Many cloud-native teams also follow the twelve-factor app principles, a set of widely used guidelines for building software-as-a-service applications. Examples include keeping configuration out of the code and treating logs as a stream of events.

When Cloud Native Fits and When It Does Not

Cloud-native design adds real complexity. Each service needs its own deployment, monitoring and failure handling, and the team needs skills in several tools at once. For that reason, it is a poor fit for many projects.

Consider two examples. A small business website with a handful of pages gains little from being split into services, and a simple static site or a single application server is far easier to run. A software product maintained by many teams, releasing changes daily and needing to scale parts of the system separately, is where the approach pays off.

A useful question is whether the benefits of independent scaling and frequent releases outweigh the operating cost. If they do not, a simpler design is usually the better choice. For the container side of the trade-off, see serverless vs containers.