kubernetes-handbook/cloud-native/cloud-native-programming-la...

30 lines
3.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# 云原生平台配置语言
云原生平台配置语言是一种 DSLDomain Specific Language通过编程的方式来创建云原生平台目前已有的云原生 DSL 有:
- Ballerina
- Pulumi
- Cue
- KCL
- Kusion
以下内容引用自 [Joe Duffy 的博客](http://joeduffyblog.com/2018/06/18/hello-pulumi/)。他说这些是为了说明为什么要创造 Pulumi在此我引用它说明为什么会有云原生编程语言。
对于每一个 serverless 函数来说,我都要写几十行的 JSON 或者 YAML 配置。要链接到一个 API 端点,我还要学习晦涩的概念,执行一系列复制 - 粘贴的低级工作。如果我想在本机上运行一个小的集群的话,那么 Docker 还是很棒的,但是如果要在生产上使用的话,那么就要手动管理 etcd 集群,配置网络和 iptables 路由表,还有一系列与我的应用程序本身不相干的事情。不过 Kubernetes 的出现至少让我可以配置一次下次就可以跨云平台重用,但这还是会分散开发人员的精力。
我认为我还算一个经验丰富的工程师,已经在软件行业从业 20 年了,但是当我想要将自己的代码部署到云中的时候,我感觉自己就像是个傻子。真是太令人悲哀了!如果我掌握了这些能力,那么是世界就会出触手可及。我总是在淌这浑水,处理云的复杂性,而我真正想做的是花时间来创造业务价值。
关于编程的许多方面都经历了类似的转变过程:
- 在 80 年代初,我们使用汇编语言对微处理器进行了编程。最终,编译器技术进步了,我们可以同时处理多种常见的架构。像 FORTRAN 和 C 这样的 Low-level 的编程语言开始兴起。
- 在 90 年代初期,我们直接针对低级别操作系统原语进行编程,无论是 POSIX 系统调用还是 Win32 API并进行手动内存和资源管理。最终语言运行时技术和处理器速度提升到了可以使用更高级别语言的状态如 Java。除了动态语言之外这种趋势已经加速如 JavaScript 统治了 Web。
- 在 21 世纪初期,我们的编程模型中的共享内存并发性最好是原始的([我花了很多时间在这个问题上](http://joeduffyblog.com/2016/11/30/15-years-of-concurrency/))。现在,我们简单地假设 OS 具有高级线程共享、调度和异步 IO 功能,以及编程到更高级别的 API例如任务和承诺。
我相信云软件也在进行类似的转变。从构建单一应用程序到构建真正的云优先分布式系统,我们正处在一场巨变中。然而,当海啸发生之前,人们几乎不知道它正在发生。
从上面的角度来看,使用 “配置” 情况是有道理的。在虚拟机的早期,我们利用现有的应用程序并将它们扔在栅栏上,以便有人添加一点 INI 或 XML 粘合剂,让它们在虚拟机内部运行,以实现更灵活的管理。随着我们将这些相同的虚拟机 “提升并转移到云中”,这种配置方法一直伴随着我们。这将我们带到了大致正确的边界。
使用这种相同类型的配置表示基于容器的微服务、serverless 和细粒度托管服务之间的关系导致了异常的复杂性。将应用程序转变为分布式系统应该是事后的想法。事实证明,云覆盖了您的架构和设计。表达架构和设计的最好的方式是使用代码,使用真正的编程语言编写抽象,重用和优秀的工具。
早些时候Eric 和我采访了几十个客户。我们发现,开发人员和 DevOps 工程师都普遍感到幻灭。我们发现了极端的专业化,即使在同一个团队中,工程师也不会使用同一种语言。最近几周我已经听到了这个消息,我期待有一天会出现 NoYAML 运动。