If you’ve paid attention to trends in the business and practice of software engineering over the past few years, you may have heard the term “cloud native” bandied about. Like other buzzwords, it seems to mean something different depending on whom you ask; yet none of these explanations seem to quite fit. I don’t know about you, by my natural instinct in these cases is to quickly tune out. If no one can clearly define it, it must not mean anything!

However, this phrase does actually stand for something real, despite being nebulous. If you’re a practitioner or entrepreneur in this space, it pays to understand it, for one simple reason - it sheds significant light on where the technology of this industry is heading.

The key to understanding this isn’t to try to unpack the meaning of the individual words. Buzzwords are entirely about context. “Cloud native”, in particular is really just a term that stands in for several big simultaneous trends affecting application architecture. So, let’s explore the trends - what has happened over the past few years?


The first major trend is the shift to packaging software as containers, rather than OS packages (e.g DEB or RPM), language-specific packages (e.g. Gems, Wheels, NPM), or tarballs.

Containers solve some pretty gnarly problems that developers and DevOps engineers have been dealing with for a long time:

  • Isolation from the host operating system. Containers are fully self-contained - they include all of the libraries necessary to execute the application. This prevents most dependency conflicts which are common with other packaging systems. It also makes it much more plausible to co-locate disparate applications on the same host.
  • Single-step installation. Previously an installation might have required copying of files into various directories, setting up init.d files or systemd units, editing configuration files, etc. With containers, this is greatly simplified.
  • Predictable installation. Plain OS and language packages would usually be installed during the deployment phase. Container images, on the other hand, can be assembled in the build phase, reducing the number of error-prone steps during deployment.
  • Immutability. Container images can’t be modified, which means any persistent data has to be stored outside of the container, in explicitly defined volumes.


At the same time, the types of applications people are building is changing.

In the 2000s, we saw a massive push to bring traditional businesses online. This often meant creating specialized data management applications in various business contexts. Largely, the interaction with these applications were variations on the CRUD (CReate/Update/Delete) pattern, with relatively minimal processing or business logic. This meant that archetypical “app” throughout this era has been the monolithic web app, usually with a backing database.

However, this is gradually changing. Simple web apps grow over time and add increasing numbers of external components for data storage, caching, authentication, and so on - and become more distributed in the process. Additionally, most of the traditional business workflows that deal with simple data management have now been digitized. Of course, there will always be new web apps, but the overall mix of software is shifting away from their dominance.

Meanwhile, a new set of applications is emerging. These new applications are more complex and more distributed. They operate at larger scale and extend beyond CRUD. For example, machine learning and data science applications often require a significant batch or offline processing component; IoT backends might ingest large volumes of data, and do stream processing. By their nature, these applications require multiple services.

Larger teams also have reason to adopt a microservices/SOA architecture. Once an organization grows beyond a single team, it becomes difficult to manage a single codebase and a single deployment cadence (see Conway’s law).

Maturing infrastructure abstraction

The third important trend is the significant maturation of infrastructure management and software operations. This shift began with the rise of “DevOps” culture over the past decade. The idea of DevOps is that IT operations should be less about system administration (manual grooming of infrastructure and software packages) and more about automation (writing software to automate the same processes).

One interesting result of this is the gradually emerging interface between the application and infrastructure. This is a natural byproduct of increased automation - ops automation systems are software, and software needs a user interface.

Configuration management systems were an iteration on this. For the most part, these systems are a kind of development kit - providing an easier way to write automation code. Kubernetes, and other container orchestrators, are a much more well-refined take on the operational interface. They provide a specific and well-defined API for workflows such as deploying or upgrading application instances. These types of tasks would have previously been managed through ticketing systems and semi-automated workflows, still driven manually by system administrators.

A clearly defined API places certain demands on both sides of the interface. The infrastructure is effectively abstracted and presented to the user as pools of resources (compute, network, and storage). Developers must package up their software in a way that allows it to be managed in a consistent way, regardless of the application’s specifics. Application instances need to be immutabile, stateless, and ephemeral. You can no longer design software to require special case handling at the infrastructure level.


“Cloud native” is a way to describe the current era in backend software and infrastructure management. It stands for three trends - the adoption of containers as a packaging mechanism, the embracing of distributed architectures (microservices/SOA), and the emergence of a well-defined IT operations API layer (e.g. Kubernetes).

Each of these trends results in a new set of requirements for both the infrastructure and application layers. The infrastructure part is “the cloud” (even if it’s private and on-premise), and the applications must be designed in a “cloud native” manner in order to work well with the infrastructure abstraction.

What are the specific requirements, patterns, and best practices for “cloud native” apps? Well, that is a topic for a separate blog post (or ten!).

Are you considering building out an infrastructure platform on premise? Doing it from scratch can be a lot of work.

Try Operos. Operos is an open-source Linux-based operating system that integrates Kubernetes orchestration, Ceph distributed storage, provisioning, and many other features in an easy-to-use, turn-key package. Spinning up a cluster takes less than 20 minutes!