我为什么放弃了云原生（中文版）
出于种种原因，我选择不再关注云原生。在那之后，我发现云原生并没有像我以前坚信的一样强大，它不是银弹，我也无需执着于它。
第一次认识云原生
在 2022 年 4 月之前，我曾经非常喜欢基于 Spring Cloud Alibaba 的微服务——使用它可以很容易地开发出完善的微服务。我开发了一套基于 Spring Cloud Alibaba 的微服务用于参加一个软件开发比赛，但在我将这些微服务制作成 Docker 容器并使用 Kubernetes (K8S) 去管理之后，我发现 K8S 和 Spring Cloud 并不能很好地配合：它们中的很多功能（例如 Spring Cloud Gateway 与 Ingress）都是重复的，造成了两者互不兼容。两者之间的冲突多到整个项目都无法正常运行。
这次犯错让我意识到我对 Spring Cloud Alibaba 和 Kubernetes 的了解都远远不够。在查找了足够多的信息后，我意识到 Spring Cloud 是用于构建传统微服务的框架，并不适合与 K8S 一起使用——除非你使用 Spring Cloud Kubernetes。此外，我也在收集资料的过程中了解到了一种名叫“Service Mesh”的新技术和一种名叫“云原生”的新理论。
对于当时的我来说，云原生和 Service Mesh 并不是容易理解的知识。但当我读了许多与此相关的文章和书籍之后，我最终理解了它们是什么，以及它们的优势在哪里。我立刻感到传统微服务是相当落后的东西——传统微服务过于依赖 SDK，服务代码与 SDK 紧密耦合，微服务架构中的许多通用基本功能，例如服务发现、资源调度等，都是由 SDK 提供的。更糟糕的是，当 SDK 发生破坏性更新时，服务代码也得跟着更新。Service Mesh 提供了一种更棒的解决方案：将这些基本功能做成一个进程或容器，并使其与微服务容器共同运行（也就是运行在同一个 Pod 里）。Service Mesh 令我震惊的同时，还解决了我关于微服务的所有问题。
云原生，我曾经最爱的理论
Service Mesh 引起了我对于云原生的兴趣。我发现云原生是一种引人注目的理论，并且一千个人眼中有一千种云原生。即使云原生如此抽象，以至于我至今都无法完全理解它，但我仍然在 2020 到 2022 年间持续学习它。我决定要从事与云原生相关的工作（例如云原生工程师、SRE、基础软件工程师等），所以我选择了 Go 语言作为我主要使用的编程语言，并且深入学习了 Docker、K8S 和 Istio，还没有错过任何一场我可以参加的有关于云原生和 Service Mesh 的会议。我并不认为这是一个成功的选择，不过我除了学习使用这些云原生工具以及它们的原理之外，还学到了大量软件设计和软件架构的知识。
现在再来回顾这段时光，我可以自信地说“云原生是我曾经最爱的理论”。
为什么我放弃了云原生
最终，我在 2022 年末决定不再关注云原生。做出这个决定的原因主要有以下三点：
- 云原生只是软件工程领域中的一种不成熟且抽象的理论，它并不能被用于解决所有问题——例如设计简单且低成本的 Web 服务。
- 创业公司和小公司在实践中不适合使用云原生和 Service Mesh。这是针对成熟的大型 Web 服务的理论和工具。
- 云原生是一种非常宽泛的理论，我并不需要如此执着于它本身。例如，开发和维护类 UNIX 操作系统和高性能的网络代理服务也是对云原生和 Service Mesh 的贡献。
当然，这并不意味着云原生这一理论不好或者我们不应该关注它。准确地说，我只是改变了为它做贡献的方法——现在的我将专注于开发类 UNIX 操作系统、网络代理、虚拟机等与云相关的基础软件，以此为云原生做出自己的贡献。