传统开发被冲击得“七零八落”，云原生时代下开发者要如何自救？

Posted 2021-12-24 CSDN资讯

整理 | 郑丽媛
出品 | CSDN（ID：CSDNnews）

当前，新一轮科技革命和产业变革正在重塑全球技术发展格局，传统开发模式开始变得难以满足企业产品业务快速迭代和升级需求，数字化转型已然成为大势所趋，加之伴随着容器、Kubernetes 及微服务等技术热度的持续攀升，可以说云原生正以不可撼动之势，剑指云计算的下一个十年。在此趋势下，我们不禁展望未来：云原生市场将如何发展？各大云原生平台能否实现互通？云原生时代下，开发者会遇到怎样的问题，又该如何抓住机遇？

（图中从左到右依次为：于邦旭、陈皓、张鑫、司徒放）

为此，在 2021 长沙·中国 1024 程序员节上，我们特设了「云原生时代的开发者」圆桌对话环节，在 CSDN 副总裁于邦旭的主持下，MegaEase 创始人陈皓、火山引擎副总经理张鑫和阿里云应用 Paas 与 Serverless 产品线负责人司徒放三位专家共同探析云原生的未来图景，揭示云原生时代对开发者带来的价值与挑战。

以下为对话全文：

一、从“小作坊”步入“工业时代”

于邦旭：云原生时代为软件开发带来了哪些新的机遇和挑战？对程序员来说又面临着哪些变化与不变？

陈皓：对程序员来说变化在于“分布式”。以前开发代码可能都是在一台机器上完成，但现在不行了——除了一台电脑，开发者还需要很多配套设施，这大概也会是云原生的一个变化。

挑战则是人们需要去了解更多知识，包括组件都比以前复杂得多，由此导致开发环境、编程环境也变得更为复杂。

于邦旭：诚然如此，早期我们写代码通常都是写完直接上传，由运维去部署。当时程序员写代码关注的可能是操作系统和单机，但现在我们更多关注的是云。换句话说，以前我们可能是面向操作系统编程，而今天是面向云原生编程：我们用的很多 API 可能已经不是操作系统所带来的，而是云操作系统带给我们的。

张鑫：我打个比方：我认为没有云原生之前，我们的生产方式很像小作坊或者夫妻店，而有了云原生之后就开始步入类似工业时代的大规模、自动化生产，但这种转变有好也有坏。小作坊时代效率比较低，但感觉更为可控；大规模自动化阶段在效率上有所提升，可有些时候程序员可能会感觉比较黑核，因为代码提交后系统会自动适配，心里容易感到有些不安。

正如陈皓老师刚刚所说，云原生时代对程序员来说的确会改变他们的编程方式和习惯。以前我们编程的时候，需要在业务逻辑里面写控制逻辑、还有服务发现等，都需要写在代码里。但到如今新的模式后就真的完全解耦了，其实这是一件好事，但对程序员来说必须要完成这种思维和习惯的转变。

于邦旭：我对此深有同感。2012 年左右，那时我需要写一个能实时上报心跳的程序，但当时 ETCD 和 Consul 还不够成熟，开源领域也不像如今这么火，所以我没能获知 ZooKeeper 的存在。当时的我，一般就是写个代码然后一直上报，上报之后再去写大量的程序，然后从数据库里读出来、判断它的状态、再做后续的判断。结合陈皓老师和张鑫老师的看法，其实未来我们只需要引入一个云原生的 SDK 进行初始化，甚至可能连初始化都不需要，这一切问题就迎刃而解了。但这同时也会给开发人员带来一种疑惑：为什么我写完程序放到云原生平台后，监控系统那边的人很容易就能知道我服务的状态？为什么明明我没做这个工作，我的应用却掌握了这个技能？

司徒放：因为我是做云产品这一块，所以我会看到很多传统客户的整个软件开发过程已经被云原生冲击得七零八落了。不论是从 CI/CD、运维、监控还是到观测，整个开发领域在云原生时代下产生了非常巨大的变化和冲击，也就要求开发者要重新学习，学会推倒重来。同时，变革之下也是机遇，而我相信，云原生带来的将是未来 10 年都难得一遇的绝好机会。

此外，对许多业务企业来说，一方面云原生确实会给他们带来冲击，但另一方面他们也能从中受益：曾经需要自研的部分，如今几乎可以在开源领域中“唾手可得”。

于邦旭：从我的角度来说，云原生更大的机会是在于帮助一个企业省钱，这个省钱不仅仅是说省资源，更是降低线上损失。曾经，一个公司如果想做在线网站，必须招聘一个优秀的 IDC 运维人员，为此公司还需要帮他对接采购、对接买服务器，包括上架网站和之后的运维工作。但在云计算诞生以后，这个问题完全得到解决：你不需要有专业的 IDC 建设和运维人员，你只需要把应用部署到云原生平台上，所有工作就都可能由专业的云计算公司来完成。在这一基础上，企业就可能将优秀的研发人员专门投入到业务层面而非基础建设，这也就是云原生时代下该抓住的机遇。

二、“化敌为友”可能并不是梦？

于邦旭：目前阿里云、华为云、腾讯云还有火山引擎都推出了自己的云原生解决方案，未来这几家云原生是否有可能互通？

陈皓：总体上看来，我觉得不太可能。这些公司都是商业公司，并不中立，他们希望的是用户能够留在自己的平台上。不过从 AWS 发布 EKS Anywhere 可以看出公有云已经感到云原生的压力了——它卖控制台，但代码却可以运行在私有云里，也就是说 AWS 在这一点上开始中立，在把目前的公有云厂商往下压，让用户得以自建系统。这样一来对用户来说，一方面降低了成本，另一方面也拥有了自主可控的能力，不会被云厂商给锁住。不过即便有这种转变的态势，我依旧不觉得他们最终能够互通。

张鑫：从目前的趋势来说，互通是一个方向，但问题是谁来做这件事情，是云厂商、独立第三方还是用户？我最近看了很多报告：有些美国报告指出现在平均一家美国企业在用 5.2 朵云，但这个云里也包含了他们自己的 IDC；中国信通院最近也有一个调研报告，其中约 58% 的受访企业表示未来一定要基于混合云。

从商业本质来说，我认为应该是要满足“互通”这个市场需求的——因为以客户的角度出发，肯定是希望互联互通、有弹性，而不是被绑定，所以剩下的就是由谁来完成这件事。从 AWS 发布 EKS Anywhere、阿里发布 ACK Anywhere，可以看出公有云厂商现在都有不同的策略，作为“后来者”的火山引擎来说，我们也希望能做得更开放。

司徒放：云厂商自然是希望开发者、企业和用户都可以长在自己的云上，尽可能满足所有人。但我个人认为，用户的多元化诉求是必然的，这也必定是未来的一个趋势。

云厂商通常会把 IaaS 这层作为构建产品差异化竞争力的重点，所以会想方设法在计算能力、网络、存储等方面尽力提升，但本质上这其实已经被 K8s 标准化了。而对于 PaaS 这层来说，用户的多元需求不会改变，这在云原生的趋势下体现得更明显，所以云厂商会进一步拥抱开源。我们也知道用户喜欢开源开放，国内开源的环境也越来越好，因此我们也不断通过贡献社区、推出一些开放的、与社区兼容的产品等，去推动标准的建立，希望能做得更加中立和开放，也便于用户迁移过来或离开——个人认为，我们应该贴紧用户的需求，靠云产品自身硬核实力而不是绑定来留住用户。

三、中立的前提：开源开放

于邦旭：未来有没有可能出现这样一种情况：有一家公司专门做云原生平台，但它不做 IaaS，可开发者却更愿意使用这家公司的云原生标准或把应用托管到这家云原生平台，最后由这家云原生平台将其调度到其他家的 IaaS 上？

陈皓：我认为会出现这种公司，但前提是它必须保证开源开放，采用的必须是通用技术，甚至还要把源代码给到用户，方便他们对其贡献。举个例子，如果阿里云是这样的公司，那它就要做到允许用户一键迁到腾讯云，这样才能让人信服它是开放的。但对于一个商业公司来说，这其实很难。

对于用户来说，他们的诉求其实也各不相同。有些用户喜欢体验非常好的封闭产品，例如苹果手机，也有些用户更喜欢自主可控、支持自行修改的开源产品，例如安卓手机。回首过去 20 年皆是如此：要么你的确做得好，我愿意付钱，要么虽然你可能做的不如他好，但你性价比高并且开放。所以这两种形态一定是会并存的，不存在谁打过谁，即便未来有这么一家公司可能会把 PaaS 这些东西都做得更中立、更标准，但依然会有用户选择像阿里云和 AWS 这样的专有云。

张鑫：这个问题我们公司内部讨论的也非常多。作为后发者，我们当时在想，火山引擎要采取一个怎样的定位，是做一个独立的纯 PaaS，还是一起做 IaaS？后来我个人感觉同时做 IaaS 和一个非常中立的 PaaS 可能不矛盾。

虽然这件事直观看来用户肯定不相信，会觉得“你做 IaaS 肯定是希望把我绑在这”、“你又做 IaaS 又做 PaaS，怎么可能是中立的”。但从开放和中立的真正含义上来说，我觉得我们可以做到：

第一，让用户今天上得去明天下得来，并且成本很低，令他们觉得安心。

第二，要足够标准化，不要让用户有“我用了你的产品就用不了其他家产品”的担忧。

第三，要有足够灵活的可扩展性，甚至开放源码。

只要 PaaS 层满足这三个特性，不论有没有做 IaaS，用户都能感觉到你是相对开放和中立的。不过这只是一个理想状态，能不能实现还要看未来。

司徒放：现在可以看到已经有越来越多的云原生产品和平台出现，很多云厂商包括我们也都在做这方面的东西。刚刚陈皓老师提到能否从阿里云一键切换到腾讯云，虽然现阶段不管是阿里云还是其他云，大家还不会做这件事，未来要看这件事将来会如何演化，因为最终的出发点都是客户的诉求。

在阿里云做 PaaS 的人也希望客户能一直使用下去，所以阿里云 PaaS 是一定会往开放、标准化和开发者友好的方向去做的，只是说现在PaaS的多云形态还没到那个时候，我们 PaaS 跟 IaaS 的产品集成还有很大提升空间。

四、自主可控 vs. 方便稳定

于邦旭：现在很多云厂商都提供了标准的服务，但开发者可能更愿意使用一个标准的云平台把它变成服务化，所以未来云厂商的服务是否会演变成这种形态：开发者只使用云厂商的 IaaS 和 PaaS 能力，而真正的服务形态可能来自更为低价的开源版本？

陈皓：我觉得这种需求是一定会有的，主要出于对以下三个因素的考虑：

第一，成本，这无需多说。

第二，定制化需求。以阿里云 Kafka 为例，它的标准是一致的，或者最多有几个版本让用户选择，但对用户来说，有时可能要根据业务场景有所调整，定制化能力就显得较为重要，而这对云厂商的运维来说又比较困难。

第三，问题响应速度。如果使用的是开源版本，一旦发现问题开发人员就可以立即解决；但如果使用的是云厂商封闭化的标准服务，开发人员则需要给云厂商开工单、解释问题等，比较影响解决问题的效率。

不过这也存在一个隐患，即如果公司开发人员拥有这些修改权限，也会对应用稳定性产生一定威胁，因此还是需要在功能和稳定性之间进行权衡。

张鑫：这需要根据不同的用户群体而定。有些企业不想把自身的研发或运维团队扩建得太大，标准化的云上产品基本也可以满足业务需求，他们就会选择商业化服务。也有一些企业更喜欢自主可控，就会出现于老师说的这种情况，这主要有三个原因：

第一，服务响应慢，商业产品完全黑核，自己改不了，有问题只能发工单；

第二，很难结合自己的场景做深度定制和优化；

第三，随着开源和云原生的出现，自建的成本和门槛都降低了一些。

但这种模式下，用户往往会需要另外一种服务：有一些互联网公司希望云就用标准的 IaaS，中间 PaaS 层就基于开源自己搭，但同时他们也希望有一个最佳实践的技术团队来进行指导和解决难题。

司徒放：这个现象在云上是十分常见的，我们也有很多客户是直接拿开源自建。

有些企业相对来说技术实力没那么强，其实用开源也可以，但真正出了问题之后他们还是往云厂商和云服务迁移，然后这个时候比的就是成本。这种场景下，云产品其实一直在降价，或者说它会提供一些基础版来匹配这一类用户。

还有一种拥有很强技术实力的大型公司，他们也有足够的运维实力，所以如果他们倾向用标准的 IaaS，然后在 PaaS 层自建，这种客户目前很可能是不会用到阿里云的PaaS，所以有时候为这类企业提供一些最佳实践的帮助和咨询更为合适。

在开源的层面上，我认为在开源社区可以一起做相关交流，但未来还是要看人才的流动情况，比如能搞得起 kafka 这种深度问题的人才会有多少？这种人才谁养得起？在这种考虑下，只有云厂商和大公司才能招到这种人才，一般小公司很难招到这种专业人才，所以我认为未来的趋势应该还是以采用标准云服务为主。

五、程序员能力提升指南

于邦旭：各位对于工程师和程序员的培养理念是什么？在帮助自家公司程序员的能力提升上有何举措？

陈皓：首先我招的不算精英，精英我也招不起，我招的是潜力不错但被其他公司低估的人或者年龄较大其他公司不愿意用的人。

关于程序员能力提升方面，我主要有四个方法：

第一，写作。所有东西都必须写下来，写作是一种深度思考，是一种结构化的表达方式和沟通方式，我认为只要能把东西写好或者写得有条理性的人，基本上学习能力都会很强。因为写作需要做归纳总结，而归纳总结是学习能力中最高级的方式。

第二，所有技术方案都要拿出引用：到底是谁做的？有谁这么用了？最佳实践是怎样的？以此驱使他必须去翻很多论文、开源实践等，这叫“磨刀不误砍柴工”，因为我最讨厌的就是凭经验做事。

第三，分享。分享也是一种很好的学习方式，我们公司有硬性的分享要求，现在也在对外，因为对外你就会知道你要准备哪些知识。

第四，给予更多挑战性工作。这就像下棋一样，你得找个高手才能越下越好。

总体来说，我们公司培养人才就是以上这四个方法，基本在我们公司干一年提升的能力等于在别的公司干五年。

张鑫：我认为在人才培养方面有两点需要注意：

第一，多参与开源。因为参与开源面对的是整个开放社区和生态，这不仅会迫使我们更好地去提升自己的代码质量和架构能力，我们还可以从中找到设计很好的代码或者经验比较强的人当“师傅”。

第二，做 To B。当企业内部发展平稳后，可以通过 To B 创造更多富有挑战性的场景，以此推动程序员不断提升自我能力。

司徒放：阿里在人才培养上不仅关注技术，对商业、对客户、对产品使用等方面也有一个较为齐全的系统提升。

例如，阿里有“83 行代码”活动——工程师觉得自己代码写得好，就可以把优秀代码放到一个内网页面供大家评审；阿里有个不断更新的开发规约——里面有很多“避坑指南”供开发人员参考；阿里内部有一个 ATA——技术人员会把一些架构方案和设计在内网抛出来，文章质量很高，员工可从中学习；阿里也很推崇开源开放——技术团队会鼓励大家去做开源投入相关的事情，并且在开源社区中能学习到很多。

最后作为程序员来说，我有一个感觉挺幸福的点，那就是让自己的技术有变现的能力。相较于之前只能做一些 PPT 展示技术成果，现在通过 To B、云服务市场，你的产品有人用钱为你“投票”，这种挑战和成就感是完全不一样的。