寓言
搬进院子里的机器和长在院子里的大树
老魏的企业软件公司接到一个大客户，要求全部系统部署在客户自己的机房内，数据不能出内网。老魏把公司云上的产品打了一个离线安装包，派了三个工程师出差一周，在客户的服务器上一项一项装好、配通、跑起验收脚本。客户签了验收单，项目交付。
两个月后，客户的运维主管打来电话：系统隔三差五报错，日志显示多个微服务因为依赖的下游服务不可用而崩溃。老魏查了配置：客户机房里的服务器规格不一，有些节点的内存不够，Kubernetes 调度器自动把多个 Pod 挤到了少数几台高配机器上，低配机器反而空着。这套调度逻辑在公有云上运行良好，因为云上所有节点的规格是统一的。
老魏意识到一个本质问题。他们的产品是为云环境设计的——依赖弹性负载均衡、自动伸缩组、托管数据库、统一的节点规格。这些云原生的基础设施能力在客户机房内不存在。他们把一棵云上长大的树连根拔起，硬塞进了客户的院子土里，树还在按云上的方式长，但土壤、水分、风力全变了。
老魏跟团队做了一个艰苦的决定：不回滚到云上，而是把产品在客户机房内重新适配。他们把微服务的健康检查超时从五秒调到二十秒，因为内网延迟比云上高。把自动伸缩关掉，改成固定实例数，因为没有弹性伸缩组。把数据库的高可用方案从云托管切换到了手动主从切换。
适配之后系统稳定了，但运维模式跟云上版本完全不同。云上的运维看的是自动伸缩日志和托管服务的 SLA 面板；本地化版本的运维靠的是人工巡检、手动扩容、硬件故障报修。两个版本的功能一模一样，但运维成本差了将近三倍。
老魏在客户复盘会上画了一张对比表：一行是云原生产品的运维成本组成，一行是本地化部署后的运维成本组成。两个版本的功能相同，但运维成本里多出来的部分，全是「云环境替你做的事现在要你自己做」——硬件监控、网络排错、数据备份策略、灾备演练。
后来公司在售前阶段加了一个标准动作：先问客户部署在云上还是本地，然后给出两个版本的运维成本估算。对选择本地化部署的客户，合同里明确列出需要客户自行承担的基础设施运维项。老魏把这叫做「不让客户把云上的体验当成本地化部署的默认配置」。
年底技术分享会上，老魏总结说：云原生是一套生长环境——土壤、气候、灌溉系统都是云厂商配好的。本地化部署是把同一棵树移栽到客户的院子里，树可以活，但养护方式全变了。如果移栽的时候不重新配土、不调整浇水量、不搭防风支架，树活不下来。