WTF Is Cloud Native

A Glossary Of Cloud Native Terms

We need to talk.

No, really—one of the hardest parts of wrapping your head around the complexities of Cloud Native is getting a handle on all the lingo. Containers, microservices, and orchestration, oh my! Sometimes the best place to begin a conversation about new technology is with a quick Cloud Native 101 to make sure we are all talking about the same things in the same way. 

So here is rundown on some essential Cloud Native terms and concepts. If you are already familiar with many (or even all) of them, it’s still a handy resource to share with those who aren’t. After all, a shared vocabulary is helpful when talking with managers, executives, or anyone else in your organisation who needs to understand why it’s time to get on board with Kubernetes—and all that comes with it. 



 Software development principles focusing on iterative delivery, frequent user feedback, and collaboration over complex processes. Scrum is the most well-known development method integrating the Agile principles. For example, sprints in Scrum implement the Agile principle ‘deliver working software frequently’.


A term for delivering hosted services over the internet. Cloud services differ from traditional infrastructure and platform hosting because they are elastic (users can employ only as much service as they need), sold on demand, and fully managed by the provider (requires only a computer and Internet access). See: Private Cloud, Public Cloud.

Configuration Management

Specifically, the automation of server configuration and management, using tools such as Ansible, Puppet, Chef, or Terraform.


 Lightweight, standalone executable software packages that include everything required to run an application: code, runtime, system tools, libraries, and settings. Containers are a sort of ‘standard unit’ of software that packages the code with all its dependencies so it can run anywhere, in any computing environment. 

Continuous Integration

Continuous Integration (CI) is a development approach where teams implement small changes and check in code to version-control repositories frequently, so that the codebase is constantly iterated and updated. The technical goal of CI is to establish a consistent and automated way to build, package, and test applications.

Continuous Delivery

Continuous Delivery (CD) starts where Continuous Integration ends. CD automates the delivery of CI’s small, iterative changes to run on cloud-based infrastructure. Most teams work with multiple environments outside the production pipeline, such as development and testing environments, and CD provides an automated way to push code changes to them. CD automation then performs any necessary service calls to web servers or databases, and executes procedures when applications are deployed.

CI/CD and Continuous Deployment

 When integrated, CI/CD together make it possible to implement Continuous Deployment. In Continuous Deployment, application changes run through the CI/CD pipeline and passing builds get deployed directly and seamlessly to fully automated production environments. Teams practicing Continuous Delivery can deploy to production on a daily or even hourly schedule.

Cross-Functional Teams

On such a team, members have different skills, but work collaboratively toward the same goal. Team members have all competencies necessary for accomplishing the work within the team—so there are no dependencies on others outside the team. In software development this typically means frontend and backend developers, database and UX specialists, QA engineers, and any other role necessary for producing the product or service.


How individuals within an organisation communicate and work with each other. Culture is the sum of the daily actions that you take, your routines. If you talk to people as part of doing your work, you have a collaborative culture. Needing to seek permission before trying something new means you have a hierarchical culture. If you change the actions, you change the culture.

Data-Driven Design

The practice of developing or improving a product based on things you can measure. Metrics like site analytics, carrying out A/B testing, or surveying users for feedback are all used to make design decisions.

Design Thinking

A human-centred approach to business processes. Design thinking focuses on customer problems and challenges as the foundation to producing products and services that satisfy their wants and needs, and is an excellent tool to combine with Cloud Native development processes.


Both a culture and a set of processes aimed at reducing the division between software development and its actual operation. With DevOps, the traditionally siloed Development and Operations teams work together as one cohesive team (or, sometimes, two teams in tight collaboration). The approach facilitates fast and seamless software development while optimising both productivity and reliability. Companies adopting the DevOps model create teams that embrace the entire development and infrastructure lifecycle in their scope of responsibility. See: SRE.

Greenfield Project

Building a complete software development system where previously there was none. In Cloud Native, it means not just cloud-based infrastructure but also incorporates architecture, design, process, and culture—basically, starting completely from scratch in every possible area. Greenfield development is often viewed as advantageous because it is free from constraints that can be imposed by a system’s existing networks/infrastructure.

Infrastructure as Code (IaC)

A key DevOps practice, IaC is the process of managing and provisioning infrastructure, including networks, virtual machines, load balancers, and connection topology through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. An IaC model generates the same environment every time it is applied. Definitions are declarative and are typically held in a version control system.


An approach to application development in which a large application is built as a suite of modular components or services. Each service runs a unique process and usually manages its own database. A service can generate alerts, log data, support UIs and authentication, and perform various other tasks. Because microservices enable each component to be isolated, rebuilt, redeployed, and managed independently, development teams can take a more decentralized (nonhierarchical) approach to building software. 

New call-to-action


A software application in which different components combine into a single executable program, launched from a single platform. Monolithic applications can only be released once all components are ready, which can lead to long release cycles.


Refers to the automated configuration, coordination, and management of computer systems and software. In cloud computing, it refers more specifically to orchestrator tools. The best known is Kubernetes, an open-source system for automating the deployment, scaling, and management of containerised applications. In Cloud Native, orchestration is all about managing the lifecycles of containers, especially in large, dynamic environments. (Dev)Ops teams use container orchestration to control and automate tasks such as the availability, provisioning, and deployment of containers, load balancing of containers across infrastructure, and scaling up/down by adding/removing containers as needed. See also: Containers.

Private Cloud

A Private Cloud is meant to serve a single company. It’s usually built and operated by said company in its own data centre. A Private Cloud provides greater control over data storage and other operational and security aspects. 

Public Cloud

Public Cloud providers sell cloud services to any client, who creates an account with them. All clients share the same pool of computing resources. Examples of Public Cloud providers include Amazon Webservices (AWS), Microsoft Azure, and Google Cloud.  


Site Reliability Engineering (SRE) is a term coined by Google to explain how it runs its systems. It was Google’s answer to today's challenges with ensuring application performance and reliability at unprecedented scale. In SRE, responsibility for an organisation’s platform is split between a product team, which focuses on delivery of the business value, application, or service (including innovation), and a reliability team, which focuses on both maintaining and improving the platform itself.


 A commonly used model of software development based on a logical progression of steps that form the software development life cycle. One follows after the other in strict order, much as a waterfall cascades down from top to bottom. This method is often associated with lengthy release cycles. While the rise of Agile methodologies have caused the Waterfall model to decline in popularity, its sequential process still contains advantages and it remains a common design process in the industry.WTF_subscribe_CTA2.png

Leave your Comment