What is Cloud Native?
Is cloud native the adoption of containers?
Is cloud native the adoption of Kubernetes?
Is cloud native a technology or a set of technologies?
Is cloud native an architecture for running applications in the cloud?
There is no hard and fast definition for what cloud native means. In fact, there are other overlapping terms and ideologies. At its root, cloud native is structuring teams, culture, and technology to utilize automation and architectures to manage complexity and unlock velocity. Operating in this mode is as much a way to scale the people side of the equation as it is to scale the infrastructure side.
One important note: You don't have to run in the cloud to be cloud native. Cloud native techniques can be applied incrementally as appropriate and should help smooth any transition to the cloud.
The real value from cloud native goes far beyond the basket of technologies that are closely associated with it. To really understand where our industry is going, we need to examine where and how we can make companies, teams, and people more successful.
At this point, these techniques have been proven at technology-centric, forward-looking companies that have dedicated large amounts of resources to the effort. Think Google, Netflix, or Facebook. Smaller, more flexible companies are also realizing value here.
"Cloud native is structuring teams, culture, and technology to utilize automation and architectures to manage complexity and unlock velocity." --Joe Beda, Principal Engineer, VMware.
High Level
Cloud-native applications: Generally speaking, they are developed and optimized to run in a cloud as distributed applications. According to the Cloud Native Computing Foundation, cloud-native applications, which are also generally referred to as "modern" applications, are marked by the following characteristics:
Containerized for reproducibility, transparency, and resource isolation.
Orchestrated to optimize resource utilization.
Segmented into microservices to ease modification, maintenance, and scalability.
Cloud-Native Applications
The Cloud Native Computing Foundation, a project of The Linux Foundation, defines cloud-native applications as follows:
Containerized---Each part (applications, processes, etc.) is packaged in its own container. This facilitates reproducibility, transparency, and resource isolation.
Dynamically orchestrated---Containers are actively scheduled and managed to optimize resource utilization.
Microservices oriented---Applications are segmented into microservices. This segmentation significantly increases the overall agility and maintainability of applications.
Kubernetes covers the second part of the definition by scheduling and managing containers. For the third part, both Kubernetes and Docker help implement microservices.
The key element, however, is the container---a process that runs on a computer or virtual machine with its own isolated, self-described application, file system, and networking. A container packages an application in a reproducible way: It can be distributed and reused with minimal effort.
Different organizations, however, have different definitions. Dell EMC, for example, defines cloud-native application as a highly scalable next-generation distributed application architecture that uses open standards and is dynamic in nature.
Definition of Cloud Native by the CNCF
"Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."
--From https://github.com/cncf/toc/blob/master/DEFINITION.md
Characteristics of Cloud Native Application Architectures
Here is a take on the characteristics of cloud-native application architectures. These characteristics are paraphrased from Migrating to Cloud-Native Application Architectures.
twelve-factor apps. The formula for building twelve-factor apps is a set of patterns that optimize application design for speed, safety, and scale.
Self-service agile infrastructure. Cloud platforms that enable development teams to operate at an application and service abstraction level, providing infrastructure-level speed, safety, and scale.
API-based collaboration. An architecture pattern that defines service-to-service interaction as automatically verifiable contracts, enabling speed and safety through simplified integration work.
Antifragility. Improving the robustness of systems to deliver speed and scale.
Cloud Native vs. Cloud Computing
Cloud native and cloud computing are not the same thing.
In Special Publication 800-145, NIST defines cloud computing as follows:
"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
Better Tooling, Better Systems
Cloud native is defined by better tooling and systems. Without this tooling, each new service in production will have a high operational cost. It is a separate thing that has to be monitored, tracked, provisioned, and so on. That overhead is one of the main reasons why sizing of microservices should be done in an appropriate way. The benefits in development velocity must be weighed against the costs of running more things in production. Similarly, introducing new technologies and languages, while exciting, comes with costs and risks that must be weighed carefully.
Automation is the key to reducing the operational costs associated with building and running new services. Systems such as Kubernetes, containers, continuous integration and continuous delivery (CI/CD), and monitoring all have the same overarching goal of making application development and operations teams more efficient so they can move faster and build more reliable products.
The newest generation of tools and systems are better set up to deliver on the promise of cloud native compared to older traditional configuration management tools because the new tools help break the problem down so that it can easily be spread across teams. Newer tools generally empower individual development and ops teams to retain ownership and be more productive through self-service IT.
Outcomes
With some of the early experiences being proven out and shared, the following themes are emerging as outcomes that stem from the adoption of cloud native practices and technology:
More efficient and happier teams – Cloud native tooling allows big problems to be broken down into smaller pieces for more focused and nimble teams.
Reduced drudgery – This is accomplished by automating much of the manual work that causes operations pain and downtime. This takes the form of self-healing and self-managing infrastructure. Expect systems to do more.
More reliable infrastructure and applications – Building automation to handle expected churn often results in better failure modes for unexpected events and failures. For example, if a single command or button click deploys an application for development, testing, or production, it can be much easier to automate deployment in a disaster recovery scenario (either automatically or manually).
Auditable, visible, and debuggable – Complex applications can be opaque. The tools used for cloud native applications, by necessity, usually provide much more insight into what is happening within an application.
Deep security – Many IT systems today have a hard outer shell and a soft gooey center. Modern systems should be secure and least trust by default. Cloud native enables application developers to play an active role in creating securable applications.
More efficient usage of resources – Automated, cloud-like ways of deploying and managing applications and services open up opportunities to apply algorithmic automation. For instance, a cluster orchestrator can automate placement of workloads on machines instead of having an ops team manage the placement in a spreadsheet.
Find Out More
Find out from Kubernetes Founders Craig McLuckie and Joe Beda about the difference between Cloud and Cloud Native
Last updated