What is a Cloud-Native Application Anyway? 12 Definitions Distilled

Cloud-Native Application (CNA) has been a trending buzzword in blogs, books and articles for several years now. But what does it take for an application to be(come) cloud-native? Do we need to throw out our established programming languages, frameworks and architectures? This post collects and analyzes definitions that identify desired cloud application properties and ways to achieve them.

Twelve-Factor App by Adam Wiggins (circa 2011)

As “a methodology for building software-as-a-service apps”, The Twelve Factors from Heroku (Co-)Founder Adam Wiggins advise to:

• “I. Codebase One codebase tracked in revision control, many deploys
• II. Dependencies Explicitly declare and isolate dependencies
• III. Config Store config in the environment
• IV. Backing services Treat backing services as attached resources
• V. Build, release, run Strictly separate build and run stages
• VI. Processes Execute the app as one or more stateless processes
• VII. Port binding Export services via port binding
• VIII. Concurrency Scale out via the process model
• IX. Disposability Maximize robustness with fast startup and graceful shutdown
• X. Dev/prod parity Keep development, staging, and production as similar as possible
• XI. Logs Treat logs as event streams
• XII. Admin processes Run admin/management tasks as one-off processes”

There is one Web page per factor. Some might say that these properties apply to a Platform-as-a-Service provider and its tenants, Heroku Web apps or even Ruby on Rails apps¹ only. But the community seems to agree that they have broader appeal — which does not mean that all of them always have to be followed (which would a bad idea anyway according to our adoption rule “Context Matters”).

“Cloud Computing Patterns” Book by Christoph Fehling et al (2013/2014)

Not much later, Christoph Fehling and his pattern book co-authors (Frank Leymann, Ralph Retter, Walter Schupeck and Peter Arbitter) came up with the IDEAL² properties:

Isolated State, Distribution, Elasticity, Automated Management, Loose Coupling

These properties overlap with the Twelve Factors, but emphasize architectural constraints a bit more. Summaries of the Cloud Computing Patterns are available online; even Loose Coupling, the L in IDEAL, is captured in pattern form. A composite Three-Tier Cloud Application is supposed to look like this:

Two Examples from Academia (2016, 2017)

In “ClouNS — a Cloud-Native Application Reference Model for Enterprise Architects” from 2016, Nane Kratzke and Rene Peinl defined a CNA by directly referencing cloud platform characteristics and the service-oriented composition style:³

“A cloud-native application is a distributed, elastic and horizontal scalable system composed of (micro)services which isolates state in a minimum of stateful components. The application and each self-contained deployment unit of that application is designed according to cloud-focused design patterns and operated on a self-service elastic platform.”

A second example of a peer-reviewed academic paper is “Architectural Principles for Cloud Software” by Claus Pahl, Pooyan Jamshidi and a less relevant third author 😇. The principles behind the title are service-orientation, virtualization, uncertainty and adaptivity; patterns include microservices, models at runtime and controller-based feedback loop. Control theory might come as a surprise here, but fits — most cloud systems respond to external stimuli such as environmental changes and management commands (from provider and/or tenant).

InfoWorld and Cloud Native Computing Foundation (CNCF) (2018)

“What is cloud-native? The modern way to develop software”, an InfoWorld article by Andy Patrizio from June 14, 2018 brings in agile practices including Continuous Integration (CI) and Continuous Delivery (CI/CD) and DevOps:

“Cloud-native computing takes advantage of many modern techniques, including PaaS, multicloud, microservices, agile methodology, containers, CI/CD, and DevOps”

According to the same article, the CNCF originally defined “cloud-native” a little more narrowly:

Using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.

CNCF Cloud Native Definition v1.0, approved on June 11, 2018, has different content. We learn about target platforms, architectural building blocks and desired properties:

“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.”

The first paragraph covers concepts and technologies, the second one important qualities such as observability.

Cloud Strategy Book by Gregor Hohpe (about 2019)

In line with the CNCF, Gregor Hohpe observes that “Docker containers have become virtually synonymous with being cloud native” in his book “Cloud Strategy — A Decision-Based Approach to Successful Cloud Migration”.

The book also contributes six FROSST principles (originally defined by Jean-François Landreau):

Frugal, Relocatable, Observable, Seamlessly updatable, internally Secured, failure Tolerant

More desired qualities (“-able”)! But also overlap with the ones in the previous definitions.

Kyle Brown and Kim Clark on Medium (2020)

This series on “The ‘How’ of Cloud-Native” has five parts:

• Part 1 gives an overview and has one key quote: “… writing components that: minimize statefulness, reduce dependencies, have well defined interfaces, are lightweight, are disposable”.
• Part 2 provides the “People and Process Perspective”: “Agile methods; lifecycle automation; DevOps and site reliability engineering; team autonomy”.
• Part 3 has architecture and design principles as sections: “Fine-grained components, appropriate decoupling, minimal state, immutable deployment, zero trust”.
• Part 4 is on “Technology and Infrastructure Perspective”: “Elastic, agnostic, secure platform; lightweight runtimes; automated operations; observability and monitoring”.
• Part 5 returns to “Goals and Benefits”.

Kyle and Kim fuse previous definitions and their community’s experience. They organize their advice in three perspectives (Parts 2 to 4 of the series, as introduced above); in total, they compiled 13 ingredients, shown in their overview figure.

More Definitions (2008 to present)

There are many more characterizations of cloud-native:

• Aqua Security defines cloud-native applications with four traits: resilient, agile, operable and observable.
• The “10 Key Attributes of Cloud-Native Applications” are a superset of IDEAL; APIs are mentioned explicitly (like in the CNCF definition).
• Vamsi defines CNA “as an application built using a combination of technology paradigms that are native to cloud computing – including distributed software development, a need to adopt DevOps practices, microservices architectures based on containers, API based integration between the layers of the application, software automation from infrastructure to code, and finally orchestration & management of the overall application infrastructure” and provides a visualization.
• Tyler Jewell outlines several concepts and technologies to build cloud-native applications: “Reactive architecture for stateful microservices and stateful serverless; Event-Driven Architecture (EDA) and event streaming for loosely-coupled state processing; stateless middleware running on stateful orchestration (horizontally scalable storage and planet-scale database); Jamstack, reactive GUIs, and headless CMS for decoupling state, model and representation to scale stateful front ends”.

We’d have another five definitions waiting to be listed here (and certainly there are even more). But the twelve-source collection is broad and deep enough to move on. Time to stop collecting — and start analyzing. 😂

Analysis of Definitions: Commonalities and Differences

Let’s take out our software architect toolbox, a.k.a. Design Practice Repository and Reference (GitHub, Leanpub), to analyze what we got. Here are some observations:

• Naturally many of the definitions refer to definition(s) of cloud computing one way or another (NIST, OSSM). This is somewhat natural, but also runs the risk of being tautologic.⁴
• In the area of non-functional requirements, the disposability quality is introduced. For instance, it is one of the Twelve Factors and also featured in the Cloud Strategy book. Many classical quality attributes are varied or extended, for example those dealing with security and privacy.
• Moving on to architectural principles, loose coupling is emphasized, not surprisingly. Adaptability is mentioned sometimes, and so is agility. Architectural patterns are mentioned here and there.
• Different viewpoints are taken to address the concerns of particular stakeholder groups (logical vs. physical, tenant vs. provider). Some definitions focus on the provider infrastructure, others on the hosted application; some do both.
• The abstraction levels vary as well; concrete technologies are included sometimes.⁵
• The role of microservices ranges from enabler to must-have.
• The same holds for (operating system) virtualization, (Docker) containers and (Kubernetes) orchestration.

It is also worth noting that some authors look at goals, and others at ways to get there. Sometimes, goals and means to achieve them are combined. For instance, some sources emphasize structure such as components and connectors and/or properties and/or design rationale (structural elements, their properties and rationale for selecting them actually comprise the three parts of modern definitions of software architecture, so this is good).

Exercise: Various books put “cloud native” (and/or microservices) in their titles: Examples include “Cloud Native Patterns” by Cornelia Davis, “Cloud Native Architectures” by Tom Laszewski, Kamal Arora, Erik Farr and Piyum Zonooz and “Design Patterns for Cloud Native Applications” by Kasun Indrasiri and Sriskandarajah Suhothayan. You may want to compare the definitions of cloud-native in these books with some of the above.

Summary and Outlook

What have we seen in the eight plus four definitions that we featured in this post, and their analysis?

1. Making cloud applications awesome (as cloud computing is OSSM too) is hard. Lift-and-shift is not a good approach usually, as one cannot expect existing on premises systems to already have all desired properties.
2. Design principles and patterns can guide the creation of cloud natives and cloud immigrants.
3. The compiled definitions give first advice. They vary quite a bit in content and viewpoints taken, but do agree on their core messages.

The Medium version of this post (slightly shorter) is here.

Next up: two third-generation fusion definitions of cloud-native, see this post.

– Olaf Zimmermann and Mirko Stocker