Shulou(Shulou.com)06/01 Report--

This article shows you what the brief introduction of cloud native landscape from CNCF is like, which is concise and easy to understand. I hope you can get something through the detailed introduction of this article.

When you are studying cloud native applications and technologies, you may have seen the cloud native landscape map provided by the Cloud Native Foundation (CNCF). Not surprisingly, it is quite large in scale. So many categories and so many technologies. What should we think of it?

Like any other complex thing, if you don't break it up and analyze it, you'll find it's not that complicated. In fact, cloud native landscapes are organized functionally, and once you understand what each category represents, you can easily "navigate".

In the first article in this series, we will break down this vast native cloud landscape and provide an overview of the whole, each layer, each column, and each category. In subsequent articles, we will focus on each layer and column, and introduce what each category is, what problems it solves, and how to apply it.

The four layers of the original cloud landscape

In the first layer, it is a tool to configure the cloud native infrastructure. The second and third layers add the tools needed to run and manage the application, such as the runtime and orchestration layers. At layer 4, there are tools for defining and developing applications, such as databases, mirror builds, and CI/CD tools.

Now, the cloud native landscape starts with the infrastructure, and each layer is closer to the real application. You may also notice that there are two "columns" that run across all layers, which we will discuss later in the article.

1. Supply layer (Provisioning)

Provisioning refers to the tools involved in creating and strengthening the foundation of cloud native applications. It covers everything from automated infrastructure creation, managing and configuring image scanning, image signing, and storing images. In addition, it also has tools to build authentication authorization and handle key distribution in applications and platforms, as well as tools in the areas of resource provisioning and security.

In the supply layer, you will see:

Automation and configuration tools (Automation & configuration): help engineers build the underlying environment without human intervention.

Container repository (Container Registry): stores an image of the application.

Security (Security & compliance): involves different security areas.

Key management (Key management): helps with encryption to ensure that only authorized users can access the application.

These tools enable engineers to know the details of all the infrastructure so that they can be adjusted as needed to ensure their consistency and security.

two。 Runtime layer (Runtime)

Runtime is one of the most confusing terms in cloud natives. Like many terms in IT, there is no strict definition and can be defined according to the context used. In a narrow sense, the runtime is the specific sandboxed environment in which the application is run (the minimum required for the application to run). In a broad sense, the runtime is any tool that an application needs to run.

In the CNCF cloud native environment, the runtime focuses on components that are particularly important for containerized applications. They include:

Cloud native storage (Cloud native storage): provides virtualized disks or persistence for containerized applications.

Container Runtime (Container runtime): provides constraints, resources and security for containers.

Cloud network (Cloud native networking): the network through which nodes of distributed systems connect and communicate.

3. Choreography and management (Orchestration & Management)

Once the infrastructure (supply layer) is automatically built in accordance with security standards and the tools (runtime layer) that the application needs to run are set up, engineers need to know how to orchestrate and manage their applications.

Orchestration and management to manage all containerized applications as a group. Also determine whether you need to communicate and coordinate with other services. At the same time, cloud native applications have good scalability.

In this layer, it includes:

Orchestration & scheduling: deploy and manage container clusters to ensure that they are resilient, loosely coupled, and scalable. A typical container orchestration tool is Kubernetes.

Service discovery (Coordination and service discovery): a tool by which services can communicate with each other.

Remote procedure call (RPC): a technology that communicates across services on a node.

Service broker (Service proxy): the sole purpose of the agent is to exert more control over the service communication, and it does not add anything to the communication itself. These proxies are critical to the service grid mentioned below.

API gateway: an abstraction layer through which external applications can communicate.

Service grid (Service mesh): somewhat similar to an API gateway, it is a dedicated infrastructure layer through which applications communicate, but it provides communication for policy-driven services. In addition, it may include everything from encryption to service discovery to application observability.

4. Application definition and Development layer (Application Definition & Development)

As the name implies, the application definition and development layer is a tool that focuses on enabling engineers to build applications and make them run.

Under this category, you will see:

Database (Databases): enables applications to collect data in an organized manner.

Streaming and messaging: enables applications to send and receive messages (events and streams). It is not the network layer, but a tool for queuing and processing messages.

Application definition and image building (Application definition & image build): services that help configure, maintain, and run container images.

Continuous integration and continuous delivery (CI/CD): enables developers to automatically test code, automate packaging, and even automate deployment to production environments.

Tools that run across all layers

Next, we will introduce the two columns that run on all layers-observability and analysis.

Observability and Analysis (Observability & Analysis)

To reduce MRRT (time to resolve software problems), you need to monitor and analyze all aspects of the application so that any anomalies can be detected and corrected immediately. Failures can occur at any time in a complex environment, and these tools will help mitigate the negative effects of failures by helping to identify and resolve them as soon as possible. Because this category traverses and monitors all layers, it is on the side, not embedded in a specific layer.

Here you will find:

Logging (Logging): a tool for collecting event logs (information about processes).

Monitoring: collect metrics (system parameters, such as RAM availability, etc.) and monitor health.

Tracing: go one step further than monitoring, which is related to the service grid.

Chaos Engineering (Chaos engineering): a tool for testing software in production that can identify defects and fix them before delivery.

Platform class (Platforms)

As we can see, each module solves a specific problem. For example, storage alone does not provide all the functionality needed to manage the application. You will need an orchestration tool that covers multiple layers and bundles different tools together to solve bigger problems.

You may notice that all categories are expanded around Kubernetes. This is because Kubernetes is the most popular cloud native orchestration tool.

Platforms can be divided into four categories:

Kubernetes distribution: unmodified open source code (although it has been modified) and adds functionality to track market demand.

Kubernetes hosting: similar to distributions, managed on the provider's infrastructure.

Kubernetes installer: use them to automate the installation and configuration of Kubernetes.

PaaS / Container Services: similar to Kubernetes hosting, but contains an extensive set of application deployment tools (usually part of a cloud native environment).

In each category, there are different tools designed to solve the same or similar problems. The difference lies in their implementation and design methods.

When making a choice, engineers must carefully consider and weigh each feature to determine the best choice for their use cases. Although this brings additional complexity, it is critical to choose the data store, infrastructure management, messaging system, and so on that best suit the needs of the application.

The above is a brief introduction to the cloud native landscape from CNCF. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.