Finding your way into Cloud Native 

I presume you already have heard about Cloud Native before but if not certainly about Cloud Computing at some point. In a nutshell, Cloud Computing is the usage of a distributed computer network that consists of servers, network components and storage. Everybody uses services hosted on “the cloud” day by day (This website is also hosted in the cloud). Maybe you or your team have also configured a system using a Cloud Provider AWS, Azure, GCP or planning so. From here on out we are on a good path to getting into the Cloud Native topic. Let me say right now, Cloud Native is not another Cloud Provider, it adds to it.

You can expect of this article to get an introduction to Cloud Native. We will not dive into details that much though. I am planning a couple of follow-up articles that talk about Cloud Native topics in more detail.

Hello, Cloud Native

With Cloud Native you will encounter the Cloud Native Computing Foundation (CNCF) that hosts some of the biggest Cloud Native projects. That is right, only some - Cloud Native is not a brand, it is a term to describe a certain kind of service. These Cloud Native Applications (CNA) have common attributes that make an application Cloud Native. Let’s walk over those and then look into the CNCF and its Projects.

Attributes of Cloud Native Applications

The CNA attributes are all familiar to Software Engineers and lay the ground for well-designed software. Let me just mention these briefly.

• Scalability: The ability of a system to behave as expected in the face of significant upward or downward changes in demand without the need to be refactored to perform its intended function.
• Loose Coupling: Components have minimal knowledge about other components. Changes to one component also do not require changes to another component (components are loosely coupled).

• Resilience: Measure how well a component withstands and recovers from errors and faults. Operation should be possible at a reduced level without failing completely.
• Manageability: The ability to change the behavior of a component without altering the code.
• Observability: Measure of how well and accessible a component makes information about its internal state available without the need of altering the code.

Any application running in the cloud should strive to meet these CNA attributes. Just as an aside, these attributes do not describe platform requirements. These are generic design concepts that can be applied to any IT infrastructure, like your own data center or any public cloud. For example, AWS Lambda is also a Cloud Native Application by definition. The fact that it is provided only on AWS does not eliminate the service from being cloud native. It is possible to create a Cloud Native system in a public cloud environment using only the public cloud services.

Context of Cloud Native Applications

To build a system which incorporates these Cloud Native attributes you committed to build a microservice or service-oriented system that uses containers to ship the software. Just by running a container on a VM you cannot reach those goals of scalability, resilience, manageability, observability and loose coupling we talked about before. The surrounding infrastructure allows that, which can be provided by public cloud services or container orchestrators like Kubernetes. Kubernetes will be introduced briefly later in this article. To better follow these thoughts, you can consider the following diagram.

As said, the services around your application turn the application into a Cloud Native Application. All these services can be self-managed or managed by someone else. Let’s return to the initial introduction of CNCF and the role it is playing in the Cloud Native world.

Cloud Native Computing Foundation (CNCF)

The Cloud Native Computing Foundation (CNCF) is an open-source software foundation that hosts some of the largest and most prominent cloud native projects. The CNCF, a subsidiary of the Linux Foundation founded in 2015, aims to build a vendor-neutral community of developers, end users, and IT technology and service providers to collaborate on open projects. With the donation of the Kubernetes project from Google, the CNCF was founded and has grown rapidly since then. The CNCF hosts events such as KubeCon and other gatherings. The CNCF is mainly funded by donations from large IT companies.

Why does the CNCF exist?

We've already talked about the CNCF's mission and its role in the cloud native landscape. One question you might be asking yourself now is why it exists at all. Why do you give your project to CNCF and not just keep it in your organization? I think clarifying that question explains why CNCF was created and exists. From my perspective, it's about adapting to new projects. The CNCF and similar organizations have (not so) secret superpowers in terms of project adaptation.

• Open-source community: By hosting projects as open-source software, the technology becomes transparent, changeable, and manageable by everyone. Open source is a key factor in why CNCF can be sustained and works so well. Focusing on building community and events that connect people in the industry is one of the paybacks for everyone's work.
• Conflict-free software: By hosting projects through an independent third party, there is no potential for conflict between two competing companies. Two companies competing with each other do not promote or support each other's projects but are likely to develop more or less the same project sooner or later. Projects under CNCF or similar organizations avoid that because they are independent.
• Organization, creditability & corporate image: Managing open-source projects are not trivial, a lot of commitment has to be invested. Integrating a project into the CNCF gives the project a certain degree of credibility and embeds it into an organizational structure.

• Ecosystem: CNCF is building an ecosystem of software that can work well together. This may sound like vendor lock-in, but since it is not a closed system, any integration can be added to any project. It's a very good thing to pull all the strings together so complex projects can work better.

Let’s look at some projects!

CNCF Projects

The CNCF has three categories to develop projects first a project is in the Sandbox stage then it moves to the incubation stage and finally reaches the graduation stage (you can find more information about this here). Note that there is no guarantee when or if a project will move to the next phase. In the following image you can see all graduated projects as of March 2022. For a more complete picture you can check out the Cloud Native landscape (don't let it scare you :D).

Let's introduce a few of these projects briefly.

• Kubernetes: is an open-source system for automating deployment, scaling, and management of containerized applications. Kubernetes is the hearth of the CNCF ecosystem and the first project that joined the CNCF.
• Prometheus: is a project for system monitoring and alerting. It is the second project after Kubernetes that joined the CNCF in 2016.
• Etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines.
• Helm is used to manage Kubernetes applications and acts like a package manager.

You can find an overview of all these projects on the CNCF website.

Why does Cloud Native matter

I assume you have already found reasons why Cloud Native is a thing, but let's conclude anyway. I think you can also break this question down into smaller "why does it matter" questions, such as why it matters to develop open source, why it matters to develop Cloud Native applications, or as we have already discussed, why the CNCF matters. All of these come together and conclude into Cloud Native matters.

Open-source matters because it is a transparent, free, open, and community-driven way to develop software. Cloud Native Applications matter because they are the result of developing good software in the cloud. Cloud Native matters because it gives you the tools to build well architected systems in the cloud.

That wraps it up. Questions, feedback, anything is always very welcome! You can reach me on Slack on the Kubernetes server or on Twitter.