cncf

What Is the Cloud Native Computing Foundation?

The impact of open source has been immense in the world of software development. By making the source code of a software tool available to anyone in the world, open source has led to collaborative development and innovation like never before. With open source, developers worldwide can contribute their knowledge and ideas to a project, leading to faster development cycles, more stable software, and a community-driven approach focused on solving problems and creating value for users.

Open-Source Free Software, What Is That?

Before we can explore why the Cloud Native Computing Foundation was needed, we have to understand what open-source, free software is and how it's maintained.

Let's take Linux as an example. Linus Torvalds wanted an operating system of his own, so he developed the heart of the operating system, the kernel. This kernel would later be named Linux.

At first, this was a personal passion project. Of course, it was private since only Linus had access to it. But Linus wanted to share this with the whole world. So, he uploaded the source code of Linux to the Internet. Technically, this is what it means to open-source something, to allow anyone in the world to see the entire source code of some software tool.

With open source, when something cool happens, people with similar hobbies and who are passionate about the problem the project is solving will join in. They'll look at the code, fix stuff, add new features, make the program work faster, and so on. This will be in the form of code suggestions which the project owner can accept or decline.

But Linus went even further. He didn't just open source; he also made Linux "free software." This is where there's usually some confusion. People tend to believe that the word "free" in "free software" comes from the fact that we usually don't have to pay to use it. But, actually, the word "free" in "free software" refers to freedom.

Whether we are a big company like Apple or Microsoft, a small local business, or just an individual, we can use Linux for whatever we may need. We are free to do anything we want with it without signing contracts, buying licenses, asking for permissions, and so on.

This is how Linux got big. First of all, by open-sourcing, Linus wasn't working alone anymore but got help from thousands and thousands of developers around the world. Making it free software attracted companies that needed to move fast without worrying about contracts and legal stuff. They could just download Linux and immediately use it without even asking Linus for permission.

How the CNCF Was Born

Now, let's go back in time to the year 2014. At that point, Google was already using containers and container automation tools to serve billions of users. Inside their company, they created a tool called Borg and used it for container orchestration. But this was private. Only they had the source code for this awesome tool, and only they were allowed to use it. But in 2014, that finally changed. Just like Linus Torvalds did with Linux, so they did with Borg. They open-sourced this project and made it free software. Borg would later be renamed to Kubernetes.

We saw that open-source, free software is a cool concept. Anyone is free to use it however they want, and anyone can suggest code changes that might improve the project. But there's also a problem with this model. There still needs to be some sort of leadership: people that decide how this open-source project should be developed, how it should evolve, what code changes get accepted, and which get rejected.

Now, let's say that Apple or Microsoft is the leader in this area. They oversee everything that happens with Kubernetes. They might be tempted to develop the software in a direction that only benefits them, not the entire community. They might implement things that only help them have an advantage while leaving their competitors at a disadvantage.

To avoid these kinds of problems, Kubernetes needed a neutral home. So, Google discussed how to solve this with the Linux Foundation. This foundation already has a long history of being neutral, working for the benefit of the entire community, not just some chosen few. So, a lot of companies already trust it.

In 2015, the Linux Foundation created a sort of sub-organization called the CNCF, the Cloud Native Computing Foundation. Finally, Google donated Kubernetes to the CNCF, which has now become its neutral home.

What is the Cloud Native Computing Foundation Today?

Ok, so the CNCF started out as a home for Kubernetes. But, as years went by, this became much more. First of all, the CNCF now has many more projects under its umbrella. Here are some of the most popular ones:

Kubernetes for orchestrating containers.
Helm is a package manager for Kubernetes.
Containerd, a container manager. It takes care of things such as pulling images from a server on the Internet, starting a container, stopping it, and so on.
etcd, is a distributed key-value store. It is also highly available and fault-tolerant.
Open Policy Agent (OPA) lets us define policies in our Kubernetes clusters, what should be allowed, and what should be disallowed.
Fluentd, which makes it easier to collect logs about what is going out in our cloud or Kubernetes infrastructure.
Prometheus is a monitoring toolkit originally developed at SoundCloud. It is designed for monitoring highly dynamic containerized environments and provides a time-series database, a query language, an alerting mechanism, and various visualization tools. It can be used to monitor various metrics such as CPU usage, memory usage, disk usage, network traffic, and more.
Linkerd is a service mesh that provides a way to manage, secure, and observe communication between services in a microservices architecture.

We can kind of see how the additional projects landing under the CNCF were things that played well with Kubernetes. Things that added new functionality on top of it. But this is not a rule. Nowadays, we can see a lot of projects under the CNCF that aren't necessarily for Kubernetes, but rather, they work well with cloud infrastructure. Otherwise said, projects that are "cloud-native," and we'll see what that means later on.

CNCF Responsibilities

With many more projects adopted, the CNCF also has many more responsibilities. Here are some examples:

They promote the projects that they adopt. Basically, the projects get some free marketing to help them get a good start and gather some community around them. And by community, this doesn't mean only developers that can contribute code. It also means people or companies that use these software tools to solve some real-world problems.
They organize events such as KubeCon + CloudNativeCon conferences. This serves both as a way to market CNCF projects and also as a way to allow more people to learn how to use these tools effectively.
They secure funding for projects that need it.
They try to make sure that all the projects they adopt can work reasonably well with each other. That means these tools should be able to interconnect if used in a cloud infrastructure. So, they may suggest ways in which the developers can make these tools compatible with each other.

Why Contribute a Project to the CNCF?

But why would we want a project to become part of the CNCF? Let's say we worked on some cool open-source tool, and we have it on GitHub, where people download it and use it on their servers. Assume we even have around 50 developers regularly contributing better code for this project. Our software tool is awesome, but its community is still small.

This could be a reason for us to contribute our project to the CNCF. If they see that our tool has a lot of potential, they can help us get a lot more visibility on the Internet. With more visibility, our community will grow. More people will test our software; more people will contribute code. So our project could evolve much faster with CNCF's help. In this case, we can consider it an accelerator for projects with great potential but small communities.

This is not the only reason why someone would want to contribute something to the CNCF. It's just one example. Others might have different reasons, as we saw with Google wanting to find a neutral home for Kubernetes.

What Is "Cloud Native"?

Now, the CNCF cannot adopt any project under the sun. So, there are a lot of conditions that must be accepted. For a project to get accepted, it has to somehow be "cloud native." But what does "cloud native" mean? To understand this, we should go back in time.

Cloud-native refers to a software development approach that utilizes cloud computing to build and run applications. It involves designing applications specifically for deployment on the cloud, allowing them to take full advantage of the cloud infrastructure's flexibility, scalability, and agility.

Cloud-native applications are typically built using containerization and microservices architecture, which enables developers to develop, deploy, and manage applications more efficiently and effectively. Overall, cloud-native applications are designed to be highly resilient, scalable, and adaptable to meet the demands of modern cloud environments.

Cloud Native Analogy

This might sound weird, but the cloud infrastructures today, in a way, resemble how the human body works. We have billions and billions of cells. Each of them is very small and specialized in a single task. Each works independently. But all of those independent billions of cells make up a SINGLE human body.

The cloud is similar. We launch and configure lots and lots of small pieces in the cloud. Each piece is independent. But when we interconnect all of them, we create a single organism, our cloud infrastructure. This will be the cloud infrastructure that lets us run our operation and offer service to our customers.

Going forward with our analogy, in the human body, new cells are born all the time, and old cells die all the time. But this goes unnoticed; the body still works normally. In the cloud, a similar thing happens. We don't have this big thing like a single server storing a database, as we did in the old model. Instead, we have a lot of small things storing up the database or parts of the database.

They are like little cells that specialize in database operations. Since we now have hundreds or thousands of cells specialized in database operations, nothing bad will happen if one or two cells die; there are still many that remain functional. So our database will always work even if some parts malfunction. Furthermore, we don't need to interrupt our service if our business grows. We don't need to migrate from one small server to one big server. We just add more cells to our infrastructure.

This is what we would call "cloud native" tools: small services, small components, or small pieces of software that we can launch independently and then interconnect to create a larger structure. So, for a tool to have a chance to be adopted by the CNCF, it has to be "cloud native." Otherwise, it has to be able to work this way so it can find a natural home running in the cloud somehow.

CNCF Maturity Levels and Project Proposal Process

A project under the CNCF umbrella can be placed in one of three categories: Sandbox, Incubating, or Graduated. These are the so-called maturity levels. It's easier to get a project accepted in Sandbox, but it's a lot harder to get it accepted as Incubating and very hard to get it into the Graduated group.

Sandbox

Usually, if someone wants to donate their software tool/tools to the CNCF, they'll start by filling out a form and ask for it to be included in the initial Sandbox level. The CNCF has a few members who are part of the Technical Oversight Committee (TOC). Among other things, they are responsible for deciding what can become part of the CNCF. In this case, TOC members look at the tool asking for inclusion, and if the majority votes with a "yes," this will become part of the CNCF's Sandbox.

If a tool becomes part of the CNCF, the tool's trademark and logos must be donated to this organization. That's so the CNCF can legally use these when promoting these tools on their websites, blogs, live events, and so on. Basically, it is a way to avoid legal trouble down the road.

For a software tool to be accepted into Sandbox, it has to have these properties:

It's very good at solving a particular problem in this cloud-native space.
The tool is still very young, though, still in its early experimental stages. Some people use it in the real world, but not enough. It's still unproven, and this tool is not guaranteed to work correctly in most situations. It needs more time to be tested by more and more people until we can be sure that it's reliable.
Since this tool is rather young, there might not be many people contributing code, suggesting changes, improving it, or working on it somehow. So it has some community around it, but not a very large one.

Incubating

A project sitting in Sandbox can be upgraded to incubating if it proves it has evolved and matured enough as time goes by. If a software tool is already going strong, has a lot of people and companies using it, and has a lot of code contributors, its owners can request that it become part of the CNCF's Incubating category directly. That is, they can skip Sandbox and jump to Incubating directly.

Either way, the process of becoming part of incubating is much harder. Instead of filling out a simple form, the tool's owners have to write a technical document and send it to CNCF's GitHub repository. In this document, they must prove that their tool meets all the requirements to become part of the Incubating category. This can include community size, social channels, examples of companies using their tool, etc. Here is an example of a proposal.

If a Technical Oversight Committee member is impressed and has the time, they can step in and become what is called the "Incubation sponsor." They become a bridge between the tool's owners and the CNCF organization, other TOC members included. They lead and guide the discussions between all people involved.

They help other TOC members get a technical understanding of this tool and why it's a good candidate for incubation. The TOC members vote after a long process and technical analyses. For a project to be accepted as Incubating, two-thirds of the members must vote in favor.

To get a tool accepted in the Incubating category, it needs to have these properties:

It solves a problem in the cloud-native space.
It has a lot more community around it. Enough developers contribute code. Enough people in the team can review that code to decide what should get accepted, adjusted slightly, or rejected.
There needs to be proof that at least three end users use this tool and that it works reliably for them. But what is an end user? Someone that uses a cloud-native tool but DOES NOT sell cloud-native services.
Security is very important for a tool to be used in the real world. So, to be accepted into Incubating, such a tool must have a clearly documented way of handling security issues. They must have a publicly accessible document instructing users on reporting security issues. They must also specify how they handle those security issues and how they update their code or release new software versions to fix those issues.
They must have a clear versioning model. For example, they go from version 1.0.6 of their tool to version 1.0.7. It must be clearly documented how they decided to make such a version jump. Or how they go from 1.0.8 to 1.1.0, under what circumstances, what the conditions are, etc.

Graduated

Finally, let's take a look at the highest maturity level, Graduated. For a tool to get to this stage, it must be in the incubating category. The project maintainers must submit a graduation proposal document to CNCF's GitHub repository.

In this document, they should provide all proof that the project meets all requirements for this category. Here are some examples of a graduation document.

If and when a TOC member steps in as the sponsor, discussions begin. After a long process and careful analysis, TOC members vote. Two-thirds of the members need to vote in favor of the tool to be promoted from Incubating to the Graduated category. Here is Linkerd’s graduation document.

These conditions must be met to get a tool accepted into the Graduated category:

As usual, the tool must solve a problem in the cloud-native space.
All conditions from the Incubating category must be met.
The project must have committers from at least two organizations. What's a committer? Well, imagine I send a new piece of code to your project. I just suggest a change, but I cannot modify your project. You see my suggestion and agree that it's a good one. If you accept that suggestion that changes your code, the technical term is that you committed that change. Since you have the right to do commits, it is said that you are a committer for this project.
The project must have earned and maintained a so-called "Core Infrastructure Initiative Best Practices Badge." This badge is earned when the project follows a long list of best practices for an open-source, free software project. Some conditions to get this badge are pretty straightforward; for instance, the project's website must list what this tool does or how people can contribute new code or code improvements. Other conditions are a bit harder to achieve; for example, one developer in the team must know how to design secure software. Here is the full list. FLOSS Best Practices Criteria (Passing Badge).
TOC must vote in favor of the project to move into this Graduated category. Two-thirds of the votes must be in favor of passing.
Another document must list the organizations that adopted this project and those actively using it in their infrastructure.
A document on the project's website needs to detail the so-called project governance and committer process. For example, this document could explain all the steps required to take a code suggestion and actually commit the change to the project. It could also explain how to become a maintainer and what the responsibilities are. In a nutshell, it explains how the project is governed and how things should be done if you want to contribute to the project.
The project needs to ask an independent company to do what is called a security audit, where they look for security vulnerabilities in that software tool. After the audit, all of the critical vulnerabilities need to be fixed.

That's it. Those are the three CNCF project stages.

Explore our Open Source for Beginners Course to learn more about how to get involved in open-source projects.