Since its inception in 2015, the Cloud Native Computing Foundation (CNCF) has become one of the most important enablers in the open source ecosystem, especially when it comes to tools that impact containers and other "cloud-native" technologies. The CNCF was founded to facilitate and organize projects related to large industry trends, including containerization, orchestration, and microservice architecture. Since then, the CNCF has added 10 open source projects.
Even if you have never heard of CNCF, you must have heard of one of its more popular projects: the Kubernetes container orchestration platform, but CNCF is much bigger than Kubernetes. If you want to learn about important developments in containers and cloud computing, you can take a look at other important projects in the CNCF ecosystem described below.
LEFT
The first is Linkerd, an open source "service mesh" project for microservices-based cloud-native applications.
The idea behind Linkerd is: Microservices are great, but the benefits of microservices are only realized when you have a good way to connect them together to form a complete application. Otherwise, your microservices application becomes a bulky moving part that doesn't fit well with each other.
Linkerd is an open source project that aims to solve the above challenges by providing what developers call a "service mesh". Linkerd's service mesh provides a convenient and reliable interface where different services can run interactively. In addition to simplifying the programmer's job by providing a simple way and a consistent abstraction layer for connecting services, Linkerd is designed for scalability, high availability, and security. The project is overseen by Buoyant, who joined CNCF in early 2017.
FLUENTD
Metrics are only one facet of the microservices application visibility puzzle. Centralized logging is another.
As the number of applications and company size grows (especially as more and more services are containerized), it is important to collect, analyze, and query structured logs in one place.
This is the original intention of Fluentd. Fluentd is a log collector (similar to logstorage) through which logs can be filtered, sanitized, and routed to various destinations. Like other log collectors, Fluentd can be used with various core and third-party input and output plugins such as Elasticsearch plugin, S3 plugin, etc.
Fluentd also has some in-memory storage and reliability. The log path from multiple hosts to Fluentd and then to the rsyslog file of the Elasticsearch cluster is extremely concise, and this simple example also fully demonstrates the benefits of using Fluentd.
OPENTRACING
A third project worth paying attention to is distributed tracing. As a monolithic application is decomposed into various smaller services, it is natural that more and more data is transferred across services, from front end to back end, and from service to service. But what happens when a common application with various dependencies is suddenly delayed? This is where distributed tracing comes in. At its core, tracing is propagating metadata through different request calls, threads, and processes, and ultimately building a graph based on this metadata.
OpenTracing is a tracing standard that was created in response to a long-standing problem in the distributed tracing space - namely, how a company's stack might consist of a large number of third-party software, operating systems, and custom applications. Coordinate tracking?
OpenTracing, a standardized tracing program, is the solution to this dilemma. This project provides standardized services for device APIs across (ie timing operations) management and inter-process propagation. Therefore, users can easily switch to tracking libraries or centralized tracking systems (such as Zipkin, Dapper, etc.) without complicated configuration and a lot of trouble.
GPRC
So far, we've seen how to deploy, schedule, and understand microservices in the cloud. But what is the mode of communication between them?
Let's take a look at "Remote Procedure Call (RPC)".
The concept of remote procedure invocation has been around for a while and refers to a pattern in which functions are called remote and are typically used in systems rather than the CRUD model based on RESTful services.
However, gRPC refers to Google's implementation of Remote Procedure Call, which utilizes http/2 and protocol buffers. Compared to jsf-based RPC, gRPC has been shown to be orders of magnitude faster, making it an excellent choice for large distributed platforms. In fact, etcd (the popular key-value store from CoreOS) and Google's own BigTable are both gRPC!
RKT
A final noteworthy project is rkt (also known as Rocket), a container runtime. Although Docker's containerd runtime may be a container-oriented runtime that promotes the concept of containers, Docker is still a commonly used runtime in the orchestration ecosystem, so we believe that RKT will become more and more popular in the future.
The difference between the two is also obvious. While Docker has opted to be packaged in a cluster and consist of a daemon and an executable that communicates with the guard via a REST API, rkt is much simpler. It consists of a simple command line tool that enables rkt to run a container when given an image, a canonical format, and an image discovery mechanism.
With RKT, users can avoid issues like systemd when configuring the container runtime. Additionally, rkt can run not only images in the App Container format, but also standard Docker images.
Epilogue
We are moving faster and faster to a world of microservice architectures, and at the same time, more and more open source projects are emerging to serve organizations and individuals who really want to be "cloud native". CNCF has a large number of excellent but not necessarily well-known projects. This article only covers some of them. It is recommended that you learn more about other projects and reserve for the future: https://www.cncf.io