今天看到公众号”非法加冯“的文章”数据库应该放入K8S里吗？“，很有一些感触，我想谈谈我的一些看法。
我的职业生涯早期，正赶上无中间件时代（主要是国内）的末期。那时公司的一个银行业务系统全部是 C 语言编写的，从通讯到界面，都是自己的代码，那时没有太多开源项目，没有中间件。数据库是有的，不过主要是那几个厂商的产品。那时公司的几个核心程序员都是名牌大学毕业，甚至有好几个状元，在我们那个二线城市中十分的耀眼。
不过，中间件时代不可避免的到来了。一方面，中间件确实解决了问。随着农信社省集中到要求，公司的应用无法承担省级业务的压力，将应用迁移到了 Tuxedo 。另一方面，JEE 中间件的崛起也让许多人有了做程序员的能力。在我离开这家公司好几年后，我得知这个公司的主要程序员已经都是一些普通本科学生了。而我后面的中间件产品支持生涯，经常需要与一些离谱的程序和程序员作斗争。
无论如何，整个行业被 IBM 这样的大公司塑造了。无论是开发还是运维，都是围绕着这些大厂商的产品进行，尤其是运维，因为产品稳定运行的需要，以及商业保障的要求，国内的大企业，尤其是一些金融机构，都在大厂商的指导下建立了健全的运维体系。
出现这个局面我觉得无可厚非，当基础能力不足时，如果能自上而下的推进先进的管理和技术理念，迅速的建立体系，自然能够大大加速整个行业的发展。但是，整个行业的发展，不仅仅来源于大厂商的顶层设计，也有另一个力量在发挥着巨大的作用。开源软件一直也是整个行业的驱动力，例如《黑客》一书描述的三代黑客，也拍成了纪录片。中国进入 WTO 之后这些商业驱动的大厂商更快的进入中国市场，而与之分庭抗礼的开源文化则姗姗来迟。
这些文化的作用不可小觑。例如大厂商塑造了企业级开发语言 Java，而 Hibernate 和 Spring 这样的开源项目却成为事实上标准，最终影响了 JEE 规范的建设。以至于，现在已经有很少人提及 JEE 规范，而 Spring Boot 却依然是市场的主流。
于是，中国的企业，尤其是早期依靠信息化发展的企业，以及这些企业的人，都有着深深的大厂商烙印。由这些头部企业引导的整个行业，也具备了更多大厂商的特色。再加上中国本身的一些原因，整个行业缺乏了一种自下而上的动力，即使互联网时代的到来对这个局面也并没有改善太多。
随着业务需求变得更加急迫和复杂，开源软件和云计算厂商发挥了更大的作用，传统厂商的建立的秩序受到了冲击，不能垄断原先的中间件和数据库市场了。越来越多的解决特定需求的数据库和中间件产品涌现了出来，相对于传统厂商的产品，这些产品有以下特点：
- 产品种类更多：为了解决越来越复杂的业务问题，需要更加特定产品；而开源技术的发展，也让创造一个产品越来越容易，所以各类产品层出不穷。
- 架构更加复杂：这些产品往往要解决大规模、实时性要求更高的场景，所以架构会更加复杂；同时，这些产品也缺乏传统厂商产品的那种支持力度，所以对于复杂的封装往往不够，让使用者感觉更加困难。
- 与开发更加紧密：许多产品远没有传统厂商产品那样与应用泾渭分明，甚至许多产品本身更像是一个平台，想要运维好这样的产品，必须理解其被程序使用的方式，这对运维人员是一个不小的挑战。
对运维人员来说，需要支持数量更多，架构更加复杂，且与开发和业务结合更紧密的产品，其中的压力不可谓不大。
对于中国用户来说，信创制度无疑又让这个形式更加严峻。如果说市场竞争下涌现出的新产品是为了解决特定问题，没有需求的话完全可以不用。而信创则是在原有的领域创造了一堆相似的竞品，用户不得不选，不得不准备更多的人力去应对。
毫无疑问云计算本来是一个非常标准的答案。许多云计算厂商培养出来的“DBA”，只知道在云计算界面上点鼠标，无疑让这个行业的门槛又“降”了一级。
虽然对于专业人士来说，这个“降级”很不专业，但有些云计算厂商也确实抬高了这一行的上限。云计算厂商将自己的各类服务封装成了统一的接口，通过厂商自己的工具，或 Terraform 这样的基础设施即代码工具，专业人士可以在云计算服务商实现高效的运维，甚至实现平台工程。
云计算封装的数据库服务确实解决了许多问题，以至于许多数据库产品厂商，例如 MongoDB，Snowflake 也把盈利的重心投向了数据库即服务，而且这些专业的数据库服务商可以提供跨云计算厂商的数据库服务，一定程度上缓解了客户对云计算厂商绑定的担忧。
又说到了中国特色，似乎中国公有云市场的远没有国外那么大。2021年有一个报道，说是 38 家上市公司实现了 A 股 42% 的利润，姑且不提许多民营小企业没有上市，这种数据也暗示了真正有能力在 IT 上大量投入的许多企业，因为合规等原因，是不会大规模使用公有云的。国内几家云厂商的行动也印证了这个认识，现在的各类金融机构，基本上都购买了某个云厂商的私有云产品。
但是这个私有的云，对于云计算供应商来说可能也是一个负担，一个现象是许多这样的私有云的软件版本很低。可以想象，这些私有化部署的云，运维的成本不低，采取保守的版本策略也正常。因此，私有云中的产品也往往不如公有云环境中的丰富，版本也可能不够新。
对于有创新需要的企业，这些私有云可能无法满足业务的需要，还是需要用自己的办法解决问题。许多企业会建设自己的云管平台，但是可以理解，其功能未必能超越这些私有云产品。
最近通过不同渠道听了许多相关的需求，有不少企业的组织中已经建设了这样的平台，或者准备建设这样的平台。这个平台就很能体现康威定律，因为提出这种需求的部门，寻求的就是解决自己部门的问题。例如DBA想要一个数据库的综合管理平台，而中间件部门希望想要个中间件的，很多供应商也是积极迎合。可以理解，组织架构决定了软件架构，在自己的职责范围内，不需要也不能考虑太多。
但实际上，运维的任务往往不能按照基础设施、中间件和数据库这样简单的拆解，许多时候需要从业务角度看待问题，更加重要的是多个组织协同时的效率，这时这种割裂的平台就失去了价值。
还有许多企业，依然认为自动化运维平台可以解决问题。笔者早年也主持过几个自动化运维平台的开发，当时的想法很简单，觉得只要将日常的任务封装成表单，就省掉了敲命令的负担。
实际上呢？这条路可以走通，但不是每个团队都能走通。许多这样的自动化运维平台会炫耀支持多么复杂的流程制定，但复杂带来的是难以维护，难以复制，只有将任务抽象，将流程简化，这个路子才能走通。
这里我借用一个隐喻，运维平台可以看作是一个盖房子的机器。这个机器如果使用砖块盖房子，那想要盖一个房子就要设计非常复杂的流程来组合砖块和水泥；如果这个机器使用墙体、门廊这样的预制件盖房子，那流程就会简单许多。许多企业，并没有设计预制件的能力，所以选择了从砖块开始的路线，开始简单，之后越来越艰难，因为每个房子需求都不一样。
那为什么不直接选择成品的预制件呢？很多人很清楚，我所说的就是 Kubernetes 。
前面已经讲了，如果你使用公有云，你完全可以使用云计算厂商的数据库服务，或者是那些数据库厂商的跨云数据库服务。如果你使用私有云，而且对创新没有太多追求，那也可以安心使用私有云的服务；亦或者你是个私有云的大客户，云计算厂商愿意为你提供无微不至的服务，那也不用操心了，让云计算厂商去实现吧。
如果你不属于上面任何一个，如何降低自己的数据库运维工作量。我想举一个我们团队的例子，今年我们团队的应用完全迁移到了 Kubernetes，所以有时间启动一系列新的项目，需要引入 PostgreSQL、ElasticSearch、MongoDB 和 ClickHouse 等数据库，这个任务交给了一个只有半年工作经验的 Kubernetes 工程师，他只花了一两个星期便为开发人员搭建了一套包含上述数据库的测试环境，支撑了开发阶段的需求。诚然，数据库运维还有许多复杂的任务，但是 Kubernetes 确实让基础的任务更简单了。后来，我们团队又整合了其他几个数据库的 Helm Chart，增加了可观测性和自动备份，一个简单的数据库管理平台就出来了。
Kubernetes 管理数据库确实带来了更多的复杂性，但是这已经是各种可能的复杂性中最简单的一个，而且我们也相信有办法将这种复杂性隐藏。例如，我们的 EtudeDB 通过一系列标准的 Helm Chart 降低复杂性，而开源项目 Percona 尝试建立一套统一的 Operator 来降低管理各类数据库的复杂性。
眼花缭乱的云原生图景确实令人生畏，但是令人欣慰的是这些组件并不是泛滥生长，他们很有可能是可以协同工作的。另外，平台工程也是解决复杂性的解决方案。
最后，再提一下存储的问题，实际上有许多解决方案。既然虚拟机的存储不是问题，我相信容器的存储问题也能够解决。
无论哪种方案最终胜出，都是市场的选择，有形的手有时可以加速这一进程，也有可能让答案扭曲，扭曲的危害有多大，只能拭目以待。
其实一直就想写类似的文章了，感觉很多话题想展开说，但是那样就太长了。很希望和大家做更多的交流，有兴趣的朋友可以加我的微信 rocksun21:
- 《黑客》: https://book.douban.com/subject/6860890/
- 《黑客-电子时代的巫师》：https://www.bilibili.com/video/BV1G54y1X7mj/
- 《开源软件崛起》:https://www.bilibili.com/video/BV1Qf4y1m7R3/
- EtudeDB: https://gitee.com/etudedb
- Percona: https://github.com/percona/
- 《复杂性孕育了平台工程》：https://yylives.cc/2023/11/15/how-platform-engineering-comes-from-complexity/