In 2021, where will cloud native go?

Head picture | Paid download at Visual China

Translation | Daixiang (Huawei Cloud Native Team)

Author | Chris Aniszczyk (CNCF CTO)

Recently, CNCF released an annual summary of all work in the cloud native field in 2020[1]. We have had a solid year under the epidemic situation. We hope readers and friends will read the report. This article will share my thoughts on the direction and trend of cloud native development in 2021 and beyond.

Cloud Native IDE

In the future, the development life cycle (code, build, debug) will mainly occur on the cloud, rather than local Emacs or VSCode. Each PR will have a complete development and deployment environment to meet the needs of development and debugging.

Currently, GitHub Code Space and GitPod are both specific examples of this technology. Although the GitHub code space is still in the testing phase, you can try GitPod. Take Prometheus as an example. In about a minute or so, you will have a complete online development environment, including an editor and a preview environment. The craziest thing is that this development environment (workspace) is described in code and can be shared with other developers in the team like other code middleware.

I look forward to seeing cloud-native IDEs continue to innovate incredible in the future, especially when the GitHub code space is widely used at the end of the testing phase, so that developers can experience this new concept and fall in love with it.

Edge Kubernetes

Kubernetes was born in a mass data center, but Kubernetes will evolve into a new environment like Linux. The final result of Linux is that end users have expanded the kernel to support various new deployment scenarios in different fields, including mobile and embedded.

I firmly believe that Kubernetes will undergo a similar evolution. We have seen operators (and startups) use Kubernetes as an edge platform, transforming VNFs into CNFs (Cloud Native Network Function) through open source projects such as KubeEdge, k3s, k0s, LFEdge, and Eclipse ioFog. ). The support of hyper-scale clouds for operators and edge scenarios, the ability to reuse cloud native software, and the ability to build on the current huge cloud native ecosystem are all driving forces that consolidate Kubernetes as edge computing in the next few years. The position of the dominant platform.

Cloud Native + WASM

Web Assembly (WASM) is a technology that is just getting started, but I hope it can become an increasingly important role in the cloud native ecosystem, especially as WASI matures and Kubernetes is more used as the edge collaboration described above Device. One use case is to power the extension mechanism, as LuaJIT and Envoy do. Instead of dealing directly with Lua, you can use a small optimized runtime that supports multiple programming languages.

The Envoy project is currently in the process of adopting WASM. I expect that any environment will follow a similar pattern, and the scripting language as a popular extension mechanism will be completely replaced by WASM in the future.

On the Kubernetes side, some projects like Microsoft's Krustlet are exploring how to support WASI-based runtimes in Kubernetes. This should not be too surprising, because Kubernetes has been extended through CRD and other mechanisms to run different types of workloads, such as VM (KubeVirt). In addition, if you are new to WASM, I recommend this introductory course from the Linux Foundation:

https://www.edx.org/course/introduction-to-webassembly-runtime。

The rise of FinOps (CFM)

The outbreak of the novel coronavirus has accelerated the transition to cloud-native, and at least half of the companies are accelerating their cloud plans during the crisis...Nearly 60% of the respondents said that due to the COVID-19 pandemic (State of the Cloud 2020 Report https ://info.flexera.com/SLO-CM-REPORT-State-of-the-Cloud-2020), the cloud usage rate will exceed the previous plan. Most importantly, cloud financial management (FinOps) is a growing problem and a concern for many companies.

To be honest, in the past six months, some companies and I have discussed about half of the cloud-native journey. You can also say that cloud providers are not motivated to simplify cloud financial management because that would make it easier for customers to reduce expenses. The real pain is the lack of open source innovation and standardization in cloud financial management (all cloud cost management methods are different). There are not many open source projects in CNCF that try to make FinOps simpler. The current KubeCost project is still very young.

In addition, the Linux Foundation recently launched the FinOps Foundation to promote innovation in this field. They have a lot of introduction materials in this field worth reading (https://www.edx.org/course/introduction-to-finops). I hope to see more open source projects and specifications in the FinOps field in the next few years.

More cloud-native Rust projects

Rust is still a young and niche programming language, especially if you take Redmonk's programming language ranking as an example. However, my feeling is that in the coming year, you will see Rust in more cloud-native projects, because a few CNCF projects have begun to take advantage of Rust, such as microvm Firecracker. Although most of CNCF's current projects are written in Golang, I expect that within a few years after the Rust community matures, Rust-based projects will be the same as Go-based projects.

GitOps + CD/PD has grown significantly

GitOps is a cloud-native technology operating model that provides a set of best practices for unified application deployment, management, and monitoring (originally proposed by Alexis Richardson from Weaveworks).

The most important aspect of GitOps is to describe the desired system state for declarative versioning in Git, which actually enables a complex set of system changes to be applied correctly and then verified (audit logs enabled by Git and other tools).

From a practical point of view, GitOps has improved the developer experience. With the continuous growth of projects such as Argo, GitLab, and Flux, I expect GitOps tools to have more impact on enterprises this year. If you look at GitLab's data, GitOps is still an emerging practice, most companies have not yet explored it, but as more and more companies begin to adopt cloud-native software on a large scale, the development of GitOps will naturally be as I said.

Service Catalog 2.0: Cloud Native Developer Kanban

The concept of service catalog is not new. For those of us who grew up in the ITIL era, you may remember things like CMDB, but with the rise of microservices and the development of cloud native The ability to catalog and index various real-time service metadata is essential to drive developer automation. This may include using the service catalog to understand the ownership of handling incident management, managing SLOs, etc.

In the future, you will see that the developer dashboard is not just a service catalog, but can be extended with various automation features. Typical open source examples are Lyft's Backstage and Clutch, but any company that uses cloud native often has a platform infrastructure team that tries to build something similar. As open source dashboards with a large plugin ecosystem mature, you will see more and more platform engineering teams accelerate their use of them.

Cross-cloud is no longer a dream

Kubernetes and the cloud native movement have proven that in a production environment, cloud native and multi-cloud approaches are possible. The data shows that 93% of enterprises use the services of multiple cloud vendors such as Microsoft, Amazon, and Google (2020 State of the Cloud Report https://info.flexera.com/SLO-CM-REPORT-State-of-the-Cloud -2020).

As the cloud market continues to mature, Kubernetes is expected to open programmatic cross-cloud management services. A specific example is reflected in the Crossplane project, which uses the scalability of the Kubernetes API to provide an open source cross-cloud control plane to achieve cross-cloud workload management (see https://thenewstack.io/gitlab-deploys-the-crossplane- control-plane-to-offer-multicloud-deployments).

eBPF becomes mainstream

eBPF allows you to run programs in the Linux kernel without changing the kernel code or loading modules, you can think of it as a sandbox extension mechanism. eBPF allows a new generation of software to extend the behavior of the Linux kernel to support a variety of different functions, including improved networking, monitoring and security. The disadvantage of eBPF is that it requires a high version of the kernel version to use it, and for a long time, this is not a realistic choice for many companies.

However, the situation is changing and even newer versions of RHEL start to support eBPF, and you will see more projects using it. If you look at Sysdig’s latest container report (https://sysdig.com/blog/sysdig-2021-container-security-usage-report/), you can see that Falco usage using eBPF for container security checks is increasing increase. Therefore, please stay tuned and look for more eBPF-based projects!

In 2021, where will cloud native go?

The king of distributed architecture? Why Kubernetes

Mendix enters China low-code, are you ready, developers

How does information spread virally? Understand the Gossip protocol in one article

See through the appearance of the container, demonstrate the principle of Linux container implementation

Guess you like